skywind3000 最近的时间轴更新
skywind3000's repos on GitHub
Shell · 11754 人关注
awesome-cheatsheets
超级速查表 - 编程语言、框架和开发工具的速查表,单个文件包含一切你需要知道的东西 :zap:
Vim Script · 1859 人关注
asyncrun.vim
:rocket: Run Async Shell Commands in Vim 8.0 / NeoVim and Output to the Quickfix Window !!
Vim Script · 920 人关注
asynctasks.vim
:rocket: Modern Task System for Project Building, Testing and Deploying !!
C · 350 人关注
avlmini
AVL implementation which is as fast/compact as linux's rbtree
C · 232 人关注
clumsy
A fork of jagt/clumsy to add bandwidth limit
C++ · 132 人关注
BasicBitmap
Simple and high-performance and platform independent Bitmap class (34% faster than GDI/GDI+, 40% faster than DDraw)
C · 118 人关注
AsyncNet
AsyncNet
Python · 79 人关注
CloudClip
Your own clipboard in the cloud, copy and paste text with gist between systems !!
66 人关注
awesome-gamedev
:video_game: A list of Game Development resources to make magic happen.
Python · 40 人关注
collection
没地方放的代码,懒得开新项目了,放这里吧。
JavaScript · 37 人关注
atom-shell-commands
Execute user defined shell commands (looking for new maintainers)
Vim script · 27 人关注
asyncrun.extra
Extra runners for asyncrun to run your command in Tmux/Gnome-terminal panel, xterm, Floaterm and more.
C · 16 人关注
asmpure
Asmpure is a library written in C for compiling assembly code at run-time
13 人关注
abandonware
Abandonware Collection
10 人关注
awesome-c
Continuing the development of awesome-c list on GitHub
6 人关注
awesome-fish
A curated list of packages, prompts, and resources for the amazing fish shell
C · 6 人关注
cannon
Cross Platform Network Framework
C · 6 人关注
crtzero
Zero Dependent on CRT (libc)
CMake · 5 人关注
cmake-examples
Useful CMake Examples
Python · 3 人关注
asyncredis
Async Redis Client for Python
Vim Script · 3 人关注
colors-from-neovim.vim
:rainbow: Backported NeoVim Colors for Vim
3 人关注
cs144
CS144 website
Java · 2 人关注
asclib
Basic Java Network Lib
2 人关注
awesome-vim
The Vim plugin shortlist
C++ · 1 人关注
adplug
Hardware-independent AdLib sound player library
1 人关注
awesome-c-1
A curated list of awesome C frameworks, libraries, resources and other shiny things. Inspired by all the other awesome-... projects out there.
1 人关注
bgfx
Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.
Vim script · 1 人关注
bufferhint
A handy buffer switcher for VIM
CMake · 1 人关注
cmake-scratch
Cmake Templates
0 人关注
cgi
Useful CGI Scripts
skywind3000

skywind3000

