views:

389

answers:

7

When editing non-WYSIWYG (LaTeX, HTML, etc) prose you probably want to have newlines at the ends of your sentences. This has several advantages:

  1. Easier to rearrange sentences.
    • Easier to comment out sentences.
    • Easier to spot run-on / overly long sentences.
    • Easier to comment on sentences.

For example:

% The following isn't strictly true; maybe excise or comment out for now:
After all, people who use Word or other WYSIWYG editors are aiding and 
abetting terrorists.

And probably the most important advantage of all is that it makes collaborative editing under version control much easier. Otherwise you end up with conflicts where it just informs you "the following two versions of this huge paragraph are in conflict".

But maintaining newlines at the ends of sentences is easier said than done...

As you edit the prose
it will get all chopped up, like this.
Normally you'd do a "reformat paragraph"
to clean it up, but then
you lose the newlines at the ends of your sentences!

The following question asks about how to solve this problem in emacs:

http://stackoverflow.com/questions/539984/how-do-i-get-emacs-to-fill-sentences

I'd like to know how people deal with this in other editors, including vim, TeXShop, TextMate, and any others you think would be useful to collect here. Advice on soft vs hard wrapping is also welcome.

+3  A: 

I'd think the simplest solution to this is to only add newlines after full stops. Your edits would then never fragment lines.

Note that for prose you can very well rely on your editor's line-wrapping features to wrap long sentences - unless you insist on indenting it like you would with code (I don't indent that much in latex),

yungchin
This will certainly work, but I initially rejected it (still willing to be convinced) because it places demands on my collaborators' choice of editors.
dmckee
Seriously: do people use editors that can't wrap lines?
yungchin
People certainly use editor that are _set_ not to. YMMV and all that.
dmckee
+1  A: 

Vim:

You can turn off text-wrapping (set formatoption-=t) and it will not add linebreaks unless you hit enter. Better still, if you can figure out how to set up the 'comments' option so that it recognizes your comments, you can set an auto-wrap width only for your comments and not for anything else:

set comments=b:%
set textwidth=80
set formatoption+=c
set formatoption-=t

This is the method I use, so that my comments are tidy, but my code doesn't get mangled unless I do it myself.

too much php
A: 

This all seems a rather contrived way of working around a limitation of diff. Why not create a sentence sensitive diff rather than screwing with your source?

hadley
How would it know when to be line-based and when to be sentence-based? In any case, I think reasons 1 through 4 are compelling enough that I don't think it's contrived. I think the biggest downside is that it makes your document less compact.
dreeves
A: 

I'd like to know how people deal with this in other editors,

FWIW on the Windows platform, the Zeus editor has a configurable right margin and a built in line wrap function.

So for example, with the right margin set to 60 characters, marking the text of your example and then using the Macros, Linewrap Paragraph menu, Zeus will reformat the text as follows:

As you edit the proseit will get all chopped up, 
like this. Normally you'd do a "reformat 
paragraph"to clean it up, but thenyou lose the 
newlines at the ends of your sentences!

The wrapping is hard in that all the lines above have a end of line character inserted.

jussij
It's the newline between "...this." and "Normally..." that I want to preserve though.
dreeves
Well I guess one solution would be to create a macro that joins all the lines of the marked area into one line and then have the macro split the line by replacing all periods/exclamations with period/exclamation and new line. Any scriptable editor (including Zeus) should be able to do this.
jussij
It would have to be smart about it, since there are plenty of non-sentence-ending periods and bangs and such.
dreeves
I don’t think a script is ever going to be that smart. But by having the user mark the text region to be formated puts the smarts where they belong, in the hands of the user.In any case if the script does make a mistake, a simple undo command should be all that is required to undo the damage.
jussij
+1  A: 

A normal text editor should not attempt to change the file you write, unless you explicitly ask it to. It may change file's appearance on screen for readability, but that's it.

Therefore most decent editors in my experience do soft wrapping and keep your line breaks wherever you inserted them.

That's all. I must confess I can't see what the fuss is about, unless you are using some pretty weird text editors that insist on doing hard wraps and need workarounds.

If you want to keep formatting useful for diff, just do the line breaks after each sentence, and accept that diff will work on sentence level.

Gnudiff
A: 

you do not want newlines at the end of sentences.

sure it's easier to do the 4 things you list, but that is not worth doing it different from how the rest of the world does it (even if the world's reasons are as stupid as the reasoning behind CR LF = newline).

and your biggest advantage is not true:

Otherwise you end up with conflicts where it just informs you "the following two versions of this huge paragraph are in conflict".

How would it know when to be line-based and when to be sentence-based?

you can use Meld or some similar diff tool and let it do the work.

oberhamsi
Did you note that he is talking about editing the source of a LaTeX document of similar situation here the shape of the input file has limited bearing on the shape of the formatted output.? And doing so in a collaborative environment? Special case problem. Cheers.
dmckee
yes, even in html / latex whitespace and newlines in some cases do have meaning. and just ignoring them everywhere will get you into trouble especially if you want to work collaborativly.
oberhamsi
+1  A: 

In vim, you can fill to the end of the current sentence with gw). It won't reformat an entire paragraph or region for you, but if you are careful to insert newlines after each sentence, and you reformat with gw) as you write, it works pretty well.

Jason Blevins