C-n and C-a

C-n and C-a

[Richard M Stallman]

The new definitions of C-n and C-p seem to work reasonably
conveniently with the very long lines that non-Emacs-users often
write.  However, it is very counterintuitive that C-a and C-e have not
been changed in the same way.  They keep surprising me, and I have to
work hard to remember not to use them to do the natural thing.

I think they too should be changed to operate on screen lines;
that's a necessary part of the change that was already made.

If C-a and C-e are changed this way, we would want some way to go to
the beginning and end of the real line.  Here are some ideas:

* Make C-u C-a and C-u C-e do this.  I suspect nobody uses
those combinations with their current meanings.

* Make M-{ and M-} treat each line as a paragraph.  That would be the
right thing for them to do in such text.  This would require either a
minor mode or detecting long-line text heuristically.

What do others think?

Re: C-n and C-a

[Tassilo Horn]

Richard M Stallman <rms@gnu.org> writes:

Hi Richard,

> The new definitions of C-n and C-p seem to work reasonably
> conveniently with the very long lines that non-Emacs-users often
> write.  However, it is very counterintuitive that C-a and C-e have not
> been changed in the same way.

I mentioned this inconsistencies before in
<874p55z20j.fsf@thinkpad.tsdh.de>.  I was told that the current behavior
was due to a consensus.  But still I don't like it, so I switch on
`visual-line-mode' where everything operates consistently on screen
lines.

IMHO without `visual-line-mode' everything should work on real lines,
with it turned on everything should work on screen lines (as it does
right now).  This half screen half real line behavior is somewhat
confusing.

> I think they too should be changed to operate on screen lines;
> that's a necessary part of the change that was already made.

You can have this by turning on `visual-line-mode'.

> If C-a and C-e are changed this way, we would want some way to go to
> the beginning and end of the real line.  Here are some ideas:
>
> * Make C-u C-a and C-u C-e do this.  I suspect nobody uses
> those combinations with their current meanings.

Yes, that would be ok.  A bit more convenient would be to type `C-a'
twice, which would toggle between screen and real line beginning.

> * Make M-{ and M-} treat each line as a paragraph.  That would be the
> right thing for them to do in such text.  This would require either a
> minor mode or detecting long-line text heuristically.

I wouldn't like that, because it would require that texts one writes
have to obey the convention that each paragraph has to be on one line.
Especially when working with others this cannot be enforced while an
empty line to mark paragraphs in pretty standard.

Bye,
Tassilo

Re: C-n and C-a

[Harald Hanche-Olsen]

+ Tassilo Horn <tassilo@member.fsf.org>:

> A bit more convenient would be to type `C-a'
> twice, which would toggle between screen and real line beginning.

Or even more simply: If the cursor is at the beginning of a screen
line, let C-a go to the beginning of the real line. Otherwise it goes
to the beginning of the screen line. That way you don't have to
remember any state. I am sure I could get used to this real quick.
(Or was that in effect what you were suggesting already?)

- Harald

Re: C-n and C-a

[Tassilo Horn]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> + Tassilo Horn <tassilo@member.fsf.org>:
>
>> A bit more convenient would be to type `C-a' twice, which would
>> toggle between screen and real line beginning.
>
> Or even more simply: If the cursor is at the beginning of a screen
> line, let C-a go to the beginning of the real line. Otherwise it goes
> to the beginning of the screen line. That way you don't have to
> remember any state. I am sure I could get used to this real quick.
> (Or was that in effect what you were suggesting already?)

Not exactly.  I though that the first C-a would jump to the beginning of
the screen line, a second would jump to the beginning of the real line,
a third would jump back to the beginning of the previous screen line.
Of course this would have to me remembered.

But I think this toggling behavior is only convenient in very rare
cases, so I'd go with our simple approach.  (To go back to the beginning
of the previous screen line only a few `next-line's are needed anyway.)

Bye,
Tassilo
-- 
A child of five could understand this! Fetch me a child of five!

Re: C-n and C-a

[Karl Fogel]

Richard M Stallman <rms@gnu.org> writes:
> The new definitions of C-n and C-p seem to work reasonably
> conveniently with the very long lines that non-Emacs-users often
> write.  However, it is very counterintuitive that C-a and C-e have not
> been changed in the same way.  They keep surprising me, and I have to
> work hard to remember not to use them to do the natural thing.
>
> I think they too should be changed to operate on screen lines;
> that's a necessary part of the change that was already made.
>
> If C-a and C-e are changed this way, we would want some way to go to
> the beginning and end of the real line.  Here are some ideas:
>
> * Make C-u C-a and C-u C-e do this.  I suspect nobody uses
> those combinations with their current meanings.

That sounds great.  I've literally never used C-u C-a or C-u C-e in
their current meanings (don't know about other people, though).

I like this solution much better than C-a C-a (which some others have
suggested), or having C-a go to non-visual line-beginning when point is
already at the visual beginning.  Doing either of those would require
one to keep state in mind when writing or executing macros; I think they
would be bug-prone.

-Karl

Re: C-n and C-a

[Harald Hanche-Olsen]

+ Karl Fogel <kfogel@red-bean.com>:

> I like this solution much better than C-a C-a (which some others
> have suggested), or having C-a go to non-visual line-beginning when
> point is already at the visual beginning.  Doing either of those
> would require one to keep state in mind when writing or executing
> macros; I think they would be bug-prone.

Ah. Keyboard macros. I didn't think about those. You have a point
there. Too bad; otherwise, I would have liked my solution much
better, but I think your argument must prevail.

- Harald

Re: C-n and C-a

[Adrian Robert]

Tassilo Horn <tassilo <at> member.fsf.org> writes:


> IMHO without `visual-line-mode' everything should work on real lines,
> with it turned on everything should work on screen lines (as it does
> right now).  This half screen half real line behavior is somewhat
> confusing.

