更新2020-09-24
现在已在全网络范围内进行。
更新
现在已在Meta Stack Exchange和Meta Stack Overflow上进行了发布。任何错误和反馈都可以作为答案发布在这里。

我是Ben,我是Stack Overflow团队团队的一名开发人员-我们是专注于建立私有团队的团队这样的经验。我最近一直在从事后期编辑的工作,我想展示一些即将在网络上发布的初步工作。
; TL; DR
我们将代码块突出显示库从Google Prettify突出显示。仍然支持所有您喜欢的语言,并且您根本不需要更改帖子的撰写方式。唯一的主要变化是我们如何呈现突出显示的代码块。此外,我们也借此机会介绍了我们的新的突出主题。我们将从MSE / MSO开始,并逐步推广其他网站,逐步进行。 (有关日期,请参阅本文底部的FAQ。)
Prettify的一些历史记录/代码块高亮显示
当我们第一次采用Prettify时,我试图做一些挖掘,但是看起来它的历史已经过去了回到网站最早的日子。我可以找到的最早参考文献是08年代的。我也在内部问了一下,我能得到的最佳答案是:

¯\ _(ツ)_ /¯-每个人


问Atwood-Dean



如果我不得不猜测的话,这与“没有太多选择,并且Google使用了很多选择,所以可能很好”-凯文

最终,精彩的《蒂姆邮报》将我引到了2008年6月播出的Stack Overflow Podcast#11,在那儿Jeff和Joel谈论了当时的情况令人难以置信以及Google如何将其用于Google代码(RIP)中的语法高亮显示。他们还提出了替代方案的呼吁,我不得不假设替代方案很短。
为什么要进行更改?
一段时间以来,Google Prettify一直没有得到积极的开发,并且于4月被Google正式停产,因为大家都让我们反复知道。这意味着不支持任何新的语言语法,并且现有语言语法也不会进行更新以支持其所有新功能。是时候转向支持现代前端工作流(例如为初学者提供npm程序包)并继续发展以满足开发人员需求的东西了。
我如何撰写帖子? />绝对没有:)。帖子的编写方式绝对没有改变。我们仍然支持您知道和喜欢的所有Prettify语言别名,以及Highlight.js中的新别名。但是,我们目前不添加对任何新语言的支持,而是选择使初始更改集保持简单,并瞄准当前功能的奇偶性。仍支持所有当前的markdown语法,以及从标记和站点默认值确定代码突出显示的内容。
那么,正在发生什么变化?
“唯一的”变化是可见的。我们正在更新客户端代码块渲染器,以在帖子(问题,答案等)和编辑器预览中为您的代码设置样式。总体上,未指定语言时的语法自动检测应该会更好,总体上应该会突出显示语法。对于典型用户而言,最大的外向变化将是我们的新主题(有关详细信息,请参见下文)。
为什么Highlight.js?为什么不呢?
我们为什么选择Prettify而不是Highlight.js?好吧,首先,您是专门要求它的。更令人信服的是,它是开源的,经过积极维护的,并且总体而言只是一个可靠的产品。
我们非常关注SO(无论是在客户端还是在服务器上)的性能,因此我们需要确保网站上最热门页面上的这一重大更改不会对用户产生负面影响。早在2016年就对Highlight.js的性能进行了一些调查,但我认为我们应该再给它一个镜头。
在我们的内部性能基准测试中,在所有浏览器中,highlight.js的得分均始终高于Prettify(除了macOS Safari 13.1,实际速度稍慢一些)2。它比Prettify3轻了一点,在包含了我们在网络上支持的所有语言之后,重量(通过电线)增加了约17kB。这种额外的增重对我们来说是可以接受的,可以作为我们获得回报的折衷。
为什么我们选择Highlight.js而不是其他竞争者?简而言之,这是满足我们需求的最佳选择。我们需要一个可以轻松控制以在浏览器中使用的库(延迟加载,特定主题的主题化),同时还易于通过npm包使用,而无需特定的构建步骤或特殊的babel插件来仅提取部件我们需要。此外,我们可以在服务器上运行它(通过Node.js),以统一我们的Stacks文档中的语法高亮显示,从而为我们所有产品提供一个语法高亮显示。还有一个主要优点是能够标记突出显示结果以供我们的新编辑器使用(敬请期待!)。
有哪些潜在缺点?
最明显的缺点是语言自动检测与Prettify不同。通常,它会更加准确,但最终可能会得到与Prettify所提供的结果不同的结果。这并不是什么坏事,因为如果您是Prettify的高级用户,那么它可能会变得有些习惯。
如前所述,整体代码束的大小也要大一些。绝大多数用户甚至都不会注意到该更改,这只会影响首次提取,因为浏览器无论如何都会在本地缓存文件以备以后点击。 highlight.js倾向于不突出标点符号,这使得它比其他突出显示符号的色彩少一些。这被认为是一个功能。无论如何,这都不是破坏交易的东西,但无论如何我都应该提到。
设计新主题
为了深入了解新主题的设计方式,我联系了作者,首席设计系统设计师Aaron Shekey。

自从我们进行升级以来,我们想借此机会设计一个Stack Overflow风格的主题,该主题利用了CSS变量等新技术,该技术可以识别亮和暗模式。尽管我们已经对其进行了改进,但当前的生产主题很可能仅使用Prettify提供的原色。
我们需要一个可以在明暗模式下均可使用的主题Stack Overflow的品牌色彩,并在整体上引入了更多的对比度。
幸好,我们并非从零开始。在构建Stacks文档时,我们花了一些时间制作Jekyll主题显示代码段,这些代码段非常接近实现这些目标。但是,这是在黑暗模式之前的事情,我们只建立了一个假定固定黑暗背景的主题。我们必须将此主题扩展到浅色模式,并在此过程中重新查看对比度。
使用Stacks文档作为游乐场,我们现在可以在浅色和深色模式下找到主题,看起来像Stack Overflow,并添加或保持对比水平。我们竭尽所能,以达到AAA的对比度水平,其中一些变量浸入了AA中。您可以在我们的颜色常量文件中看到评论的确切测量值。

以下是从我的本地开发环境中获取的新主题的一些屏幕截图(单击图像以将其展开)。您可以在Stacks文档中预览更多语言(通过轻松的暗/亮模式切换)。
之前

之后

常见问题解答


Q:何时推出?


问:如果我发现错误,该怎么办?
A:报告此问题的答案中的错误(每个答案一个)。我们将在几个几个星期(直到10月2日星期五)之前保持开放状态,以解决所有即时问题,然后我们将更新此帖子,并请您在此之后将错误作为新问题发布。


脚注
1我检查过,复数语法是语法。以那个拼写检查器为准。
2个客户端基准测试是正确的,根据机器和浏览器的不同,我们测得的操作速度每秒提高〜49%-60%。 Safari 13.1的异常值减少了29%(有利于美化),而Edge“旧版”的评分比美化了〜279%!
3通过比较生产中的prettify-full.en.js文件与新的highlight.pack.js软件包进行了大小比较。两者都经过缩小,并通过设置了compress标志(启用gzip支持)的webpack-dev-server实例进行服务。然后将它们包含在带有script标签的常规html页面上,并使用内置的浏览器开发工具进行测量。在进行测量时,prettify通过电线降落在23.3kB上(意味着文件已缩小+ gzip压缩),而高亮显示在40.7kB上。这是17.4kB的增加,或者文件大小的增加了约74%。

评论

很高兴看到Teams开发人员也在将功能引入公共网络!

然后,我需要进行一些更新,例如,关于这一点:语法荧光笔的默认语言是什么? ...

@rene我有一个(不完全确定的)帖子列表,此列表发布后需要更新。我将其添加到列表中。感谢您引起我的注意

我希望突出显示语法的FAQ(在此处和在MSO上)也都属于该列表。

@SonictheMaskedWerehog是的,他们俩都是!感谢您的入住。安全性胜过遗憾,因为它们是此功能的“真相之源”。

当被要求突出全能时,它有多严重cho住? (是的,这是单段代码,是294种语言中每种都不同的有效程序。)

@Mark老实说,还不错。速度(在视觉上实际上并没有对其进行基准测试)与我的测试页相当,上面有16种不同的语言。出于好奇,自动突出显示检测将该代码段标记为bash。

@SonictheMaskedWerehog为什么将资源投入到非核心产品中?

@Braiam我以为SO是他们的核心产品。语法高亮是其中的核心部分。

问与答是@Sonic的核心产品,而不是语法荧光笔。语法高亮只是其中的一小部分,对平台的成功并不重要。 Stack Overflow不需要所有权或控制权。就像您不应该开发自己的JavaScript框架一样,当已经有了可以很好地完成工作的工具时,也不应该开发所有自己的工具。

如果突出显示发生在客户端,那么允许用户指定highlight.js模板的功能又如何呢?如果SO上的代码看起来与我的IDE相同,那将非常酷。熟悉的(彩色)样式使代码更易于阅读。

请问您的问题作为答案,因为这为Ben提供了更多单独回答的空间!

无论您做什么,都不要更改代码块的行高

不要忘记更新此页面以提及Highlight.js而不是Google Prettify。

@Clonkex已经很好了!您可以在该页面的元版本上看到更新(打开后会自动发生)。虽然很好看

#1 楼

Stack Exchange能否定期(而不是仅根据请求)定期更新Highlight.js的更新版本?
正如我在之前的报告中所说,Google停止了Prettify的工作,即使用语法提交错误和功能请求的过程突出显示会很费力,并且会花费不必要的时间。流程如下:

向Prettify提交错误,如果有的话,将需要6-8个月的时间来解决。 (我在2014年提交了一个错误,但在Google将该项目搁置时,该错误仍未得到解决。)到较新的版本。这通常需要6-8周的响应时间,但通常会比大多数请求花费更长的时间,因为据我所知,只有在开发人员偶然发现它们时才采取行动。据我所知,Highlight.js的维护非常活跃,并且对它的请求都得到了很快的解决,因此,#1不再是问题(至少在当前期限内不是)。但是,如果SE坚持使用仅根据要求仅更新到较新版本的现有模型,则#2仍然是个问题。据我所知,它们发布后会立即变得繁重),而不是仅根据请求更新到新的荧光笔版本?这将消除#2中的问题,并使整个过程大大加快,因为只需向Highlight.js提交错误或功能请求即可,并且可以很快在SE中修复。

评论


评论不作进一步讨论;此对话已移至聊天。

–本·凯利♦
20-10-30在21:29



#2 楼

我感到很沮丧,因为我无法轻易看到前后图片之间的差异,因此我做了一些剪切和粘贴操作,因此可以并排查看一下前后,以便更轻松地比较它们。然后我想到其他人可能也想这样做,所以请随意看看。应该与问题中的基本信息相同,但要安排得更有意义。
首先暗模式:

然后亮模式:

对不起,我的裁剪效果还不是很完美,因此(尤其是在浅色模式下),您会看到一些实际上不应该出现的暗线。但是,即使有一点多余的垃圾,至少您也可以做一个真实的比较,这样变化就可以很明显地体现出来。
对我来说,新的配色方案似乎至少存在几种不同类型的问题。 br />一是技术准确性(即令牌化本身的准确性)。例如,在Python示例中,if是一种颜色,None是另一种颜色(010b101以及someFuncSomeClass看起来是相同的颜色)。 ifNone都是关键字,因此看起来相同的颜色是合理的。两个关键字使用明显不同的颜色,而其中一个关键字与某些标识符和文字值使用相同的颜色似乎并不合理或没有用。
另一种选择是颜色本身。一般来说,为了舒适地观看,我们希望在两个极端之间取得平衡。如果颜色之间的差异太小,则并不总是清楚两件事是相同还是不同。当无法轻松区分颜色时,我们就失去了使用颜色作为起点的很多好处。
同时,我们并不需要太多的对比度,尤其是当两个物体彼此相邻时。如果执行此操作,则观看变得不舒服1。
在这种情况下,我们看到了第一个问题。如前所述,在Python示例中,NonesomeFuncSomeClass100b101都以看起来相同的颜色显示。可能这并不是一个真正的解析问题-也许是为每种颜色分配了唯一的颜色,而且它们恰好是如此相似,以至于我们无法区分它们。
旧的配色方案还区分了类名和函数名,新名称似乎都使用相同的颜色。鉴于它们都是语法上的标识符,因此有争议的是,这不会影响准确性(因此),但是对我来说,很明显,旧方案正在提供更多有用的信息。
在黑暗模式下图片中,我们至少可以看到一些明显对比度过高的案例。最明显的是在深黑色背景下以亮白色显示的参数(param1param2)。在这种情况下,我们显然已经超出了大多数人可以舒适看待的对比度范围。顺便说一句,在某些情况下,打破或至少弯曲此规则稍微更合理一些。例如,如果您要为面积很小的物体(例如,句号或逗号)着色,则通常可以得到比面积较大的对比度更高的对比度。
至少在我看来,在这方面,新颜色的灯光模式版本至少要好一些。我们仍然将None着色为与标识符和文字匹配,并与if不匹配。另一方面,在这种情况下,背景为浅灰色,而参数名称则为较深的灰色,因此对比度范围要容易得多。
在广泛的受众群体中,我们也希望配色方案能够很好地解决视力受损的人们。最常见的色觉障碍称为申黄体异常。如果通过筛选器运行图片,则可以看到近似的外观模拟。例如,下面是具有模拟申命规则的Python轻型代码:字面量(例如'gre\'ater')可能不太接近,以至于我认为这方面显然是失败的,但这足以使我至少有点不舒服(至少在为有色觉缺陷的人提供服务方面) ,这几乎完全是彻底的失败。)
在这方面,旧的配色方案显然是优越的-尽管在某些情况下对比度肯定会降低,但是所有以单独的颜色开始的东西仍然很容易区分。 >当然,还有其他形式的色觉不足,甚至包括真正的完全色盲。幸运的是,这种情况很少见。申命记是最常见的,对付它通常也会对大多数其他不太常见的情况(例如,Protanomaly,Tritanomaly等)产生良好的效果。
不幸的是,很难自动检测当颜色具有足够的对比度以使差异易于看到时。可以通过计算“ delta E”来告诉您两种颜色之间有多少差异,但是眼睛很容易被欺骗,因此(例如)周围环境可能会使具有相同颜色的两个区域看起来明显不同,或者使具有不同颜色的区域变得困难区分。我们希望在这种情况下(最好是对系统进行改造,影响过多的页面以致无法单独查看每个页面)最好是摆脱明显的问题。


现在很少相关了,但是在CRT时代,您可以在此方面做更多的事情,因为单个像素的边缘往往具有一定程度的渐变,因此即使最亮的白色与最暗的黑色仍然至少具有一定程度从一个到另一个的梯度。不过,对于LCD而言,情况并非如此,因此我们必须更加小心,因为该技术已不再涵盖我们的错误。


评论


但是,孤立地查看各个颜色之外,我们看到的对比度太高。深色背景上的变量名的亮白色实在令人痛苦。用于函数名称的Haloween橙色与上述腐烂的绿色形成强烈反差。

–杰里·科芬(Jerry Coffin)
20 Sep 9 '20 at 6:48

从功能的角度来看,新的配色方案也存在问题。例如,类名称,函数,数字文字和无(在Python示例中)似乎使用相同的颜色。其中有些甚至在语法上都可能无法感觉到-例如,在Python中,if和None都是关键字,但是新的着色器为它们提供了不同的颜色。

–杰里·科芬(Jerry Coffin)
20 Sep 9 '20 at 6:54

哦,以防万一出现这个问题:是的,我会定期校准显示器,并保持背景照明足够暗以确保我的眼睛几乎完全适应显示器的白点,而不是房间的白点。 (尽管在任何情况下,它都是标准D55光源的相当合理的近似值)。

–杰里·科芬(Jerry Coffin)
20 Sep 9 '20 at 7:07

我喜欢旧颜色,因为它们看起来像Visual Studio。新颜色真的很奇怪(尤其是绿色的字符串,我总是将其与评论联系在一起)。

–Métoule
20 Sep 9 '20 at 8:01

我不同意新方案的全部内容,尽管显然这是一个主观考虑,并且他们永远不会让每个人对该领域的任何变化(或没有变化!)感到满意。但是,正如@Métoule所提到的,由于几个非常常用的工具都将绿色用于注释,因此字符串文字的绿色可能是个问题。我喜欢您将评论保留为灰色。无论如何,我发现突出显示的内容和对比度水平远比特定颜色重要,只要我能看到对我有所帮助的关键事物,我就会很快适应新的配色方案。

– David Spillett
20年9月9日在9:49

成功地对设计变更进行了指责-具体问题可能应该存在于问题中,尤其是诸如“其中某些甚至在语法上可能无法感觉到的东西之类的东西-例如,在Python中,if和None都不是关键字,但是新的着色器给了他们不同的颜色。”人们发现平淡无奇的东西通常是个人品味的问题

–游侠怪胎♦
20 Sep 9 '20 at 10:37

@Métoule我使用的IDE的字符串为绿色,注释为灰色。

–橙色狗
20/09/9在13:48

感谢您创建前后并排拍摄。除了“我同时拍摄旧照片并同时拍摄新照片”以外,我没有任何有意识地创建它们的方法。我会将您对配色方案的反馈传递给设计师。我确实看到您关于某些颜色可能不匹配或不匹配其他IDE的观点。我将做一些交叉引用,看看我们是否可以在其中进行一些调整以获得快速的胜利。

–本·凯利♦
20 Sep 9'在14:28
旁注:我发现您评论中的信息非常有帮助。我建议将其添加到您的帖子中,以帮助充实声明/请求,并有助于阻止“个人口味”与“特定问题”的反对意见

–本·凯利♦
20 Sep 9 '14:30

特别是在Python中,None和if都是两个关键字,但是它们具有不同的语义角色:if是控件结构,None是常量。以不同的颜色突出显示它们在IDE中很常见,实际上我认为这样更好。

– zwol
20/09/10在12:59



@zwol:我至少可以看出这种思路的一些优点。我个人的偏好是从高层次开始,使事物或多或少地具有层次结构,例如(关键词)用绿色阴影表示,而值用蓝色阴影表示。在这种情况下,我可以看到在哪里有意义可以说,“无”或多或少是蓝绿色,以准确地反映出它是在值上下文中通常使用的关键字。

–杰里·科芬(Jerry Coffin)
20/09/10在18:10

嘿,杰瑞,谢谢您的更新答案-真的很棒。 :D

–Catija♦
20 Sep 10 '18:49

在IDLE,repl.it(在线IDE)和PyCharm中,如果和None默认为相同颜色。

– Rainbolt
20/09/14 '14:12

如果旧的配色方案更好(在我看来是这样),是否可以为新的荧光笔创建一个“主题”以匹配旧的荧光笔的配色方案?

–山姆·沃特金斯(Sam Watkins)
20-09-14在22:19

#3 楼

我想说我很感激这篇文章。
它很清楚,非常有用,非常详细,向我展示了人们对社区的关注。
当然,总是会有不同的意见。结果(“我更喜欢前一个突出显示”,“我更喜欢新的突出显示!”),但这是不可避免的。
我发现改变(和选择)足够引人注目的原因,由此产生的亮点令人愉悦。眼睛。
(我担心一些事物以相同的颜色显示:这是不可避免的。突出显示是要使连续的部分具有不同的颜色,从而使过渡可见,并且整体结构看起来,并且不要让所有内容都有其特定的颜色)
@ ben-kelly,谢谢您提供信息

评论


谢谢你的客气话!我很高兴这个帖子引起您的共鸣。如果您对某些看起来很有趣的项目有任何特别的关注(无论是整体还是特定的语言),我也很乐意提供

–本·凯利♦
20 Sep 9 '14:56

@BenKelly:谢谢!关于更正:我会让别人比我更好的回答(到目前为止,我个人认为还可以。在将其验证并充分强调之前,暂时将其保持在“默认/原始”状态可能是一件好事。测试,除非指出一些明显的问题)

–奥利维尔·杜拉克(Olivier Dulac)
20 Sep 9'在15:07

@BenKelly:我只是建议(可能已经完成):对具有几种“色觉缺陷”的几个不同的人进行测试,因为这是一个常见的问题,并且影响到很多人(某些网页或图表仅依赖于颜色以传达一些信息,但并非所有人都可以使用。)只要有可能,其他方式(图形,符号,斜体等)也会有所帮助(对于语法着色,没有太多选择,但是对比度或粗细可能有助于帮助区分某些颜色。我很确定.js的开发者考虑到这一点:它甚至可以解释他们的颜色选择?)

–奥利维尔·杜拉克(Olivier Dulac)
20 Sep 9 '15:16

信不信由你,我们实际上确实使用Chrome的新版Emulate视觉缺陷工具进行了一些测试。您可以在公共Stacks PR上看到我的一些评论(含图片)。显然,仿真不是完美的,但绝对比根本不检查好。

–本·凯利♦
20 Sep 9'在15:29

@BenKelly:很高兴知道!

– V2Blast
20 Sep 11 '20 at 0:46

#4 楼

bug status-bydesign

<!-- language-all: lang-none -->提示似乎不再起作用
这篇文章在顶部显示了<!-- language-all: lang-none -->提示,以防止突出显示其中的所有代码块。我尝试将lang-none更改为none,但仍然无法正常工作。 (正如您在帖子中所说,即使更改后,Prettify标识符仍将继续工作。)
在进行CommonMark迁移时,我们被告知<!-- language-all: [language] -->提示将继续受到支持,这与之前的<!-- language: [language] -->语法不同
,此问题似乎特定于lang-nonenone提示,这是这种HTML注释样式的一部分;其他的似乎工作正常。例如,此帖子包含这样的注释以指示C作为突出显示语言,并且以下代码段在C中突出显示:
 #include <stdio.h>
 

(为了进行测试,我还更改了注释以指示Python,并将上面的内容突出显示为Python。) br />
 ```none 

总结:```lang-none#include <stdio.h> 似乎无法禁用特定文章的语法突出显示。

评论


感谢您的报告。今天将对此进行调查。

–本·凯利♦
20年9月11日14:04在

@BenKelly一个星期后,评论有什么结果?

–好奇号刺猬索尼克
20 Sep 19'5:08

抱歉,忘记回复此邮件。当前,此功能与尚未打开Highlight.js的其他站点相同。例如,尝试使用Stack Overflow(仅预览,无需发布!)。 language-all仅适用于未设置替代语言的块,例如通过代码围栏字符串或常规语言注释。

–本·凯利♦
20-09-21在19:49

@BenKelly仅供参考,我们等同于“无语言”是“明文”,而CSS则是“不突出”。当然,您也可以在SO端自由处理它,而无需执行任何操作。

–乔什·戈贝尔(Josh Goebel)
20-10-7在17:02

@JoshGoebel是的!我将别名从无添加为纯文本。轻松修复以弥合差距

–本·凯利♦
20-10-7在17:41

#5 楼

尽管这里我会添加一些简短的注释,但是Highlight.js的当前维护者。这被认为是一个功能。无论如何,这都不是破坏交易的东西,但无论如何我都应该提及。 (与现有主题配合使用,而不是具有侵略性等)。 https://github.com/highlightjs/highlight.js/issues/2500

我向您保证在启动时将支持Mathematica Stack Exchange。由于mma语言定义的内容很大,因此该语言实际上已与其他语言分开了。 ..我不确定Mathematica是不是一种这样的语言。我们的某些语言非常繁琐,因为关键字方法更简单(更准确)。就是说,仅分解文件并根据需要加载它们可能是某些较不流行语言的最佳解决方案。并且也会有助于自动检测速度。

例如,在Python示例中,如果是一种颜色,而“无”则是另一种颜色(对于0,它看起来是相同的颜色, 1、0b101以及someFunc和SomeClass)。如果和None都是关键字,

我们总是以不同的方式突出显示文字和关键字。对于Python,目前将FalseNoneTrue定义为文字。

前5个内联注释根本不解析为注释。一个简单的解决方案),GitHub问题将不胜感激。 :-)

汇编语言的语言自动检测似乎已损坏。

自动检测是在“尽力而为”的基础上进行的……摘要越小,自动检测的效果就越差,但是某些语言比其他语言难于自动检测。如果您真的认为有一个明显的问题(一个巨大的代码片段不断地被错误地标记,等等),那么GitHub问题将非常受欢迎...

