背景

[集智]注意力与知识管理群

中大家经常就一些工具产生各种讨论, 俺一向的标签是:

  • Python
  • Pythonic
  • Leo

其它还好, 有广泛群众基础, 这个 Leo 就经常引发嗯哼

引子:

pimgeek-知识管理工具研究者: 插一个技术提问. . .

  • @大妈🙊Zoom.Quiet LeoEditor 的节点支持类似 {{ var }} 这样的模板语法吗?
    • 我知道 << section >> 这样的用法,还有 valuespace + jinja 的方式, 不知还有没有其它实现方式?[疑问] '
    • << section >> 这种用法是 LeoEditor 内置的实现方式
    • {{ var }} 这种用法是 LeoEditor 插件的实现方式
  • 我就是希望定义一些可填充的内容,把这些内容从代码主体中抽取出来,这样我编辑起来方便. '
    • 有些内容,比如网页里的作者信息等,一次编辑后反复引用. 修改时也方便.
    • 专业的 Web 开发者应该是把这些代码拆成多个文件来管理. 我现在尝试用一个 LeoEditor 的大纲文件来管理. '
  • << section >> 的用法也是类似的,只不过它必须是模板节点的子节点. '
    • 这样不必对每个节点都执行特殊操作,最省心. '
    • 如果需要复用比如 html-header 中的信息,我可以利用 clone 节点的方式. '

tomz-没有褒贬: 发现leo把tangle命令去掉了. 只能命令行输入tangle. 没有尝试成功怎么用尖括号引用父节点. 找不到文档了. ' noweb和org这种没有outline结构的软件就能任意引用任何节点. ' tomz-没有褒贬: 对啊 原来用tangle命令就能引用父节点 等于是全局变量 ' tangle才是真正的noweb方式 现在只能子节点有了局限 '

pimgeek-知识管理工具研究者: @tomz-没有褒贬 我昨天已经实现自己的想法了,虽然没有 tangle 没有全局变量,可能会稍微麻烦一些.

  • 我现在是这样,如果有需要被反复引用的代码段 S,我会先放在一个专门收集这类代码的大纲节点下.
  • 后面但凡有代码 X 需要用到时,我就在 X 下方创建一个 S 的 clone 子节点,然后在 X 中使用 << S >> 引用之. 😄 '
  • 如果我发现 S 代码段,暂时对 X 没有帮助了, 我也不用把这个 clone 节点删除, 只要把那个 << S >> 从代码 X 中移除掉就可以了 😎 '
  • 所以 Leo Editor 的 clone 节点是个好东西啊 [耶] '

大妈🙊Zoom.Quiet: 才发现? 俺宣传了有14年了...没人相信, 这是最好的重构姿势... '

  • pimgeek-知识管理工具研究者: 不是我不相信,而是以往的开发需求没被明晰化,更早以前则不知道 Leo Editor 😂 '
    • 2016 年关于 Leo Editor 的讨论 '
    • 理论上可以把个人的所有开发代码都这样管理起来:
      • 网上发布用 Git, 本地管理用 Leo,
      • 互不干扰
      • (Leo 大纲可以自动生成带有特殊注释的代码文件, 文件发生变化时也能同步回 Leo 里 )互不干扰.

𝙰𝚣𝚎𝚛𝚒𝚕: 这是大妈的上古神器系列的... '

大妈🙊Zoom.Quiet: 是也乎 ╮(╯▽╰)╭

@pimgeek-知识管理工具研究者  --> 那都是老黄历了

现在 Leo 有了更好的算子
    ~可以不污染输入又确保双向感知了~ '

pimgeek-知识管理工具研究者: 我集中问一下:

    1. 有什么比 @file 更好的方式, 可以双向感知?
    1. 有什么比 << section >> 更好的方式, 可以实现代码段引用? '

' 大妈🙊Zoom.Quiet: 代码引用 --> 这是高德纳原创发明~比宏直觉又简洁~含自注释~ 多用~没毛病 '

pimgeek-知识管理工具研究者: @file 节点我去看文档, 但是问题 2 我真没找到, 可能我搜索方式不对, 昨天至少花了 3 个小时找替代, 就是没找到. '

  • 大妈🙊Zoom.Quiet: Directives Reference — Leo 6.0 documentation
    • 之前是用 @nosent 替代 @file 的
      • 后来找到自动 diff 并双向合并技术后
      • 就有了 @auto @clean
    • 一次性将 混入/出 时依赖的标记文本从目标文本中清除了 '
  • 所以, 作为 Leo 老用户, 从来不看官方文档,
    • 导致一直用老经验使用效率有问题的流程...
    • 那么, 推而广之, 可能其它工具也都有类似问题存在//// '

' 大妈🙊Zoom.Quiet: ' pimgeek-知识管理工具研究者: 大多数文档中的例子和提问/设问相对较少, 如果能多一些例子和提问/设问就好多了. '

看 FAQ ....

官方文档很多都是从代码自动生成, 
难免呆板,
所以, FAQ 中有灵活自然的问答...
甚至于, 都是开源项目哪, 
你哪儿不舒服, 问哪.... '

