Closed huoguangjin closed 2 years ago
_(:з」∠)_ 我好难啊
~
_(:з」∠)_ 我好难啊
~
哈哈 , 找了老半天就找到你这一款自定义关键字高亮 。 可惜我不会java.
能不能搞个自动渲染, 不要手动切换 (:з」∠) 像内置的关键字一样。
能不能搞个自动渲染, 不要手动切换 (:з」∠) 像内置的关键字一样。
听描述我理解的意思大致是:按预设规则,自动高亮所有特定关键词/标识符?可能有点类似于浏览器插件Multi-Highlight
的那种直接匹配的效果?
最初开发这个插件的动机是高亮标识符,方便阅读源码。这里issue是高亮纯文本关键词(或者分析失败的标识符)。这两点似乎都有点不完全对应你提的需求。
这需求还是有点意思,说不定哪天也有人用得上,和原需求和功能也有一定重合。代码实现上不确定是否合适走IDE中关键字高亮的逻辑,这需要做额外语法分析再着色,实现上可能可能会有点诡异🤔,具体需要细看SDK源码再定论,监听document
的修改再刷新搜索匹配的实现方式虽然粗暴点但逻辑上应该更自由可控。
也许有必要额外开issue跟踪。😀
能不能搞个自动渲染, 不要手动切换 (:з」∠) 像内置的关键字一样。
听描述我理解的意思大致是:按预设规则,自动高亮所有特定关键词/标识符?可能有点类似于浏览器插件
Multi-Highlight
的那种直接匹配的效果?最初开发这个插件的动机是高亮标识符,方便阅读源码。这里issue是高亮纯文本关键词(或者分析失败的标识符)。这两点似乎都有点不完全对应你提的需求。
这需求还是有点意思,说不定哪天也有人用得上,和原需求和功能也有一定重合。代码实现上不确定是否合适走IDE中关键字高亮的逻辑,这需要做额外语法分析再着色,实现上可能可能会有点诡异🤔,具体需要细看SDK源码再定论,监听
document
的修改再刷新搜索匹配的实现方式虽然粗暴点但逻辑上应该更自由可控。也许有必要额外开issue跟踪。😀
是的 , 就是自定义关键字高亮 .
我自定义了一个log模块来代替默认的print ,
放到
builtins
里就可以在任意文件使用IIC 而不用先import IIC .
但是缺陷就是IIC不能高亮 ,而默认的print有高亮 ,
所以产生了这需求 .
谷歌了下也没发现自定义关键字高亮的插件.
百度有一篇自定义高亮的 , 不知道符合不合法. https://jingyan.baidu.com/article/11c17a2cd85035f446e39dda.html
能不能搞个自动渲染, 不要手动切换 (:з」∠) 像内置的关键字一样。
听描述我理解的意思大致是:按预设规则,自动高亮所有特定关键词/标识符?可能有点类似于浏览器插件
Multi-Highlight
的那种直接匹配的效果? 最初开发这个插件的动机是高亮标识符,方便阅读源码。这里issue是高亮纯文本关键词(或者分析失败的标识符)。这两点似乎都有点不完全对应你提的需求。 这需求还是有点意思,说不定哪天也有人用得上,和原需求和功能也有一定重合。代码实现上不确定是否合适走IDE中关键字高亮的逻辑,这需要做额外语法分析再着色,实现上可能可能会有点诡异🤔,具体需要细看SDK源码再定论,监听document
的修改再刷新搜索匹配的实现方式虽然粗暴点但逻辑上应该更自由可控。 也许有必要额外开issue跟踪。😀是的 , 就是自定义关键字高亮 .
我自定义了一个log模块来代替默认的print , 放到
builtins
里就可以在任意文件使用IIC 而不用先import IIC . 但是缺陷就是IIC不能高亮 ,而默认的print有高亮 , 所以产生了这需求 . 谷歌了下也没发现自定义关键字高亮的插件.百度有一篇自定义高亮的 , 不知道符合不合法. https://jingyan.baidu.com/article/11c17a2cd85035f446e39dda.html
没想到百度经验居然有这种文章。。
SyntaxHighlighterBase
是用于高亮特定语法文本的,用在这里会有比较多的限制。
SyntaxHighlighterBase
做的事情是将Lexer
分析出来的token
跟文本样式名TextAttributeKey
对应起来。每个TextAttributeKey
对应一个用于描述文本样式的TextAttribute
,IDE在渲染时就会为每个文本按TextAttribute
样式创建对应Highlighter
绘制出来。
不灵活的地方是:
SyntaxHighlighterBase
依赖特定语言的词法分析,不是任意文本通用的。当然直接把token
当文本比较也不是不可以,但要是文本没有对应的Lexer
支持就很尴尬了,另外别人的Lexer
切出来的token
也有可能是不符合预期的。 TextAttributeKey
是需要提前定义的,这个主要是对样式配置不友好。像主流语言在设置页Color Scheme
列出所有TextAttributeKey
给用户调TextAttribute
样式的,要支持动态增减TextAttributeKey
会比较尴尬。document
文本不变,语法树也没变,IDE认为缓存的token
也是没必要变动,所以SyntaxHighlighterBase
应该不会被触发刷新,这样对修改样式或者增删关键字匹配规则都不利,只能设法让语法分析强刷一遍,或者用其他法子绕一绕。这就是前面提到诡异的几个问题点,总的来说,SyntaxHighlighterBase
做起来应该会比较别扭,毕竟它设计出来就是为了给语法树上色的,比较专一。
How to search words?
search by regex (surrounding with
\b
).search by FindManager.
How to trigger search?
add a additional Action.
show additional options in Balloon.
fallback if highlight PsiElement fails.