见鬼，为什么要新公关？在旧公关中，有太多无价的讨论，不会直接联系在一起。

见鬼，为什么要新公关？在旧公关中，有太多无价的讨论，不会直接联系在一起。

请看讨论的结尾-我想重新设定公关的基础，因为有很多修正和回复以及其他混乱。如果我在那里重新设定了基准，那么讨论的内容就不清楚了，因为提交与讨论不相符。公关链接在这个公关的顶部，所以我看不出有什么问题。

在与之前相同的地方以及其他一些地方进行测试，结果与预期相符。

这是对以前功能的巨大改进，应该合并，以后可以添加改进。如果没有变化，没有反对意见，我会在周末后合并。

然后，希望它能得到一些测试，并能发现任何实际的性能问题，而不是过早地进行优化。

（这个想法是在你考虑其他事情之前合并，把这个公关也搞砸了😜 )

（这个想法是在你考虑其他事情之前合并，把这个公关也搞砸了😜 )

好策略：-）。

但是，在对其进行了更多测试（并发现了从其他文件继承的容易修复的问题）之后，我对结果感到非常满意。所以，是的，我同意。

也许 吧#3176也可以同时合并——我认为这是一个低风险、简单的补丁，也与自动完成有关，希望不会引起很大争议。

我批准了#3176不久前，问题是为什么它还没有合并：-）

我真的不太满意b710cf3型

它做了很多假设

基本上，这样做的唯一假设是源和相应的头具有相同的文件名，并且头具有一些常用的头扩展名。

看起来真的很贵

请注意，这不使用任何文件系统操作-这适用于TMSourceFile结构，该结构表示经过解析的源文件，没有任何扩展名，仅是打开的文档（使用类似ProjectOrganizer的东西，它可以是整个项目）。确实，这个函数会进行字符串比较，这可能有点昂贵，但文件的数量往往比标记的数量少2个数量级。

通过硬编码仅适用于C/C++

这是真的，但我没有看到任何迹象表明其他任何ctags解析器很快就会获得cxx解析器的功能，因此在可预见的未来，范围自动完成将是C/C++唯一的功能。

与局部变量无关

这并没有，但本公关中的其他事情都没有——这是关于改进范围自动完成的。当您键入以下内容时

无效MyClass:：myFunction（）{名称。//<--}

代码是否首先查找成员会有所不同名称在头或任意成员中名称在工作区中-在这种情况下，您会得到错误的结果。

事实上，我正在考虑通过查看#包括标记（我们目前忽略它们），并首先使用包含文件中的标记。

现在想想，我应该以不同的方式实现它——我可以在里面实现sort_found_tags（）并将排序标签的文件名与源文件名进行比较，这样比较就会更少，代码也会更短。

请在单独的PR中讨论该功能。

我可以将其分离，但在某种形式上，我希望保留此功能，因为它改进了范围自动完成的结果。

此外，如果我们想要这样做，那么以某种方式公开“查找标头”逻辑以实现“转到标头”功能可能是有意义的（我认为ProjectOrganizer已经有类似的功能了？）

ProjectOrganizer和Geany的区别在于Geany不知道所有的项目文件（在Geany中没有属于项目的文件的概念）。对于ProjectOrganizer中的每个项目文件，Geany中都有TMSourceFile，仅用于打开的文件，除非Geany搜索文件系统中的头，否则无法在Geany本身中轻松复制此功能。

我批准了#3176不久前，问题是为什么它还没有合并：-）

我不确定LGBI是否得到了足够的批准；-）。现在已合并。

是的，确实有很多与本地标签无关的更改。理想情况下，这些都是单独的PR。这使得检查本地标记的必要更改比必要的更困难。

然而，从我所看到的来看，“非标题”更改的争议性较小，所以我愿意接受它们作为本次公关的一部分。

有了ProjectOrganizer，可以有很多打开的文件，所以我有点喜欢简单地迭代所有文件。此外，可能存在同名的头文件，因此需要某种巧妙的解决方案。无论如何，该功能的补丁足够大，足以保证单独的PR。

代码首先在头中查找成员名称还是在工作区中查找任意成员名称会产生不同的结果，在这种情况下会得到错误的结果。

自我更正范围补全可能会找到正确的类（尽管从标题中查看标记肯定不会有什么影响）。但它对非扫描自动完成绝对有用。

@库格尔-您是否明确阻止此操作，直到@技术人员将其分为两个PR？或者现在你已经复习过了，这次可以吗，但不要再做了？

请分开PR

@库格尔-为什么你在最后一刻才进来，要求把公关分开，而浪费了其他人测试和检查的精力？

它不像这个项目有大量的空闲资源，并且使它变得更困难并不是将改进包括在内的方法。

@库格尔-

理想情况下，这些都是单独的PR。这使得检查本地标记的必要更改比必要的更困难。

我愿意接受他们作为这个公关的一部分。

你为什么变了？我的问题与你的评论有关，我是否应该放弃它。

我听不懂。昨天我第一次试着复习整件事。我惊讶地发现，自从我最初的非常粗糙的外观（那不是一个评论）以来，更改已经变得多么大，并且发现添加了许多不相关的更改（w.r.t到本地标记）。GitHub甚至默认隐藏了tm_workspace的差异！！因为我也想要这个功能，所以我试图在一个公共关系中接受大多数功能，尽管我并不自信。但标题的功能有点太多了，不符合我的口味，应该单独处理。

从我所看到的来看，这是一个必须退出的单一提交，事实证明这并不是什么麻烦。

对于未来，我希望公关人员专注于他们创造的目的，不要累积太多不相关的变化。

我听不懂。昨天我第一次试着复习整件事。我惊讶地发现，自从我最初的非常粗糙的外观（那不是一个评论）以来，更改已经变得多么大，并且发现添加了许多不相关的更改（w.r.t到本地标记）。GitHub甚至默认隐藏了tm_workspace的差异！！因为我也想要这个功能，所以我试图在一个公共关系中接受大多数功能，尽管我并不自信。但标题的功能有点太多了，不符合我的口味，应该单独处理。

就我个人而言，问题在于你的态度。你没有在中指明#3175你会花更多的时间在这个公关上，而谈话主要是我和@elextr公司。从这次公关开始，你就开始抱怨“为什么要新公关”，你“愿意接受”什么，以及（在你看来）引入公关的“无关的改变”。对我的影响是“服从”的意愿大大降低。

你所说的那些“不相关的更改”来自于对启用局部变量的自动完成工作方式的测试。它提供了比以前多得多的结果，仅仅启用局部变量是不够的。我花了很多时间测试自动补全的工作原理，路上的补丁是我（或@elextr公司)run-into（就像对非作用域自动完成标记进行排序是Lex的一个好主意一样，从标题中获得标记意味着在C++中，类的成员（通常您会频繁访问）位于列表的顶部）。我通常会尽可能多地分离补丁，但同时我想让结果有用而不烦人，因为您将更频繁地看到范围完成，并且您将在非范围自动完成中看到更多符号。无需提醒我如何制作紧凑型PR，我尝试用真正无关的代码来做，但事实并非如此。

