配置 git 与 latex 配合使用(即使用点而不是线作为参考点)

配置 git 与 latex 配合使用(即使用点而不是线作为参考点)

通常情况下,git 很棒,但如果我将其用于书面文档(报告/小说)并进行校正阅读,它必须重写几乎整个文档,因为大多数段落都可能会发生变化。但如果句子发生变化,仍然只有 10%。因此,我在想,如果可以让 git 引用句子而不是行,那就太好了。这可能吗?

编辑:更多动机:

使用换行符作为参考的 git 对于学术文章来说非常有效,因为段落往往相对较短(因此如果 git 替换一个段落,更改仍然会在本地捕获)。对于更平淡的文本然而,修正(尤其是在后期)可能很微妙,但段落往往很长。因此,在 git 中替换整个段落会使以后在日志中发现更正变得困难。

关于在每个句子后添加一个新行,我认为这会破坏出现在 latex 文档中的文本的视觉结构。 特别是如果编辑器启用了自动换行。

只需看一下上面的文本,将其分成新行即可:

Having git using newlines as reference works quite well with academic articles, 
because paragraphs tend to be relatively short 
(hence changes are still locally captured if git replaces a paragraph). 
For a more prosaic text, however, 
the correction (especially at later state) might be subtle but the paragraphs tend to be quite long. 
Therefore replacing an entire paragraph in git makes it difficult to spot the correction later on in the logs.

Regarding making a new line after each sentence, 
I think that destroys the optical structure of the text appearing in the latex document.
Especially if the editor has wordwrap enabled.

答案1

这不是一个答案,而是一个强有力的、受欢迎的建议。

重新配置git可能不是解决问题的正确方法;这里需要改变的是您的书写方式。请记住,许多语言根本不关心换行符!(LISP、C/C++、Java;这个列表很长。)哪种语言更容易阅读?

#include <stdio>
int main(char* count, char** values) { for (int i = 0; i < count; i++) { puts(values[i]); } return 0;}

相对

#include <stdio>
int main(char* count, char** values) {
    for (int i = 0; i < count; i++) {
        puts(values[i]);
    }
    return 0;
}

对于 C 来说,源代码分布多少行并不重要;这是我们为 VCS 和可读性添加的内容。

TeX(通常使用)是几乎这些语言之一,段落标记和分组方面只有一些差异。因此,就 TeX 而言,你可以像这样编写段落

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis tempor commodo vestibulum. Mauris auctor leo sit amet enim posuere, vitae pretium mauris pharetra. Etiam mattis ante a dolor facilisis iaculis. Morbi placerat adipiscing pharetra. Suspendisse at posuere tortor, quis ornare nisi. Vivamus porttitor risus quis justo convallis dictum. Nulla id nisl ultrices, imperdiet enim eu, hendrerit nulla. In convallis, tortor id semper commodo, neque elit bibendum tortor, et interdum tortor libero a tortor. Aenean eget sodales lorem, at condimentum neque.

或者类似

Lorem ipsum dolor sit amet,
  consectetur adipiscing elit.
Duis tempor commodo vestibulum.
Mauris auctor leo sit amet enim posuere,
  vitae pretium mauris pharetra.
Etiam mattis ante a dolor facilisis iaculis.
Morbi placerat adipiscing pharetra.
Suspendisse at posuere tortor,
  quis ornare nisi.
Vivamus porttitor risus quis justo convallis dictum.
Nulla id nisl ultrices,
  imperdiet enim eu,
  hendrerit nulla.
In convallis,
  tortor id semper commodo,
  neque elit bibendum tortor,
  et interdum tortor libero a tortor.
Aenean eget sodales lorem,
  at condimentum neque.

TeX 不会在意。因此,通过将每个短语(或句子,如 @Torbjørn 所建议的)保留在其自己的行上,您可以按照git预期的方式本地化更改。

唯一的区别是,不可否认的是,可读性。虽然有点不同的这样阅读,我很快就能习惯。

如果你真的想从屏幕边缘到边缘阅读文本,我宁愿要求编辑功能比 VCS 定制更重要。(我visual-line-mode想到了 Emacs。)

(提示:这篇文章的 markdown 源代码就是这个概念的一个很好的例子。)


凭借 TeX 格式,两个新行开始一个新段落并不奇怪。

为了充分利用 TeX 的 VCS 管理功能,你必须做出一些明显的牺牲。这确实需要一点时间来适应(大约一天左右的良好写作),但你会发现它实际上更轻松当你这样做时,阅读你的作品。我显然不知道这是否适用于所有人,但当我阅读时,我倾向于“说出我脑海中的单词”,就像这样。坦率地说,在这些停顿中换行实际上是理想的原因有二:

  • 你可以暂停一下,让你的眼睛花时间追踪下一个短语,并且
  • 你可以确保,至少对其他人来说,阅读你的论文中,永远不会有一个句子太长而无法整体理解。

    (你有没有试过读一个句子,它只是所以长期以来(如果出现明显的中断,你的大脑可能会得到休息,为下一个想法做好准备,但读者实际、有意义地理解它的机会却会大大减少?好吧,现在你有了。)

因此,对于您的示例,我实际上会对其进行如下编辑:

Having git using newlines as reference works well with academic articles, 
  because paragraphs tend to be relatively short
%
% I would say overly-short paragraphs are bad style regardless of your audience 
%
  (hence changes are still locally captured if git replaces a paragraph). 
For more prosaic text, however, the correction
  (especially at later stages in the editing process)
  might be subtle, but
  the paragraphs tend to be quite long. 
Therefore replacing an entire paragraph in git
  makes it difficult to spot the correction later on in the logs.

Regarding making a new line after each sentence, 
  I think that it destroys the optical structure of the text
  appearing in the LaTeX document.
Especially if the editor has wordwrap enabled.
%
% Well, then, I would disable it. :-)
%

相关内容