Vim、LaTeX、自动换行和版本控制

发布于 2024-08-30 14:14:25 字数 1274 浏览 6 评论 0原文

我正在 vim 中编写 LaTeX 文档,并且将其硬包装为 80 个字符,以便于阅读。但是,这会导致版本控制中跟踪更改出现问题。例如,在本文开头插入“Lorem ipsum”:

1 Dolor sat amet,consectetur adipiscing elit。菜豆
2 quis porta。 Aenean 前庭 magna vel purus laoreet atmolestie Massa
3 沉思。前庭前庭, mauris nec convallis ultrices, Tellus sapien
4 ullamcorper elit、dignissim consectetur justotellus et nunc。 

结果是:

1 Lorum ipsum dolor sat amet,consectetur adipiscing elit。必比菜
2 莱博尔蒂斯 quis porta。 Aenean 前庭 magna vel purus laoreet at
3 骚扰马萨苏西皮特。前庭前庭, mauris nec convallis ultrices,
4 Tellus sapien ullamcorper elit,dignissim consectetur justotellus et nunc。

当我在 git 中查看这一更改时,它告诉我该段落的所有行都由于换行而发生了更改,即使只发生了一个语义更改。解决这个问题的一种方法是让每个句子独占一行。这在渲染的文档中看起来是相同的,但现在源代码更难阅读,因为每一行的行长度都有很大不同:

1 Lorum ipsum dolor sat amet,consectetur adipiscing elit。
2 菜豆 (Phasellus bibendum lobortis lectus quis porta)。
3 Aenean前庭magna vel purus laoreet atmolestie Massa Suscipit。
4 前庭前庭、mauris nec convallis ultrices、tellus sapien ullamcorper elit、dignissim consectetur justotellus et nunc。

(如果我在 80 处进行软换行,事情看起来仍然很糟糕,只是以不同的方式。)

是否可以将我的文本存储在磁盘上,每句话一个换行符,但在 vim 中显示和编辑它,就好像每个段落的文本是一行长长的文字,80 个字符?我认为它需要一些 vim-foo 而不是调整 git 或 LaTeX。

I'm writing a LaTeX document in vim, and I have it hard wrapping at 80 characters to make reading easier. However, this causes problems with tracking changes with in version control. For example, inserting "Lorem ipsum" at the beginning of this text:

1 Dolor sit amet, consectetur adipiscing elit. Phasellus bibendum lobortis lectus
2 quis porta. Aenean vestibulum magna vel purus laoreet at molestie massa
3 suscipit. Vestibulum vestibulum, mauris nec convallis ultrices, tellus sapien
4 ullamcorper elit, dignissim consectetur justo tellus et nunc. 

results in:

1 Lorum ipsum dolor sit amet, consectetur adipiscing elit. Phasellus bibendum
2 lobortis lectus quis porta. Aenean vestibulum magna vel purus laoreet at
3 molestie massa suscipit. Vestibulum vestibulum, mauris nec convallis ultrices,
4 tellus sapien ullamcorper elit, dignissim consectetur justo tellus et nunc.

When I review this change in git, it tells me that all the lines of the paragraph have changed because of the wrapping, even though only one semantic change has occurred. One way around this problem is to have every sentence on its own line. This looks the same in the rendered document, but the source now is harder to read, because each line has quite a different line length:

1 Lorum ipsum dolor sit amet, consectetur adipiscing elit.
2 Phasellus bibendum lobortis lectus quis porta.
3 Aenean vestibulum magna vel purus laoreet at molestie massa suscipit.
4 Vestibulum vestibulum, mauris nec convallis ultrices, tellus sapien ullamcorper elit, dignissim consectetur justo tellus et nunc.

(If I soft wrap at 80, things still look bad, just in a different way.)

Is it possible to have my text on disk with one newline per sentence, but display and edit it in vim as if the text of each paragraph was one long line, soft wrapped at 80 characters? I assume it requires some vim-foo rather than tweaking git or LaTeX.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

枉心 2024-09-06 14:14:25

无需引入奇怪的编辑策略:您正在寻找的 git 功能是使用 git diff --color-words 来查看更改。

No need to introduce weird editing policies: the git feature you are looking for is using git diff --color-words to review changes.

时光与爱终年不遇 2024-09-06 14:14:25

我认为另一种方法是像我通常所做的那样改变vim窗口的宽度:

  1. 首先,在.vimrc中放置“set wrap”以启用“wrap”功能;

  2. 为了在虚拟终端中运行 vim,我总是将终端的窗口宽度设置为 80 个字符(如“urxvt -geometry 80x38”)。因此,每当我在虚拟终端中的 vim 中编辑文件时,当一行包含超过 80 个字符时,它会自动换行。

  3. 如果您更喜欢 gvim(gtk-vim、gnome-vim),您可以通过在 .gvimrc 中添加一行来设置 gvim 窗口的大小,例如“setlines=38columns=80”。