无论如何，现在我建议在所有问题解决并讨论完所有问题之前，不要合并这个公关——我认为不急。你提到你“没有真正的自信”，所以请慢慢来，把你认为有问题的东西贴在这里。同时，我也想在这里讨论一下标题补丁——我不会仅仅因为你不喜欢它就花时间删除它——我想看看一些真实的论点（我试图回复你最初的评论），并知道你的建议。

正如我所提到的，我想对其进行概括，以便将包含文件中的符号也排序到列表的顶部-这可能意味着通过使用包含文件名的哈希表（模拟集合）来更改检查文件是否为头文件（或包含文件）的函数的实现，检查TMSourceFile并检查文件名是否在表中。

“查找可能是与这个C文件对应的头文件”显然是一个新特性没有什么与本地标记有关。在开始对这个PR进行深入审查之前，我没有意识到这个功能被添加到了之前的PR中。我也从来没有说过我不喜欢或不想在Geany中使用它，我只是想单独讨论和审查它，因为我对实现的假设有一些怀疑，我不想使用“本地标签”努力被这阻碍。这也是整体差异的一大组成部分，我喜欢查看较小的差异。

我关注了你关于其他公关的讨论，但我只是没有时间进行深入的审查。对不起，聚会迟到了。

如果你不打算花时间删除它，那么我就不会再花时间审查这个PR了。显然，你已经@elextr公司我已经很高兴能在没有我参与的情况下越过终点线了，这很好。差异中也没有致命错误，所以继续。

@库格尔-我不认为搜索、排序和标题部分与启用局部变量是分开的，它们是以可用的方式向用户呈现局部变量的不可或缺的部分。

你抱怨说#3175但看起来你并没有理解。否则你会明白，如果没有C/C++全局标记文件中PR无关全局标记的筛选和排序部分，会淹没自动完成列表中的局部变量，使它们无法使用。

如果没有为范围自动补全选择最可能的基本符号的工作，那么它也就没那么有用了，因为它更有可能为错误的变量提供补全。

局部变量具有固有的作用域，内部作用域隐藏外部作用域。因此，“启用局部变量”内在地涉及处理范围，而这些规则内在地特定于语言，请参阅中的示例#3175.Geany没有精确的范围检测，尤其是包含文件，因此排序和筛选，包括（对于C/C++）将头文件符号优先于全局变量，为在自动完成列表顶部显示最可能的候选对象提供了启发式方法，并为范围自动完成选择最可能的基础，使其可用

