合并两个列表时，

• 拖动单项列表时，要用小圆点拖动（目前没发现其他方法）
• 拖动多项列表时，要先选中所有列表项块，再用列表项图标拖动（目前没发现其他方法）

这叫简单的不得了？

那这个该如何合并：

根本拖不到一块

确实，把一个列表跟一个单项列表拖一块时，基本很难拖到位

你先打开插件文件夹，在报错的那一行前添加一行代码

                console.log(mutationsList[i].addedNodes[0])
​

然后关闭插件再打卡插件，看看打开搜索界面后的输出

好像是挂件 bug，但是不想修了

-dh123 这样，搜索文档和 1、2、3 级标题

我刚刚测试能用啊

@88250 windows11 商店版 2.10.3，同样的问题

2.1 版本太老了，更新到最新版吧

docker 你可以先试试能不能用，如果能我在集市里加上

这也太精细了吧，感觉很少用

v0.0.6

集市里

• “通过搜索打开文档”和“通过文档树打开文档”为什么不能统一呢

• ctrl p 与 ctrl f 的搜索条件相互独立、互不干涉

  这个方案考虑吗

• Ctrl x 剪切内容后无法 Ctrl m：

  刚刚试了下，视频如下，但现在好像不能稳定复现

• 通过搜索打开文档：搜索打开时是定位到搜索位置，那搜索文档名打开一个文档，此时搜索位置是哪里呢？目前来看似乎是文档开头，我觉得应该和文档树打开一个文档一样，记住位置

• 网络图片转化为本地图片问题，关于网络问题，网络图片我是能正常访问的，但在思源中不行。

  https://tboox.org/cn/2019/11/21/quickstart-6-build-qt-project/
  ​

  你可以看看上面这个网址的最后几张 gif 图片能否正常显示，然后再把它剪藏到思源，然后看看剪藏到思源最后几张 gif 图片是否成功剪藏。如果能，那么可能是我这的问题（因为网址中图片能正常显示，但剪藏失败）

• Ctrl f 与 Ctrl p
  ctrl f 后仍保持了 Ctrl p，这个设计是不是这样理解：Ctrl f 是在本文档搜索，而 ctrl p 不再是全局搜索，而是记住上次搜索条件的搜索，全局搜索快捷键已经不存在了，是这样吗？
  这样似乎是为了兼容命名查询，但我的常用的搜索习惯现在似乎不能用了：我极少用到命名查询，很多人应该也很少用到，我的绝大部分搜索操作就是全局搜索（原 ctrl p）+ 本文档搜索（ctrl f）+ 记住上次搜索关键词，现在全局搜索没了，虽然 ctrl p 绝大部分时候就是全局搜索，但每当我 ctrl f 一下后，ctrl p 就不是全局搜索了，而是记住上次搜索条件变成本文档搜索，这让我不敢用 ctrl f 了
  对于这个问题，我现在想到的解决方案是：ctrl p 与 ctrl f 的搜索条件相互独立、互不干涉，ctrl p 是记住上次 ctrl p 搜索条件的搜索（一般情况下就是全局搜索），ctrl f 是记住上次 ctrl f 搜索条件的本文档搜索。这样 ctrl p 又仍可以被看做全局搜索而不会被 ctrl f 打断

• ￥￥ 与公式块，￥￥ 生成公式吧，这个感觉挺常用的

上次搜索内容我也很常用，还是希望加回来

目前打开搜索框下面是有默认显示的内容的，我记得好像是最近修改过的文档还是块什么的，没怎么关注过这个，不过我觉得这些内容不如换成上次以及最近搜索过的内容，毕竟搜索界面显示历史搜索合情合理啊，天经地义啊，为什么要显示更新的块

行内代码快我也想要非 markdown 纯文本 😋

其实在使用上我觉得这两个选项是比较常用的

段落开头空格和添加文档标题一般在写格式比较严谨的文档导出 docx 的时候会开这个，而对于其他的一般的文件，比如导出 md 文件，md 文件一般不会空两格之类的，空格标题就一般不会加上了，所以还是建议在导出页面也加上

@88250

早鸟也有教育优惠吗

连 gnome 的 wayland 都不太行啊

前段 api 呢

问题依旧的

ctrl+n 新建文档能不能也与这个路径保持一致

老乡好啊

问题是之前发的他就是被虚拟引用了啊

我没有建“vscodevim”，只有“vscode”和“vim”，你也不要建“vscodevim”试试

唔那难受了

所以这个问题是解决不了了吗