正在编辑C标准

对于那些看过我之前的一篇文章的人来说，为什么大多数C实现甚至在最简单的情况下都会故意炸掉你的腿，你可能已经注意到了，我说我成为了C的项目编辑。这是一种奇妙的方式，说我把标准粘合在一起，同时生成工作草案/工作文件(WDS/WPS)、编辑报告，以及WD与最后发布的WD的Diffmark of the WD(工作草案/工作文件(WDS/WPS))和WD的Diffmark of the WD(WD与最后发布的WD)的区分标记(Diffmark Of The WD)。

在我可以通过iso®N-Paper™系统将其发布之前，工作草稿和差异标记都在这里。

撇开愚蠢的符号不谈，这是对30多篇论文、几份缺陷报告、几个编辑问题以及对一些来源的小小清理。有大约3个会议的积压文件需要整合，从过去错过的几个整合和一些我必须涵盖的会议中提早整合的一些文件进行整合、赠送或接收，这些论文都是从过去遗漏的几个整合中获得的，还有一些来自我必须报道的会议的早期整合的东西。尽管当我第一次处理成为项目编辑时出现了一些相当疯狂的恶作剧，但一切都变得很顺利！无论如何，在很大程度上，我已经可以闻到所有我可能搞砸了整合的东西的编辑报告。但是，编辑标准文档是什么感觉呢？把所有这些文件变成一份工作草案是什么感觉？

与任何项目一样，它需要工具。该标准由一套工具构建而成，任何*NIX程序员都会感到欣慰：

Git，用于提取标准的先前标记版本，以尝试创建有用的差异。

还有许多其他辅助工具用于生成一些文档和其他东西，但这是它的核心！像往常一样，如果我不说下面的…，讨论LaTeX的任何内容都是不完整的。

我讨厌乳胶。可用的LaTeX发行版是无用的垃圾，打印行号，但不跟踪任何文件信息，这会使任何多重编译流完全无用，并且需要为每个文件单独调用LaTeX编译器，并且需要Magic才能知道您所在的是哪个文件。这并不是大多数人组织文档的方式：\Input{the_file}是在LaTeX环境中开发模块化文档的选择，具有类似于#Include的行为，但实现的编译器质量为0%。

当然，更改一件事会导致一系列错误，警告被分成多行，以便使大多数错误解析和警告解析regexen在尝试从1MB的错误字面转储中挑选错误时毫无用处，而试图编辑最基本语法之外的任何内容都是一项繁琐的工作。除了以！开头的“硬错误”之外，LaTeX错误没有任何合理性、特殊形式或可靠的结构。

空格在语言中并不重要(除非它是)，人们将即席命令拼凑在一起，以弥补LaTeX严重的低效，并添加脚注，将接下来的3段文字弹出，写到右边的空白处，你听说过我们的主与救世主HBox满了吗？

我给每个人的永恒忠告是，请不要再用乳胶写文档了。即使是在Microsoft Word中，你也会走得更远、更快，而且它在互联网上的渲染效果会更好。它有数学支持，当你想要给你的作者和书名加一个温和的空白时，它不会在床上到处拉屎，也不会尖叫，还会含糊其辞地暗示什么才能让它足够满意，不再在糟糕的输出中涂抹漂亮的亚麻布。

如果你的手一想到不在简历上使用漂亮、布局强大、手工烘焙的乳胶就会发抖，那么有一些模板可以让你的Word文档看起来像乳胶文档。仅仅使用一种不同的serif-y字体可能会对你的外观有很大帮助！

…。话虽如此，C标准是用LaTeX编写的，所以这就是我们正在编辑的。

不要误会我的意思：LaTeX是垃圾，但是我收到的标准对于LaTeX文档来说是相当好的质量。它很容易构建和编辑，一旦我安装了所有合适的东西，我就不会迷路(我并没有决定试图计算出“最低要求的分发版”，而是直接获取安装文件和文本)，文件也是井然有序的。引用事物有点可怕，但这更多的是一个乳胶问题，而不是结构问题。我还很幸运地得到了一份乳胶文档：这个标准过去是用一些可怕的腐烂坏东西写成的，名字叫“Troff”。我对此知之甚少，从我所学到的很少。

