利用内联聊天作为显示编辑的方式。
TLDR; 内联聊天可以很容易地扩展以提供编辑器中的编辑功能(PR #190258)。
简介
目前,实验性的内联聊天提供了一种有趣的方式来显示仅限于单个文件(TextEdits)的编辑。假设这个API是扩展作者感兴趣的内容(例如,参见#85682),它可能会为扩展作者工具箱增添很大的价值。
主要优点与重构预览相比(compared to Refactor Preview):
- 为小型编辑/单个文件编辑,不会因为提供不必要的大上下文而破坏用户的焦点
- 建议的编辑是可以编辑的
- 减少用户查看编辑所需的点击次数
同时,我意识到内联聊天的目的是聊天,但目前看来,编辑预览逻辑已经与聊天的内部融合在一起,无法轻易提取。
建议
扩展现有的inlineChat.start
(或者引入一个新的命令,例如inlineChat.showEdit
),这将允许接收edits: vscode.TextEdit[]
(或者vscode.WorkspaceEdit),并在内联聊天中添加额外的检查。这些编辑将添加到选项中(传递给InlineChatController
),并会稍微修改状态流。
在INIT_UI
之后,中断_nextState
并将编辑作为新的响应附加,然后继续使用_nextState
和APPLY_EDIT
。
如果选项中提供了编辑,则隐藏工具栏的部分(对话部分),只保留操作。
在PR #190258中完成。
其他不错的功能
- 通过命令/API调用从扩展中接受/拒绝编辑(仅适用于提供的扩展提供者)
- 在操作栏中添加Markdown信息文本(例如,为编辑提供一些有用的提示)
- 能够明确选择可视化模式(内联/并排)
VS Code版本:1.81.1
操作系统版本:ChromeOS 114.0.5735.239
3条答案
按热度按时间xtupzzrd1#
将来这个PR是否会合并?
yqhsw0fo2#
如果@jrieken同意启用,我很乐意将PR更新到最新版本。
不过我们需要注意的是,这不是一种干净的实现方式。
相反,功能应该通过专用API公开,并最好将内联差异完全分离(作为一个全新的核心组件)。
话虽如此,添加专用API相对容易,作为中间步骤,可以自动为扩展主机注册提供者(同时仅允许调用上述提到的命令),然后在API后台将功能切换到一个带有编辑面板的单独内联差异。
(如果同意的话,我很乐意将其添加进去 :))
f45qwnt83#
editor.experimentalInlineEdit.enabled
设置有关?我问这个问题是因为在某个更新过程中,一些冲突的System
实验性功能的键盘快捷键(例如Ctrl + Space
)被静默地添加到我的用户设置中,相当烦人。如果我能找到关于这个实验性功能的任何公共发布说明,我就不会问这个问题了。希望微软的某位工作人员能解释一下experimentalInlineEdit
是什么,并可能回应 @marrej 。