昵称没什么用,随便写都行

Bard
关注
62076 号成员,2020-10-13 01:07:44 加入
1.5k
个人主页 浏览
404
帖子 + 回帖 + 评论
6058h39m
在线时长
“底层统一标签和双链”
  • 思源笔记 8G 的空间用完了怎么办?

    2023-01-13 00:35

    也是推荐“笔记和文件分开管理”

    用专业的软件做专业的事情

    比如 OneDrive 适合管理和同步文件,而思源并不擅长

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-13 00:30

    我理想中的制卡就是不需要重复正文中提到的 Step2 和 Step3。因为同一篇文章的卡片很自然地应该属于同一分类,因此重复进行 Step2 和 Step3 是无意义的,并且这一过程让人抓狂。

    这是个很主观,想当然,思维保守,目光狭隘的观点

    • 对于“一元笔记”用户来说,这不够“自然”
    • 对于 Daily Notes 的用户来说,也不够“自然”
    • 对于笔记关系复杂的用户来说,也不够“自然”

    而思源笔记的优点之一就是包容不同的使用方式

    所谓的“抓狂”,可能是思源的包容,也可能只是自己的“倔强”

    因此思源不能因小失大,往路窄的地方发展

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 23:32

    我的部分理念是这样的

    1. 写的清楚,才算想的清楚,就像卢曼说的:不写,就无法思考
    2. 优秀的设计也是可以说清楚的,尤其是体验如此深刻的功能

    不妨稍微耐心一点,或许可以

    1. 将理想中的功能描述的更加翔实一些,证明其优秀,无关 RN
    2. 把我和别人观点中的谬误,不理解你的地方指出来,阐述明白,继续探讨
  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 23:22

    不建议用 “RN 如何如何…怎样怎样…”来证明“思源也需要如此”

    需要的是“这样很有用,这样很方便,这样设计足够优秀,比之前设计的还要优秀”

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 23:15

    这个没什么好纠结的,用户已经主动在文档树中给出分类了。如果在文档树中把 数学史 归为 数学 一类是可接受的,那为什么在卡包中把 数学史 归为 数学 一类就是不可接受的了呢?

    如果一定要把 数学史 同时归为 数学历史,也不是没有办法,我简单提几个方案。

    方案一,给 数学史 这篇文档加上 历史 标签,同时引入标签树即卡包的机制。

    方案二,在 历史 笔记本的某篇文档里,粘贴 数学史 为嵌入块。

    作者:openAI
    链接: 希望取消闪卡的卡包,因为文档树就是天然的卡包 - openAI 的回帖
    来源:链滴
    协议:CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    这两个方案依旧是没有明白

    在思源中的“标签”和“双链”是没有统一的

    方案二也难以经得起细致的思考和推敲,比如以下我认为不是“抬杠”的思考

    1. 在 历史 笔记本的哪篇文档呢
    2. 这篇文档应该叫什么名字呢
    3. 要不要跟原文档重名呢
    4. 不重名的话如何命名区分呢
    5. 以后还有别的卡要用这样的方式放到 历史 笔记本中,是继续新建文档,还是放这个文档呢
    6. 还是统一叫类似“历史 - 其他卡片”
    7. 就算确定了解决的统一方案,会比原来的添加卡包更加优雅吗
    8. 思考创建分类的时间成本合算吗
  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 23:00

    方案三:如果用户甚至只有一个笔记本,连一级分类都没有,所有的笔记都是未分类的日记,那么可以采用标签机制来对卡片分类。比如,2023.01.12 这篇文章是关于中日战争的,那么可对里面的段落打上 历史/中国史历史/日本史 两个二级标签,自然地,相关的卡片就属于 中国史日本史历史 这 3 个卡包。这样同时也就克服了我上面提到的第 ④ 个缺点,可以直观地看出卡片属于哪个卡包。(文档树即卡包、标签树即卡包这两种机制是可以同时存在的,是兼容的)

    作者:openAI
    链接: 希望取消闪卡的卡包,因为文档树就是天然的卡包 - openAI 的回帖
    来源:链滴
    协议:CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    这个方案是不符合现有思源的理念的,现在实现不了,或者要实现是很难的

    因为思源的标签和文档(也就是双链)是还没有统一的

    我盲猜这是常用 RN 的思维惯性,因为我也听闻“RN 的统一性是十分好的”(对本句持谨慎观点)

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 22:46
    1. RemNote 在用,并不代表就是优秀的设计,一个软件有这样的功能,并不代表另一个软件也需要有,就算增加这个功能也是因为“这个功能足够好”,推荐从这样的做有着“无以复加的好处”的角度开始论述
    2. RN 依然无法优雅解决一张闪卡位于多个卡包的问题,
    3. 文档树分类无法“一对多”的特性,会导致难以实现十分具体的卡包,比如“文科综合错题知识点”的卡包,而实际使用中是可能面对这样场景的
  • 能不能不要阿三式的程序设计?

    2023-01-12 22:29

    隐藏起来是没有之前方便了

    不过既然常用,还是推荐用快捷键

    效率更高

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 22:06

    关于“如何提建议”的感悟:

    推荐“建议自己需要的功能”

    不推荐“建议取消自己用不上,且不知道别人是否在用的功能”


    @openAI 可以考虑一下这条评论的观点

    如果认为我说的没有问题,建议是改一下标题

    如果坚持的自己原有的观点,也不妨进一步详细的阐述一下

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 21:32

    闪卡的制作本身就需要问题有一定的原子性

    而思源也是基于“块”的笔记,块的原子性更好

    因此我认为:把“块”当作闪卡,比把“文档”当作闪卡是更合适的选择

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 21:28

    回复了之前几条,我明白了核心分歧在哪里

    当前建议的是按照“文档树”的使用方式建议的

    而思源有相当一部分人是按照“没有文档树”的方式使用的,与当前建议难以兼容

    或者可以说“建议兼容文档树卡包,但绝不能取消原来的闪卡卡包”

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 21:20

    举个小栗子:

    假如一个闪卡“唐朝建立于公元 618 年”

    想要分别放到“唐朝历史知识”,“关键历史事件节点”,“上次考试错题”等卡包时候

    文档树管理的卡包就很难去实现

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 21:13

    一个小点:

    利用文档树分类,很容易导致文档路径过长

    文档路径过长,在某些系统中会有限制

    这也是设置选项中有个大致叫“文档路径不能超过 7 层”选项的原因

    这是也我在整理用文档树管理的“老文档”的时候遇见的问题

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 21:09

    很多像我放弃“文档树”的人来说文档树是种“可能落后”“可能低效”“可能繁琐”“分类压力大”等的使用方式

  • 希望取消闪卡的卡包,因为文档树就是天然的卡包

    2023-01-12 21:07

    有很多用户,比如我,是不用文档树的来管理文档的,用 MoC

    文档树对很多人来说,最大的问题是难以应对“一对多的分类”

  • 思源笔记——即刻用户年度推荐

    2023-01-02 21:42

    思源不能失去链滴,就像西方不能失去耶路撒冷 trollface

  • 思源笔记 windows 无法创建 local.json

    2022-12-28 22:48

    换个目录试试

  • 建议手机版不要自动上传数据或者弄个开关设置是否自动上传

    2022-12-27 23:45

    我也很久没打开手机版了

    现在计划也是卸载手机版

    就算下次使用,大不了全量同步

  • 158 款常见紫砂壶型大全

    2022-12-24 23:54

    匏瓜,那不是孔子嘛,哈哈哈哈哈哈

  • 全局搜索 Ctrl+P 失效

    2022-12-22 16:04

    已经修复,应该会在 2.5.6 发布

  • ctrl+P 搜索失效

    2022-12-22 00:07

    已经修复,等下个版本吧

  • 同步失败,file exists v2.5.4

    2022-12-19 23:58

    已经修复,估计今晚或者明天会发版

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 21:14

    懂的都懂

    不敢面对实际问题

    读写能力差,水平又不行

    讲了道理,却又听不懂

    最后只好“如网上很多平台说的那样…”

    从平台层面进行整体污蔑

    说什么话,麻烦请摸着自己得良心

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 02:00

    用 A 软件就好好用 A 软件

    不要非得把 B 的主要特性提议给 A

    非要如此,更建议给 B 提议增加 A 的特性

    软件有 Bug,个人有需求,没什么问题,毕竟是社区共建

    但挑战“共识”就需要有足够深厚的积累

    就像卡尔萨根所说“超乎寻常的论断,需要超乎寻常的证据”

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 01:44

    既然使用笔记软件了,还写了这么一大堆

    说明是有读写能力的,没错读写是分“读”和“写”的

    之前的帖子都可以再读一遍的,里面也有详细讨论和解释

    读懂别人的观点之后,再来发表观点,才有延申讨论的增量价值

    就像我,引用一段,解释一段的形式

    这贴明明没什么深入谈论的价值,那为什么我非要说这么多呢

    我今晚比较闲

    正好碰见个锻炼读写能力的机会

    感谢您的文本

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 01:35
    • 对系统工具,对第三方工具的友好性,不正是本地化的一大便利么(另一大便利是安全)
      • 对三方工具的友好性,和便利没关系,便利也可以是在自己体系内的“功能自恰”
      • 在单一软件内,相对效率才能更高,更换软件容易打断心流体验,得不偿失
    • 如果 ID 化是子文档的代价的话,那真是子文档的一个最糟糕的本地化实现,更何况子文档也丝毫不会对笔记带来本质的提升。纯在线的 ID 化无所谓,用户根本不关心这个。可用思源就是冲着本地来的
      • 没有看到过“ID 化是子文档的代价的话”请列明出处,或者详细阐述这个观点
      • 像什么“真是子文档的一个最糟糕的本地化实现,更何况子文档也丝毫不会对笔记带来本质的提升”更像是主观臆断,欢迎继续详细表达自己的观点
      • 现在的思源还是在本地为主,上条评论已经有所阐述
    • 特性的引入伴随思源一直在收紧自由度,从资源的统一管理到文档名的 ID 化,收紧的方向正常,但方法真是一言难尽
      • 哪里没有自由度了,是不让你用了,还是不让你回来了
      • 文档 ID 化在那次知后就都是 ID 了,什么叫“一直在收紧自由度”,请把后续收紧自由度的措施列出来
      • 思源是个开源软件,全开源的软件,开源的
      • 什么叫方向正常?本地 Markdown 么,不要不符合自己的使用习惯就说“别人的方法一言难尽”
      • 那么“怎么收紧不一言难尽”可以详细阐述下
    • “思源用户不关心本地文件名,软件能打开就行”,但还是有一部分用户关心文件名的,越是深度用户越关心,随着笔记的数量提升,协作需求的提升,也许会有越来越多的用户看到这一串 ID 而苦恼吧
      • “一部分用户关心文件名”到底多少用户是关心“文件名”还坚持用 “ID 化”,还是坚持到现在的,不谈剂量谈毒性都是哈哈哈,推荐发个帖子统计下
      • 再说一次看看用户文档吧,有协作需求,请用在线笔记,不要跟你看重的“本地化”笔记来较真,南辕为何北辙
    • 实现同样的功能,应该有比文件名 ID 化更高效,更平和的实现吧?希望两位主创能考虑下这个问题
      • 没有
      • ID 化是计算机发着这些年最重要的发明,不然“数据库”就不会存在,就不会有今天的互联网
      • 如果你能有完美方案,或者更好的方案,欢迎推荐
      • 如果有,我觉得这值得一个“图灵奖”

    作者:dwe3030
    链接: 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?
    来源:链滴
    协议:CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 01:11
    • 除思源外任何工具对思源文件的管理不具备可读性和可操作性性
      • 思源没有承诺要对别的软件具有可读性
      • 对别的软件不可读反而是软件市场的大多数
      • 实在想用 .md 可以 Obsidian,Logseq,typora
    • 系统资源管理器几乎变为资源管理空气
      • 请精确描述什么叫“空气”
      • 是文件没了,还是看不到,还是被污染了
    • 文件级,文件夹级拷贝分享变的异常艰难,以至不可能
      • 要分享可以导出 Markdown 文件夹
      • 想要在线分享,说明文档里有推荐别家的
    • 第三方同步盘的同步日志变得没有丝毫可读性,同样文件级的版本恢复变得异常艰难(特别是思源自身的同步仍然只能作为 plan B, 即便一直改进,应该也无法和专业软件(坚果云)比肩)
      • 什么叫日志的可读性,日志本就是专业性的,日志也是有隐私需求的
      • 文件级别版本恢复困难,是软件功能不够完善,跟更换格式关系不大
      • 思源当前的确有那么些问题,但请不要否定未来的努力
      • 板凳有板凳的好,够用就行,没必要和扁担比长短
  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 01:00

    文件(夹)名称 ID 化,也还都在本地

    所以没有“与本地化的初衷渐行渐远”

    正常理解的“本地化”就是文件在本地

    非要广义到“很多软件都可编辑”“可读性”“资源管理器空气”“拷贝分享困难”,那也太广了

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 00:55

    “时代变了,大人”

    现在都 2.5.X 版本了

  • 建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

    2022-12-19 00:53

    几条理由还是挺可爱的

    推荐考虑下 Obsidian、Logseq