拆分PR现在意味着需要做更多的工作、进行双重测试、最初的PR会带来糟糕的体验，以及在拆分过程中引入错误的风险。

基于以上所有原因，我不支持拆分此PR。

我确实对你的阻拦做出了负面反应，在接受了我上面指出的公关之后，我似乎要求将其拆分，对此我深表歉意。也许你不是有意接受它，也不是有意无缘无故地要求。英语是不精确的，世界各地的用法各不相同，这里的“please do x”意思是“如果合理的话，我希望你做x”，而“do x please”意思是“我要求你做x，我说请只是为了礼貌”，但我不确定在其他英语国家是一样的，更不用说英语不是第一语言了。

@库格尔-在发布上述内容之前，没有看到您的最新评论，谢谢。

我确实想在master中获得这一点，以便对其进行更多测试，因为它的用户体验依赖于启发式，并且可能存在一些边缘情况@技术人员我错过了失败的地方。

@库格尔-我只想讨论标题内容现在所以我知道你的想法是错误的。这对我来说意味着一些额外的工作，如果结果是讨论演变成“让我们保持原样”，那么工作就白费了。这就是为什么我对“请分开PR”这样的评论不太感兴趣，因为这些评论没有对你认为错误的地方、你建议改变的地方或者你是否想完全放弃这个功能进行适当的讨论。我完全可以重新修改补丁，将其分离到新的PR中，或者如果结果不是一个好主意，就将其废弃之后适当的讨论，而不仅仅是因为有人命令我这样做。

如果您主要关心的是性能，我建议更改实现，以便添加哈希表文件名->TMSourceFile到TM工作区

关于性能，我建议，除非有人能够提供真实世界中的使用情况，证明性能不佳，否则我们就保持原样，看看情况如何。

用带有多级缓存的现代芯片和优化编译器来推理性能是有问题的，至少可以说，所有旧的经验法则都是错误的，它们是首先优化的😄

经常有人评论字符串比较“慢”（在许多问题/PR中，而不仅仅是Geany，没有挑剔@技术人员注释），但现代编译器需要-fno-内置到停止它们发出硬件优化指令，芯片制造商开发这些指令来处理C的空终止字符串，利用缓存、交错内存通道和预取等。现在，旧的经验法则是不正确的，特别是当字符串可能小于缓存线长度时，如符号，它们可能只访问一次内存，而实际的比较是隐藏的。

因此，除非一个实现存在总体性能问题（比如时间是指数级的），否则除非我们有一个实际的使用情况，这是一个问题，或者基准测试，否则首先使用最简单的方法来编写和维护实现。

我不想在这里与我的公关人员产生紧张关系，也不想引入其他人不同意的代码，所以我删除了与标题相关的代码。我相信我也谈到了所有其他的评论@库格尔-had，在适用的情况下，通过在per-file标签数组中搜索，改进了非范围自动补全的性能，并进行了一些清理。

@库格尔-你觉得好看吗？关于通过在TM工作区基于文件名进行快速查找？

@elextr公司我同意大多数关于性能的东西，我认为我们不应该做任何疯狂的优化。另一方面，当我们做一些不必要的事情时，我会感到不舒服，而且有一个简单的修复方法，比如本例。

@技术人员我们能完成这个吗？你还需要什么？

因此，我们似乎决定合并当前状态（同样，IMO需要一些挤压操作），并在主分支上进行更多测试，同时进行进一步改进？

我不太确定我们是否确定了一些事情，这就是为什么我大部分时间都放弃了这个公关；-）。

@技术人员我们能完成这个吗？你还需要什么？

基本上是从与代码相关的东西开始，除非我不忽略某些东西，否则剩下的东西就是我刚才添加的缺失注释和文档。关于文档，我更改了@elextr公司提议有些不同&将在下一篇文章中添加解释。

似乎使用表格1在附录中会更清楚（我不确定内容是否正确，@技术人员修复他决定合并版本的时间）：

尽管每个人都喜欢表格、图表和类似的很酷的东西，但我认为表格在这里太过夸张了。当前的排序不是必须保留的，如果我们找到更好的启发式，将来可能会改变，它只是“首先显示最相关的符号”的代理。所以

对于某些语言，自动补全列表是按启发式排序的，以尝试在列表顶部显示更可能是用户想要的名称。

IMO就足够了。

作用域自动完成部分：