I agree.  It's also better to use visual-line-mode (and turn on by
default if that is the consensus) because that is already in the
Options menu, while discovering that the irritating change from
emacs-22 was in the 'line-move-visual' setting is always a "fun"
exercise when bumping into a new emacs-23 environment -- and the
better-advertised red herring of "visual-line-mode" never fails
to distract me.

Re: C-n and C-a

[Stefan Monnier]

> The new definitions of C-n and C-p seem to work reasonably
> conveniently with the very long lines that non-Emacs-users often
> write.  However, it is very counterintuitive that C-a and C-e have not
> been changed in the same way.  They keep surprising me, and I have to
> work hard to remember not to use them to do the natural thing.

> I think they too should be changed to operate on screen lines;
> that's a necessary part of the change that was already made.

How about C-k?

I personally like the new behavior, even though it is
indeed inconsistent.  But if people want to change the default,
that's fine.

Maybe we should have a 3-value setting: fully visual-line based
operation, fully logical-line based operation, or half-assed
(visual-lines for C-n and C-p but logical-lines for the rest).

I'll let people fight over which default should be chosen.


        Stefan

Re: C-n and C-a

[Juri Linkov]

> * Make M-{ and M-} treat each line as a paragraph.  That would be the
> right thing for them to do in such text.  This would require either a
> minor mode or detecting long-line text heuristically.
>
> What do others think?

`M-{' and `M-}' are already associated with moving to the beginning and end
of the paragraph.  So they are more like `C-a' and `C-e' going to
the beginning and end of the real line that are like paragraphs in
word wrap mode.

I think `C-up' and `C-down' are better keys for real line motion commands
when `up'/`C-p' and `down'/`C-n' are used for screen line motion commands.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Juri Linkov]

>> The new definitions of C-n and C-p seem to work reasonably
>> conveniently with the very long lines that non-Emacs-users often
>> write.  However, it is very counterintuitive that C-a and C-e have not
>> been changed in the same way.
>
> I mentioned this inconsistencies before in
> <874p55z20j.fsf@thinkpad.tsdh.de>.  I was told that the current behavior
> was due to a consensus.  But still I don't like it, so I switch on
> `visual-line-mode' where everything operates consistently on screen
> lines.

In addition to inconsistencies and lack of convenient key bindings
there are also problems with the used terminology.  There are
two similar confusing names:

    line-move-visual
    visual-line-mode

The former defines half-real/half-screen line motion mode,
and the latter has a name that says nothing to most users.

I think if we want to achieve simplicity and intuitiveness
then we should have a mode

    word-wrap-mode

with a pair of variables to define variations for key bindings
and visual appearance.

By default, `word-wrap-mode' could bind C-n/C-p and C-a/C-e to
visual line motion commands, and also provide alternative keys
for real line motion commands when `line-move-visual' is non-nil.
But the nil value of `line-move-visual' could reverse the meaning
of these key bindings.

Another variant is to define a mode

    line-wrap-mode

with C-n/C-p and C-a/C-e bound to visual line motion commands and
`line-move-visual' behaving as described above.  And additionally
it could provide a variable `word-wrap' to define wrapping boundaries
(word vs non-word).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Stefan Monnier]

>     word-wrap-mode

But this is a misleading name: the issue is not how lines are wrapped
but how motion command behave.  So visual-line-mode is a much better
name in this respect.


        Stefan

Re: C-n and C-a

[mail]

Juri Linkov <juri@jurta.org> writes:
> I think `C-up' and `C-down' are better keys for real line motion commands
> when `up'/`C-p' and `down'/`C-n' are used for screen line motion commands.

C-up and C-down are too far away from the regular position of fingers to
be useful as the only option for anything, one needs a C-p/C-n like
equivalent binding.

Re: C-n and C-a

[Richard M Stallman]

    > * Make M-{ and M-} treat each line as a paragraph.  That would be the
    > right thing for them to do in such text.  This would require either a
    > minor mode or detecting long-line text heuristically.

    I wouldn't like that, because it would require that texts one writes
    have to obey the convention that each paragraph has to be on one line.
    Especially when working with others this cannot be enforced while an
    empty line to mark paragraphs in pretty standard.

You're right; however, it's also true that some text represents each
paragraph as a single long line and the only indicator of the
paragraph boundary is the newline character.

Re: C-n and C-a

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 29 Jan 2009 20:20:21 -0500
> Cc: emacs-devel@gnu.org
> 
> >     word-wrap-mode
> 
> But this is a misleading name

100% agreement.

Re: C-n and C-a

[Sascha Wilde]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> The new definitions of C-n and C-p seem to work reasonably
>> conveniently with the very long lines that non-Emacs-users often
>> write.  However, it is very counterintuitive that C-a and C-e have not
>> been changed in the same way.  They keep surprising me, and I have to
>> work hard to remember not to use them to do the natural thing.
>
>> I think they too should be changed to operate on screen lines;
>> that's a necessary part of the change that was already made.
>
> How about C-k?

I would strongly vote for not changing it:

Most over-long lines I encounter are made of content which really
belongs logical together (generated code, log messages ...)

I expect C-k to kill a logical line and doing otherwise would keep the
risk of leaving artifacts.

cheers
sascha
-- 
Sascha Wilde
"The primary difference [...] is that the Java program will reliably
and obviously crash, whereas the C program will do something obscure."  
   -- Java Language Tutorial

Re: C-n and C-a

[Juri Linkov]

>>     word-wrap-mode
>
> But this is a misleading name: the issue is not how lines are wrapped
> but how motion command behave.  So visual-line-mode is a much better
> name in this respect.

visual-line-mode is no less misleading - in addition to enabling visual
motion commands it also enables word wrap mode.  And there is no way
to enable visual motion commands without enabling warping text at
word boundaries.

These are two separate features amalgamated into one mode.
I think we should provide a way to toggle them separately.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Juri Linkov]

>> I think `C-up' and `C-down' are better keys for real line motion commands
>> when `up'/`C-p' and `down'/`C-n' are used for screen line motion commands.
>
> C-up and C-down are too far away from the regular position of fingers to
> be useful as the only option for anything, one needs a C-p/C-n like
> equivalent binding.

If we can't find key bindings equivalent to C-n/C-p/C-a/C-e/C-k
for real line commands in visual line mode then we should find
a key sequence to toggle visual line mode easily.

I propose `C-x n v' (similar to the related key `C-x C-n' plus `v'
that stands for "visual") or `C-x l v' (with the mnemonics of
"line visual").

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Stefan Monnier]