V2EX 第 28805 号会员,加入于 2012-10-23 18:20:07 +08:00
分享篇文章:为什么我会使用 Vim ?
  •  7   
    Vim  •  skywind3000  •  2022-09-02 21:31:17 PM  •  最后回复来自 FrankHB
    195
    asyncrun 发布六年后的更新
  •  2   
    Vim  •  skywind3000  •  2022-06-29 13:47:50 PM  •  最后回复来自 linuxyz
    16
    更符合直觉的 Snippet 输入方式
    Vim  •  skywind3000  •  2021-02-08 01:56:10 AM  •  最后回复来自 IgniteWhite
    7
    如何用 C++ 写一个软件渲染器?
  •  2   
    C++  •  skywind3000  •  2020-08-18 15:06:18 PM  •  最后回复来自 skywind3000
    6
    Vim 中缺失的任务/构建系统 - asynctasks.vim
  •  2   
    Vim  •  skywind3000  •  2020-02-14 20:43:25 PM  •  最后回复来自 kevinhwang
    18
    z.lua - 新增 fzf 快速向后跳转
  •  1   
    Linux  •  skywind3000  •  2020-02-10 17:14:11 PM  •  最后回复来自 skywind3000
    3
    AsyncRun 新增:在内置终端内执行命令,调试程序更加方便
  •  2   
    Vim  •  skywind3000  •  2020-02-11 04:23:11 AM  •  最后回复来自 skywind3000
    2
    Vim/NeoVim 内置终端调教记
  •  3   
    Vim  •  skywind3000  •  2020-02-03 15:27:40 PM  •  最后回复来自 MrUser
    10
    Borland/Turbo C++ 主题风格的目录系统(Vim 8.2 专用)
    Vim  •  skywind3000  •  2020-01-25 22:26:34 PM  •  最后回复来自 czjackjin
    10
    skywind3000 最近回复了
    2022-08-30 02:03:23 +08:00
    回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
    @haoliang 大部分认同。

    > cli 下的 vim 受限于 terminal 不能使用所有按键组合、不能显示图片、也没法在 split window 中预览渲染好的 markdown

    后面都是对的,就是个不能显示图形和不同字体的问题。至于第一条 “不能使用所有按键组合” 是不对的,Vim 提供灵活的机制让你定义每个组合键的键盘码,大部分人不会初始化而已:

    https://github.com/skywind3000/vim/blob/master/plugin/altmeta.vim

    showkey -a 看看键盘码,然后像我上面这样设置一下就行,这样的设置允许你设置任何组合。

    Vim 8.2 还引入了 modifyOtherKeys 的特性,只要终端支持,任何组合键都没问题。
    2022-08-30 01:55:19 +08:00
    回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
    @daveh 你喷了 vim 一半天也没喷到点上,看看 109 楼是怎么喷的,那才叫专业喷法,可以学习一下。
    2022-08-30 01:53:34 +08:00
    回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
    @felixcode

    > 其实楼主的帖子没说 VSCode 或其它 IDE 有什么不好。
    > 但很多人一定要通过抨击 vim 的不好,来显示出自已用的 IDE 多么强大,用自己的方案多么合理。

    是这么回事情,我向来只见过 vimer 们安安静静的在自己的板块下交流心得,从来没见过哪个 vimer 跑到大 JB 或者其他 IDE 板块下面去劝退,反倒是大 JB 和其他 IDE 的人按耐不住,经常跑了 vim 板块里踢馆,来说 Vim 都是垃圾。

    他们的大 JB 和 IDE 那么好,自己用得爽不就行了,经常跑来 vim 板块里气急败坏的闹事和劝退为个啥?
    2022-08-30 01:38:57 +08:00
    回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
    @ColorfulBoar 70 楼,不要出来丢人了。

    计算机分支技术那么多,从来没见过哪个领域,像某些 C 艹 er 一样喜欢卖弄的,急着想给人当老师的。看了下你的回答,说你是语言律师都高抬你了,比你有水平十倍的人都不会像你这么爱卖弄。

    ## 指针

    > 居然还指着一个内部 private/protected/public 乱飞还藏着个 virtual destructor 的 class 讨论跨二进制

    我好心提醒你 xxx_ptr 跨二进制要挂,你来跟我说我写的 BasicBitmap.cpp 不能跨二进制,合着我哪句话跟你说过,我说了句 “跨二进制” 那么我所有类都要跨二进制了?你脑袋是不是进水了才会理解成这样?

    BasicBitmap 本来就不是为了跨二进制实现的,天生就是为了继承设计的,它后面可以继承 GdiBitmap, GdiPlusBitmap, DDrawBitmap ,提供出不同风格的 Bitmap 来,

    > 行还是回去复习一下 COM 是怎么搞的吧,Essential COM 第一章就行

    COM 里不就是依靠 Release 代替析构保护跨二进制不同堆的析构释放冲突问题么,老衲二十多年前写 COM 时看一眼就明白了,用得你来教?你哪年学会的 COM ?写过多少 COM 相关代码啊?

    > 裸指针手动释放配合多个退出路径是件多么可怕的事情,在 goto 和 goto 到的进行集中错误处理的地方中间会发生什么可怕的事情

    现代程序,内存分配失败就应该 assert 了,还 goto 多路径释放啊?即便要处理,也只是构造和析构里刻意注意下罢了,这种你都写不来么?

    > 它最后(在你不手动塞进去奇怪的 deleter 的时候)生成的代码真的和裸指针有区别吗(当然前提是后者用对了并确实持有所有权)。

    生成代码是一致的,但是我也不想到处用,为啥?根本不是性能问题,有些人干什么事情都爱带套,明明就是只有这个类用的资源,构造里产生,析构里删除,你觉得非要套个 unique_ptr 的套套你才舒服,我也没说你不对,但是干什么事情都头上都要顶个套套,更多人会觉得浑身不自在,就像明明没下雨,有个二百五非要穿一件雨衣在操场上跑步一样,凡事有利有弊,到不说说不能跑,只是觉得这么搞有点二,有点书呆子的感觉。

    > 再思考一下什么人会在别人指着拿指针传进去的字符串的时候第一个反应不是证明这里不适合用(w)string_view 。

    你以为代码只在你一人的机器上编译吗?有些象牙塔里 C 艹 er 就是喜欢对着新标准就高潮,从来没考虑过客户的编译环境,因为他们很少做真实交付的项目,不是说新标准不好,string_vew 的 17 标准里也有我想用的东西,比如 if constexpr ,可以让我的代码编译期做判断提升性能,但是我忍住没用了,改用模板和宏去模拟,为啥?

    不是迫不得已非必要不升级,我想尽量维持 14 以下的标准,因为 PyStand 本来就是辅助 Python 部署的一套库,我希望用我项目开发的人至少可以在 xp 下发布他们软件,并且大概率手上的编译器都可以编译。

    这些工程领域的侧重和思考,真的不是某些甚至校园都没出过,正儿八经的项目都没做过几个小儿能理解的啊。

    再,即便 14 里有 string_view ,我也不想用,string_view 这种东西我看不上眼,正式项目里我用自己仿照 Qt 实现的 QString ,std::string / string_view 这种东西同 if constexpr 不是一回事情,我真看不上,QString 有多强,你可以学习下:

    https://www.zhihu.com/question/54664311/answer/140476787

    大道至简,这个 PyStand.cpp 很简单,我不想引入太多依赖,这么简单的代码,这么简单的指针用法你都 hold 不住,非要带一个 string_view 的套套,当我没说。

    > 另外正常人也别写这种 string 转 wstring 都能搞得一坨 magic number 乱飞的代码,不会转可以塞进 std::filesystem::path 让它自己转

    又来,我跟你说了我希望尽量限制标准在 14 及以下,你完全 get 不到我的角度。

    有一种虫,春天出生,到了夏天就死掉了,你跟它说冰是怎么一回事情,它是永远不可能明白的,所以叫 “夏虫不可语冰”,我觉得写代码让更广泛的编译器支持我的代码的意义,比只知道无脑飙 C++ 版本更有意义。算了,没做过啥真实交付项目的人,说一百遍他都领会不到。

    > C 风格指针恶心人的程度已经是罄竹难书了,这连一半都不到

    觉得恶心的话你去跟标委会那帮子鸟人提案,让他们把指针从 C 艹 下个版本里删掉啊,我乐见其成,看看他们听你的不。

    有些 C 艹 er ,成天听到的名词不少,可实际深入点的经验全无,拜托你读两个真的工程上大量使用的项目代码再来这瞎 BB ,计算机领域很多,别总在你熟悉的那个领域里打转,真实的世界永远不是象牙塔那么的简单和纯粹。

    ## inline

    > 如果后面的读者不想变得这么搞笑:inline 是让你处理 one-definition rule 的,或者再简化一点,inline 的意思是「你可以就把定义写在这」永远忘了内联优化这回事

    所以说你从来只看得到一,看不到二三四。BasicBitmap 里,老衲前面已经给 inline `#define` 成具有 always_inline 属性的宏了,你是眼睛瞎了看不见,还是不知道什么叫做 always inline / force inline 啊?

    ## 底层

    > 自行搜索 abstract machine 找个 talk 听一下 ... 还做着自己真的控制了编译出来的汇编的春秋大梦呢(顺便这种人恐怕一半不知道 CPU 上最后执行的不是一条条的汇编指令),实在不信找份 C++98 的文档(我感觉 C89 都行),搜一下 volatile 是干嘛用的。

    计算机分支技术那么多,从来没见过哪个领域,像某些 C 艹 er 一样喜欢卖弄的,喜欢好为人师的,volatile 我二十多年前的代码里就有了,要你教么?

    程序员别成天只知道代码,别满脑袋都是技术,走向社会要吃亏的,有空多了解下技术以为的人文知识,荀子曾说:“故不问而告谓之傲,问一而告二谓之囋。傲、非也,囋、非也;君子如向矣。”,看不懂的话我给你翻译一下,荀子他老人家说:“别人没有问就去告诉的,叫做急躁,别人问一个问题而告诉别人两个问题的,就叫做唠叨”。

    动不动就 “你看看 A 去”,“你知道 B 吗?”,生怕别人不知道他懂一般,在荀子口中都是君子为人需要避免的东西,计算机领域博大精深,谁都有不知道的东西,动不动就想教别人一下,在你小圈子里没问题,出了圈还这么着,不能教而强教,担心闹笑话。

    > 顺便看一眼 strict aliasing rule ,懒得搜可以直接读 https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html 这个系列,再看看 C 语言大师们起手-fno-strict-aliasing 然后觉得自己特懂底层。

    拉倒吧,就你懂,别人都不懂,得了吧? strict aliasing 鬼东西,我几年前就喷过了:

    https://www.zhihu.com/question/19707376/answer/1174526354

    上面那个 volatile 是合理的,因为编译器做优化时无从得知是否有另一个线程在访问同一个变量,因此如果计算的结果出于优化目的暂时不落内存而呆在寄存器里,那么另一个线程就无从得到最新值了,这是非常合理的设计。

    但是 strict aliasing 这种傻鸟设计的东西不一样,这属于当年标委会那帮子鸟人设计出来的缺陷东西,全部遵守的话,全部遵守的话,让那帮象牙塔里的人来用当年的标准(不用 bit_cast 这些 20 里打补丁做裱糊的东西),他们都很难写出正确的 memcpy ,这不搞笑么?

    所以不管 vc, clang 这些广经实践检验的编译器知道对这条要留神处理,gcc 早年版本也还好,只有最近几年的版本不知道是不是眼红 java/clang 的优化牛逼,自己又没本事进一步优化,才会这么丧心病狂的拿着这条标准里的鸡毛蒜皮出来最大化的恶心人。

    语言设计要为实践服务,不用反过来,标准也不用跪舔,有缺陷就要承认,手动加 `-fno-strict-aliasing` 就是要帮那群鸟人做一个生理上的结扎,让他们不要出来祸害人间。你这么看不上 `-fno-strict-aliasing` 的话,把你电脑里所有用到这个的项目干掉,你看看你电脑还能不能启动。

    ## bonus

    > 我看到图形引擎四个字终于想起来了……后面的人请打开 。。。跳到 DirectX 那一节,啊 2015 年……彼时 Metal 、DX12 、Vulkan 这一批现代图形 API 都已现世,早就翻来覆去讲清楚了传统状态机式图形 API 是一件多么恶心人的事情,在这个时间点居然能舔得下去 OpenGL……我已经说不出来话了,哪位心理学大师能帮我分析一下为什么一个这么热爱《底层》《精细控制》的人能喜欢上 OpenGL 。

    拿着我一篇 2015 年写的旧文说我不懂 2015 年刚出的 Vulkan ,合着你 2015 年就用 Vulkan 写过程序?那我拜服你了,vulkan sdk 1.0 直到 2016 年才发布,你真牛逼。

    象牙塔里的人就是这样,听过的名词一大堆,现实的项目没碰过,说起图形能谈论的就是几个 API 名称,除了这些大名字你还能谈论啥呢?

    你只有本事把评论区六年前和我抬杆的人的 "状态机" 拷贝下来和我说,任何 API 都有不完美的地方,状态机是 OpenGL 不完美的地方,但是编程里不是没法处理的,事实上游戏和图形里的 render states 一般都比较稳定,同一批次的渲染指令一般都用类似的 states 执行,程序稍微注意下是很容易处理的,不是什么过不去的砍,后面新的渲染技术诸如延迟渲染和 shadow map 这些需要多个 pass 的,会频繁大量的切换渲染状态,2D 界面和 3D 物体的渲染也会大规模状态切换,这时,不管 Dx 还是 OGL 都有对应 API 来一次性保存和恢复 render state ,大部分引擎都会有一个 render context 的封装类,来处理这些大规模状态切换。

    至于我不喜欢 DirectX 喜欢 OpenGL 的原因前面我也给出理由来了,D3D8 以前,DX 基本上是被 OpenGL 按在地下吊打的,D3D7 有时甚至做不到精确渲染,但是 OpenGL 没问题,可是微软出于商业目的故意打压限制 Windows 下的 OpenGL 发展,这个事情恶心到我了,尽管后来 DX9 开始做的不错。

    ## ?

    > C++当然不止一种写法,但所有主动写 C with class 的 100%连基本的东西都没弄懂,永远在传播错误的认识。

    不要生活在真空世界里了,C++ 比你厉害十倍的人我也经常和他们交流,真的懂 C++ 的根本不会像你这么阳春白雪。

    你所想要消除指针的想法很美好,标准更迭那么多年了,年年有人骂指针,又没本事把指针从新标准里删除,所以如果你一定追求,大可以换个语言,不用写 C++。

    某个领域的成功经验,换个领域就完全不适应了,而大部分人却只会把自己特地环境里成功的经验总结成万古不变的真理,进而在环境改变后碰到挫折还不能自知。

    比如 GUI 领域的著名项目,Qt / wxwidgets ,看看他们是不是指针到处飞?语言领域的 v8 里面是不是到处飞指针?音视频领域的 webrtc/srs 这些是不是到处飞指针?只有局部地方才会有限制的用一下 xxx_ptr ,图形领域的各种 3D/2D 引擎 Ogre3D / Unreal / urho3d 哪个不是飞指针?他们不懂引用计数?他们懂啊,局部用,用也是用自己实现的,看不上你 std::xxx_ptr 。

    系统开发领域唯一的 C++ 内核 Fuchsia ,它是用了 std::shared_ptr ,但是用的也是非常节制和有限,大部分地方还不是在飞指针。

    为啥?就是你一直在笑话的“精确控制”,你但凡读一两个上面这类各个领域的著名项目,你都不会这么肤浅的尬笑了。你觉得飞指针就代表没有生命期和所有权管理么?非也,给个项目都有明确的所有权和生命周期的管理方法。

    实在没时间读上面的代码也没关系,Qt 解释过自己为啥用裸指针,以及他的所有权管理:

    https://doc.qt.io/qt-5/objecttrees.html

    Rust 程序员给 qt 做 port 的时候都能意识到:

    > Qt has its own ownership system that must be respected

    连天天把所有权视作生命的 rust 程序员都能 respect ,不明白你个 C 艹 er 在这里一副要秒天秒地秒空气的样子干嘛?

    工作上 C 艹 写的比你牛逼的人多的是,我很尊敬他们的,他们有学术素养又有成熟的工程意识,还能平实的和人讨论问题,可他们没有一个像你这样摇里晃荡的摆来摆去,像孔雀开屏一般,生怕别人不知道你有几斤几两。
    2022-08-28 02:57:28 +08:00
    回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
    @ColorfulBoar C 艹 er 怎么到处都喜欢好为人师,不要来规定 C++ 代码该怎么写,我爱怎么写怎么写,BasicBitmap.cpp 就是 c with class ,怎么着了,十多年前写的代码,保证 c++ 98 也能编译,你没见路径前面的 vintage 单词么?

    1 ) stdio.h 有啥问题?我爱用 printf 。
    2 ) main(void) 怎么了?写着好看。
    3 )参数里 const wchar_t * 再正常不过,xxx_ptr 别乱用,接口部分如果跨二进制你还给我写一堆 xxx_ptr 的话你不怕死的很惨么?
    4 )我本来就不喜欢写 auto ,auto 你写的时候爽,读的时候痛苦。
    5 )截图里哪里有 inline ?你看花眼了吧?

    你只知道 xxx_ptr 不理解它的问题,我早就回答过特定的地方限制它的原因:

    https://www.zhihu.com/question/33084543/answer/2197934746

    不同层次的应用使用有不同风格 C++ ,你写上层业务怎么爽怎么来,越靠近底层,你会发现越是要控制,你只在一个领域开发,当然只觉得一种写法合适,你多接触几个领域就知道不同了。

    越底层的越是要精细控制,你看看 v8 核心代码里是不是到处指针飞?各种图形引擎里是不是指针飞?某些地方要管理资源也是自己做的引用计数,为啥?想过没?

    不要觉得天底下的 C++ 就该一种写法,是你接触的项目类型不够多,就是那一类,好好写你的代码吧,别一天到晚装语言律师到处教别人做人,就跟有些中国人特别爱给其他中国人指正英文水平一样,招人嫌,人家水平更高的 natvie 都没那群鸟人烦。

    至于截图里的 PyStand.cpp 本来就是个随意的小项目,我非常清楚我在干什么,我打 int 可以少打两个字符,传 const wchar_t * 是因为不想四处带个套。

    最后,Vim 早就支持 LSP 了,你不知道么,我上面的类型就是 clangd 推导出来的。
    2022-08-28 00:37:28 +08:00
    回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
    @daveh 上面给你 append 了一段回复你。
    2022-01-12 22:53:41 +08:00
    回复了 skywind3000 创建的主题 Vim asyncrun 发布六年后的更新
    @zbinlin 你可以定义成一个命令:

    command! -nargs=0 AsyncBexec AsyncRun -program=shebang -mode=term -pos=top $(VIM_FILEPATH)

    然后用 :AsyncBexec 代替你的老命了
    2022-01-12 22:50:17 +08:00
    回复了 skywind3000 创建的主题 Vim asyncrun 发布六年后的更新
    @zbinlin 更新一下,我给你加了一下,通过 asyncrun 的 “命令修改器” 机制来完成:

    :AsyncRun -program=shebang -raw $(VIM_FILEPATH)
    :AsyncRun -program=shebang -mode=term -pos=top $(VIM_FILEPATH)
    2022-01-06 12:31:27 +08:00
    回复了 skywind3000 创建的主题 Vim asyncrun 发布六年后的更新
    2022-01-06 06:33:53 +08:00
    回复了 skywind3000 创建的主题 Vim asyncrun 发布六年后的更新
    @haoliang 这和你开发用的语言有关,比如你如果是开机启动个浏览器,然后就一直改代码,刷新浏览器,那么确实没有用武之地,你如果开发需要频繁编译,或者执行的程序,那你一看就知道用在哪里了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2483 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 05:26 · PVG 13:26 · LAX 21:26 · JFK 00:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.