汇编语言的不同风格使用不同的注释字符,所以这是一个棘手的问题。

的确如此,为什么要有多个汇编语法,而不仅仅是一个语法。正是因为这个原因,我不知道是否可能只有一个语法。

评论


离题评论:此页面上指向您的GH个人资料的链接已断开,它们指向github.com/yyyc514,该链接不存在。你能解决吗?

–影子向导正在接种疫苗
20-09-21在14:45

我不确定我是否可以更新网站本身(我会问-它仍然由原始作者管理),但是我已经更新了GitHub上的CHANGES.md文件,在将来的发行说明中它将是正确的。还添加了一个占位符/指针配置文件,因此将来没有人会迷路。感谢您指出!

–乔什·戈贝尔(Josh Goebel)
20/09/21在15:02



好招,@ Josh。谢谢!

–影子向导正在接种疫苗
20/09/21在15:30

@JoshGoebel非常感谢您的签到!能够使用Highlight.js感到非常兴奋。我已经针对它编写了几个项目,我可以说我大部分时间都在挖掘它。期待尽快回馈该项目。找到时间后,我有一些建议/要求反对;)

–本·凯利♦
20-09-21在19:35

@JoshGoebel我认为,相当多的SO用户都希望看到无论哪种语言的颜色都与普通IDE的颜色匹配。目前在SO上不支持(例如,对于C#和VB.NET,字符串为绿色而不是紫色)。着色是由于Highlight.js还是SO的定制?

–安德鲁·莫顿(Andrew Morton)
20/09/30在15:52

@AndrewMorton通常,SO通过其自定义主题来控制颜色。我以为目标是使它在整个平台上看起来基本一致-而不是让每种语言都具有完全自定义的外观。那是我的理解。

–乔什·戈贝尔(Josh Goebel)
20-10-1的16:56

#6 楼

😄感谢您这样做!我对这个结果感到满意,因为我是2016年改用Highlight.js的主要支持者。
太好了! …但是发生了什么变化?
为了满足我自己的好奇心,我想知道您是否对2016年到现在之间的变化做出了解释或理论,以使转换可行。奥德(Oded)的绩效分析似乎提出了一些重大问题,您的帖子表明它们不再是问题,但我看不到事情发生变化的原因。例如:
2016年的大小:

[太大]…每天至少有5kb的最小空间,可满足每天数百万个请求的需求...仅随着添加更多语言而增长。 br />
现在的大小:

…包括我们在网络上支持的所有语言之后,额外的〜17kB(通过线路)。体重的增加是我们可以接受的,可以作为我们获得回报的折衷。

2016年的速度:

…(别忘了-我们拥有很高的嵌套的DOM,以及许多“基准”都在一个非常简单的页面上完成-这并不表示Stack Overflow的性能)。 …在我的测试中,highlight.js的CPU时间是比prettify高出2到4倍……我也通过在高亮显示调用中使用console.time进行了测试-Highlight.js始终比prettify差。

现在的速度:

在我们的内部性能基准测试中,highlight.js的得分要比Prettify始终要好。。。 / CDN,还是仅仅因为其他人在做决定?当然,每天的请求数量自2016年以来仅增加了吗?
您是否了解Oded在2016年进行了哪些性能测试,为什么现在的结果如此不同?内部性能测试基础架构是新的吗?
是否对“高度嵌套的DOM”进行了根本的技术更改以使突出显示效率更高?还是对highlight.js本身进行了重大的性能改进?
再次,我很高兴现在进行了更改—我想知道是否有正当的理由等待4年,而更改的原因是什么?那时。我们可以采取其他措施来鼓励人们尽快采用吗?

评论


好吧,一方面,发布了版本10,该版本使用的是EC2015,IE不支持该版本。但是,由于SE早已淘汰了IE支持(并于去年删除了所有IE特定代码),所以这不是问题。

–好奇号刺猬索尼克
20年9月9日18:00

同样发生的是亚科夫。一月份,我设法在他身上得到了一些低调的水果Prettify FR,这可能已经触发了他,足以使他们意识到他们已经走到了尽头。我们很荣幸成为社区倡导者。

–rene
20 Sep 9'在19:22

我认为一个很大的因素是美化不能作为“现代”软件包使用并且不再得到维护的问题。这对应用程序的可维护性产生了重大影响,而这种影响并不直接显而易见。从2016年到现在,缓存基础设施也发生了变化,四年时间已经足够OSS团队改善性能...

–Vogel612的影子
20 Sep 10 '20 at 10:51

我看过这篇文章,并没有忘记它。我正在与我们的架构团队联系,以草拟一个令人满意的答案,因为在基准和大小变化的前提下,它们是对更改做出最终决定的决定。

–本·凯利♦
20/09/10在14:13

@rene不要完全认为这是负责任的。我认为,我后来在6月发布的有关Prettify被Google终止的帖子也不负责任,因为它最初暗示要创建一个新的本地SE语法突出显示工具,这可能导致该帖子在内部被降级。我认为真正的触发因素是Ham Vocke在CommonMark上的帖子,有人问过是否会更改语法高亮显示,对此Ham的回答是“一旦CommonMark全面推出,我们会考虑的”,我认为它已被放置在当时的内部雷达上。

–好奇号刺猬索尼克
20/09/11在19:21

更改的主要内容是Prettify已停产。如果在我进行分析时是这种情况,那肯定不是一个选择,我将不得不评估一些不同的选择。我相信@BenKelly在这里打了正确的电话,并且我相信架构团队会为此提供帮助,以确保将影响降到最低。事实是-停产的图书馆必须要更换。

–奥德
20-10-29在21:44



#7 楼

不支持C
Highlight.js中没有C语法突出显示器。 Highlight.js将C ++荧光笔用于C,这是一场噩梦。实际上,与没有突出显示相比,使代码更难阅读。我在Stack Overflow上看到一则帖子,其中相同的两个令牌struct List以3种不同的方式着色:

是的,我检查了lang-c是否在使用中。逻辑,它检测以struct List开头的子句是一个声明,然后将整个行涂成棕色:
 struct List *newnode = (struct List *)malloc(size * sizeof(struct List));
 

,但这不是无论如何,它都是有用的,如果您实际上使用了typedef List,那么它的颜色会有所不同:
 List *newnode = (struct List *)malloc(size * sizeof(struct List));
 

其他所有C语言荧光笔,我见过颜色标记类,无上下文。例如,令牌struct(一个关键字)应该始终具有相同的颜色。
(尽管,由于在struct X中,X是一个标记,因此可以与X(即typedef或变量或函数名)区分开来)

评论


这是一个悬而未决的问题:应该将C和C ++拆分(并且C ++也需要大大改进)。与荧光笔的几乎所有语言级别的改进一样,这是“需要帮助”的,也就是说,如果没有人提交拉取请求,就不会发生。

–康拉德·鲁道夫(Konrad Rudolph)
20-09-30在10:38

@KonradRudolph为什么不希望解决此问题?还是从lib的角度来看这是需要帮助的?

–Rob Grant
20-10-2在10:03



@RobGrant帮助从图书馆的角度出发。当然,SO希望对此进行修复,但是我目前还没有看到他们将任何开发资源投入到Highlight.js。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-2在10:16

谢谢;说得通。我可以肯定地说,如果SO正在使用此lib而不是编写自己的荧光笔,那么如果他们希望语法高亮起作用,就应该添加此支持。

–Rob Grant
20-10-4在11:07

实际上,我已经针对此特定的错误提交了一个新的问题,因为没有一个现有的问题可以直接解决该问题:github.com/highlightjs/highlight.js/issues/2736 —作为进一步的解释,highlight.js不会试图解决这个问题。上下文无关(与您的主张相反,Antti,也没有其他许多广泛使用的荧光笔)。特别是,它尝试识别函数和类/结构的声明,并分别突出显示它们。这提高了可读性,很难正确理解。当前,它仅查找struct关键字的存在,这是不够的。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-5在8:54



@KonradRudolph多数这样做,它们还根据AST不仅解析令牌,还解析源代码和颜色。特别是在C ++中,如果不分析整个源代码就不可能正确。如果x是类型,则int a(x)是函数声明,如果x是对象,则int a(x)是带有构造函数调用的变量声明,您仅通过处理所有包含就可以知道这一点。

–安蒂·哈帕拉(Antti Haapala)
20-10-8在11:42



@Antti我很清楚标记化C ++代码的可能性。但是,与您所说的相反,许多现代语法标注工具都尝试在不解析的情况下为令牌分配含义。尤其是GitHub的语法荧光笔和VS Code(无语法分析模式)在根本上存在相同的问题;他们的工作稍好一些,但仍然做错了(请参阅第二个链接)。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-8在13:52



无论如何,将C和C ++标记器分开可以使我们至少获得100%的C权利,而我正在为此努力。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-8在13:52

#8 楼

如果highlight.js支持一种语言但Stack Exchange不支持该语言怎么办?
有一个完整的Mathematica StackExchange,因此Mathematica语法突出显示对我们来说非常重要。但是,当我做一些挖掘工作以查找SE似乎正在提供的Highlight.js捆绑软件时,Mathematica不在registerLanguage("...", ...)块中,即使StackExchange似乎正在定义它在别名集中,也就是这行捆绑包
 StackExchange.highlightjs=function(){var e={..."mma":"mathematica",...} ...}
 

被我们为之做出巨大贡献的公司所遗忘的确令人讨厌但是让我们的语法突出显示突然消失会更令人讨厌。正如我们的一个mod所写的那样,我们一直在获得对Google Prettify的自定义支持。当我们认为Highlight.js已经支持Mathematica时,缺乏支持就更加令人困惑。
......为公司Stack Exchange不需要额外支持的语言添加突出显示的协议是什么,因为Highlight.js已经拥有它。
样本代码
作为参考,以下代码块以lang-mathematica作为规范。从撰写本文时起,它呈现为未突出显示。
 pot =
  Evaluate@With[
     {
      n = 4,
      l = 1,
      c = .25,
      s = .075,
      scale = 4,
      broad = 5
      },
     scale*(JacobiP[n, l, l, #/broad] + .2 JacobiP[2, l, l, #/broad])*
       PDF[
        MixtureDistribution[
         {1, 1},
         {
          NormalDistribution[-c, s],
          NormalDistribution[c, s]
          }
         ], 
        #/broad
        ] - PDF[NormalDistribution[0, .35], #](*+(#/broad)^2*)
     ] &
(* Out: *)
-1.1398350868612364/E^(4.081632653061225*#1^2) + 4*(2.659615202676218/E^(88.8888888888889*(-0.25 + #1/5)^2) + 
    2.659615202676218/E^(88.8888888888889*(0.25 + #1/5)^2))*(5 + 0.2*(3 + (15*(-1 + #1/5))/2 + (15*(-1 + #1/5)^2)/4) + 
    35*(-1 + #1/5) + 70*(-1 + #1/5)^2 + (105*(-1 + #1/5)^3)/2 + (105*(-1 + #1/5)^4)/8) &
 


评论


我会说这是一个不包含在内的错误。我本人不太了解Highlight.js,但是由于某种原因,MMA语言JS文件位于单独的Additional-langs文件夹中(本身),该文件构建时似乎没有包括在内。似乎应该将其包括在内,尤其是考虑到它已在关键字中列出。

– animuson♦
20-09-18在4:17



很好的问题。我向您保证,启动时将支持Mathematica Stack Exchange。由于mma语言定义的内容很大,因此该语言实际上已与其他语言分开。目前,我们也使用Prettify进行此操作(请检查网络日志中的lang-mma.min.js)。我已经确保此捆绑包已创建并且可以在我的本地计算机上使用。感谢您对此进行检查,我对此表示感谢,并了解与此有关的任何潜在焦虑。

–本·凯利♦
20/09/18 '17:20

这里对“ fun”有一些额外的注释:实际上,我确实试图向主捆绑包添加mma支持,但是在gzip后增加了31.1k!这意味着一种语言的捆绑包大小增加了75%。不幸的是,这并没有实现,因此我们将继续将其作为单独的js文件提供给Mathematica.SE。

–本·凯利♦
20-09-18在17:26

我个人绝对认为这很公平,很高兴听到它将在我们的网站上正常工作!您是否对将其添加到主捆绑包感到满意呢?我们以前的高亮显示使用了trie来节省尽可能多的字节,我想知道是否值得花时间来降低highlight.js实现的影响。 (此外,请注意,MMA会定期添加需要突出显示的符号,因此,定期进行更新会非常有用)

–卡尔·兰格
20/09/18在22:28

是否可以延迟加载“外来”语言的定义?即至少对于明确指定语言的受防护代码块而言。这样,至少“高级用户”可以在不给其他人造成严重负担的情况下突出显示其“异国”语言?

–最大
20-10-1在8:11

@Max从技术上来说绝对是可能的...因此必须编写少量的自定义JS来处理类似的事情... Highlight.js的目的是使语法模块可以独立加载/获取....因此如果SO使这成为可能,则绝对有可能使Stack Overflow的单个页面加载晦涩的语言只是为了突出单个代码段。

–乔什·戈贝尔(Josh Goebel)
20-10-20在1:35

#9 楼

我刚刚尝试了以下JavaScript代码(来自Code Golf中的我的回答),因为Google Prettify无法正确解析正则表达式,后跟正确的内联注释。这就是为什么我在原始帖子中使用备用斜杠字符(我在下面将它们变成了常规的斜杠字符)。
但是现在情况更糟了,因为前5个内联注释根本不解析为注释。

 f = (                // f is a recursive function taking:
  [c,                //   c   = next digit character
      ...a],         //   a[] = array of remaining digits
  o = '',            //   o   = output string
  S = new Set        //   S   = set of solutions
) =>                 //
  c ?                // if c is defined:
    f(               //   do a recursive call:
      a,             //     pass a[]
      o + c,         //     append c to o
      o ?            //     if o is non-empty:
        f(           //       do another recursive call
          a,         //         pass a[]
          o + [, c], //         append a comma followed by c to o
          S          //         pass S
        )            //       end of recursive call (returns S)
      :              //     else:
        S            //       just pass S as the 3rd argument
    )                //   end of recursive call (returns S)
  :                  // else:
    S.add(           //   add to the set S:
      o.replace(     //     the string o with ...
        /\d+/g,      //       ... all numeric strings
        n => +n      //       coerced to integers to remove leading zeros
                     //       (and coerced back to strings)
      )              //     end of replace()
    )                //   end of add() (returns S)
 

我确定这将很快得到解决,所以这是当前渲染的图片供以后参考。 :-)


评论


这看起来像是语言处理器本身上游的错误。前几个注释被标记为包含在函数的参数中。我建议针对Highlight.js本身提交错误或提交PR

–本·凯利♦
20/09/14 '14:25

@BenKelly无论如何,Code Golf上可能有几个不错的测试用例,因为您会发现许多不寻常(但仍然有效)的编写和注释代码的方式,至少对于几种实际被标准识别的标准语言而言Highlight.js。 (显然,我们在使用的所有esolang中根本不使用语法突出显示。)

– Arnauld
20 Sep 14 '14:46

@Arnauld为此进行了公关,还修复了一个长期存在的Scala问题,该问题与我在该问题上相似。谢谢。将使其纳入下一个次要版本。

–乔什·戈贝尔(Josh Goebel)
20/09/22在15:15

@JoshGoebel太好了!谢谢。

– Arnauld
20-09-22在15:21

这应该在10.3(刚刚发布)中解决。

–乔什·戈贝尔(Josh Goebel)
20-10-17在17:40

#10 楼

LaTeX代码@中的字母应视为字母,在tex.stackexchange上可以是任意数量的示例,但
\ beamer @ leftmargin缩进上的未定义控制序列
 \begin{frame}[fragile]{E}
\makeatletter
\hskip-\beamer@leftmargin
\makeatother
\lipsum[2]
\end{frame}
 

\beamer@leftmargin是单个令牌,但beamer是彩色的,而@leftmargin被保留为未样式化的文本,这使得代码很难阅读。在代码部分中出现时是一个字母,并且在语法突出显示中是更好的默认值。

评论


似乎您应该将文件归档到Highlight.js存储库中。

–好奇号刺猬索尼克
20 Sep 25 '21:25

@SonictheMaskedWerehog我可以,尽管我不确定stackexchange是否在这里收集东西,然后报告上游,而不是一百万个stackexchange用户突然用单独的错误报告淹没了highlight.js存储库...

–大卫·卡莱尔(David Carlisle)
20-09-25在22:12

非常感谢@schtandard所提供的10.3.0版本中对LaTeX的极大改进(完全重写)。我刚刚发布了10.3.0。

–乔什·戈贝尔(Josh Goebel)
20-10-17在17:39

#11 楼

有时候我会用<!-- language: lang-none -->关闭代码突出显示,因为Prettify弄错了,没有突出显示比错误突出显示更好。 (我想到的示例是一个Bash代码段,其中#并不是注释指示器,但Prettify认为是注释指示器。)在完成此更改之后,我是否应该回顾这些帖子并再次打开代码突出显示功能?更好吗?
我想可以测试一下。

评论


老实说,我建议您只要有意识地考虑一下,就只需添加语言。如果使用代码围栏语法(我个人的喜好),则可以轻松设置语言。话虽这么说,试一试!我在Meta Stack Overflow上有一篇兄弟文章,解释了如何更改自动突出显示(无论如何在5000英尺处)。

–本·凯利♦
20-09-9下午14:33

@BenKelly,您认为强迫我们在问题中的10个代码段中的每一个上手动设置lang是可以的,例如?即使这样,它也很不稳定,仅适用于某些摘要,不适用于其他摘要。这里的例子。

–尼斯
20-09-26在17:01

这被标记为bash @BenKelly,但Prettify并未将其拾取。我将尝试再次查找该帖子,然后对其进行编辑。不记得它在哪里。

– TRiG
20-09-26在20:08

对。有用。 stackoverflow.com/a/6482403/209139

– TRiG
20-09-26在20:11

@WillNess我想现在对SO实际支持哪种语言(有了新的Highlight.js支持)有些困惑。您可以在帖子中找到完整列表,他们在其中讨论突出显示的工作原理。 meta.stackexchange.com/questions/184108/…如果未列出某种语言,则没有适当的标记方法会有所帮助。有些人感到困惑,因为Highlight.js支持一种特定的语言,但SO不支持。

–乔什·戈贝尔(Josh Goebel)
20-10-20在1:38

@JoshGoebel,例如pastebin.com它只是工作。因此,事实并非如此。我会让付费的东西担心剩下的。 :)

–尼斯
20-10-20在6:06

@WillNess单一目的站点总是更简单。 :-)如果SO稍微修正了其核心实现,然后人们开始报告剩余的问题,我想情况会有所改善。我不认为回到Prettify是一个选择,因此除非他们想要切换到其他内容或发布自己的最佳结果,否则最好是改进Highlight.js并修复任何明显的错误。 :-)您对Prettify超级熟悉吗?当我看一看(在原始代码中)时,它看起来只是一个非常简单的模式匹配器/突出显示器……这就是全部吗?

–乔什·戈贝尔(Josh Goebel)
20-10-20在18:20

@JoshGoebel pastebin也支持多种语言;多好,我不知道。但例如Haskell在那看起来超级好。因此,SO可以只使用他们正在使用的东西,如果是在内部,则只需购买东西即可。不,我完全不了解实施此操作。 (从完全切线的角度来看,某人(我)有一天第一次有机会两次见到一个新的,有点不寻常/显着的姓氏,一天两次!我的意思是您和1980年代的Randy Goebel某人)我看到今天提到的与“滑铁卢序言”有关的人....有什么机会!!?:))

–尼斯
20-10-20在18:57



(……是纯属偶然)。太巧了吧?

–尼斯
20-10-20在19:12

@WillNess pastebin.com是服务器端的样子……我想让客户端在自己的服务器上进行突出显示或繁重的工作对SO非常重要……对于简单(占用空间较小)的JS基于突出显示我知道的两个主要参与者是Highlight.js和Prism。我想他们也会考虑棱镜,尽管我很想知道是什么导致他们选择我们而不是棱镜。 (在突出显示方面,我们的确比棱镜更具野心)

–乔什·戈贝尔(Josh Goebel)
20-10-20在19:33

#12 楼

我们一直在等待Verilog和SystemVerilog(SV)突出显示很长时间。显然,highlight.js将支持Verilog,但SV将继续不受支持。还是比以前好多了。我对此更改感到满意,并感谢您的付出。
让我在此处放一些Verilog代码(来自Highlight.js演示),以查看部署后的结果。我假设语言代码为lang-verilog
编辑:我们没有得到Ben Kelly在评论中提到的Verilog支持。以下代码段没有语言代码,因此我们看到了自动检测的结果。
`timescale 1ns / 1ps

/**
 * counter: a generic clearable up-counter
 */

module counter
    #(parameter WIDTH=64, NAME="world")
    (
        input clk,
        input ce,
        input arst_n,
        output reg [WIDTH-1:0] q
    );
    
    string name = "counter";
    localparam val0 = 12'ha1f;
    localparam val1 = 12'h1fa;
    localparam val2 = 12'hfa1;

    // some child
    clock_buffer #(WIDTH) buffer_inst (
      .clk(clk),
      .ce(ce),
      .reset(arst_n)
    );

    // Simple gated up-counter with async clear

    always @(posedge clk or negedge arst_n) begin
        if (arst_n == 1'b0) begin
            q <= {WIDTH {1'b0}};
            end
        else begin
            q <= q;
            if (ce == 1'b1) begin
                q <= q + 1;
            end
        end
    end

    function int add_one(int x);
      return x + 1;
    endfunction : add_one

`ifdef SIMULATION
initial $display("Hello %s", NAME);
`endif
endmodule : counter

class my_data extends uvm_data;
  int x, y;

  function add_one();
    x++;
    y++;
  endfunction : add_one
endclass : my_data


评论


欢呼。大约..ing时间。

–汤姆·卡彭特(Tom Carpenter)
20/09/10在11:17

如果需要SV支持,建议您查阅Highlightjs开发文档并创建请求请求。我正在针对多种语言进行此操作。

–康拉德·鲁道夫(Konrad Rudolph)
20 Sep 10 '13:37

我不想成为坏消息的承担者,但是此更新没有添加任何新的语言支持(正式地。从技术上讲,Less / scss之类的子语言已被css支持所吸引)。我在开发环境上测试了此代码段,并将其自动检测为scala。话虽这么说,在我们的捆绑软件中添加更多语言在技术上是微不足道的,但是我们需要注意扩大可交付的规模。一旦我们重新考虑并决定是否添加其他语言支持,我将牢记这一建议。

–本·凯利♦
20 Sep 10 '14:10

@BenKelly感谢您提供信息。我删除了语言代码,但是scala也没有突出显示。

– Ahmedus
20/09/11 '14:37

@BenKelly为了避免bundle肿的捆绑包,是否可以根据页面上的内容动态地加载新的synxaxes? (我对diff和elixir支持抱有希望...)

–莱昂内尔·罗(Lionel Rowe)
20-09-11的15:18

@LionelRowe从理论上讲,是的。话虽这么说,但我没有研究那里的可能性或它如何影响我们(从带宽/托管的角度)或我们的用户(从UX /性能的角度)。如果我们将来决定扩展支持的语言,那么绝对要牢记这一点。

–本·凯利♦
20/09/11在17:35

我想我们已经集体等待了7年,再等等。 ¯\ _(ツ)_ /¯

–汤姆·卡彭特(Tom Carpenter)
20/09/11在19:56



@TomCarpenter您必须指的是这个问题。距7周年还有15天。 :)

– Ahmedus
20 Sep 11 '21 at 21:34

@BenKelly如果您需要提高性能,则可能需要维护两个单独的文件:highlightjs-compact(仅包含核心语言,例如C ++,Java,Python ...)和Highlightjs-all(包含更多的语言选择,包括Kotlin,Fortran, SystemVerilog,...)。

–玛蒂·乌尔哈克(Mateen Ulhaq)
20 Sep 19'2:54



@BenKelly Highlight.js GitHub上的“动态加载”语言存在一个问题,但是现在并不是一个重要的优先事项。有人也有一个插件,但是我还不会称其为“ solid”……(不确定这是否是正确的解决方法)做到这一点的最佳方法可能是“包装” HLJS(或者至少是highlightBlock) )...如果该语言有效(但尚未捆绑并且尚未加载),则发出fetch ...,然后在竞赛中只需在promise成功回调中再次调用HighlightBlock。加载时,您将应用hljs类(因此,这些块显示为未突出显示的代码)。

–乔什·戈贝尔(Josh Goebel)
20-09-21在15:51

我在我们的代码库中使用了类似的演示/原型,但问题不仅在于捆绑包的大小,而且还与网络请求的数量有关。在CDN帐单上,即使在我们最热门的网站(SO上的“问题”视图)上最热门的页面上甚至添加了一个额外的请求,都将成为谋杀手段。无论如何,这不是不可克服的,但它只需要我们规模上的额外思考/设计即可。我们希望首先弄清基础,并确保它能正常工作,然后才能真正开始处理该过程。

–本·凯利♦
20-09-21在19:30

@BenKelly有人提到了一个用于本地缓存的Web工作人员...当然,仅通过fetch / localStorage或类似的东西也可以实现同样的事情...语言语法应在补丁版本之间被100%冻结(这应该非常简单地将它们的缓存)...因此,一旦您在给定的客户端上缓存了说“ 10.3.1 / obscure_lang.js”,它将不再需要再次获取,直到您的Highlight.js版本被碰到,这会使“ 10.3.1”缓存键无效...要减少总请求数,您可以使用一个“辅助包”来加载多种语言。

–乔什·戈贝尔(Josh Goebel)
20-10-20在1:43

#13 楼

status-bydesign
会将默认代码标记更改为代码栏吗?
当前,如果在编辑器中单击代码({})图标,则所选文本仍会缩排(或不缩排)4白色

由于不赞成使用indent方法定义特定代码块(例如<!-- language: python -->)的语言的方式¹,因此按钮的默认功能不应将代码包装在
1

以前的指定突出显示语言的方法仍然可以用于HTML代码块:将HTML注释<!-- language: lang-or-tag-here -->放在<pre><code>标记之前,并且它
另外,对于四空间缩进的代码块,尚未完全删除此以前的方法,而已不推荐使用。虽然暂时仍可在四空间缩进的代码块上使用,但将来可能会/将其删除。


评论


嗨,谢谢你的举报!目前,尚未对编辑器本身或您编写markdown的方式进行任何更改。

–本·凯利♦
20 Sep 25 '15:02

@BenKelly感谢您对相关功能(特别是旧语言规范)的不赞成做任何更改,我更具体地说是要进行更改。谢谢。

–拉努
20 Sep 25 '15:08



我想说,考虑到我们在公开路线图上有一个“新编辑器”,不太可能对当前的降价编辑器进行更改。我可以确认围栏是那里的默认围栏。请继续关注有关此事的更多更新。

–本·凯利♦
20-09-25在15:11

太好了,谢谢@BenKelly回答了这个问题(答案?)。 :)

–拉努
20 Sep 25 '15:13

堆栈片段也是如此。

–贝尔吉
20-09-30在8:37

我觉得Ben Kelly从现在起应该发布所有公告。

–Rob Grant
20-10-2在10:09

我的偏好始终是使用代码围栏(```)后跟我要使用的语言(或``无'')。例如,在Swift中我执行swift 我的代码`,而对于C#,我执行`chsarp 我的代码``,如果我想显示输出没有格式,我使用“ none 我的代码”,因为将其保留为空白将使用基于问题和标签的推论。在新的编辑器中最好也让我们在此处指定它,因为很多人甚至不知道您可以做到这一点,从而使您可以在单个帖子中混合代码。

–马克·A·多诺霍
20 Dec 23'23:52



#14 楼

显然,从未支持asm / assembly作为语法突出显示语言,并且我们过去获得的相当不错的突出显示来自自动检测(大概是其他带有#;注释字符的语言。)
highlight.js的自动检测碰巧产生的汇编结果比prettify.js产生的结果要差得多,因此在实践中这里存在真正的回归。它在语法上已经很简单,并且具有规则的行格式。但是,通过将注释淡化为比其他代码少一些的颜色,确实可以极大地受益。堆栈溢出/ SE上未启用包括x86asm的Highlight.js语言,因此使用它们当然无济于事。

汇编语言的语言自动检测似乎已损坏。例如,请注意,使用Linux系统调用而不是printf使用AT&T语法将整数打印为字符串时,问题中没有突出显示。编辑完我的答案以在主代码块上使用``lang-assembly''之后,该代码块将突出显示,而其他代码块则没有。 (而且实际上看起来还不错。)
另外,NASM的语法突出显示(使用;作为注释字符的另一种asm语法)被破坏了。在表达式中减去NASM宏的意外结果中,`''lang-nasm或lang-assembly导致的混乱可能比没有糟,因为单引号用作注释中的英语标点。与<!-- language: lang-assembly -->相同的结果。
(更新:不再像几个星期前那样糟糕。注释中的撇号似乎仅影响紧缩单词的结尾,而不影响整个块的其余部分。但是此NASM语法仍然没有非常有用地突出显示块,例如注释不会变灰,只有0中的0x..是红色。至少它并没有明显差很多,或者没有差很多。支持的语言中列出了x86asm,并且Highlight.js的x86 asm荧光笔应该用于NASM语法。结果没有突出显示;我必须使用x86asm来获取当前的突出显示。)
 lang-x86asm 

以前,此元答案不是“不会突出显示语法;

SO asm答案往往比您在现实生活中受到的评论更多,因为目标受众是不了解asm基础的人们。而且SO代码块比普通的文本编辑器在水平方向上局促得多,因此它鼓励将注释保留在代码的末尾,如果在视觉上更难忽略它们,则更糟。 (尤其是在一些格式较差的初学者问答中,其中的注释参差不齐,在指令之后几乎没有空格。)有些人使用section .rodata ; groups read-only together inside the .text section msg: db "Thank you" var: db 0x34, 0x33, 0x32, 0x31 ; dd 0x31323334 ; Since you're passing these bytes to write(2), writing them separately is probably less confusing. (x86 is little-endian, so they will come out "backwards") ;; apparently you want to include var as part of the message, for some reason msglen equ $ - msg ; $ is the current position 修饰数字文字(例如ARM),因此将#;#当作注释字符并不总是有效。
如注释中所述,highlight.js具有针对几种不同asm语法的突出显示,没有通用的asm。
通过查看@[arm]之类的标签,Stack Overflow在理论上应该能够选择正确的asm语法突出显示。
对于诸如markdown中显式[assembly]覆盖的情况(这还不够显式:没有说出哪种味道),Stack Overflow可以(理论上)仍然可以基于ISA标签自动检测要突出显示的语法。例如对于带有lang-asm标签的帖子,[c] [x86]块仍可以选择x86高亮显示。 (lang-asm)。许多问题没有使用特定的汇编语法名称标记,仅x86。 (大多数非x86 ISA在广泛使用中只有一种语法;这主要是x86问题。)
为了使事情更复杂,GAS [gnu-assembler]仍使用GAS指令和注释字符,与GAS处于AT&T语法模式时相同。所以#语法问题并不是唯一的;是正确的注释字符的问题,即使我们可以依靠所有碰巧使用标记有.intel_syntax noprefix的AT&T语法的问题。
但除非/直到那件事发生,否则我猜我们应该使用以下之一标记asm块:

[att]

#(我想这是Keil的ARMASM的指令语法,而不是GAS?尽管两者之间的指令语法是相同的。)
[att]

我还没有研究Stack Overflow如何向内部支持的highlight.js事物分配任何东西。

评论


“ SO asm答案往往比您在现实生活中受到的评论更多……”我看到您还没有阅读太多我的真实汇编代码。 :-)公平地说,我经常写一个不懂基础的人,因为那个人通常在6-8个月后才成为我。

–科迪·格雷
20-09-23在0:44

实际上,在我的系统上,示例代码是突出显示的,但是突出显示根本没有任何意义。参见屏幕截图:十六进制文字无法识别;即使我将它们更改为Intel风格的34h,h仍为黑色。 “喜欢”,“为了”,“因为”是蓝色,这对于汇编也没有意义。

–俄罗斯
20-10-1在19:49

@Ruslan:是的,现在对我来说是这样,但以前没有。 (现在,如果我在编辑框中添加<!-language:lang-asm->到链接的答案中,则匹配我在SO上看到的内容,我没有保存它,因为突出显示该答案仍然比没有结果差) 。也许当P.Mort改变了。保存了修改,或者在不重新保存问题的情况下默默地更改了渲染。显然,highlight.js正在开发中。

– Peter Cordes
20-10-1在21:43



仅供参考:Highlight.js没有通用的“汇编”语法。我们目前有ARM组件,AVR组件,MIPS组件和x86组件。因此,为了获得最佳结果,SO将必须包括所有这些(或任何流行的),否则某人将不得不创建第三方通用的“汇编”语法,而SO必须将其用于标记为“汇编”的代码。

–乔什·戈贝尔(Josh Goebel)
20-10-7在17:06



@JoshGoebel:根据程序集标记用法指南,所有标记为[assembly]的问题也应标记为ISA。我已经编辑了缺少这样一个标签的asm问题来添加它。 (问题量很小,无法跟上,并且几乎可以看到每个asm问题。)例如,一些带有多个ISA的标签用于与x86事物的ARM等效问题。

– Peter Cordes
20-10-7在20:43

@JoshGoebel:但是对于x86来说,有许多不同的语法。即使使用不同的注释字符(用于x86的gnu汇编器,使用#以及几乎所有其他内容都使用;),以及分别使用AT&T和Intel。 (GAS .intel_syntax仍使用#作为注释字符)。即使问题碰巧使用了该语法,它们通常也没有被标记为gnu-assembler或att。还有一些语法,例如goasm,有些不同。我不知道其中的一些差异对于语法突出显示有多重要。但是对于非x86,标签应该很好地消除歧义。

– Peter Cordes
20-10-7在20:46

嗯,我们的x86似乎是NASM语法,或者至少是注释中所说的。 github.com/highlightjs/highlight.js/blob/master/src/languages / ... @PeterCordes我不知道您所说的所有标记是什么意思...我只是在澄清Highlight.js没有单个“ asm”或“汇编”语法...因此,除非SO选择为我们的单个语法之一加上别名,否则标签不表示任何含义-我不确定这是个好主意。

–乔什·戈贝尔(Josh Goebel)
20-10-7在21:01



@JoshGoebel:这是指Stack Overflow如何使用它,而不是上游Highlight.js。如果没有用于突出显示的特定语言替代,则Stack Overflow会通过问题上的标签检测语言。通过查看[arm]和[assembly]之类的标签,Stack Overflow在理论上应该能够选择正确的asm语法突出显示。对于诸如markdown中的显式lang-asm覆盖之类的情况(这还不够显式:没有说出哪种味道),Stack Overflow可以(理论上)自动检测要突出显示的语法。

– Peter Cordes
20-10-7在21:30

哦。我不知道它可以使用标签。我读过的大多数讨论都是关于Markdown覆盖的,是的,因此,如果他们愿意,可以将一个别名映射到多个自动检测。或使用多标签处理整洁的事情。我不确定他们实际上是否已经编写了任何逻辑。尽管我不确定,堆栈溢出可能根本没有加载这些asm语法。

–乔什·戈贝尔(Josh Goebel)
20-10-8在1:11



@PeterCordes SE不支持该语言。他们仅支持其他链接中的语言:meta.stackexchange.com/questions/184108/…。因此,这不是错误,而是向荧光笔添加特定语言的功能请求。

–Luuklag
20-10-8在9:26



@Luuklag:请稍等,所以SO从未支持lang-asm / lang-assembly吗?碰巧它会基于语法进行自动检测,并且在大多数情况下对prettify.js有用,而与Highlight.js不同呢?我想事后看来,它可能像使用#注释一样对待其他GAS代码。无论如何,实际上,它仍然是实际结果的回归,但是我们希望对其进行分类,并可能在将来对其进行一些处理。至少这解释了为什么x86 NASM语法高亮不起作用。

– Peter Cordes
20-10-8在9:40

汇编代码始终在StackOverflow上随机着色。似乎没有人在乎。尽管有另一个答案说没有颜色比错误的颜色要好,但大多数人似乎只是想要漂亮的颜色。我目前认为所有内容都是绿色语法高亮,我认为汇编通常在技术上会更好,但是并不能为人们提供他们想要的漂亮颜色,也不提供任何有用的语法高亮。

–罗斯里奇
20-10-8在17:00



@PeterCordes如果有人能找到过去确实使用过的Prettify语法的话,那将是非常有趣的,前提是它看起来工作得很好... SE总是可以选择将汇编程序强加到他们想要的任何语法上,从而提供良好的效果突出显示结果(如果他们选择不构建显式汇编语法)。

–乔什·戈贝尔(Josh Goebel)
20-10-28在3:07

@PeterCordes我认为长期SE会动态加载更多语法...(这是真正的解决方案)...但是,如果不是,他们应该考虑一些微小的自定义语法...如果您最关心的只是评论只需很少的代码就可以制作仅会突出显示注释的语法,而使其他所有内容都具有0个误报。

–乔什·戈贝尔(Josh Goebel)
20年11月6日在8:53

@JoshGoebel:正如我在回答中指出的那样,不同的汇编语言具有不同的注释字符(在某些情况下,某些字符使用#作为数字文字语法的一部分),但是可以的,对于不同的注释字符,可以使用几种不同的简单语法。是的,除了评论之外,什么也不做就可以了,总比没有好。良好的asm风格已经使大多数其他事物在视觉上变得容易。一些改进可以包括标签的颜色:标签。我可以想到的其他一些简单的事情在格式错误的asm中会有所帮助(例如insns不缩进)。

– Peter Cordes
20年11月6日在8:57

#15 楼

<!-- language: [language] -->提示会消失吗?
回到SE切换到CommonMark时,我们被告知旧的<!-- language: [language] -->语法已被弃用,将来可能会被删除。 (在实现代码围栏之前,这是强制将单个代码块与其余文章不同地突出显示的正确语法。)进行此更改后,将注释样式发布给所有人后,该注释样式是否将被删除这些网站吗?
目前看来一切正常。以下内容指定为C代码块:
 #include <stdio.h>
 

...这是相同的文本,但是作为Python代码块:
 #include <stdio.h>
 

是否有计划将其删除,或者在可预见的将来仍会保留?如果要删除它,是否仍然如我们当时所告知的那样,在删除之前呈现的帖子仍将保留它直到被编辑?

评论


目前,尚无计划完全删除对语言注释语法的支持。如果要更改此设置,我们将首先在meta上发布公告。尽管我不喜欢该语法,但我们并不能很好地替代语言-所有这些都是通用标记或我们支持的扩展语法。我没有更改Highlightjs开关的实现中的任何内容,因此任何问题都应视为错误。 (我看到了您上面报告的内容,感谢您的报告!)

–本·凯利♦
20年9月11日14:10在

@BenKelly需要明确的是,所有语言将继续得到支持;仅弃用了语言。就像您说的那样,并不能很好地替代所有语言,但是代码栅栏提示已成为当今语言的首选替代品。

–好奇号刺猬索尼克
20/09/11 '17:17

我应该指定:目前尚无计划完全删除语言或全部语言。将来可能会删除其中一个或两个(因为有一种实际的,被广泛接受的替代方法,所以语言可能会优先出现)。如果我们将来决定这样做,那么我们会提前广播更改,以收集社区的反馈。

–本·凯利♦
20/09/11 '17:33

@BenKelly我只是进一步阅读了该帖子,似乎该计划并不是要完全删除语言,而是要删除对四空间缩进代码块的支持,并保留对HTML
 块的支持。我认为从技术上讲可能很难实施,因此我认为最好的解决方案是保持原样。 (在我看来,Ham当时打算完全删除它,但是遇到了问题,因此他只是将其标记为“已弃用,可能会被删除”。)


–好奇号刺猬索尼克
20 Sep 13 '21:25

#16 楼

是否支持懒惰地加载语法?
这将允许突出显示不太常见的语言的语法,这些语言不需要在每次页面加载时都急于加载。
这是概念验证的两倍作为Tampermonkey用户脚本:

Highlight.js概念的延迟加载

自然地,它有点笨拙,但可用于以下所有示例:
```lang-diff
 - print('failure')
+ print('success')
 

```lang-elixir
 spawn_link(fn ->
  send(current_process, {:msg, "hello world"})
end)
  
receive do
  {:msg, contents} -> IO.puts(contents)
end
 

```lang-bf
 ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
 


评论


它可以在CSS上使用吗? Google Prettify荧光笔一直很难识别CSS。

–user289905
20-09-21在23:49

@ user289905它仅适用于用lang-XXX指定的语言。不过,对于CSS来说,它不是必需的,因为默认情况下它已经被急切加载。

–莱昂内尔·罗(Lionel Rowe)
20-09-22在8:02

运行此命令时,我只会收到一堆控制台警告,并且没有任何可见的效果:找不到语言“ _____”,您是否忘记加载/包含语言模块? diff,e剂和bf。

–zcoop98
20-09-22在22:54

这个概念肯定不错,但是我非常喜欢能够运行将突出显示更多语言的脚本用户端的想法。

–zcoop98
20-09-22在22:55

@ zcoop98这些警告是在hljs进行初始传递时生成的,而不是在用户脚本运行时生成的。我已经对其进行了修改,使其可以在原始hljs脚本的load事件上运行(该脚本本身是动态加载的),但这仍然不能消除警告。您可以确认运行脚本后在这些代码块上根本看不到颜色吗?目前,由于hljs配色方案,因此很难看到,特别是对于Elixir示例。

–莱昂内尔·罗(Lionel Rowe)
20-09-23在9:12

@LionelRowe我现在可以看到颜色!

–zcoop98
20/09/23在15:01



已修复以与最新更新一起使用-急切加载的运行现在突出显示未知但指定的语言,而我认为这是最佳尝试?无论如何,用户脚本的v0.4现在将覆盖它们。

–莱昂内尔·罗(Lionel Rowe)
20 Sep 25 '20:02



@LionelRowe这太棒了。不要认为您可以抑制警告,因为在Highlight.js成为第一次通过之前,您可能无法加载和更改任何内容……但是它们也没有造成任何危害。

–乔什·戈贝尔(Josh Goebel)
20-10-18在2:38

@LionelRowe为什么需要MutationObserver?

–乔什·戈贝尔(Josh Goebel)
20-10-28在3:46

@JoshGoebel至少在执行此操作时,在触发DOMContentLoaded时不存在hljs脚本,因此需要MutationObserver。我将3个条件留在底部,以防更改加载方式。

–莱昂内尔·罗(Lionel Rowe)
20-10-28在7:54

@LionelRowe这是Chrome扩展的概念证明:github.com/joshgoebel/se_highlightjs :-)扩展的好处是您可以捆绑文件,完全不需要任何CDN或外部提取。

–乔什·戈贝尔(Josh Goebel)
20-10-29在0:15



#17 楼

状态已完成
Visual Basic代码不再突出显示
控制台中的错误是:
 Could not find the language 'vb', did you forget to load/include a language module?
Falling back to no-highlight mode for this block. <pre class="lang-vb s-code-block">
 


评论


似乎VBA,VB.Net和VBScript都受到了影响,即使highlight.js中都唯一支持这3个(与prettify不同,我认为VBA只是映射到其他两个之一)

– Gredo
20 Sep 24 '21:33



有趣的是,vbs,vb,vbnet作为代码隔离的标签都导致某种默认的突出显示,某些不可靠的标签dfbdfkbk也产生了这种仿冒,就像它们未被识别一样-但是vba完全抑制了突出显示,因此略有不同

– Gredo
20 Sep 24 '21:37



感谢您的报告。我可能在这里错过了语言别名。我将仔细检查,并将更改纳入今天发布的第一轮修复程序中。

–本·凯利♦
20 Sep 25 '15:05

现在,vb和vbs会将语言设置为vbscript。我只是因为这两种语言而错过了别名:facepalm:。从我职业生涯的前半段开始,一定是某种压抑机制,主要是在VB.Net;)中进行的。 vbnet和vba(不受支持的别名)将导致代码自动突出显示。

–本·凯利♦
20 Sep 25 '19:44

@BenKelly谢谢。但是,对我来说,当前的亮点一点都不像VB :(

–GSerg
20 Sep 25 '19:53

@GSerg您是否正在查看示例文章,我可以使用该示例来重现您所看到的内容?

–本·凯利♦
20 Sep 25 '20:00

@BenKelly真的吗?例如。 stackoverflow.com/q/64017640/11683。类型声明(As String)应为蓝色,包括As。字符串文字不应为绿色。对与错应该为蓝色。

–GSerg
20-09-25在20:05

@GSerg谢谢您的更新。 “未突出显示”是Highlight.js的vbscript语言定义的缺点。至于颜色,主题应保留什么颜色。 Highlight.js推出的一部分是一个新主题,这可能会引起混乱

–本·凯利♦
20 Sep 25 '20:11

@BenKelly这真的不足为奇,因为vbscript首先没有As。它还没有其他内容,我认为这些内容也不会突出显示。可以说,在VBA,VB.NET和VBScript中,后者是代表其他两个的最不理想的候选人。那三个人当然是退后一步:(

–GSerg
20-09-26在6:52

@GSerg我已经考虑了您的评论,并决定将语法突出显示器从vbscript切换到vbnet。启动vbscript并没有特定的原因,这就是我选择的。事后看来,vbnet是显而易见的选择。感谢您提出来!更改应在明天的某个时间生效。

–本·凯利♦
20 Sep 28 '21:03

@BenKelly在查看不同语言(vbscript,vba,vbnet)的突出显示文件后,需要考虑的一个因素是后两个包含“非法”属性,例如'// | {|} | endif | gosub | variant | wend | ^ \ \ $',/ *在vbnet中保留不推荐使用的关键字* /。我相信这些非法属性只会通过告诉语言识别器是否发现虚假通知早期保释来影响默认突出显示-因为这可能与Vb.Net不匹配-但是,虚假通知在VBA / VbScript中当然是有效的。 IIUC SO标签会覆盖默认值,这有关系吗?基本上不会自动检测到某些有效的VBA

– Gredo
20-09-29在16:30



基本上,我的意思是,如果SO依赖于highlight.js自动检测,则使用vbnet(或vba)突出显示所有vb系列,将导致一些错误的负面结果,例如。代码在VBA中有效,但在VB.Net中无效。 VBScript在语法上最宽容,因为它语法最少(因此,突出显示VBA和VB.Net的工作做得很差,但是检测它们却做得很好)。如果SO不需要太多自动检测,那么这就不成问题了,最富关键字的vbnet无疑是最好的选择(ofc,所有3个单独的荧光笔都将是最佳的)

– Gredo
20-09-29在16:40



@Greedo您能告诉我在什么情况下VBScript(相对于VBA或VB.net)仍然有效并在今天使用吗?

–乔什·戈贝尔(Josh Goebel)
20-10-7在17:32

#18 楼

status-bydesign
Powershell和批处理语法高亮显示不可用,并且都无法正常工作(左:StackExchange;右:Microsoft的VS Code)

似乎批处理和Powershell语法已链接到彼此之间根本不起作用,这是因为两者之间使用变量和其他字符的方式不同:

Powershell注释使用#,而批处理使用::

Powershell变量使用$,而批处理使用%<variable>%

Powershell不支持通过&链接命令。 &&,而不是;,该批次不支持除非经过编辑,否则不突出显示语法,因为如果整个命令/参数全部为小写或全部为大写(后者也会影响批处理),则语法不会突出显示,因为Powershell不区分大小写,因此应该突出显示

在使用代码防护时,Powershell和批处理语法突出显示不会如应有的那样发生(其他语言也存在问题),无论是否在代码防护之后指定了语法-可靠地突出显示语法的唯一方法是使用HTML语法注释<!-- language-all: lang-powershell -->lang-bat(Prettify也是一个问题)






评论


评论不作进一步讨论;此对话已移至聊天。

–游侠怪胎♦
20-10-18在6:49

功能要求:请把支持PowerShell的Highlight.js版本带到StackExchange上

–康拉德·鲁道夫(Konrad Rudolph)
20-10-18在13:55

#19 楼

SQL格式问题
由于我几乎完全坚持使用SQL Server相关标签,因此我了解了sql语言格式的一些问题/功能。
哈希字符在SQL中被错误地解释为注释字符
在下面的示例中,在第一行中,#中的VIN#之后的所有内容均以彩色作为注释。在第三行,#中的#TempTable之后的所有内容。但是,这不会出现在文字字符串中,不会出现在方括号([])(由T-SQL用作分隔符)中,也不会出现在双引号(")(ANSI SQL分隔符)中。 br />
 SELECT VIN#, NTT.fID, GETDATE(),
       SYSDATETIME()
FROM #TempTable TT
     JOIN dbo.NonTempTable NTT ON TT.ID = NTT.fID
WHERE Description = 'Hello#there' AND NTT.Val = 3
  AND [VIN#] > 7
   OR "VIN#" < -12;
--This is an actual single line comment
/* 
This is a
Multiline
Comment
*/
 

#甚至不是SQL中的注释字符。单行注释用--定义,而多行用/* ... */定义。
这实际上是一个问题,尤其是当临时对象以#开头并且经常在DDL和DML示例中使用时。

进一步编辑
不将括号([])视为分隔符
在T-SQL中(如上所述),括号([])是默认的分隔符,而不是双引号("),这是ANSI分隔标识符。
如果某个关键作品在方括号内,则会错误地突出显示。例如:
 SELECT [name]
FROM dbo.[Table] T
     JOIN dbo."VIEW" V ON T.ID = V.IDl
 

我确实决定检查,但没有T-SQL变体选项:
SELECT [name]
FROM dbo.[Table] T
     JOIN dbo."VIEW" V ON T.ID = V.IDl


另一项编辑:
@字符不被识别为变量标识符
变量名不突出显示,或不受其他突出显示的影响。变量名称在SQL中带有@前缀。例如:
 DECLARE @variable varchar(10),
        @Table table (ID int),
        @Date datetime2(0),
        @1 int,
        @NonReservedWord sysname;
 

请注意,除NonReservedWord之外,所有变量名称都收到不正确的语法突出显示。

评论


Highlight.js的“ SQL”语言旨在成为非常“基准”的语言。它不会很好地处理所有可能的SQL变体。当前,它包含的内容过多(并且在列表中有待缩减)...如果某人想要“更好/更好”的MS SQL支持,那么正确的解决方案是为某人提供针对MS SQL变体的第三方语法模块。目前,除了普通的in那教“ SQL”外,我们已经有了PostgreSQL(核心)和Transact-SQL(第三方)语法。

–乔什·戈贝尔(Josh Goebel)
20-10-7在14:50



@JoshGoebel不能解释以上大部分内容。是的,方括号([])是T-SQL特定的,但是#是一个完全不同的故事,因为-和/*...*/是ANSI注释方法。 @也是变量的通用主题。其中大多数不是特定于T-SQL的。在我看来,将#错误地解释为注释是特别有害的。

–拉努
20-10-7在14:53



回复:评论。这是因为尚不存在“ MySQL” SQL语法,因此对SQL的支持受到了挤压。MySQL确实允许#条注释。这里需要做的是让某人创建一个单独的MySQL语法,然后可以简化SQL语法(删除#注释)。 ANSI SQL甚至有变量吗?将变量添加到现有的SQL支持中会变得非常琐碎(因为它目前包含太多)。我愿意接受针对添加变量的SQL的PR。

–乔什·戈贝尔(Josh Goebel)
20-10-7在15:08

根据2014年的答案,@ JoshGoebel不会(没有)。不过,并非所有语言都使用@。例如,T-SQL(SQL Server),MySQL使用@,而asPL \ SQL(Oracle)和pgSQL(PostGreSQL)不使用@。 SQLite实际上根本不支持变量。通过它的外观。我确实承认,从通用“ SQL”语言实现的角度来看,所有使用(大量)SQL实现的RDBMS确实存在许多问题。

–拉努
20-10-7在15:14

我将为SQL添加变量支持,因为这样也可以防止错误的关键字。 github.com/highlightjs/highlight.js/pull/2740/commits/…

–乔什·戈贝尔(Josh Goebel)
20-10-7在17:14

遗憾的是,SQL语法的改进并没有使它升至10.3,因为事实证明,我们将完全重写SQL语法。新语法有望在摘要上整体上做得更好,但会删除特定于供应商的(非标准)内容,例如MySQL注释。我们仍然可以使用任何想要为MySQL和Oracle创建(并帮助维护)第三方模块的贡献者,以支持这些供应商的SQL语法的细微差别。

–乔什·戈贝尔(Josh Goebel)
20-10-17在17:48



感谢更新@JoshGoebel,谢谢。

–拉努
20-10-17在18:22

如果Oracle Corp无法挽救任何人,我很乐意为Oracle SQL和PL / SQL提供帮助:)

–威廉·罗伯逊
20-11-2在23:13



SQL改进终于在10.5版中发布了一个假期版本! SE刚刚更新到10.4.1,所以我不确定何时下一次更新。 CC @本凯利

–乔什·戈贝尔(Josh Goebel)
20 Dec 23 '21:05

#20 楼

按设计状态(根据下面的发现,将其从bug手动更改为status-bydesign。)
我四处搜寻,但找不到以前引用RegEx的帖子。
突出显示复杂的表达式时有一些怪异的效果,例如,它不是在Highlight.js支持的语言列表中(Prettify支持)。从这个答案:
 (?:[a-z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
 

它有时使星号*之间的字符变为斜体,而有时却无法突出显示方括号内的字符列表[]
如果Highlight.js不支持,该突出显示方案甚至来自哪里?请参见更新RegEx是否错误地包含在FAQ列表中1?我注意到SO上正则表达式标记的默认突出显示是lang-default而不是lang-regex

Update
所以我做了一些挖掘,看来这里真正发生的是,即使指定为regex,此帖子中的正则表达式也会自动识别为Markdown。
设置与lang-markdown相同的代码段的标识符与regex具有相同的效果:
 (?:[a-z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
 

这导致了我的发现,该发现主要围绕着我原始帖子的最后一句话:

我注意到默认的荧光笔SO上的正则表达式标记是lang-default而不是lang-regex

此帖子由@TJCrowder描述,并由帮助中心支持,在将代码块标识为lang-X与。只需X即可。
根据帮助中心(强调我的意思):

您可以使用任何一种受支持的语言代码,如e lang-cpplang-sql,或者您可以指定标签,并且将使用与此标签关联的语法突出显示语言。

这对我来说是个新闻!我一直在印象中,我敢肯定还有很多其他印象,即ID X只是lang-X的快捷方式。这是不正确的。
因此,将代码段标识为regex实际上是在说“将其标识为正则表达式的已定义标识符”。恰好是lang-default,它实际上是告诉荧光笔“猜测”正确的高光应该是快捷方式的快捷方式,在这种情况下,它变成了markdown。 regex
打开控制台以查看第一个代码段,即使它被标记为markdown,它仍然会显示lang-default。我认为这是由于highlight.js的工作原理所致,它似乎从未真正更改标识符类名称本身,而是无论如何都将标识符类名称注入其下。

1-看起来像它已在9月28日(修订版100)的FAQ帖子中重新添加到列表中,并且鉴于以下发现,答案是肯定的,这是一个错误。

评论


@BenKelly我真的很想知道您是否不应该完全突出显示某些标签。突出正则表达式没有很好的猜测...您甚至不应该尝试。结果保证是差的。这可能也适用于其他一些更独特的语言,例如Br​​ainfuck等。

–乔什·戈贝尔(Josh Goebel)
20-10-20在1:45

#21 楼

Highlight.js是否支持在格式为“代码”(即缩进4个空格)的块中进行强调?
改写MSE问题:
在代码中突出显示(可以做任何事情),将是一种强调的好方法重要的部分。
目前,最好的人可以做的是ASCII艺术箭头,例如:
printf("%5s", "foo")
         ^--- add a width value

它经常发生,并且可能做得不多,因为这很痛苦又丑陋。
/>能够突出显示(在这种情况下)5非常好,方法是将其变成红色,粗体,或者用一些特殊的字符将其包围,例如!5!或其他有效的字符。粘贴复制代码块时未选择注释。

我举起手来贡献我的时间和无与伦比的软件工程技能来实现这一目标。让我知道您有github存储库时,已将我添加为贡献者,并且您有任务管理系统(例如Trello,请不要jira!)

评论


我知道,highlight.js中没有这样的东西。从技术上讲,我们可以支持差异突出显示,但这带来了自己的缺点。 highlight.js确实支持插件,因此我们可以为此编写插件。据我所知,目前这还不是我们要注意的问题,但绝对是将来要考虑的问题。

–本·凯利♦
20/09/18 '17:31

由于HTML标记将被显示而不是被视为标记,因此在代码块的情况下无济于事,但是如果是StackExchange上受支持的HTML标记,这样可以突出显示相关的文本部分,那就太好了。

–贾斯汀·M
20 Sep 18 '18:42



@ben让我感到惊讶和难过的是,我没有利用1000名愿意捐出他们的时间(他们已经这样做)来编写代码以交付功能的顶级开发人员。由于某种原因我无法理解,因此开发人员是一家封闭式商店。在这种情况下,肯定有100个属于这个社区的开发人员可以编写这样的插件。为什么不只是要求他们这样做,它就会被否决。

–波西米亚风格
20 Sep 18 '18:47

@ M.Justin是的,一定有办法。如果我们编写一个插件,我们可以选择我们喜欢的东西。例如, some.code()时未选中

–波西米亚风格
20 Sep 18 '18:53

 块可以包含任意HTML(如果编辑器允许并且它们使用传统的HighlightBlock)...因此您可以将其包装在我的代码中,然后假设有一个高亮类,则将保留HTML,并在突出显示代码时将“通过” HTML……因此,完成后,跨度仍将保留。但是需要一个CSS类。通过某种插件长期解决诸如之类的解决方案可能会更好。


–乔什·戈贝尔(Josh Goebel)
20/09/21在15:24



#22 楼

语法高亮并不总是出现在整个代码块中。
这很奇怪。我已经注意到了几种语言,不仅是SQL,而且有时高亮显示并不适用于整个代码块。当代码片段本身不完整时(这也不是有效的语法本身),这种情况似乎还会发生。
以下面的SQL代码片段为例:
 SUM(CASE WHEN SIPCOD in ('001','500') or (SIPCOD = '013' and SISHCD = 'OTA') 
         THEN 1
         ELSE 0
    END) -
SUM(CASE WHEN SIPCOD in ('501','502') and SIHRS >= 3.0
         THEN 0.5
         ELSE 0
    END) as [Days Worked]
 

即使已定义语言(使用sqllang-sql),接收语法高亮显示的第一行也是第四行(END) -),前几行没有高亮显示。下面来自SO Dark Theme的图片:

我将尝试使用其他一些语言对其进行复制并进行编辑,或者如果我看到其他示例(我肯定至少看过1个)周末在我的移动设备上使用了C#和Powershell示例)。
这又是SQL,但是由于某种原因,该代码未突出显示最后一行:
-override“> IF EXISTS (SELECT 1 FROM [135.282.123.12].tempdb.sys.tables WHERE [name] = N'##Tmp1') PRINT N'YES'; ELSE PRINT N'No';


抱歉,这再次是SQL,但是突出显示在此代码块中有很多错误。它开始,然后突然停止,然后在最奇怪的地方再次出现:
 CREATE TABLE dbo.RealTable (ID int IDENTITY);
GO

DECLARE @SQL nvarchar(MAX);
--Good attempt
EXEC dbo.CreateNewColumn @TableName = N'RealTable',
                         @ColumnName = N'SomeString',
                         @sql_dtype = N'nvarchar',
                         @length = '255',
                         @SQL = @SQL OUTPUT;

PRINT @SQL;
--Another good attempt
EXEC dbo.CreateNewColumn @TableName = N'RealTable',
                         @ColumnName = N'SomeInt',
                         @sql_dtype = N'int',
                         @SQL = @SQL OUTPUT;

PRINT @SQL;
GO
DECLARE @SQL nvarchar(MAX);
--A bad attempt
EXEC dbo.CreateNewColumn @TableName = N'RealTable',
                         @ColumnName = N'AChar',
                         @sql_dtype = N'char',
                         @length = N'CREATE USER test WITHOUT LOGIN',
                         @SQL = @SQL OUTPUT;

PRINT @SQL;
GO
DECLARE @SQL nvarchar(MAX);
--Bad parameters
EXEC dbo.CreateNewColumn @TableName = N'RealTable',
                         @ColumnName = N'SomeNumeric',
                         @sql_dtype = N'decimal',
                         @length = 7, --This should be precision and scale
                         @SQL = @SQL OUTPUT;
GO
DECLARE @SQL nvarchar(MAX);
--Good parameters
EXEC dbo.CreateNewColumn @TableName = N'RealTable',
                         @ColumnName = N'SomeNumeric',
                         @sql_dtype = N'numeric',
                         @Precision = 7, --This should be precision and scale
                         @Scale = 2,
                         @SQL = @SQL OUTPUT;

SELECT *
FROM dbo.RealTable;
GO
DROP PROC dbo.CreateNewColumn
DROP TABLE dbo.RealTable
 


评论


这是JS的代码:stackoverflow.com/a/16497499/2415524

–mbomb007
20-10-1在20:19

包含多个关键字的报价似乎使它感到困惑。可能与我的问题相同-meta.stackexchange.com/a/354944/394486

–威廉·罗伯逊
20-10-4在19:20

那是“设计使然”:当前的SQL定义仅明确尝试正确突出显示完整的SQL块。可以说这没有充分的理由-这是一个值得商design的设计决策。相同的设计决策会导致@WilliamRobertson观察到此问题。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-5在9:10

在包括完整的代码解决方案(如Code Review,@ KonradRudolph)的网站上可能是可以的,但是,Stack Overflow代码块通常不包含完整的代码解决方案,因为它们不需要这样做。强制代码块完整,有效而不是摘要是对语法突出显示的巨大损害。

–拉努
20-10-5在9:14



@Larnu我显然同意。我的评论是在解释而不是捍卫这种行为。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-5在9:15

公平地说,@ KonradRudolph,我可能误解了您的评论意图。

–拉努
20-10-5在9:16

让我们清楚,“按设计”并不总是意味着“有意”。我不确定是否有理由按原样编写SQL语法,但是我不反对改进它以减少对上下文的了解(这将改善微小的SQL代码段的突出显示-如果将它们标记为sql)。小片段当然总是很难正确地自动检测。

–乔什·戈贝尔(Josh Goebel)
20-10-7的15:01

如果语法突出显示只是在某个点“停止”,则可能是语法规则集的不足。 IE,它与规则的开头相匹配,却从未找到预期的结尾,从而导致其余内容未突出显示。

–乔什·戈贝尔(Josh Goebel)
20-10-7在15:03

#23 楼

bug
没有与任何语言关联的标签的问题都不会自动突出显示其代码块。示例:
Preloader在Angular通用SSR应用程序上不起作用
如何在Guild Discord.js中获取成员列表
请注意,如果问题至少带有一个标记,则会突出显示问题即使他们的Wiki语言是default,也要在其Wiki中使用“突出显示语言”(例如正则表达式)。带有至少一个此类标签的问题将自动突出显示其代码块。相比之下,只有带有discord.js之类的标签而没有突出显示语言(甚至没有default)的问题也不会突出显示任何代码块。
我认为,当没有标签与它们相关联的语言时,问题的代码块应该自动突出显示。也许可以消除带有default突出显示的关联与不存在时的语言关联之间的区别,除非某些事情需要它。 (或为所有标签提供default语言关联。)
所有问题至少应具有类似
 <div style="display:none" id="js-codeblock-lang">default</div>
 

但它永远不能为空,否则自动突出显示将不起作用:
 <div style="display:none" id="js-codeblock-lang"></div>
 

此问题与相关的独立版本非常相似问题:改进语法突出显示语言的自动检测。

#24 楼

support
如果根本没有打开语法突出显示该怎么办?
一个非常简单的代码块(仅带有c#标签)的问题是这样的:
/>
对于代码块:

MapperConfiguration config = new MapperConfiguration( cfg => cfg.CreateMap<Source, Dest>()
    .ForMember( k => k.Sector, opt => opt.MapFrom<MyResolver>() ) );

Mapper.Initialize( config );


由于某些原因,唯一的亮点在new上。其余c#问题对我来说都是正确的突出显示。
如果有什么不同,请在Windows上使用最新的Firefox,并且没有控制台错误。

评论


这是预期的行为。没有其他关键字可以突出显示。

–乔什·戈贝尔(Josh Goebel)
20-10-18在2:40

#25 楼

bug
我注意到在这个问题上,某些C ++代码的语法高亮部分停止了。
尤其是,它被以下代码绊倒了:
 template <class T>
ostream& operator<< (ostream& os, const skg::Triplet<T>& p_t) ;
void other_stuff_that_isnt_colored();
 

如果将运算符从<<更改为其他内容,则着色会继续
>
,但是template <class T> ostream& operator+(ostream& os, const skg::Triplet<T>& p_t) ; void other_stuff_that_is_colored(); 关键字的颜色是标识符颜色,而不是关键字颜色。
如果删除了operator零件,则颜色正确。
 template <class T> 


评论


当我发布我的第三个消息时,没有注意到这个答案。很高兴以为我没有发疯,并且在其他语言上也看到了这一点! :)

–拉努
20-09-29在12:48

见github.com/highlightjs/highlight.js/issues/2716

–康拉德·鲁道夫(Konrad Rudolph)
20-10-3在12:45

我相信这已在10.3.1中修复。

–乔什·戈贝尔(Josh Goebel)
20-10-20在1:46

#26 楼

TikZ环境中的LaTeX高亮显示是错误的。
请参阅https://tex.stackexchange.com/a/564540/38080:

宏参数中的换行符似乎会使解析器...
谢谢!
PS:可能是这样:https://github.com/highlightjs/highlight.js/issues/2709 ...

评论


问题不是换行符,而是嵌套花括号的问题。 }后,荧光笔认为它不再位于参数内,并开始在外部(即橙色)突出显示。比较\ foo {\ bar} \ foo {{} \ bar}。有关另一个清晰的示例,请参见tex.stackexchange.com/questions/564420/…。

–马林
20-09-28在20:14



#27 楼

Bash突出显示似乎已损坏。
 echo "$(true)"
echo $(true)
 

您可以看到,第一个子shell中的命令未突出显示,可能是由于引号,但第二个是(无引号)。都应突出显示。
添加PNG图像以防万一。


评论


感谢您的举报!这看起来像一个上游问题。该语言已被正确检测为bash,因此出现问题是由于Highlightjs语法定义本身引起的。

–本·凯利♦
20-10-6在15:17

正确,当前字符串中的$(...)仅匹配为“ subst”(字符串中的特殊代码),没有对子shell进行进一步的递归处理...这应该是可修复的...

–乔什·戈贝尔(Josh Goebel)
20-10-7在15:23

在Ben发出消息之后,我查看了Highlight.js问题,似乎已经报告了类似的问题。突出显示此特定情况有助于用户发现错误(即使他们在提交答案之前应尝试自己的代码;)。

–阿尼斯·拉德拉姆(Anis Ladram)
20-10-7在23:19

#28 楼

状态已完成
没有Objective-C高亮显示
我评论说Objective C的高亮显示令人失望,但是我被告知要打开一个错误,因为这不是Highlight.js的问题,而是Stack的问题溢出未应用它(它改为应用C突出显示,因此我看到的突出显示是有意义的)。
bug

评论


感谢您的举报!这实际上是由于目标c语言从类c语言中分离出来的,并且标记仍指向旧的语言代码。我今天将解决此问题。好赶上!

–本·凯利♦
20-10-5在17:14

此修复程序现已生效。现在,所有带有Objective-C标签的帖子都将正确分配lang-objectivec语法,而不是lang-c。

–本·凯利♦
20-10-6在21:06

@BenKelly更好,它现在可以识别类名和声明,但是它不突出显示方法和属性,因此看起来仍然没有突出显示。它可以选择样式,还是对目标C而言,highlight.js不好吗?

–厄瓜多尔
20-10-7的16:19

传统上(作为一项策略),我们没有突出显示方法的派生或属性,但是现在我们对此更加开放,并在易于检测的情况下欢迎PR。参见github.com/highlightjs/highlight.js/issues/2500。有一些工作要做,以确定如何突出显示它们,是否需要添加新的CSS类,等等。因此,如果您想提供帮助或加入讨论(或从事PR的工作)随时可以这样做。 :-)

–乔什·戈贝尔(Josh Goebel)
20-10-18在2:48

#29 楼

PL / SQL有点奇怪(或SQL-我不确定是否真正支持PL / SQL。可悲的是,语法高亮显示插件不受欢迎。)
引用的SQL语句似乎失败了
 select blah into blahblah from blahblahblah;  -- Semicolon here seems to do it

xxx := 'select select';

Quoting is now reversed.
 

看看其他与SQL有关的问题,我看到了语法高亮并不总是出现在整个代码块中,还有一个示例,其中引号被包含SQL关键字的引号打断。
后代的截屏:出现在这里:https://stackoverflow.com/a/64183788/230471
编辑:
标记为Lua似乎更适合引用:
 select blah into blahblah from blahblahblah;  -- This is a comment

xxx := 'select select';

Quoting is not reversed.
 


评论


Highlight.js不支持PL / SQL,特别是Stack Overflow仅支持SQL,这很遗憾,因为Highlight.js为pgSQL提供了一个单独的定义(包括PL / pgSQL!),其质量比SQL定义。

–康拉德·鲁道夫(Konrad Rudolph)
20-10-5在9:01



我们通过PL / pgSQL支持PL / SQL ...如果StackOverflow希望提供该变体,则可以。 “ SQL”的意图是非常基础的(尽管遗憾的是,目前它已与MySQL混合在一起)。确实,SQL变体是如此不同,以至于要获得最佳结果,您确实需要使用特定于所用服务器变体的一个-这就是为什么应将它们全部分解为单独的语法的原因。还有大小方面的问题(这可能是为什么Stack Overflow不想在厨房水槽中添加所有内容的原因)...我肯定愿意更好地支持“简单” SQL。

–乔什·戈贝尔(Josh Goebel)
20-10-7在15:13

我对SQL进行了微小的更改,该更改将始终匹配字符串(即使在明显的SQL语句之外)也可以防止上述示例完全被破坏。 github.com/highlightjs/highlight.js/pull/2740

–乔什·戈贝尔(Josh Goebel)
20-10-7在15:41



我猜想“ MySQL混合”是为什么只突出显示define关键字之后的第一个声明。在PL / SQL中,declare标记包含多个项目的节的开头,并以begin开始。

–威廉·罗伯逊
20-10-10在9:15

由于PL / SQL是SQL的包装(除其他外),也许有一种方法可以包括通用的SQL语法,并使用PL / SQL的begin / end / loop等扩展它。但是后来我再也没有写过JavaScript语法解析器,所以我不知道我在说什么(尽管我确实将代码美化的分支扩展到了PL / SQL。

–威廉·罗伯逊
20-10-10在9:16



#30 楼

状态完成
Groovy语法高亮显示有两个问题:


旧语法没有自动转换为新语法,即丢失了成千上万与Groovy相关的问题和答案语法高亮显示。


通过 ```groovy进行Groovy语法高亮显示在许多情况下(例如,此处)仅在某些情况下不起作用。


有关详细信息,请阅读此问题及其评论。

评论


在问题中添加了评论。也将在此处标记为状态审核

–本·凯利♦
20-09-25在15:00

请参阅对链接问题的答复。仍然没有明确支持Groovy语法,但是现在至少应该自动突出显示类似的语言Highlight.js认为可能的语法。

–本·凯利♦
20-09-25在19:40

如果您正在谈论groovy-lang.org,那么我们确实有针对Groovy的语法。我认为StackOverflow根本还没有加载吗?

–乔什·戈贝尔(Josh Goebel)
20-10-7在15:14

我知道这一点,并且在我的问题中也提到了这一点。它不知道为什么SO不仅仅使用已经存在的东西。我还在评论中询问如何进行功能请求以显式支持Groovy,但未得到任何答复。切换主题突出显示框架后,总体而言,IMO语法突出显示的情况略显偏离主题(同样适用于Java)。我自己的答案比以前更难以理解,突出显示的元素更少,并且它们在哪里并不突出,这也间接影响了Groovy。

– kriegaex
20-10-8在1:19