此外，还可以使用latexdiff和其他方法来生成漂亮的分隔符。结果相当不错，有些记号噪音太大了。尽管如此：只要它突出了变化的一般领域，它就会产生一个相当好的代理，即“寻找发生变化的东西的地方”。它确实忽略了新添加的文件，这就是为什么《工作文件》开头的列表--其中详细列出了每次会议添加的文件--并没有全部以蓝色突出显示。上一位编辑给我留下了一个很好的LaTeX文档，其中包含一些非常好的组织结构，这使得本文的下一部分成为最简单的…。

太棒了，你写了一篇恶心的Rad Paper，现在需要把它放到C标准中去了！那么，它是如何做到这一点的呢？实际上，你并没有写出与标准不同的内容。至少，不是真正的不同：C标准的来源是对世界隐藏的，以确保它们的安全，即使黑暗的时刻降临到我们身上。您所写的是给项目编辑的说明(嗨，这就是我！)，然后我接受您的说明，尽我最大的努力(™)在C标准中反映它们。大多数措辞都事先得到了委员会的批准，编辑通常是直截了当和简单的。例如：

然后，我接受这些建议/指示/建议，然后代表你去敲打乳胶。这样做最大的好处之一就是你不需要了解乳胶。或者如何建立标准，或者其中的任何一部分。项目编辑器是您和标准的实际文本之间的“间接层”。这也意味着，从理论上讲，我可以将整个标准重写为Microsoft Word文档，或者用restructuredText重写整个标准，而你们中没有人会知道其中的区别。或者，不管怎样，这就是最理想的情况。不幸的是，遵循人们的标准编辑指令并不总是最直接的…

见鬼的“3.4.3p4”是什么意思？那么，我必须构建标准(或者去看看更老的标准)，弄清楚您指的是哪一节/段，然后修改它。通常情况下，C标准的发展速度非常缓慢，这通常不是问题。然而，要做到这一点有点困难，因为有3次会议需要进行积压的更改。论文之间有很多重叠之处，也只是彻头彻尾地奇怪地描述了如何改变一些我一开始不理解的东西。奇怪的嵌套在最近C浮点组织对该标准的更改中集成了各种有趣的东西。

“删除这些段落，然后在这里添加一些”好的，这是在你刚才让我销毁的东西之前还是之后？哦，我刚申请了一篇论文，删掉了你要求我编辑的一半内容。嗯，好吧，我想我们得马上酝酿一些有趣的词了…。好了！

做这些改动，然后对平时的地方做类似的改动，嗯，平时的地方是什么？我想是时候突破、查找/替换，找出常见的地方了！等等，你在这里做了这些改变，但是…。其他地方也有相同的措辞，我是不是也应该编辑一下呢？…。？是时候给作者…发电子邮件了。

这是一个充满挑战的有趣桶，真的。我认为帮助制作它的方法之一是在标准中添加稳定的标签，这样我就可以更可靠地知道要编辑哪些部分。C++已经做到了这一点，这意味着当有人说“编辑[alg.any.of]”时，无论章节和段落编号发生什么变化，您都知道要去哪里。25.6.2…。那是什么，再说一遍我在做什么？

C和C++委员会中最大的问题之一是历史。C++开始为他们的论文使用P-数字来解决这个问题，P-数字是PNNNNrXYZ数字，表示论文和论文的修订版本(0，1，2，…)。在XYZ部分。C没有这样的基础设施：每一篇论文都被正式提交给国际标准化组织(ISO)，并被赋予一个N编号。

您如何跟踪修订历史记录？你希望作者把它放在论文的标题里，或者放在论文本身里面。这基本上取决于作者，并不是所有的作者都这样做。这是一个更大的问题，更严格地超出了我作为项目编辑的职责范围，但这是我无论如何都要解决的问题。

多亏了LynnKirby所做的工作，我得到了一些灵感，Lynn创建了一个wg14.link网站，类似于wg21.link网站。这让我对人们希望从这样的服务中得到什么，以及我应该如何预订Keep文件及其元数据有了很大的洞察力。希望在2021年夏天之前，我能够推出一种新的方法来跟踪这些论文，保存标题、作者、摘要和历史信息，并使论文提交过程对更广泛的C社区更加友好！

尽管如此，这仍然是一大堆杂乱无章的事情，而且更多的东西将开始偏离主题，真正编辑C标准意味着什么。希望这篇文章能让你对论文/提案争论的世界有一个很好的了解！

如果你有任何问题，请随时联系我自己和其他乐于助人的人，帮助我保持项目编辑直通[email protected]，或通过新创建的WG14联系人页面联系其他人。(是的，它看起来不是很现代，但至少信息现在是最新的；一步一个脚印。这是一个非常、非常古老的委员会…)