pimgeek-知识管理工具研究者: LeoEditor 似乎没有规定源码的组织方式,如果要批量导入,可能还是先在自己头脑中预先想好一种结构,而不是依赖它的"内置结构" ... '

@SML 似乎不行,他的大纲树 和 硬盘的路径树 是两个东西

断言:

SML: 嗯嗯 所以不太适合开发flask这种组织好的工程项目',更适合学习,归类,阅读代码,或者开发小型项目 '

额,大家可能误会我意思了 ' 我并不是批判leoeditor ' 他确实不适合,类似laravel,flask这种成熟的工程项目开发 ' django项目的文件超过数百个了 ' 连批量导入都不支持... '

我明白你说的,就是用大纲的形式串起来,当做模板语言的使用 ' 这个我清楚,leo的思想是想以类,或者组件为单位 ' 这不就是 前端的经常用的组建化开发 或者模板语法么... '

@SML 这个....作为 ide 使用啊 ' 你可以尝试一下,用它来开发django,或flask 基本是不可能的 '

大妈🙊Zoom.Quiet: 该批就批~俺又不是 Leo 厂商代理~

  • 问题是不说问题 --> 只给大家你的方案... 没法儿聊啊~ '
    • 就算是ide 也和批量导入文件无关啊 --> 你想干什么?真正的? '
    • 关键为什么大家习惯性讨论问题的某个方案 --> 而不讨论问题本身呢?
    • 批量导入工程是为什么啊? '
  • 俺用 Leo 14年了~
    • 从服务端 web server / DevOps 管理/数据分析~到 chrome 插件开发... golang 单体服务 --> Qt 桌面应用... bottle dango flask ....
    • 基本上凡涉及文件越过三个的都用 leo 管理了...
  • Leo 没有自动重构
    • 没有自动跳类定义...
    • 没有您依赖的一切 IDE 功能~
    • 但并不影响开发任何想开发的软件~
  • 因为...
    • IDE 从 TurboC之后俺再没用过任何一种...
    • VSCode 也关闭或不用任何 IDE 特有功能...
    • 所以... 没理解你说的不合适在哪个功能上? '
  • 俺通过 Leo 管理的文件过千了... '

SML: 编辑哪个就导入哪个...好吧 你解答了我的疑惑 '

pimgeek-知识管理工具研究者: '我:如果想把手头现有的,已经用传统项目结构组织好的代码,转换为 Leo Editor 的"树状网结构",那可能是一项浩大的工程... 与放弃 pyCharm 转投 VS.Code 那种变化相比,肯定是不一样,要麻烦的多. ' ' SML: 这个我清楚,leo的思想是想以类,或者组件为单位 ' ' tomz-没有褒贬: 不是类和组件为单位 单位可以是一个函数其中的几行 ' 如果不是说代码内部的组织 那就是说对文件之上层次的组织了 ' 将几行作为单位 等于是为这几行做了一个注释 同时就将这几行折叠起来了 '

大妈🙊Zoom.Quiet: 也不是~

  • Leo 可抽象管理的 note 从几行到几个文件夹... 都可以~ '

' SML: 嗯嗯 就是想以 snippet 为单位吧 '

大妈🙊Zoom.Quiet: 更加不是~~~~ '

  • 如果你写过小说就懂了 '

@tomz-没有褒贬: 文学编程就是让代码更整齐更帅 😂 ' 换个词 叫一目了然 '

是也乎,( ̄▽ ̄)

Yes and Not;

