【问题标题】:Implementation of regex matches highlighting in text editor在文本编辑器中实现正则表达式匹配突出显示
【发布时间】:2017-06-12 05:13:59
【问题描述】:

我无法理解文本编辑器如何在用户键入时更新正则表达式的突出显示 - 编辑任何文本字符都可以更改匹配 - 它要求在每次用户按键时重新扫描所有文本。但他们确实如此。

  • 基于 perl 的增量正则表达式? - 它们不是自然的
  • 尝试在上一个匹配后搜索? - 上一个和下一个匹配项可能会丢失或离屏幕太远,需要重新扫描文档的大部分内容,带有环视功能的正则表达式也会被破坏
  • 另一个线程? - 似乎只是真正的解决方案,但您会收到烦人的突出显示滞后
    • 可能可以在用户输入时手动移动旧匹配突出显示(但我们仍然遇到新匹配突出显示/旧突出显示消除滞后的问题)
    • 可能在屏幕缓冲区中搜索(大多数用户正则表达式使用短字符串),然后运行线程以突出显示以查找其他具有滞后的长匹配项(晚显示总比不显示好)

我想了解更多关于现有实现的信息。

例如,我们有:5,9 MB 文件(以 ABC 开头,以 abc 结尾)和 2 个正则表达式:ABC(.|\n)*abcusing(.*?);

  • Sublime Text(regex1):正则表达式超出堆栈空间
  • Sublime Text(regex2):滞后约 300 毫秒,直到按键才更新屏幕
  • EditPad Lite 7(regex1):文本输入延迟约 500 毫秒,如果删除最后一个 'c' - 5000 毫秒
  • EditPad Lite 7(ABC.*abc - 他们使用多行点):没有滞后!如果删除最后一个 'c' - 滞后 400 毫秒。
  • EditPad Lite 7(ABC.*abc,文件 578,3 Mb):没有延迟。如何??删除最后一个 'c' - 输入字符 50 秒
  • EditPad Lite 7(regex2):没有滞后!
  • Vim(regex1): maxmempattern,但如果使用\(.\|\n\)*abc - 高亮显示文件是否滚动到结尾,没有滞后,高亮显示一直有效,直到向上滚动 300 行 17445,然后它丢失并且不会返回。它是如何工作的?
  • Vim(regex2):没有滞后,没有错误

对每个用户条目进行整个文件扫描:

  • .NET Regex(regex1):文本输入延迟约 300 毫秒(如果从文本中删除最后一个 'c' - 永远冻结)
  • .NET 正则表达式(正则表达式 2):~300 毫秒
  • .NET x86 PCRE 笨拙的 2 函数包装器(正则表达式 1):失败并出现错误
  • .NET x86 PCRE 笨拙的 2 函数包装器(正则表达式 2):~300 毫秒

【问题讨论】:

    标签: text-editor


    【解决方案1】:

    如果有人感兴趣 - 我使用了 size = screen chars + stock 的缓冲区(只是不要突出显示大匹配项)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-05-30
      • 2021-01-24
      • 2017-06-11
      • 2012-01-13
      • 1970-01-01
      • 2017-05-11
      • 1970-01-01
      相关资源
      最近更新 更多