>>> word-wrap-mode
>> But this is a misleading name: the issue is not how lines are wrapped
>> but how motion command behave.  So visual-line-mode is a much better
>> name in this respect.
> visual-line-mode is no less misleading - in addition to enabling visual
> motion commands it also enables word wrap mode.  And there is no way
> to enable visual motion commands without enabling warping text at
> word boundaries.
> These are two separate features amalgamated into one mode.
> I think we should provide a way to toggle them separately.

I'd tend to agree.  I (setq-default word-wrap t) in my .emacs, FWIW.


        Stefan

Re: C-n and C-a

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> visual-line-mode is no less misleading - in addition to enabling visual
> motion commands it also enables word wrap mode.  And there is no way
> to enable visual motion commands without enabling warping text at
> word boundaries.
>
> These are two separate features amalgamated into one mode.
> I think we should provide a way to toggle them separately.

The features are logically separate, but in practice they are usually
useful only in combination.  When there are lots of wrapped lines, it's
natural to have commands like C-a and C-n act on visual lines.
Conversely, visual-line based commands are not terribly useful unless
the buffer has lots of long lines, and that's a pain to deal with unless
you enable word wrap.

Longlines-mode had an option to separate the word wrapping and line
motion behavior, but AFAIK no one ever used it.

Re: C-n and C-a

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I personally like the new behavior, even though it is
> indeed inconsistent.  But if people want to change the default,
> that's fine.

For whatever it's worth, I also like the new behavior.  Somehow, it
gives better results than the more consistent alternatives I've tried.

RE: C-n and C-a

[Drew Adams]

> >> I think `C-up' and `C-down' are better keys for real line 
> >> motion commands when `up'/`C-p' and `down'/`C-n' are used
> >> for screen line motion commands.
> >
> > C-up and C-down are too far away from the regular position 
> > of fingers to be useful as the only option for anything, one
> > needs a C-p/C-n like equivalent binding.
> 
> If we can't find key bindings equivalent to C-n/C-p/C-a/C-e/C-k
> for real line commands in visual line mode then we should find
> a key sequence to toggle visual line mode easily.

1. I don't use this mode and am ignorant of it. But when it is active, do you
still also need the ordinary line movement bindings? If not, then why not
reuse/co-opt those when the mode is active?

2. If you must use a binding for the mode toggle, then please set that binding
only by visual-line mode itself. Let some command in the mode initialize the
binding for the mode command (even if that binding is in the global map), so
that users who never use the mode do not lose that binding to it. Somewhat a la
mode `ffap-bindings'.

> I propose `C-x n v' (similar to the related key `C-x C-n' plus `v'
> that stands for "visual") or `C-x l v' (with the mnemonics of
> "line visual").

3. C-x n is the narrowing/widening prefix. This seems unrelated to narrowing.

C-x n d		narrow-to-defun
C-x n n		narrow-to-region
C-x n p		narrow-to-page
C-x n w		widen
...               (future)

4. C-x l is count-lines-page.

Re: C-n and C-a

[Leo]

On 2009-01-31 22:35 +0000, Drew Adams wrote:
> C-x n d		narrow-to-defun
> C-x n n		narrow-to-region
> C-x n p		narrow-to-page
> C-x n w		widen
> ...               (future)

This reminds me that org mode globally binds C-x n s to
org-narrow-to-subtree.

Actually that function has nothing to do with org except the prefix
'org-'. It'd be better move it to outline-mode.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

Re: C-n and C-a

[Juri Linkov]

>>>> word-wrap-mode
>>> But this is a misleading name: the issue is not how lines are wrapped
>>> but how motion command behave.  So visual-line-mode is a much better
>>> name in this respect.
>> visual-line-mode is no less misleading - in addition to enabling visual
>> motion commands it also enables word wrap mode.  And there is no way
>> to enable visual motion commands without enabling warping text at
>> word boundaries.
>> These are two separate features amalgamated into one mode.
>> I think we should provide a way to toggle them separately.
>
> I'd tend to agree.  I (setq-default word-wrap t) in my .emacs, FWIW.

This would be a good default for most users since most editors enable
word wrap by default.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Juri Linkov]

>> visual-line-mode is no less misleading - in addition to enabling visual
>> motion commands it also enables word wrap mode.  And there is no way
>> to enable visual motion commands without enabling warping text at
>> word boundaries.
>>
>> These are two separate features amalgamated into one mode.
>> I think we should provide a way to toggle them separately.
>
> The features are logically separate, but in practice they are usually
> useful only in combination.  When there are lots of wrapped lines, it's
> natural to have commands like C-a and C-n act on visual lines.
> Conversely, visual-line based commands are not terribly useful unless
> the buffer has lots of long lines, and that's a pain to deal with unless
> you enable word wrap.

We currently have two separate three-state modes:

1. line wrapping mode with three options:

 1.1. truncate long lines (truncate-lines=t)
 1.2. wrap at window edge (truncate-lines=nil, word-wrap=nil)
 1.3. word wrap           (truncate-lines=nil, word-wrap=t)

Traditionally `toggle-truncate-lines' is not a mode, but a command that
toggles the variable `truncate-lines'.  I think `word-wrap' should be
consistently similar by providing a command `toggle-word-wrap' that
would do almost the same and to toggle `word-wrap'.