大多数语言只分析全局定义，因此范围自动补全对本地范围中声明的名称无效。一些语言同时解析本地和全局符号，这使得基本名称（例如this_name->）更有可能在可用符号中出现多次，这意味着可能会混合使用几种类型的范围补全。Geany没有准确的符号范围和可见性信息来解决要使用的定义，因此为了消除这种情况的歧义，Geany使用了[Autocompletion behavior]中描述的启发式方法来优先考虑最可能是用户想要的可能的补全。

不正确。在作用域自动完成中，我们总是按字母顺序对所有成员进行排序——例如，当你想到结构或类的成员时，这些成员是在一个文件中定义的，我们无法猜测用户想要哪个成员。

所以我用了这样的措辞：

大多数语言只解析全局定义，因此范围自动补全不适用于在本地范围内声明的名称（例如函数内部）。一些语言可以同时解析本地和全局符号（例如C/C++解析器），对于这些解析器，范围自动完成也适用于局部变量。

因此，如果您稍微压缩一下（尤其是恢复之前的提交），我会立即批准。

文档对我来说足够好了。如果有任何改进的愿望，可以稍后再做，IMO。我现在没有这种愿望。

好的（如果其他人同意的话）。

我不知道接下来的几周我有多少时间，所以我这边可能会有点延迟。

@技术人员

好的（如果其他人同意的话）。

因为我的C++是在别处完成的，所以我不会从这个PR中获得任何好处，我不会再在上面浪费时间了。

只需说，直到最后一次更改（那些现在已经被删除的更改），C++的可用性并没有真正的改善，事实上，由于自动完成中存在更多的噪音，情况可能会更糟。@技术人员很抱歉，我浪费了你的时间来改进它。

@库格尔-我不知道它是否为C添加了任何有价值的功能，我只测试了大量的C++。如果你认为它增加了什么有用的东西，那就由你来合并它，我不会。

只需说，直到最后一次更改（那些现在已经被删除的更改），C++的可用性并没有真正的改善，事实上，由于自动完成中存在更多的噪音，情况可能会更糟。@技术人员很抱歉，我浪费了你的时间来改进它。

嗯，如果没有别的，那么在非范围自动完成弹出窗口（并放在顶部）中查看局部变量不是很有用吗？从我的测试来看，非范围自动完成从这次PR中受益最大，并由于订购而开始提供更相关的结果。

范围自动完成的用处可能确实不确定，因为我们只看到静态声明的内容，而没有看到类似这样的内容汽车变量或精确类型的虚拟变量。尽管如此，它似乎与Scintilla来源（不使用汽车的，并且没有使用太多的动态C++特性）。

嗯，如果没有别的，在非范围自动完成弹出窗口中查看局部变量不是很有用吗。

现在我的。。。呃。。。呃。。哦，是的，记忆！！！但IIRC：

也许这是不同的C++编写方式，但在我测试的C++范围内，大多数代码都在类成员函数中，类数据成员名称是最常见的，但它们是在类定义中声明的，它们位于头文件中，因此如果没有头优先排序，它们就会被隐藏在自动补全的字母部分，而字母部分会显著增加。因此，我对标题优先排序删除表示不满。局部变量是第二常见的，但大多很短，所以它们甚至不会触发4个字符的自动补全，所以对这些没有多大帮助¹也有许多当地人在for（）和if（），我不记得ctags有没有看到它们。²

我测试的主要代码在类之间有一定程度的重复，因为它没有指明Geany自动补全列表中的名称来自何处，所以我关于为什么事情出现在它们出现的地方的推断可能是错误的。自那次测试以来，我使用vscode进行了一些简短的实验性编码，在那里我没有费心设置构建信息，并且自动完成显示了一个与我记得启用头文件排序时得到的类似的列表^三

正如我所建议的那样，C（或Cish C++）可能会从局部变量中获得更大的好处，因为它没有在成员函数中不带任何限定条件的可见类成员名称。使用“在顶部声明”习惯用法的旧C代码可能倾向于使用较长的本地名称，尽管在“在其可初始化之前不要声明”之后的新C代码可能会倾向于使用较短的名称和较小的范围。

是的，没有构建信息的vscode与Geany存在相同的问题

该死，我必须向vscode道歉，我的实验代码使用了几个<cthing>标题类似<cstddef>它们是等效C头的C++化版本。但他们仍然像C一样在全局命名空间中转储内容（以及礼貌地在标准：：). 为什么选择C++技术委员会？？这实现了什么？嗯哼，不管怎么说，vscode只是在做它被告知的事情。

@技术人员嘿。这方面有进展吗？只要求我这边做一些压榨。

@库格尔-是的，终于完成了，看#3266.

如未讨论#3266我推了一段稍微修改过的历史。差别是一样的。除非有人大声说出来，否则我认为这是可以合并的。

太好了，谢谢！