希望有帮助。 :-)

I think an alternative way is to change the width of the vim window like what I did usually:

  1. at first, put "set wrap" in the .vimrc to enable the "wrap" feature;

  2. For running vim in a virtual terminal, I always set the terminal's window width as 80 characters (like "urxvt -geometry 80x38"). Thus, anytime I edit a file in vim in the virtual terminal, it will automatically wrap when a line contains more than 80 characters.

  3. If you prefer the gvim (gtk-vim, gnome-vim), you can just set the size of the gvim window by adding a line in .gvimrc, like "set lines=38 columns=80".

Hope that helps. :-)

毁梦 2024-09-06 14:14:25

我自己也一直在想这样的事情,最后我不得不尝试几种不同的方法来看看哪些方法有效。我绝对不满意的一件事是硬换行符(可以通过 set textwidth=80 来实现),原因如下:

  • 每当我返回编辑先前的文本时,硬换行符都会出现在错误的地方。它要么超出我的 80 个字符限制,要么离我的 80 个字符限制太远。当然,我可以通过使用 gq 运算符的不同变体(例如 gqipgqap、可视模式,然后 gq),但这很乏味,而且我经常用 gq 错过目标区域。这对我来说是硬休息的最大缺点。 (如果您确实使用 gq 来修复段落,您可能需要使用 set nojoinspace 来避免在每个句号后出现烦人的双空格。)
  • 我经常让 Vim 和 PDF 打开一侧-并排。每当我想在 PDF 中的特定位置编辑某些内容时,我只需搜索文本片段即可。您会惊讶地发现文本中很少有地方按特定顺序使用两个相当常见的单词,因此这确实非常有效。除非您在句子中间有硬中断来中断您要搜索的单词。当使用硬中断时,这会经常延迟我的工作流程。
  • 我经常使用 fFtT 在句子中导航。这只适用于同一行。
  • 还有 OP 提到的问题,Git 不能很好地处理硬中断的段落。当然,您可以使差异看起来不错,所以这并不是一个大问题。

对我来说,使用软中断(例如每行一个句子或一个段落)并不是我为适应 Git 而采用的“奇怪的编辑策略”。这是我用来促进编辑时方便和高效的一种(也许很奇怪)编辑策略。特别是在单词中间出现的软换行符,我同意看起来很难看,但可以使用 set linebreak 将其关闭。

此外,如果您每行使用一个段落,您应该获得与硬中断相同的“外观”(使用 gq 正确维护),并且您可以使用以下命令从一个句子导航到另一个句子: 。每行一个句子,右边缘会更加粗糙,但具有 Git 和 Vim 每行一个句子所提供的优势。两者都尝试一下,看看你更喜欢哪一个(我自己还没有决定)。

I've been wondering about things like this myself, and in the end I just had to try a few different approaches to see what works. One thing I'm definitely not happy with is hard breaks (which can be acheived by set textwidth=80), for several reasons:

  • Whenever I go back to edit previous text the hard linebreak will be on the wrong place. It will either go beyond my 80 character limit, or it will be too far from my 80 character limit. Sure, I can fix this in Vim by using different variants of the gq operator (e.g. gqip, gqap, visual mode and then gq), but this is tedious, and I often miss my target area with gq. This is for me the biggest disadvantage with hard breaks. (If you do use gq to fix paragraphs you may want to use set nojoinspace to avoid getting annoying double spaces after every period.)
  • I often have Vim and the PDF open side-by-side. Whenever I want to edit something at a specific place in my PDF I just search for fragments of the text. You'd be surprised at how few places in a text you use two rather common words in a particular order, so this really works quite well. Unless you have hard breaks in the middle of the sentece that breaks between the words you're searching for. This delays my workflow rather frequently when using hard breaks.
  • I often navigate within senteces using f, F, t or T. This only works within the same line.
  • There's also the problem mentioned by the OP that Git doesn't handle hard breaked paragraphs very well. Sure, you can make the diff look nice nevertheless, so it's not really a big problem.

For me, using soft breaks (and having for instance one sentence or paragraph per line) is not a "weird editing policy" I adopt to suit Git. It's a (perhaps weird) editing policy I use to facilitate convenience and efficiency while editing. In particular the soft line breaks occuring in the middle of words I agree look ugly, but that can be turned off using set linebreak.

If, in addition, you use one paragraph per line, you should get about the same "look" as with hard breaks (which is properly maintained with gq), and you can navigate from sentence to sentence with ( and ). With one sentence per line you will get a more ragged right edge, but with the advantages Git and Vim offers by having one sentence per line. Try both and see what you prefer (I haven't decided yet myself).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文