目前块引用的预览或点击默认会显示该块的上下文。虽然首先显示的是该块，但若浏览时滑动滚轮，很容易滑到其他内容，还需花时间定位回该块。
因此能否添加一个切换选项，使块引用的预览或点击只显示该块的内容，而不显示该块的上下文。（即自动聚焦）
谢谢！
【建议】块引用可设置为自动聚焦到块本身，不显示上下文
本贴最后更新于 1126 天前，其中的信息可能已经天翻地覆
1 引用
相关帖子
-
这两天比较忙，今天晚上稍微有点时间，和 D 大认真的探讨一下这个问题吧。
首先，我想说的是，作为一个软件设计和开发者，在遇到不同用户的不同诉求时，确实是一个众口难调的问题，如果满足了这部分用户诉求，就无法兼顾到其他用户的习惯，很多时候很难抉择。一般情况下，人们普遍想到的都是通过配置项的方案来解决这样的困境，但配置项不是万能的，如果我们仔细想想，这种方式其实没有解决问题，而是把这个问题转嫁给了用户，让用户自我选择。那么带来的问题就是，这么一个选项，针对 A 类用户是常开的，针对 B 类用户是常关的，在这两类用户的配置选项中，存在一个从来也不会去调整的选项，岂不是一种冗余和干扰吗？
那么，到底什么样的功能应该放在配置项呢？我个人的理解是，这个功能的打开和关闭不是互斥的行为，而是不同场景下的不同选择。举个简单例子，就像现在搜索配置中的类型过滤，针对我来说，我一般搜索主要看简洁内容，所以我可以只配置段落，但当我有时候需要搜索很细的内容时，我就会按需打开其他类型，让搜索的内容更多一些。这个例子中，配置项解决的是用户不同场景下的不同需求。
这里也多讲一下，并不是说放入配置项不是一个好方案，而是不应该遇到不同用户诉求就想着靠配置项来解决，这不是一个好方法。合理做法应该是要更多思考，不同用户提的不同诉求，是不是真的完全互斥的？他们基于什么场景使用这个功能，这个场景真实存在还是用户臆想的？有没有其他更好的方案也是可以解决两者的诉求的？
说到这里，回到今天想讨论的核心问题：作为一个软件的设计和开发者，决策一个软件的功能依据到底是什么？我个人的拙见，应该是这个软件的核心定位，和要解决的核心场景。一切符合软件核心定位和场景的功能，都值得花大力去完善，努力提高体验；而和核心定位和场景关系不大的，也可以做，但只能是有精力或者要满足某方面诉求的情况下才去做，这些功能只能是锦上添花，而非雪中送炭；最后和核心定位和场景有抵触的功能，是要坚决不做的，不能因为有部分用户有诉求，就听取用户的意见，带来的后果会让这个产品变的越来越四不像，损害的是更广泛的用户体验，最后做了很多功能，但是却没有一个功能是用户核心使用的。
所以，思源的核心定位和场景是什么呢？当确定了这个，很多功能的取舍就变的简单一些了。先谈下我的个人一些看法，我一度理解是本地化 + 内容块，其中内容块是相对很多本地化笔记的一个高阶特性，笔记的内容不是通过文档组合的，而是通过各种文档中的内容块来组合的，将内容的粒度更精细化管理。既然内容块及内容块的组合是核心功能，那么用户在使用组合的时候，关注的要组合的具体内容，还是组合内容的相关内容？我认为是前者，这才是组合块的灵魂，至于要看内容的关联信息，完全可以点入到文档中查看，而非在预览时查看，预览的内容是我当前内容的一个补充，是为我当下内容来服务的，我的焦点应该是我当下正在关注的文档。但我现在感觉我对思源的核心功能理解似乎是有些理解偏差的（或者可能也是最近几个版本迭代思源已经进步了而我还是原来的我）
最后聊一聊用户的意见要不要听？张小龙曾说过“中国有 1 亿用户教我做产品”，如果微信听取用户的意见，那么微信早就臃肿不堪了。那微信是不是不关注用户意见？不是的，微信的团队，每天从不同渠道收集用户的意见，每天要花很多时间逐条阅读用户的反馈。但这里他们不是听用户要微信怎么增加功能，而是琢磨用户提的问题是基于什么场景，针对这些场景，微信应该要做什么调整。有些时候，确实捕捉到了某场景的刚性需求，但是如果解决这个场景会造成更多其他人的操作体验困惑，那也是不能做的。这就是要有所为，也要有所不为。
说了这么多，估计可能有些内容也是错了，但无所谓了，至少通过这个方式，能把我对思源的想法表达出来，也是给 D 大的一个参考。在这个场景下，我也是一个用户，用户的反馈很重要，但是决定权是在开发者手里，我们只是给你多了一个信息参考而已。
1 回复 - 其他回帖
-
刚准备发新贴，但看到已经有人发了这个问题了，所以直接在这个问题上回复吧 😄
这个是 1.2 改动带来的吗？我记得原先版本的体验是聚焦到块本身的，但是今天无意发现引用的块预览都是上下文，我原先为了不显示全文还专门把一篇文章中的某些我所需要的内容设置为超级块来规避全文的显示，现在直接发现引用文全部展示了。
这个体验个人感觉真的不太好，引用的目的不是创建一个文档超链接 +tag，而是只聚焦要我聚焦的内容。既然思源主打的是内容块，通过拼积木把知识组合起来，那么我现在拿其中的一个积木的时候要顺带把这个积木所在箱子里的所有积木都要带过来，似乎是违背了设计内容块的初衷了。
恳请这个点能尽早排期优化下，这个特性的优先级要明显高于其他点，希望开发者考虑。 @88250
2 回复1 操作larryggao 在 2021-06-28 23:47:46 更新了该回帖 -
-
这里主要是带上下文方便预览，众口难调的问题后面会单独出选项，目前不打算再调整了，不然需要这个的人也会抱怨，请理解一下。
2 回复1 操作88250 在 2021-06-29 10:59:00 更新了该回帖 - 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于