2. operations on visual lines (line movement and line killing)

 2.1. real line operations   (line-move-visual=nil, visual-line-mode=nil)
 2.2. visual line C-n/C-p    (line-move-visual=t,   visual-line-mode=nil)
 2.3. visual line operations (line-move-visual=t,   visual-line-mode=t)

It would be enough to have only one mode `visual-line-mode' because
intermediate half-real half-visual mode (2.2) is too confusing.
To avoid inconsistency of the half-real half-visual mode we could
enable `visual-line-mode' by default.

> Longlines-mode had an option to separate the word wrapping and line
> motion behavior, but AFAIK no one ever used it.

I think the same about the default value of `word-wrap'.  If we will set
it to t, too few users will want to change its default value to nil.

But as the same time we should not insist on enabling word wrapping
when someone will explicitly disable `word-wrap' and want to enable
`visual-line-mode' to use visual line commands on lines wrapped at the
window edge.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Juri Linkov]

>> I propose `C-x n v' (similar to the related key `C-x C-n' plus `v'
>> that stands for "visual") or `C-x l v' (with the mnemonics of
>> "line visual").
>
> 3. C-x n is the narrowing/widening prefix. This seems unrelated to narrowing.
>
> C-x n d		narrow-to-defun
> C-x n n		narrow-to-region
> C-x n p		narrow-to-page
> C-x n w		widen
> ...               (future)

Can you invent more narrowing commands?
If not, then why not to use the same prefix
for commands that would have some mnemonics
associated with it?

> 4. C-x l is count-lines-page.

Do you often use count-lines-page?

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: C-n and C-a

[Drew Adams]

> >> I propose `C-x n v' (similar to the related key `C-x C-n' plus `v'
> >> that stands for "visual") or `C-x l v' (with the mnemonics of
> >> "line visual").
> >
> > 3. C-x n is the narrowing/widening prefix. This seems 
> > unrelated to narrowing.
> >
> > C-x n d		narrow-to-defun
> > C-x n n		narrow-to-region
> > C-x n p		narrow-to-page
> > C-x n w		widen
> > ...               (future)
> 
> Can you invent more narrowing commands?
> If not, then why not to use the same prefix
> for commands that would have some mnemonics
> associated with it?

Dunno, but sure, I imagine that other things could be narrowed (outlines? code
trees? function/type/object definition parts?).

Yes, we have `narrow-to-region' as a general workhorse, but one could conceive
of a narrowed portion composed of multiple, non-contiguous portions of some
document. Both the narrowing and the widening actions could conceivably be as
complex and particular as you like. We could even provide for function binding
to do that.

And Leo already pointed out `org-narrow-to-tree' as another example. But I'm not
familiar with any others, and I have no others in mind.

If the question is whether there conceivably are such opportunities, I'd say
yes. If the question is whether I have any in mind, the answer is no (but is
that relevant?).
 
> > 4. C-x l is count-lines-page.
> 
> Do you often use count-lines-page?

Do I? No. But there are a lot of things I don't use often that I'm sure you
would not want to remove from Emacs. You really don't want that to be the
criterion. ;-)

I don't have an opinion about whether `count-lines-page' deserves a binding, or
deserves this binding.

Re: C-n and C-a

[Juri Linkov]

> I don't have an opinion about whether `count-lines-page'
> deserves a binding, or deserves this binding.

If most users don't use `count-lines-page' often
then we could rebind it to:

    C-x l p ("Lines Page") - count-lines-page

and use a new key prefix `C-x l' for more line-related commands:

    C-x l t ("Lines Truncate") - toggle-truncate-lines

    C-x l w ("Lines Word wrap") - toggle-word-wrap

    C-x l v ("Lines Visual mode") - visual-line-mode

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Carsten Dominik]

On Feb 1, 2009, at 9:11 PM, Leo wrote:

> On 2009-01-31 22:35 +0000, Drew Adams wrote:
>> C-x n d		narrow-to-defun
>> C-x n n		narrow-to-region
>> C-x n p		narrow-to-page
>> C-x n w		widen
>> ...               (future)
>
> This reminds me that org mode globally binds C-x n s to
> org-narrow-to-subtree.


>
>
> Actually that function has nothing to do with org except the prefix
> 'org-'. It'd be better move it to outline-mode.

Org-mode needs this function to be compatible with
other emacsen.  So please do not move it, copy it
if you want it in outline.

- Carsten

Re: C-n and C-a

[Juri Linkov]

Below is a patch that addresses part of problems raised on
this thread.  (I'll send a separate patch for another part later).

First, it adds a new prefix map bound to `C-x l' for line-oriented
commands, and rebinds `count-lines-page' to `C-x l p'.