文学化编辑器, 正好不怎么关心最终输出的代码是否整齐/帅

  • 但是, 一目了然, 的确是真的...
  • 只是, 只针对作者本人...
  • 为什么这么说 '
    • @pimgeek-知识管理工具研究者 发现并研究以及尝试整合的,也从无一个主流工具/软件,
    • 为什么?原因相似...
  • 可惜, 世人从来不关心自己被浪费掉的时间和精力...
    • 一脑门子 WYSIWYG 要求,
    • 全然无视了在计算机发展过程中, 最宝贵的从来不是视觉要求,
    • 而是思想要求 '
  • Django 或是 Flask 工程, 之所以, 会有多个目录和很多文件;
    • 是框架本身引导和要求的?为什么?
    • 因为框架是领域工程经验集成, 要求我们必须按照人家的工程经验走...
    • 凡是上点儿规模的工程, 一个共同经验就是:
      • 目录即系统架构
    • 目录结构以及命名以及文件分布约定本身,
    • 就决定了系统依赖/功能/数据/调运/... 内部架构;
  • 但是, 正如小说撰写, 虽然最终是由/字/词/句/段落/章节构成了小说,
    • 可小说真正想传达的意象, 叙述结构,
    • 却正好超脱这些最终产物的,
    • 而是萦绕在作者头脑内心深处的另外结构;
  • 当初为了和 C 初始人们提倡的结构化编辑叫劲儿,
    • 高老爷创造的文学化编程,
    • 就是抓住了这一更加 Bigger 的思想,
      • 完成了专用 DSL -> WEB 以及对应方言 CWEB;
    • 可以在 变量/语句/函式/类/文件/目录 之上,
    • 描述工程师对系统真正的理解和结构;
  • 但是, 为什么现在 "所有人" 用的各种 IDE 都没有这种支持?
    • 原因非常简单, 因为 IDE 所包含的工程思想, 是最平庸简单的,
    • 是能为最大多数快速理解并使用的,
    • 甚至于连商务人员都能理解和宣传的;
  • 可惜, 编程是门手艺活,
    • 每个手艺人都有自己的个性和习惯,
    • 真正注意到自己习惯和个性的手艺人, 一定是从工具开始自行构造的;
    • 这也是为什么 Plan9 小组, 大家使用的 ACM 是针对三键鼠标优化的,
    • 所有功能集成在中键点击菜单中,
    • 根本不兼容任何 IDE 的主要功能;
  • 即, 编程, 这么私人的事儿,
    • 如果工具不能充分匹配或是定制匹配,
    • 那么, 就只能被迫将自己训化为现有流行工具包含的工程思想/编程习惯/思维...
    • 当然, 多数人将之视为理所当然, 完全无视了这过程中,
    • 自己被主动无形中格式化掉的个性和思想;
  • 简单说, 商业社会中, 主流产品一定不是最优的,
    • 毕竟主流产品一定得是利润最好的...
    • 所以, 美军手中武器一定是最便宜的那种...
  • 软件行业更加是:
    • XP 统治PC 多年,
      • 为什么最后还是给放弃了?
    • JAVA 这么多人吐糟, 连创始人都退出维护团队了,
      • 为什么, 照样是商用软件C位选择?
    • 但是, NASA 照样用古老的LISP ?

...

' tomz-没有褒贬: leo本身的代码就是例子 leo是吃自己的狗食的 '

文学化:

' 𝙰𝚣𝚎𝚛𝚒𝚕: 印象中 大妈貌似还认识 Leo 编辑器的开发者老爷子吧 '

大妈🙊Zoom.Quiet: http://0.zoomquiet.top/pychina/PyCon2013China/PyConChina2013-EKR-final-v2.mp4

<-- 是也乎 ╮(╯▽╰)╭

作者本人介绍 Leo 可参考理解... '

@tomz-没有褒贬 leo所做的工作只是把一个文件的一些行折叠为一个代码块 所以我觉得可以用emacs的folding程序代替 先写文档后写代码我没有尝试过 '

是也乎 ╮(╯▽╰)╭

正好理解反了~ '

俺也没尝试过... 文学化编辑... 洽洽和文档无关~ ' 也都关联不大 --> 文学化编辑和以往结构化编辑是根本性不同的思想 --> 最大阻碍是思维惯性... '

分析

一定要找一个生活化的案例, 可能就是:

  • 刚刚来到中国的西方探险家, 一定无法理解为如何用筷子叉起食物?
  • 被 IDE 训化的绝大多数程序猿,
    • 早已忘记了写代码时自己是怎么思考的
    • 而是替之以 IDE 要求我们如何去写的
  • 这样其实, 并没什么不好
    • 毕竟, 公司不关心, 代码是怎么生产出来的
  • 这就好比, 被卖猪仔到美国的华工
    • 如果想融入当地
      • 要作的事儿, 可能就是丢指筷子,剪指头发
      • 永远不再吃米饭/炒菜, 在一切细节上伪装成周围的人
      • 直到最后从思想上也同化
    • 才可能被美国人视作长的实在丑的人
      • 而不是吃死老鼠的黄种鸡
  • 其实, 类似 Leo 这样设计思想和 IDE 完全不同的编辑环境非常多:
    • 神之编辑器 ~ Emacs
    • 编辑器之神 ~ Vim
    • 行编辑器 ~ le
    • ...
  • 那么多尝试吧, 找到自己最喜欢的那种...

回顾

其实, 俺当年也用了将近一年, 才慢慢明白过来的:

其实, 和其它全新技能一样,

  • 先熟悉工具内置功能
  • 然后, 结合具体任务
  • 完成基本行为的肌肉记忆后
  • 才可能进一步完成以往用 IDE 才能完成任务的文学化再流程...

很多时候, 和 IDE 的感觉有点儿象:

  • 手工绘画和打印槐打印一张图片的差别
  • Leo 是响应自然的思考和尝试过程
    • 将最终代码/文档的形成从目标形式中抽离了
    • 以提纲为主要结构
    • 每次时应对 node 中非常小的几行内容
  • 不象 IDE 无时不刻在整体分析/提醒你应该作什么

refer.

以往也用自己的方式尝试解释过:

相关录音:


Comments


大妈的多重宇宙 - YouTube

全新自媒体系列...科学幻想,读书,说故事...

任何问题

随时邮件提问可也:
askdama@googlegroups.com


Copyright 2001-2023 by Zoom.Quiet
Content licensed under the Creative Commons attribution-noncommercial-sharealike License.
Contact me via , mail ,github or gitlab . Tip me via || (ATOM)