EOL vs lbr when writing prose

[Daniel Choi]

I've been writing my text documents in vim using hard line breaks and
reflowing the text as needed with gqap (via a shortcut).

Then I saw this blog post

http://tech.geoff.me/2008/05/vim-word-processor.html

and tried using Vim in a more word processor-y mode, with soft line
wrapping.

After about a week of that, I went back to the EOLs. I just liked the
hard wrapping better, and it made my text files work better with tools
like grep, diff, and git.

I'm little sad however to see an increase in soft wrapped README files
in software source code (particular in Ruby), which can be attributed
I'm sure to the rise of GUI text editors like TextMate.

Thoughts?

[Tom Link]

> Thoughts?

Soft-wrap is good:

- if want to sort lists (eg TODO lists) by prefix
- if you have to edit text on devices whose screen is too narrow to
display 70+ chars
- if you want to easily include the text in a word processor document
- if you want to edit e-mails (well, it depends of course)
- if you want to insert the text in textareas in your browser
- ...

Even if it's true that text with hard line breaks work better in
conjunction with the usual set of text-related programs like grep
etc., I think an editor should support well editing soft-wrapped text
files. So I personally would like to so improved support for editing
soft-wrapped files. The breakindent patch could be a good starting
point. If the right margin could be configured too, it would be
perfect.

tom.

[Daniel Choi]

Thanks. Very good points.

But another big problem I have with soft wrapping in Vim is that it
actually makes indented text harder to work with. If you want to
indent a block of text -- like a block quotation, or bulleted text in
a list -- in Vim, you do this by inserting line breaks and putting
spaces before each line. In a word processor, by contrast, you apply a
"style" locally to the block quote that sets indentations for the
first line and subsequent lines.

I can't imagine how we would add this word-processor like behavior to
Vim without making Vim much more complicated. Does breakindent handle
this gracefully?

[Tom]

> Does breakindent handle this gracefully?

If I understood you correctly, it does what you're asking for. I
sometimes get some error messages though (about 3 times since I
applied the patch) but those messages seem to have no further
consequences and don't crash vim. It could also be that I got those
messages already before applying the breakindent patch. I cannot
remember.

Does somebody know if the breakindent patch is included in the
vim_extended git repo?

[Daniel Choi]

To illustrate what I meant:

This is normal text.

This is indented text that has hanging indents
that are generated by EOFs and spaces at the
beginning of each line.

There seems to be no way with Vim to display the text above using soft
wrapping.

[_sc_]

On Monday 23 February 2009 11:35 am, Tom wrote:
[...]

> Does somebody know if the breakindent patch is included in the
> vim_extended git repo?

no

at the moment it includes:

feat/rel-line-numbers
feat/float-point-ext
feat/lua
feat/code-check
feat/var-tabstops
feat/emb-common-lisp
fix/fast-join

sc

[Tom]

> This is normal text.
>
>   This is indented text that has hanging indents
>   that are generated by EOFs and spaces at the
>   beginning of each line.

Yes, that's the idea.

[Daniel Choi]

Thanks. I'll look at breakindent.

[Markus Heidelberg]

_sc_, 23.02.2009:

Now it is: feat/indent-wrap-lines

Tom, you can try out if everything works. I only shortly tested the
'breakindent' option, it worked. Then I would merge it into master this
week. I already did it locally and can say, whoever tries it and also
has 'feat/var-tabstops' merged, has to fix the calls of
lbr_chartabsize_adv(), since 'feat/indent-wrap-lines' adds a parameter
to it.

Markus

[Tony Mechelynck]

IMHO README files should be plaintext, suitable for text pagers such as
less, and that would mean hard line breaks spaced no more than 80
"virtual" characters apart. By "virtual" I mean that "wide" CJK
characters count double, and that hard tabs (if any) are worth between
one and eight "virtual characters" each.

As for writing prose in general, it all depends what file type
(technically, what MIME type) you use for it, and who/what the files are
meant for. Prose in plaintext and meant to be distributed to people on
any kind of computers should have lines no longer than 80. Plaintext
prose for your own use can be anything. I'd recommend lines short enough
for your printer (for the :hardcopy command) -- if you _have_ a printer.
For prose in HTML the length of lines in the source text mostly doesn't
matter, since spaces, tabs, and linebreaks are mostly all "whitespace".
(Exception: inside <pre></pre> tags.) For mail, it's usually regarded as
"good form" to use hard breaks at most 75 or so characters apart, though
format-flowed can be used to tell the receiving mail client that those
"short" lines should be concatenated on display. And so on.

Program _source code_ is not the same as _prose_. (Source code can be
written e.g. in C, Ada, Perl, Javascript, etc. Prose is written in
English, French, German, Chinese, Urdu, Cherokee, etc.) IMHO the length
of program source lines should depend on the language's syntax, and
there are so many different programming languages that I can't imagine
any "general" rule valid for all of them.

Best regards,
Tony.
--
Lawmakers made it obligatory for everybody to take at least one bath
each week -- on Saturday night.
[real standing law in Vermont, United States of America]