There was an old commented-out line for the `narrow-to-page' command
bound to `C-x p' that was later rebound to `C-x n p'.  Now we will have
a symmetrical key `C-x l p' for another page-related command.  Also it
binds more line-oriented commands to `C-x l': `toggle-truncate-lines'
to `C-x l t', `toggle-word-wrap' to `C-x l w' and `visual-line-mode'
to `C-x l v'.

`toggle-word-wrap' is a new command.  Actually it's just a copy of
`toggle-truncate-lines' that operates on the variable `word-wrap'
instead of `truncate-lines'.  By analogy with `default-truncate-lines'
it also adds a new variable `default-word-wrap'.

The default value of `word-wrap' is changed to t that is the most
expected default value nowadays as most editors do.  This eliminates
the need to enforce enabling word-mode in `visual-line-mode'.
The essential point of `visual-line-mode' is only to turn off
`truncate-lines' since otherwise it makes no sense.  The doc string
now says so.

Index: lisp/bindings.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.218
diff -c -r1.218 bindings.el
*** lisp/bindings.el	29 Jan 2009 08:53:39 -0000	1.218
--- lisp/bindings.el	6 Feb 2009 00:41:24 -0000
***************
*** 718,723 ****
--- 718,727 ----
  (define-key narrow-map "n" 'narrow-to-region)
  (define-key narrow-map "w" 'widen)
  
+ (defvar line-map (make-sparse-keymap)
+   "Keymap for line-oriented commands.")
+ (define-key ctl-x-map "l" line-map)
+ 
  ;; Quitting
  (define-key global-map "\e\e\e" 'keyboard-escape-quit)
  (define-key global-map "\C-g" 'keyboard-quit)
***************
*** 1092,1098 ****
  (define-key esc-map "\C-a" 'beginning-of-defun)
  (define-key esc-map "\C-e" 'end-of-defun)
  (define-key esc-map "\C-h" 'mark-defun)
! (define-key ctl-x-map "nd" 'narrow-to-defun)
  (define-key esc-map "(" 'insert-parentheses)
  (define-key esc-map ")" 'move-past-close-and-reindent)
  
--- 1098,1104 ----
  (define-key esc-map "\C-a" 'beginning-of-defun)
  (define-key esc-map "\C-e" 'end-of-defun)
  (define-key esc-map "\C-h" 'mark-defun)
! (define-key narrow-map "d" 'narrow-to-defun)
  (define-key esc-map "(" 'insert-parentheses)
  (define-key esc-map ")" 'move-past-close-and-reindent)
  
***************
*** 1121,1129 ****
  (define-key ctl-x-map "[" 'backward-page)
  (define-key ctl-x-map "]" 'forward-page)
  (define-key ctl-x-map "\C-p" 'mark-page)
! (define-key ctl-x-map "l" 'count-lines-page)
! (define-key ctl-x-map "np" 'narrow-to-page)
! ;; (define-key ctl-x-map "p" 'narrow-to-page)
  \f
  (defvar abbrev-map (make-sparse-keymap)
    "Keymap for abbrev commands.")
--- 1127,1138 ----
  (define-key ctl-x-map "[" 'backward-page)
  (define-key ctl-x-map "]" 'forward-page)
  (define-key ctl-x-map "\C-p" 'mark-page)
! (define-key narrow-map "p" 'narrow-to-page)
! (define-key line-map   "p" 'count-lines-page)
! \f
! (define-key line-map "t" 'toggle-truncate-lines)
! (define-key line-map "w" 'toggle-word-wrap)
! (define-key line-map "v" 'visual-line-mode)
  \f
  (defvar abbrev-map (make-sparse-keymap)
    "Keymap for abbrev commands.")

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.968
diff -c -r1.968 simple.el
*** lisp/simple.el	27 Jan 2009 20:09:38 -0000	1.968
--- lisp/simple.el	6 Feb 2009 00:42:16 -0000
***************
*** 4550,4556 ****
  
  (define-minor-mode visual-line-mode
    "Redefine simple editing commands to act on visual lines, not logical lines.
! This also turns on `word-wrap' in the buffer."
    :keymap visual-line-mode-map
    :group 'visual-line
    :lighter " wrap"
