[OS X TeX] wrap [was: migrating from emacs...]

[Herbert Schulz]

On Feb 6, 2012, at 2:09 AM, Joachim Kock wrote:

> On 2012-02-05, at 4:27 PM, Enrico Franconi wrote:
> 
>> I believe that the idea to force LF to format structured text does
>> not belong to the modern times - when windows do resize freely.  I am
>> fully with Herbert (if I understand him well): we do not need forced
>> LFs, and we need to reformat our brain to the more powerful ways to
>> organise structured text of the modern times :-)
>> 
>> Since I have been a hard-core emacs user, I gave this issue a serious
>> thought before leaving emacs, and I concluded that we need to switch
>> our paradigm, by having LFs only when there is a logical need, rather
>> than when the text hits the current accidental right margin of the
>> window you are working on when creating/editing the text.
> 
> I understand that soft-wrapped lines is a good invention in
> WYSIWYG word processors (where it depends on document width,
> not window width!), but I don't see the point of it in latex
> source code:
> 
> - with long soft-wrapped lines, go-to-line functionality like
> typing 'e' at a tex error, is less efficient;
> 

Howdy,

I guess my paragraphs are usually short enough that I don't have a problem with that.

> - diff becomes considerably less useful when differences are
> detected inside a 700-char line forming a paragraph instead of
> in a 70-char line;
> 

True. If I'm a bit confused with a usual diff (actually I love how BBEdit displays the diff) I'll usually use latexdiff which produces a LaTeX file that shows the differences between two versions of a document. You can get a Drop Script at <http://dl.dropbox.com/u/10932738/Droplatexdiff.zip>; just drop the two files you want to diff onto the Drop Script and the new LaTeX file will be created.

> - comment chars work on such "paragraphs" instead of on lines,
> and if one day the file is hardwrapped (e.g. by TeXShop's
> shift-cmd-H, or by an email transmission), it can really be
> screwed up, since a comment that used to affect 700 chars now
> suddenly only affects the first 70;
> 

True. If you display line numbers in TeXShop you can easily tell where the line breaks occur. The scope of a comment can easily be seen because comments are syntax colored. By default it is a fairly bright red but I've changed it to a medium gray (see TeXShop's Help Panel and find information about syntax colors) so comments recede into the background a bit.

> - similarly, indentation affects only the first visual line of
> the long line, hence the visual aid provided by indentation
> (automatic in many editors), for example in enumerate or theorem
> environments, is watered down;
> 

Yes, this is a problem. I've often wanted to use scope indentation but don't because of this problem. Don't know if there is a way to do it though via Apple's Text Framework.

> - the two previous points are aggravated in editors (such as
> TeXShop) where you can't visually see the distinction between a
> soft and a hard line break, so you won't know in advance the
> scope of your comment or indent operation.  In short: what you
> see is not what you have.
> 

As mentioned above, displaying Line Numbers automatically shows you where the hard line breaks occur.

> In fact even the typing process of soft-wrapped text has an
> element of confusion: when typing inside a long-line paragraph,
> the later text inside the paragraph dances around on the screen,
> and the sentence you were starring at a moment ago at some
> position on the screen is suddenly somewhere else on the screen.
> 

I think you get used to that. If it bothers you too much you can certainly enter a Return, go back one character and then type. But this is also a problem for some.

> 
> On 5 Feb 2012, at 15:49, Herbert Schulz wrote:
> 
>> Each to his/her own...
> 
> So true.
> 
> Cheers,
> Joachim.


I think it's much more what you get used to after a while and thus my comments. I know I remember fewer and fewer of the emacsen commands although I'm still using some which are used by the Apple Text Framework and have added some that are (very) occasionally useful and have added a few more (e.g., M-v [with M = Opt] for moving up a screen and centering the cursor) via the DefaultKeybinding.dict mechanism. PS: I wonder if it's possible to easily emulate the kill to end of displayed line (Clt-K in emacsen) using that mechanism which adds it to the keyboard shortcuts to all apps that use Apple's Framework.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)