[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please make line-move-visual nil

From: David Reitter
Subject: Re: please make line-move-visual nil
Date: Sun, 24 May 2009 22:32:05 -0400

On May 24, 2009, at 8:52 PM, Drew Adams wrote:
Most buffers in Emacs are code buffers or formatted text, with non- proportional fonts and hard-returns (newlines) as line separators. For _at least_ those contexts, we should keep the normal behavior. The traditional line movement fits well with lines as they are defined in those contexts. Lines defined by newlines
fit well with newline-oriented movement.

Much of my stuff is actually done in variable-width fonts (LaTeX editing, for instance). Using fixed-width fonts even for code is not a must - if it wasn't for weak indentation (tabs, etc.) and perhaps the clickability of narrow glyphs such as curly brackets, I would actually prefer a variable-width font for code as well.

I can see where you're coming from, though.

Even though you didn't notice the reasons I gave? ;-) Good. Maybe you sense the
reasons yourself?

I know fairly well by now how a lot of the developers (and certainly a share of the users) work. And as RMS pointed out in a related thread some time ago, much of the GNU tool set is based on line-by-line processing.

Note that I have bound C-n/p to non-visual movement in Aquamacs,
while arrow keys are visual.

Why would you even want non-visual movement? ;-) What's the use case/ reason? Let
me guess... code? formatted buffers? most Emacs buffers?

Yes, code and formatted buffers. But even there I wouldn't want it all the time - just in some situations.

Correspondence of the commands with what is most directly inferable from the observable state (i.e. visual interface!) is essential - more so than corresponding with some underlying format, i.e. the file format.

When I write a paragraph in this mail client (Outlook), there is no auto-fill or anything that chops the text by inserting newlines. Visual line movement might
be appropriate here (and that's in fact the line movement I have).

I believe that Auto-fill is a thing of the past. The new word-wrap is the way to go for non-code.
Here's why:

When you read this plain-text mail, it will have had newlines inserted (for
better or, more likely, for worse),

For worse, because the text only occupies 50% of the window I use to display your message.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]