--- 4560,4566 ----
  
  (define-minor-mode visual-line-mode
    "Redefine simple editing commands to act on visual lines, not logical lines.
! This also turns off `truncate-lines' in the buffer."
    :keymap visual-line-mode-map
    :group 'visual-line
    :lighter " wrap"
***************
*** 4562,4580 ****
  	;; visual-line-mode is turned off.
  	(dolist (var '(line-move-visual truncate-lines
  		       truncate-partial-width-windows
! 		       word-wrap fringe-indicator-alist))
  	  (if (local-variable-p var)
  	      (push (cons var (symbol-value var))
  		    visual-line--saved-state)))
  	(set (make-local-variable 'line-move-visual) t)
  	(set (make-local-variable 'truncate-partial-width-windows) nil)
  	(setq truncate-lines nil
- 	      word-wrap t
  	      fringe-indicator-alist
  	      (cons (cons 'continuation visual-line-fringe-indicators)
  		    fringe-indicator-alist)))
      (kill-local-variable 'line-move-visual)
-     (kill-local-variable 'word-wrap)
      (kill-local-variable 'truncate-lines)
      (kill-local-variable 'truncate-partial-width-windows)
      (kill-local-variable 'fringe-indicator-alist)
--- 4572,4588 ----
  	;; visual-line-mode is turned off.
  	(dolist (var '(line-move-visual truncate-lines
  		       truncate-partial-width-windows
! 		       fringe-indicator-alist))
  	  (if (local-variable-p var)
  	      (push (cons var (symbol-value var))
  		    visual-line--saved-state)))
  	(set (make-local-variable 'line-move-visual) t)
  	(set (make-local-variable 'truncate-partial-width-windows) nil)
  	(setq truncate-lines nil
  	      fringe-indicator-alist
  	      (cons (cons 'continuation visual-line-fringe-indicators)
  		    fringe-indicator-alist)))
      (kill-local-variable 'line-move-visual)
      (kill-local-variable 'truncate-lines)
      (kill-local-variable 'truncate-partial-width-windows)
      (kill-local-variable 'fringe-indicator-alist)
***************
*** 5075,5080 ****
--- 5083,5103 ----
    (message "Truncate long lines %s"
  	   (if truncate-lines "enabled" "disabled")))
  
+ (defun toggle-word-wrap (&optional arg)
+   "Toggle whether to use word-wrapping for continuation lines.
+ With prefix argument ARG, wrap continuation lines at word boundaries
+ if ARG is positive, otherwise wrap them at the right screen edge.
+ This command toggles the value of `word-wrap'.  It has no effect
+ if long lines are truncated."
+   (interactive "P")
+   (setq word-wrap
+ 	(if (null arg)
+ 	    (not word-wrap)
+ 	  (> (prefix-numeric-value arg) 0)))
+   (force-mode-line-update)
+   (message "Word wrapping %s"
+ 	   (if word-wrap "enabled" "disabled")))
+ 
  (defvar overwrite-mode-textual " Ovwrt"
    "The string displayed in the mode line when in overwrite mode.")
  (defvar overwrite-mode-binary " Bin Ovwrt"

Index: src/buffer.c
===================================================================
RCS file: /sources/emacs/emacs/src/buffer.c,v
retrieving revision 1.579
diff -c -r1.579 buffer.c
*** src/buffer.c	8 Jan 2009 03:15:25 -0000	1.579
--- src/buffer.c	6 Feb 2009 00:44:28 -0000
***************
*** 5175,5181 ****
  
    XSETFASTINT (buffer_defaults.tab_width, 8);
    buffer_defaults.truncate_lines = Qnil;
!   buffer_defaults.word_wrap = Qnil;
    buffer_defaults.ctl_arrow = Qt;
    buffer_defaults.direction_reversed = Qnil;
    buffer_defaults.cursor_type = Qt;
--- 5175,5181 ----
  
    XSETFASTINT (buffer_defaults.tab_width, 8);
    buffer_defaults.truncate_lines = Qnil;
!   buffer_defaults.word_wrap = Qt;
    buffer_defaults.ctl_arrow = Qt;
    buffer_defaults.direction_reversed = Qnil;
    buffer_defaults.cursor_type = Qt;
***************
*** 5540,5545 ****
--- 5540,5550 ----
  		     doc: /* Default value of `truncate-lines' for buffers that do not override it.
  This is the same as (default-value 'truncate-lines).  */);
  
