当然纯 keyboard driven 可以 但我相信没人想先 alt+x 启动选单一直按 tab 跳转来设定
或者直接写 xml 设定 完全就是悲剧

@daveh

我指的是你指定其他动作(如开启档案等一些基本操作)是否也要用组合键 组合键与 F1~F12 本身就不高效 然后绑定一个快捷运行连续行为更是麻烦(这是脚本好处) 然后最后指的连设置都不想用鼠标对应你回应的"全程 keyboard driven"
快速启动与 vim 下的命令行模式差非常多... vim 下命令行模式可以指定变量、键盘映射、呼叫命令函数甚至直接执行 vimscript 逻辑 而且都是内建直接呼叫就好 你 run groovy script 可以实现非常多 但就不是内建而且你总要先经过设置这一关 还是得用鼠标

@daveh
组合键不高效 F1~12 距离长 而且考虑到一个快捷多种行为会更低效 甚至我连设定都不想用鼠标

赞同楼主想法 vim 除了原本的使用方式有看点 扩展也简单且灵活 至于编辑器本身没有的功能可以透过外部程序 快捷键数量也十分多 组合键 连续键都可以 会觉得按键冲突本身就有原因 很多扩充很喜欢用全域变量与全域键盘映射 但是在 vim 下这些都是有作用域的 你可以不同缓冲区不同页签下使用不同的设定 不同模式下也有不同键盘映射 vscode 下 tasks 不用说了 这是很差的作法 换是我直接在项目目录下放一个.vimrc 然后启动的时候最后读取 可以根据项目自定义需要的设定 个人都是这么做 至于代码 format 说实话的 vim 本身都不一定需要提供和实作 因为 vim 可以调用外部命令修改当前文件内容并反馈至屏幕上 至于其他编辑器或 IDE 写扩充的方式不用说了 有人爱写就去写 反正我是受不了一个简单的事情搞得太复杂 markdown 的情况则是规范都没统一 要解决也不是不可以 只要你命令行功底高这都是可以解决的 差别在于技能的不同

@darknoll

这是一体两面的事情 写的很丑很难维护也是在卷他人 个人是以有没有恶性找碴为依据

会到一定的程度 为了在往后节省大量时间用来摸鱼取得好的生活与工作平衡 除非有限制难以实现否则都想这么做 既有语言框架和上头想法都是其中的影响因素

重点那些人都不见得开源多少 基于开源但无协议问题都一定要开源全部...

开源本身并没有问题 有问题的是非着作权关係下强迫开源的态度 “你用开源为什么不开源”诸如此类 开源大佬顶多就是讲一下然后自己实现 当然还是有以开源收割开源的协议 但说实话都不一定得用 copilot 是另外一回事

@mingl0280

win 下从第几版开始并不关心 在所有案例上没空格是通例 虽然 win 下有空格的很多 没空格的也很多 比起脚本更常见在于说明文档和影音 好几分可能是楼主应用范围没错 但在几乎所有情况下没空格更好做事 尤其对 shell 来说空格是魔法

@mingl0280

你有看文吗 系统以及大部份应用包内名称是没空格的 你爱看多少例外随你 看过的脚本也几乎没有含空格的名称 win 下倒是看过很多 可能有些人把 win 的习惯带进来 特例当通例

@xz410236056

应用归应用 系统归系统 你看过哪些重要组件是如此的 其它系统不管 linux 是这样

@lolizeppelin
本来就不建议档名有空格

有空格第二个 for $d*改成"$d"*

这问题可以回答

#!/bin/bash

for d in */
do
for f in $d*
do
[[ -e "$f" ]] && break 1
done && echo "Directory '${d%\/}' is not emtpy" || echo "Directory '${d%\/}' is emtpy"
done

@ysc3839

测试起来效能差不多 只是它执行档一直放在很奇怪的位置 例如 /usr/lib/jsc mac 下都有 然后几乎没人把它捆绑成类似 node 的东西(是好处 世界清净了) 然后都很肥

说实话打从心里鄙视这样的 估计不少都混的很好

这东西本来就可以做出来 只是很多 mac 用户连 mac 本身的东西都不了解 不是整天 app store 就是面向履历和风向编程

@06_taro
你不缺不代表别人不缺...

当然会 只是大厂通常怕的是大厂 小厂大小厂都怕
而且这类套件多数都不会写的太直观简洁 甚至还有缺陷 别人抄也有成本
至于比较接近底层的只能说门槛比较高 多数人看不太懂的 不懂就不能修改应用了 所以一堆上层应用会刻意建立门槛的原因就在这 这样搞才显得更上游 稍微有点类似有新人进来才能进管理阶级的意思 没钱没势又不想搞乱代码那只有闭源一途 不然成效只能说非常低 帮助穷人是做善事 那帮助有钱人呢? 多数是韭菜

@seth19960929
我说的是基本的东西 剩下的多花时间都可以完成 效能好好维护 毕竟也不能讲的太死 保守估计 这些框架本来就一堆喷点了 别人也不是做佛心的 肯定不会做的完美 一群人开发跟一个人开发本来就不是一样的 来回沟通要时间 也不是一直都有空閑时间处理 然后可能后面还有人下指导棋 甚至商业考量 blahblahblah
写的好过这些东西不难 大家都往完美迈进那就是内卷