+   DEFVAR_LISP_NOPRO ("default-word-wrap",
+ 		     &buffer_defaults.word_wrap,
+ 		     doc: /* Default value of `word-wrap' for buffers that do not override it.
+ This is the same as (default-value 'word-wrap).  */);
+ 
    DEFVAR_LISP_NOPRO ("default-fill-column",
  		     &buffer_defaults.fill_column,
  		     doc: /* Default value of `fill-column' for buffers that do not override it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> First, it adds a new prefix map bound to `C-x l' for line-oriented
> commands, and rebinds `count-lines-page' to `C-x l p'.

I don't think we should make this change now.  Maybe after the release.

> `toggle-word-wrap' is a new command.  Actually it's just a copy of
> `toggle-truncate-lines' that operates on the variable `word-wrap'
> instead of `truncate-lines'.  By analogy with `default-truncate-lines'
> it also adds a new variable `default-word-wrap'.

This seems OK.

> The default value of `word-wrap' is changed to t that is the most
> expected default value nowadays as most editors do.  This eliminates
> the need to enforce enabling word-mode in `visual-line-mode'.
> The essential point of `visual-line-mode' is only to turn off
> `truncate-lines' since otherwise it makes no sense.  The doc string
> now says so.

We should not make this change now, but we can do it after the release.
At that time, someone needs to systematically go through Emacs and see
if any major modes need to bind word-wrap to nil (word wrap sometimes
gives sub-optimal results, e.g. in buffers that contain very long
words).

Re: C-n and C-a

[Stefan Monnier]

> instead of `truncate-lines'.  By analogy with `default-truncate-lines'
> it also adds a new variable `default-word-wrap'.

The "default-*" variables are on the way out.  Please don't add
new ones.


        Stefan

Re: C-n and C-a

[Juri Linkov]

>> First, it adds a new prefix map bound to `C-x l' for line-oriented
>> commands, and rebinds `count-lines-page' to `C-x l p'.
>
> I don't think we should make this change now.  Maybe after the release.

Providing convenient key bindings to toggle these modes mitigates
part of problems.

>> `toggle-word-wrap' is a new command.  Actually it's just a copy of
>> `toggle-truncate-lines' that operates on the variable `word-wrap'
>> instead of `truncate-lines'.  By analogy with `default-truncate-lines'
>> it also adds a new variable `default-word-wrap'.
>
> This seems OK.

Installed without `default-word-wrap'.

>> The default value of `word-wrap' is changed to t that is the most
>> expected default value nowadays as most editors do.  This eliminates
>> the need to enforce enabling word-mode in `visual-line-mode'.
>> The essential point of `visual-line-mode' is only to turn off
>> `truncate-lines' since otherwise it makes no sense.  The doc string
>> now says so.
>
> We should not make this change now, but we can do it after the release.

I agree.  When I enabled word-wrap globally two days ago, I immediately
discovered a problem in Dired - after copying a file I missed it because
its very long name was wrapped completely to the left side of the dired
buffer where it is hard to notice in an unusual place.

> At that time, someone needs to systematically go through Emacs and see
> if any major modes need to bind word-wrap to nil (word wrap sometimes
> gives sub-optimal results, e.g. in buffers that contain very long
> words).

For starters, the following patch does this for dired-mode:

Index: lisp/dired.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired.el,v
retrieving revision 1.421
diff -u -r1.421 dired.el
--- lisp/dired.el	27 Jan 2009 03:53:07 -0000	1.421
+++ lisp/dired.el	8 Feb 2009 00:45:05 -0000
@@ -1744,6 +1744,7 @@
 	;; case-fold-search nil
 	buffer-read-only t
 	selective-display t		; for subdirectory hiding
+	word-wrap nil
 	mode-line-buffer-identification
 	(propertized-buffer-identification "%17b"))
   (set (make-local-variable 'revert-buffer-function)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Stefan Monnier]

> For starters, the following patch does this for dired-mode:

FWIW, I think the right patch for dired would be to set truncate-lines
to t.


        Stefan

Re: C-n and C-a

[Christian Schlauer]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I think the right patch for dired would be to set truncate-lines
> to t.

Yes, please.

+1

-- 
Christian Schlauer

RE: C-n and C-a

[Drew Adams]

> FWIW, I think the right patch for dired would be to
> set truncate-lines to t.

Why?

Re: C-n and C-a

[Stefan Monnier]

>> FWIW, I think the right patch for dired would be to
>> set truncate-lines to t.
> Why?

Why not?  It uses a buffer formatted into columns, so any wrap-around
messes up the clean column layout.


        Stefan

RE: C-n and C-a

[Drew Adams]

> >> FWIW, I think the right patch for dired would be to
> >> set truncate-lines to t.
> > Why?
> 
> Why not?  It uses a buffer formatted into columns, so any wrap-around
> messes up the clean column layout.

I have no problem with it, personally. It's good for a proposed change to be
accompanied by a rationale for the change; that's all.

Dired and (buffer-local) `truncate-lines' have been around nearly as long as
Emacs itself. I can't think of a good reason why the value here should be nil,
but perhaps someone knows why this was not changed to t before now? IOW, as you
say, why not?

Re: C-n and C-a

[Juri Linkov]

>> For starters, the following patch does this for dired-mode:
>
> FWIW, I think the right patch for dired would be to set truncate-lines
> to t.

I have no opinion on the default of truncate-lines in dired but I think
setting word-wrap to nil in dired-mode is necessary as well to prevent
the problem I described in the case when someone sets truncate-lines to nil
and word-wrap to t globally.

There are also two other ways to mitigate the word-wrap problem in Dired:

1. display arrows at the right fringe in visual-line-mode indicating
that the file name is wrapped to the left side of the dired buffer;

2. add an option to the variable word-wrap to wrap at word boundaries
instead of whitespace as is currently implemented.  Thus wrapping might
occur inside a long file name that has non-word non-whitespace characters,
and it's likely that at least the first word will remain unwrapped.
However, this is not for the coming release.

For the same reason I think we should not set word-mode in
visual-line-mode.  Someone might want to enable visual-line-mode in
dired and stumble upon the same problem.  The following patch
fixes this.

Also there is a problem with the terminology.  The term "logical line"
causes cognitive dissonance - it is a common synonym of "virtual line"
and is opposite to the "real line".  But currently "logical line"
is used as a synonym of "real line".

From Jargon File 4.4.4 (14 Aug 2003):

  virtual

     1. Common alternative to logical; often used to refer to the
     artificial objects (like addressable virtual memory larger than
     physical memory) simulated by a computer system as a convenient way
     to manage access to shared resources.

     2. Simulated; performing the functions of something that isn't
     really there. An imaginative child's doll may be a virtual playmate.
     Oppose real.

I suggest using the term "real lines" instead of "logical lines".

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.971
diff -c -r1.971 simple.el
*** lisp/simple.el	8 Feb 2009 00:46:38 -0000	1.971
--- lisp/simple.el	11 Feb 2009 22:44:57 -0000
***************
*** 4554,4564 ****
  (defvar visual-line--saved-state nil)
  
  (define-minor-mode visual-line-mode
!   "Redefine simple editing commands to act on visual lines, not logical lines.
! This also turns on `word-wrap' in the buffer."
    :keymap visual-line-mode-map
    :group 'visual-line
    :lighter " wrap"
--- 4564,4574 ----
  (defvar visual-line--saved-state nil)
  
  (define-minor-mode visual-line-mode
!   "Redefine simple editing commands to act on visual lines, not real lines.
! This also turns off `truncate-lines' in the buffer."
    :keymap visual-line-mode-map
    :group 'visual-line
    :lighter " wrap"
***************
*** 4566,4584 ****
  	;; visual-line-mode is turned off.
  	(dolist (var '(line-move-visual truncate-lines
  		       truncate-partial-width-windows
! 		       word-wrap fringe-indicator-alist))
  	  (if (local-variable-p var)
  	      (push (cons var (symbol-value var))
  		    visual-line--saved-state)))
  	(set (make-local-variable 'line-move-visual) t)
  	(set (make-local-variable 'truncate-partial-width-windows) nil)
  	(setq truncate-lines nil
- 	      word-wrap t
  	      fringe-indicator-alist
  	      (cons (cons 'continuation visual-line-fringe-indicators)
  		    fringe-indicator-alist)))
      (kill-local-variable 'line-move-visual)
-     (kill-local-variable 'word-wrap)
      (kill-local-variable 'truncate-lines)
      (kill-local-variable 'truncate-partial-width-windows)
      (kill-local-variable 'fringe-indicator-alist)
--- 4576,4592 ----
  	;; visual-line-mode is turned off.
  	(dolist (var '(line-move-visual truncate-lines
  		       truncate-partial-width-windows
! 		       fringe-indicator-alist))
  	  (if (local-variable-p var)
  	      (push (cons var (symbol-value var))
  		    visual-line--saved-state)))
  	(set (make-local-variable 'line-move-visual) t)
  	(set (make-local-variable 'truncate-partial-width-windows) nil)
  	(setq truncate-lines nil
  	      fringe-indicator-alist
  	      (cons (cons 'continuation visual-line-fringe-indicators)
  		    fringe-indicator-alist)))
      (kill-local-variable 'line-move-visual)
      (kill-local-variable 'truncate-lines)
      (kill-local-variable 'truncate-partial-width-windows)
      (kill-local-variable 'fringe-indicator-alist)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> There are also two other ways to mitigate the word-wrap problem in Dired:
...

3.  Add a wrap-prefix that indents the wrapped lines a lot so that
they're in the filename column (maybe indented extra within that
column).

> For the same reason I think we should not set word-mode in
> visual-line-mode.

This seems bizarre -- AFAICS, like 95% of the goal of visual-line-mode
is to make it easy to enable a word-wrapped mode for editing
paragraphs-end-in-newline text (i.e., a display-time version of
longlines-mode).

-Miles

-- 
Patience, n. A minor form of despair, disguised as a virtue.

Re: C-n and C-a

[Juri Linkov]

> 3.  Add a wrap-prefix that indents the wrapped lines a lot so that
> they're in the filename column (maybe indented extra within that
> column).

That would be very nice.  Setting `wrap-prefix' in Dired to a string of
50 spaces (handling variable widths is possible in `insert-directory')
produces a good-looking result.  However, when `word-wrap' is non-nil
then the result is weird: there are many empty lines for every wrapped
file name.  Seems like a bug.  I'll create a bug report later.

>> For the same reason I think we should not set word-mode in
>> visual-line-mode.
>
> This seems bizarre -- AFAICS, like 95% of the goal of visual-line-mode
> is to make it easy to enable a word-wrapped mode for editing
> paragraphs-end-in-newline text (i.e., a display-time version of
> longlines-mode).

The problem is that currently by default C-n/C-p moves by visual lines,
but C-a/C-e moves by real lines.  `visual-line-mode' is the only way to
cause C-a/C-e to move by visual lines.  But it forces `word-wrap' to be
t even in buffers where word-wrap should be nil (where word wrap gives
sub-optimal results).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-n and C-a

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>>> For the same reason I think we should not set word-mode in
>>> visual-line-mode.
>>
>> This seems bizarre -- AFAICS, like 95% of the goal of visual-line-mode
>> is to make it easy to enable a word-wrapped mode for editing
>> paragraphs-end-in-newline text (i.e., a display-time version of
>> longlines-mode).
>
> The problem is that currently by default C-n/C-p moves by visual lines,
> but C-a/C-e moves by real lines.  `visual-line-mode' is the only way to
> cause C-a/C-e to move by visual lines.  But it forces `word-wrap' to be
> t even in buffers where word-wrap should be nil (where word wrap gives
> sub-optimal results).

If visual-line-mode doesn't turn on word-wrap, then there needs to be a
new mode which is visual-line-mode+word-wrap, because I think that's an
incredibly common case (probably more so than without word-wrap).

If the only use of visual-line-mode without word-wrap is
programmatically (by other modes), then maybe it's enough to just force
word-wrap off in those modes somehow (either by frobbing the variable
itself after turning it on, or by some let-binding around the mode
invocation).

-Miles

-- 
Run away!  Run away!

Re: C-n and C-a

[Richard M Stallman]

    If the only use of visual-line-mode without word-wrap is
    programmatically (by other modes), then maybe it's enough to just force
    word-wrap off in those modes somehow (either by frobbing the variable
    itself after turning it on, or by some let-binding around the mode
    invocation).

The cleanest way would be to have a variable that these modes can set,
which causes Visual-Line mode not to enable word wrap by default.