please make line-move-visual nil

please make line-move-visual nil

[Alfred M. Szmidt]

Please make line-move-visual nil, it is totally uninutive to have the
point move to the same line, when you explicitly told it to move to
the next line.

It also breaks keyboard macros, since now you have no idea if you end
up on a new line, or on the same line but at a different column.

I know that it is pre-test time, but this behaviour is simply stupid
and doesn't make any sense.

Re: please make line-move-visual nil

[garyo]

Alfred M. Szmidt wrote:
> 
> Please make line-move-visual nil, it is totally uninutive to have the
> point move to the same line, when you explicitly told it to move to
> the next line.
> 

I agree, this is very different behavior for such a core command!

-- 
View this message in context: http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23521879.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: please make line-move-visual nil

[Deniz Dogan]

2009/5/13 garyo <garyo@genarts.com>:
>
>
>
> Alfred M. Szmidt wrote:
>>
>> Please make line-move-visual nil, it is totally uninutive to have the
>> point move to the same line, when you explicitly told it to move to
>> the next line.
>>
>
> I agree, this is very different behavior for such a core command!

I strongly disagree. I think this new behavior is way more intuitive
to new Emacs users, who may not know how to set line-move-visual to
non-nil themselves. It always bugged me when I started out using
Emacs, coming from a Windows background, that it moved like it did.

Re: please make line-move-visual nil

[garyo]

Deniz Dogan-3 wrote:
> 
> 2009/5/13 garyo <garyo@genarts.com>:
>> I agree, this is very different behavior for such a core command!
> 
> I strongly disagree. I think this new behavior is way more intuitive
> to new Emacs users
> 

Good point, it's important to attract new users, but there are already so
many ways Emacs differs from any other editor that I'm not sure it's worth
breaking existing keyboard macros that have worked for years, not to mention
forcing all the existing users to discover and change this setting.  It
really is a very core behavior, and it seems pretty late in the evolution of
Emacs to change something like this.  How about something like what C-x n n
does?  The first time you C-n down and end up on the same line, it could ask
you if you want the "notepad" behavior or the "traditional" behavior?  Then
you could enable (permanently or not) or disable.  Sure it would be a little
odd, but we're already in uncharted territory it seems to me.
-- 
View this message in context: http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23532135.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: please make line-move-visual nil

[Teemu Likonen]

On 2009-05-13 17:06 (-0700), garyo wrote:

> Good point, it's important to attract new users, but there are already
> so many ways Emacs differs from any other editor that I'm not sure
> it's worth breaking existing keyboard macros that have worked for
> years [...]

Hmm, does somebody really expect keyboard macros to work reliably over
years? (Even if they may have worked in some cases.) Well, I have used
Emacs less than year but I see macros more like temporary helpers.

I'll have line-move-visual turned on from the day I upgrade to Emacs 23,
regardless of the default. I think it's the normal behavior in text
editors and pretty much in all text editing and thus it's sensible
default. Long-timers with their years-old keyboard macros do know how to
deal with Emacs configuration.

Re: please make line-move-visual nil

[Antoine Levitt]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

I think line-move-visual is great for common usage. It seems to me the
problem of users with this new setting is mainly in keyboard macros. Why not
disable line-move-visual when typing or replaying a keyboard macro, since in
most case the user want the action to be independent of the line it is on ?
Kind of a hack, but there's clearly two usages of the line move commands
here.
2009/5/14 Teemu Likonen <tlikonen@iki.fi>

> On 2009-05-13 17:06 (-0700), garyo wrote:
>
> > Good point, it's important to attract new users, but there are already
> > so many ways Emacs differs from any other editor that I'm not sure
> > it's worth breaking existing keyboard macros that have worked for
> > years [...]
>
> Hmm, does somebody really expect keyboard macros to work reliably over
> years? (Even if they may have worked in some cases.) Well, I have used
> Emacs less than year but I see macros more like temporary helpers.
>
> I'll have line-move-visual turned on from the day I upgrade to Emacs 23,
> regardless of the default. I think it's the normal behavior in text
> editors and pretty much in all text editing and thus it's sensible
> default. Long-timers with their years-old keyboard macros do know how to
> deal with Emacs configuration.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

Re: please make line-move-visual nil

[garyo]

Teemu Likonen-2 wrote:
> 
> Hmm, does somebody really expect keyboard macros to work reliably over
> years? (Even if they may have worked in some cases.) Well, I have used
> Emacs less than year but I see macros more like temporary helpers.
> 

Well, I've been using Emacs since 1983 (about 25 years now), and C-n has
never changed in all that time, and my ancient keyboard macros I've
accumulated over the years still work :-).

Another weirdness when this is turned on is what happens when you do C-u 25
C-n (go down 25 lines).  This goes down a variable number of (real) lines
now, depending on your emacs's screen width!  A little odd, no?  Maybe it's
not, and I'm just old and stuck in my ways.
-- 
View this message in context: http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23538683.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: please make line-move-visual nil

[Teemu Likonen]

On 2009-05-14 04:29 (-0700), garyo wrote:

> Another weirdness when this is turned on is what happens when you do
> C-u 25 C-n (go down 25 lines). This goes down a variable number of
> (real) lines now, depending on your emacs's screen width! A little
> odd, no? Maybe it's not, and I'm just old and stuck in my ways.

Obviously your logic is valid too. It's just that computer users tend to
navigate visually on the screen-buffer. Machines, such as Emacs Lisp
code, navigates on file-buffer (usually).

Re: please make line-move-visual nil

[Shaun Johnson]

Alfred M. Szmidt wrote:
> Please make line-move-visual nil, it is totally uninutive to have the
> point move to the same line, when you explicitly told it to move to
> the next line.
> 
> It also breaks keyboard macros, since now you have no idea if you end
> up on a new line, or on the same line but at a different column.
> 
> I know that it is pre-test time, but this behaviour is simply stupid
> and doesn't make any sense.

FWIW I completely agree, I find this behaviour bizarre in the extreme.
I appreciate that others, coming from a different background, may find
this behaviour intuitive but I don't see that as a reason to change such
a core behaviour.

Shaun Johnson.

Re: please make line-move-visual nil

[David Reitter]

On May 14, 2009, at 9:00 AM, Shaun Johnson wrote:

> Alfred M. Szmidt wrote:
>> Please make line-move-visual nil, it is totally uninutive to have the
>> point move to the same line, when you explicitly told it to move to
>> the next line.

> FWIW I completely agree, I find this behaviour bizarre in the extreme.
> I appreciate that others, coming from a different background, may find
> this behaviour intuitive but I don't see that as a reason to change  
> such
> a core behaviour.


For people seeking to understand the reasons behind this default  
choice at this late stage in the release process, it may be helpful to  
review the discussions here about the new word-wrap (soft wrapping)  
feature, where continued buffer lines comprise whole paragraphs in  
text rather than just the occasional over-long line in code.  Also,  
consider the increased use of variable width fonts, which are standard  
for non-code text in modern operating environments.

On a more general note, I wonder why experienced users occasional  
resist change in the UI in general (as it breaks things) rather than  
avoiding to upgrade.  Perhaps, providing bug fixes for previous  
branches (e.g., Emacs 22) for a few years after the release of a new  
full version would mitigate these issues.

Re: please make line-move-visual nil

[Bob Nnamtrop]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

I somehow missed this.  I have no opinion on the default but I have noticed
an inconsistency with this variable.  In viper-mode, line-move-visual is
respected by down/up arrows but not by j/k.  I would think they should BOTH
respect the variable.  These call the functions previous-line/next-line and
viper-previous-line/viper-next-line, respectively.  It would seem the viper
version need to be corrected.

Bob

On Wed, May 13, 2009 at 7:35 AM, garyo <garyo@genarts.com> wrote:

>
>
>
> Alfred M. Szmidt wrote:
> >
> > Please make line-move-visual nil, it is totally uninutive to have the
> > point move to the same line, when you explicitly told it to move to
> > the next line.
> >
>
> I agree, this is very different behavior for such a core command!
>
> --
> View this message in context:
> http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23521879.html
> Sent from the Emacs - Dev mailing list archive at Nabble.com.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1427 bytes --]

Re: please make line-move-visual nil

[Alan Mackenzie]

On Thu, May 14, 2009 at 09:20:44AM -0700, David Reitter wrote:
> On May 14, 2009, at 9:00 AM, Shaun Johnson wrote:

> >Alfred M. Szmidt wrote:
> >>Please make line-move-visual nil, it is totally uninutive to have the
> >>point move to the same line, when you explicitly told it to move to
> >>the next line.

> >FWIW I completely agree, I find this behaviour bizarre in the extreme.
> >I appreciate that others, coming from a different background, may find
> >this behaviour intuitive but I don't see that as a reason to change
> >such a core behaviour.

> For people seeking to understand the reasons behind this default  
> choice at this late stage in the release process, it may be helpful to  
> review the discussions here about the new word-wrap (soft wrapping)  
> feature, where continued buffer lines comprise whole paragraphs in  
> text rather than just the occasional over-long line in code.  Also,  
> consider the increased use of variable width fonts, which are standard  
> for non-code text in modern operating environments.

I don't see anything bizarre and extreme about this change, but as a
minor point I wish this change had been made by rebinding C-n to a [new?]
command `next-visual-line'.  It used to be that "line" meant the text
between two \n's, and now its definition has become vague and mushy.

I think I'm marginally in favour of C-n, C-p moving by screen lines,
since the pain it causes old-timers (having to type C-n again) is less
than the pain of navigating through buffers with long lines when C-n
jumps over several screen lines.  But yes, these new commands will cuase
pain for people who use them in keyboard macros.  These people will
probably twig quite quickly what's amiss, and will be able to fix it at
the cost of a throbbing headache.

> On a more general note, I wonder why experienced users occasionally
> resist change in the UI in general (as it breaks things) rather than  
> avoiding to upgrade.

[linguistic point: "avoid" takes a noun or a gerund (which needn't be
round), not an infinitive.  You want "avoiding an upgrade" or "avoiding
upgrading" here.]

You're not trying to ignite another rambling heated debate about changing
long standing features, are you?  OK, thought not.

Changing the UI makes the new version incompatible with the learning of
the users of the old versions.  Either they must relearn things, which is
painful, or they must track down the options they need to unset to make
it work how it used to, which is painful.  This pain is a Bad Thing.
Only if the new UI is stunningly good is the change justified.  IMAO, the
UI changes in Emacs 23 aren't justified.

> Perhaps, providing bug fixes for previous branches (e.g., Emacs 22) for
> a few years after the release of a new  full version would mitigate
> these issues.

It's too much work at the moment.  It might become feasible with bazaar.
That's pure speculation by the way - I haven't tried bazaar out yet.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: please make line-move-visual nil

[Alfred M. Szmidt]

   > Another weirdness when this is turned on is what happens when you
   > do C-u 25 C-n (go down 25 lines). This goes down a variable
   > number of (real) lines now, depending on your emacs's screen
   > width! A little odd, no? Maybe it's not, and I'm just old and
   > stuck in my ways.

I find this odd as well.

   Obviously your logic is valid too. It's just that computer users
   tend to navigate visually on the screen-buffer. Machines, such as
   Emacs Lisp code, navigates on file-buffer (usually).

There are alot of statements to the effect that new users will find
line-move-visual more intuitive, and some new users have stated that
they do find it more intuitive, likewise some old time users have
stated the opposite.  But has anyone actually done a poll on it or
anything similar to that?


I really think that this change should wait to after 23, and 23 should
leave line-move-visual as nil.

Re: please make line-move-visual nil

[Lennart Borgman]

On Thu, May 14, 2009 at 11:37 AM, Antoine Levitt <smeuuh@gmail.com> wrote:
> I think line-move-visual is great for common usage. It seems to me the
> problem of users with this new setting is mainly in keyboard macros. Why not
> disable line-move-visual when typing or replaying a keyboard macro, since in
> most case the user want the action to be independent of the line it is on ?
> Kind of a hack, but there's clearly two usages of the line move commands
> here.

I have also suggested turning off line-move-visual when handling
macros. I can't see any reason not to do that.

Re: please make line-move-visual nil

[Stephen J. Turnbull]

I think a better approach to context-dependent behavior would be
buffer-local.  Buffers where long lines are very common, and modes
where newline is paragraph end, etc, should set line-move-visual on.
Programming modes, table modes, etc should not.

Lennart Borgman writes:
 > On Thu, May 14, 2009 at 11:37 AM, Antoine Levitt <smeuuh@gmail.com> wrote:
 > > I think line-move-visual is great for common usage. It seems to me the
 > > problem of users with this new setting is mainly in keyboard macros. Why not
 > > disable line-move-visual when typing or replaying a keyboard macro, since in
 > > most case the user want the action to be independent of the line it is on ?
 > > Kind of a hack, but there's clearly two usages of the line move commands
 > > here.
 > 
 > I have also suggested turning off line-move-visual when handling
 > macros. I can't see any reason not to do that.

The whole point of a macro is "what you did is what you get", but now
people have to think about how behavior is going to change from when
they just did to when they create the macro.  That's going to reduce
the utility of macros.

One of the things that makes Emacs the great (and unusual) environment
that it is is this *deliberate* blurring of the lines between UI and
API, and between API and implementation.  Because of the rigid nature
of APIs, this necessarily causes a certain amount of rigidity in both
UI and implementation.

I don't think it's a good idea to draw a line between the UI and the
API that way.  Instead, say "I'm sorry, oldtimer, but this *is* a much
better default behavior for most users most of the time, and if it
bothers your ancient macros, switch it off."  The rigidity is not a
good thing, but please don't undermine the basic greatness of Emacs
because you dislike it.

Re: please make line-move-visual nil

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

On May 14, 2009, at 11:17 AM, Alan Mackenzie wrote:
>>
>> On a more general note, I wonder why experienced users occasionally
>> resist change in the UI in general (as it breaks things) rather than
>> avoiding to upgrade.
>
> [linguistic point: "avoid" takes a noun or a gerund (which needn't be
> round), not an infinitive.  You want "avoiding an upgrade" or  
> "avoiding
> upgrading" here.]

You are right.  My heartfelt apologies.  Language is to me what people  
(me excluded) speak, not what some book says.  The avoid+infinitive  
construction doesn't get any traction in a Google search (using past  
tense), so I concede.

> You're not trying to ignite another rambling heated debate about  
> changing
> long standing features, are you?  OK, thought not.

God no, I am not.

> Changing the UI makes the new version incompatible with the learning  
> of
> the users of the old versions.

Absolutely.  But if people don't like change, then they shouldn't be  
forced to upgrade if we provided decent support for older versions.   
As you said, a new VCS will hopefully facilitate this.  I use git and  
have evaluated Bazaar, and they both can cherry-pick bugfixes from the  
development branch and facilitate just that.  One could really start  
with Emacs 22.

Projects of the size/importance of Emacs should provide a roadmap with  
a promise to support certain releases for x many years.  But even  
providing [important] bug fixes for the 22 series for a while should  
be considered.

- David
(who is actually a Diplom-Sprachwissenschaftler.)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: please make line-move-visual nil

[Stephen J. Turnbull]

David Reitter writes:

 > Absolutely.  But if people don't like change, then they shouldn't be  
 > forced to upgrade if we provided decent support for older versions.

Old versions of Emacs are not very buggy.  Lack of support for old
versions simply is not an issue.  A recent survey of Emacsen conducted
at a large 4-letter financial firm I am not at liberty to name showed
over *30* different versions of Emacs/XEmacs in use, going back to
Emacs 18.55.  That in 220 responses.

What people are upset about here is that upgrades that they really do
want include backward incompatible changes that they dislike intensely
and think are stupid.

 > As you said, a new VCS will hopefully facilitate this.  I use git
 > and have evaluated Bazaar, and they both can cherry-pick bugfixes
 > from the development branch and facilitate just that.

This is a really, really bad idea, unfortunately.  This means doing
all the design review and much of the quality assurance and some
amount of the bug-fixing over again.  People who want that are already
doing it (a certain David Reitter who maintains Aquamacs comes to mind).

But the people who are complaining about *defaults for options* (!!) 
are for sure not going to find that acceptable.  What they want is the
shiny new Emacs with the particolored new features, except the stupid
ones.  In theory that could be supported by "inverse cherry-picking"
aka "spitting out the indigestible pits" (ie, reverting patches you
don't like).

But both cherry-picking and pit-spitting run into the problem that
currently Emacs workflow does not require coherent changesets.  There
is no way to assure that *this* feature is associated with *exactly
these* patches.  Making that change to workflow is going to be very
very hard, but without it the cherry-picking roll-yer-own Emacsen
strategy is highly labor intensive.

 > Projects of the size/importance of Emacs should provide a roadmap with  
 > a promise to support certain releases for x many years.

Good luck with that.  AFAIK "we support only the current version" is
explicit policy.

Re: please make line-move-visual nil

[Stephen Berman]

On Thu, 14 May 2009 22:32:53 -0700 David Reitter <david.reitter@gmail.com> wrote:

> On May 14, 2009, at 11:17 AM, Alan Mackenzie wrote:
>>>
>>> On a more general note, I wonder why experienced users occasionally
>>> resist change in the UI in general (as it breaks things) rather than
>>> avoiding to upgrade.
>>
>> [linguistic point: "avoid" takes a noun or a gerund (which needn't be
>> round), not an infinitive.  You want "avoiding an upgrade" or "avoiding
>> upgrading" here.]
>
> You are right.  My heartfelt apologies.  Language is to me what people (me
> excluded) speak, not what some book says.  The avoid+infinitive  construction
> doesn't get any traction in a Google search (using past  tense), so I concede.

One not too rarely encountered (and to me fairly acceptable)
avoid+infinitive construction is when `avoid' is passivized with an
expletive subject: "It should be avoided to ...".  FWIW Google
(http://www.google.com/#hl=en&q="it+should+be+avoided+to"&btnG=Google+Search&aq=f&oq=undefined&fp=Frx3gI01710)
shows "about 3,380" hits.  Interestingly (and probably not
insignificantly), the same search with the German Google
(http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=cYC&q="it+should+be+avoided+to"&btnG=Suche&meta=&aq=f&oq=)
shows "ungefähr 9.520" hits (for non-German readers: the point here is used
like the comma in English).

Steve Berman

Re: please make line-move-visual nil

[Miles Bader]

Stephen Berman <stephen.berman@gmx.net> writes:
> One not too rarely encountered (and to me fairly acceptable)
> avoid+infinitive construction is when `avoid' is passivized with an
> expletive subject: "It should be avoided to ...".  FWIW Google

To my ear, "avoid to" is clearly incorrect (and I think my ear is pretty
good).

There's _tons_ of bizarro grammar/misspellings/... on the net (googling
as a means of checking spelling is risky because of that!).  I suspect
such usage is nowhere near the threshold where it's considered actually
part of the language though....

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

RE: please make line-move-visual nil

[Drew Adams]

> One not too rarely encountered (and to me fairly acceptable)
> avoid+infinitive construction is when `avoid' is passivized with an
> expletive subject: "It should be avoided to ...".

In what country is "avoid to" not too rarely encountered? ;-)

One hears that kind of thing in continental Europe, from non-native English
speakers. I always thought of it as a kind of faux ami: a direct
(mis-)translation.

The same thing happens with other verbs, besides "avoid". It's sometimes
difficult for those for whom English is a second or third language to keep track
of when the infinitive is called for.

Re: please make line-move-visual nil

[Stephen Berman]

On Fri, 15 May 2009 16:58:02 +0900 Miles Bader <miles@gnu.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>> One not too rarely encountered (and to me fairly acceptable)
>> avoid+infinitive construction is when `avoid' is passivized with an
>> expletive subject: "It should be avoided to ...".  FWIW Google
>
> To my ear, "avoid to" is clearly incorrect (and I think my ear is pretty
> good).

I agree with you (I'm a native speaker of American English) about "avoid
to", i.e. in the active voice (and with an animate subject), but do you
think the construction I referred to is just as "clearly incorrect" (I
would rather say (un)acceptable)?  I think there's a pretty clear
difference in acceptability.  There are at least a few other verbs that
pattern with `avoid' in this respect.  For example, these are all
"clearly incorrect":

(1) We avoided/recommended/suggested/discouraged to arrive early.

in contrast to these, which are "correct" English:

(2) We avoided/recommended/suggested/discouraged arriving early.

When the main verb is passivized, an expletive subject is used, and the
complements are reversed, I think there's a similar contrast.  That is,
the following are completely unacceptable[1]:

(3) It should be avoided/
       is highly recommended/
       is strongly suggested/discouraged arriving early.

while I think these sound more or less fine (`avoided' less than the
others, but not completely bad, and clearly contrasting with (3)):

(4) It should be avoided/
       is highly recommended/
       is strongly suggested/discouraged to arrive early.

Do you find no acceptability contrast between (3) and (4)?

Steve Berman

Footnotes: 
[1] There is a marginal reading of (3) where the subject `it' refers to
`arriving early' (it's marginal in (3) because as normally written it is
set off by a comma).  But on the reading I mean `it' is an expletive,
non-referential.

Re: please make line-move-visual nil

[Miles Bader]

Stephen Berman <stephen.berman@gmx.net> writes:
>>> expletive subject: "It should be avoided to ...".  FWIW Google
>>
>> To my ear, "avoid to" is clearly incorrect (and I think my ear is pretty
>> good).
>
> I agree with you (I'm a native speaker of American English) about "avoid
> to", i.e. in the active voice (and with an animate subject), but do you
> think the construction I referred to is just as "clearly incorrect"

Yes

-Miles

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

Re: please make line-move-visual nil

[Davis Herring]

>    > Another weirdness when this is turned on is what happens when you
>    > do C-u 25 C-n (go down 25 lines). This goes down a variable
>    > number of (real) lines now, depending on your emacs's screen
>    > width! A little odd, no? Maybe it's not, and I'm just old and
>    > stuck in my ways.
>
> I find this odd as well.
>
>    Obviously your logic is valid too. It's just that computer users
>    tend to navigate visually on the screen-buffer. Machines, such as
>    Emacs Lisp code, navigates on file-buffer (usually).

Perhaps this is too obvious to mention: why not make `next-line' treat
`line-move-visual' as nil whenever it is given a prefix argument?  It
would not be difficult to decorate usage of C-n/C-p/<up>/<down> with C-1
in macros that already exist.

(It would be tempting to have the prefix argument reverse the meaning of
the variable rather than merely ignore it, but then macros written to use
the character-based mode would change meaning when the variable changed.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: please make line-move-visual nil

[Stephen J. Turnbull]

Stephen Berman writes:

 > (3) It should be avoided/
 > (4) It should be avoided/

 > Do you find no acceptability contrast between (3) and (4)?

No.  As they are identical, they are identically unacceptable.  By
that, I mean that in educating my daughter (who is a native Japanese
speaker), I would *never* let that pass, not even in casual
conversation.  The only acceptable way to terminate those strings is
with an immediate period, but then "it" cannot be an expletive.

I agree that in terms of intelligibility it is somewhat better to
follow an expletive "it" with the infinitive rather than the gerund.

As a matter of style, of course that phrasing is abysmal.  There is no
need whatsoever for an expletive "it" to express that idea in English.

Re: please make line-move-visual nil

[Stefan Monnier]

> I don't see anything bizarre and extreme about this change, but as a
> minor point I wish this change had been made by rebinding C-n to a [new?]
> command `next-visual-line'.  It used to be that "line" meant the text
> between two \n's, and now its definition has become vague and mushy.

There's already been such a distinction between next-line and
forward-line.  The "text between two \n" has always been associated with
forward-line, whereas next-line was used for a mroe visually-oriented
notion of line (e.g. it skips invisible text, even if it contains \n).
For this reason, most (not all, of course) uses of next-line in Elisp is
a bug.  And for this reason as well, I don't think there's a strong
motivation to introduce yet-another line-movement command.


        Stefan

Re: please make line-move-visual nil

[Alfred M. Szmidt]

   I think a better approach to context-dependent behavior would be
   buffer-local.  Buffers where long lines are very common, and modes
   where newline is paragraph end, etc, should set line-move-visual
   on.  Programming modes, table modes, etc should not.

I think this is a good suggestion.

Re: please make line-move-visual nil

[Alfred M. Szmidt]

   >    Obviously your logic is valid too. It's just that computer users
   >    tend to navigate visually on the screen-buffer. Machines, such as
   >    Emacs Lisp code, navigates on file-buffer (usually).

   Perhaps this is too obvious to mention: why not make `next-line'
   treat `line-move-visual' as nil whenever it is given a prefix
   argument?  It would not be difficult to decorate usage of
   C-n/C-p/<up>/<down> with C-1 in macros that already exist.

C-u C-n (and its variants) is a very useful movement command.

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Sun, 17 May 2009 02:29:38 -0400
> Cc: tlikonen@iki.fi, garyo@genarts.com, emacs-devel@gnu.org
> Reply-To: ams@gnu.org
> 
>    Perhaps this is too obvious to mention: why not make `next-line'
>    treat `line-move-visual' as nil whenever it is given a prefix
>    argument?  It would not be difficult to decorate usage of
>    C-n/C-p/<up>/<down> with C-1 in macros that already exist.
> 
> C-u C-n (and its variants) is a very useful movement command.

Indeed.  I hope no one is seriously considering to interpret a numeric
argument to these commands as anything other than the number of lines
to move.

Re: please make line-move-visual nil

[Davis Herring]

>>    Perhaps this is too obvious to mention: why not make `next-line'
>>    treat `line-move-visual' as nil whenever it is given a prefix
>>    argument?  It would not be difficult to decorate usage of
>>    C-n/C-p/<up>/<down> with C-1 in macros that already exist.
>>
>> C-u C-n (and its variants) is a very useful movement command.
>
> Indeed.  I hope no one is seriously considering to interpret a numeric
> argument to these commands as anything other than the number of lines
> to move.

I wasn't -- but I was suggesting that a numeric argument specify the
number of lines and (if `line-move-visual is non-nil) change the meaning
of the word "line" for the duration of the command.  My thought is that
visual movement, where it differs from logical, is likely to be over short
distances and with quick bursts of n-n-n (with control held) or
down-down-down rather than with numeric arguments.  Maybe others disagree
on the likely usage scenario.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: please make line-move-visual nil

[Drew Adams]

I'm coming back to this thread because I just tried the new pretest (23.0.94.1),
where the default value of `line-move-visual' is t.

This is insane, IMO. The default value is t even in formatted modes such as
Buffer Menu and Info. It is t even in code modes such as Emacs-Lisp. If you use
`define-derived-mode' to define a new mode from scratch - a mode that has no
parent mode, it has value t in that mode. It has value t everywhere, by default.
This makes no sense.

If you absolutely feel the need to make the default value be t for modes such as
text-mode, which (you are convinced) are likely to benefit from it, then do so.
But PLEASE leave the rest of Emacs alone, by default. This is a bad choice for
Emacs - please reconsider this.

Re: please make line-move-visual nil

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

> I'm coming back to this thread because I just tried the new pretest (23.0.94.1),
> where the default value of `line-move-visual' is t.

By the way, the function `line-move' (and friends) has no docstring.  

A docstring would help users better understand what this function does
and how it is impacted by the default of `line-move-visual'.  The better
explanation I found is in the manual: "7.2 Changing the Location of
Point", but I wonder who will go that far.

-- 
 Bastien

Re: please make line-move-visual nil

[Leo]

On 2009-05-24 23:33 +0100, Drew Adams wrote:
> I'm coming back to this thread because I just tried the new pretest (23.0.94.1),
> where the default value of `line-move-visual' is t.
>
> This is insane, IMO. The default value is t even in formatted modes such as
> Buffer Menu and Info. It is t even in code modes such as Emacs-Lisp. If you use
> `define-derived-mode' to define a new mode from scratch - a mode that has no
> parent mode, it has value t in that mode. It has value t everywhere, by default.
> This makes no sense.
>
> If you absolutely feel the need to make the default value be t for modes such as
> text-mode, which (you are convinced) are likely to benefit from it, then do so.
> But PLEASE leave the rest of Emacs alone, by default. This is a bad choice for
> Emacs - please reconsider this.

I also think this is very bad design. Just imagine in vi, change hjkl to
something different.

If the purpose is to make new users feel at home, then we could create
something like firstboot.el that runs in the first run. Most operating
systems have this.

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

Re: please make line-move-visual nil

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> I also think this is very bad design. Just imagine in vi, change hjkl to
> something different.

During the course of Emacs development, the behavior of C-n and C-p have
already evolved significantly, even before the line-move-visual change.
For instance, they vscroll images and tall lines.

The pros and cons of display line motion have been debated extensively,
and I see no new points on either side of the debate.  But since several
people dislike the new behavior, I think it would be good to add an
Options menu entry to disable it easily.

Re: please make line-move-visual nil

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On May 24, 2009, at 6:33 PM, Drew Adams wrote:
> If you absolutely feel the need to make the default value be t for  
> modes such as
> text-mode, which (you are convinced) are likely to benefit from it,  
> then do so.
> But PLEASE leave the rest of Emacs alone, by default. This is a bad  
> choice for
> Emacs - please reconsider this.

You didn't give any reason to support your view.  I can see where  
you're coming from, though.

I believe line-move-visual should be t because in this mode of  
operation, cursor movement commands correspond most closely to the  
visual representation of the buffer.

Note that I have bound C-n/p to non-visual movement in Aquamacs, while  
arrow keys are visual.  But of course I can see the argument to keep C- 
n/p and arrow keys bound to the same commands in Emacs, where a closer  
relationship between TTY and window system use is desired.

Leo wrote:

> If the purpose is to make new users feel at home, then we could create
> something like firstboot.el that runs in the first run. Most operating
> systems have this.


... and then Emacs would magically and surprisingly change its  
configuration after the first startup?
Even more confusing.

How about a newbie-mode, which can be en/disabled directly from the  
startup screen?

Ps.: I think it's too late in the game for 23.1 for this sort of change.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, May 25, 2009 at 1:50 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Leo <sdl.web@gmail.com> writes:
>
>> I also think this is very bad design. Just imagine in vi, change hjkl to
>> something different.
>
> During the course of Emacs development, the behavior of C-n and C-p have
> already evolved significantly, even before the line-move-visual change.
> For instance, they vscroll images and tall lines.
>
> The pros and cons of display line motion have been debated extensively,
> and I see no new points on either side of the debate.  But since several
> people dislike the new behavior, I think it would be good to add an
> Options menu entry to disable it easily.

Since line-move-visual has been added partly for compatibility with
editing in other environments (like for example in Firefox where I am
writing this) and since in those environments this behaviour is bound
to up/down arrows I think the options for customizing this should
reflect that by distinguishing between C-n/C-p and up/down arrow keys.

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, May 25, 2009 at 1:53 AM, David Reitter <david.reitter@gmail.com> wrote:
>> If the purpose is to make new users feel at home, then we could create
>> something like firstboot.el that runs in the first run. Most operating
>> systems have this.
>
>
> ... and then Emacs would magically and surprisingly change its configuration
> after the first startup?
> Even more confusing.
>
> How about a newbie-mode, which can be en/disabled directly from the startup
> screen?
>
> Ps.: I think it's too late in the game for 23.1 for this sort of change.

This has been proposed in several variants. I think the best would be
an approach where key bindings (and maybe behaviour in some cases)
could be switched to major platforms conformity by some command. (This
could be implemented by options and functions turning on and saving
them groupwise.)

RE: please make line-move-visual nil

[Drew Adams]

> > If you absolutely feel the need to make the default value be t for  
> > modes such as text-mode, which (you are convinced) are likely to
> > benefit from it, then do so.  But PLEASE leave the rest of Emacs
> > alone, by default. This is a bad choice for
> > Emacs - please reconsider this.
> 
> You didn't give any reason to support your view.

I did too, though perhaps not explicitly enough.

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.

If a poll indicates that most people want to use the new behavior for buffers
such as text-mode, then the default can be non-nil for such buffers. I don't
have a problem with that. But my crystal ball says that those buffers are in the
minority, in Emacs.

And even if they were in the majority, it wouldn't make sense to impose non-nil
for the other buffers, which have newline-delineated lines and provide a good
fit for the traditional line movement.

This is a widespread change, and it should not be. Impose the change, if you
must impose it, on only text-oriented buffers - the kind of buffers for which
you might use a proportional font, for instance. (Yes, the two things are
different, but the use cases overlap considerably.)

Use it for mail messages and text-mode. Do not use it, by default, for code and
formatted buffers, whose content is split into newline-delineated lines by
design.

> 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 believe line-move-visual should be t because in this mode of  
> operation, cursor movement commands correspond most closely to the  
> visual representation of the buffer.

Visual representation is not all that is important in a buffer. In code and
formatted (e.g. tabular) text, the positions of hard newlines can make a
difference.

Look, GNU Emacs Dev itself demands that Emacs-Lisp code you submit not have
lines longer than N columns. Why? Why do we format Info and *Help* and *Man* and
*Dired* buffers? Shouldn't you be proposing that we do away with all that, and
just have lines that are a zillion chars long? Let the display take care of it
all, right?

That's a different discussion, perhaps, but I sense that the door is being
opened here...

> 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?

> How about a newbie-mode, which can be en/disabled directly from the  
> startup screen?

I don't think this is about newbies at all (except that some Emacs developers
might be hoping that many newbies will be likely to use mainly Emacs for text,
mail, etc.).

I think it is about different line movements being appropriate for different
kinds of "line". The solution, in terms of finding good default behavior, is to
do this based on the buffer, that is, on its mode.

Use newline-oriented line movement for buffers where "lines" are typically
delineated by newlines. Use, if you like, visual-line-oriented movement for
buffers where "lines" have no use for newlines.

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).

When you read this plain-text mail, it will have had newlines inserted (for
better or, more likely, for worse), and newline-oriented line movement might be
appropriate. If I instead sent the mail as HTML, then visual line movement might
be appropriate.

> Ps.: I think it's too late in the game for 23.1 for this sort 
> of change.

Dunno if it's too late, but if time is really an argument here, then we can
argue that this change of default came too late. But I think it doesn't really
matter when we have the discussion. ;-)

RE: please make line-move-visual nil

[Drew Adams]

> During the course of Emacs development, the behavior of C-n 
> and C-p have already evolved significantly, even before the 
> line-move-visual change. For instance, they vscroll images
> and tall lines.
> 
> The pros and cons of display line motion have been debated 
> extensively,

This is about the _default value_.  You have changed the default value.

> and I see no new points on either side of the debate.

What's new is that you have changed the *default value*.

> But since several people dislike the new behavior, I think it
> would be good to add an Options menu entry to disable it easily.

Sorry to say it this way, but that is a complete cop-out. 

This is about the DEFAULT VALUE. This is not about the ease of customizing.

The default value should be nil. Except, if you insist, in specific buffers
where (some) users might find it useful - for example, text-mode buffers.

Re: please make line-move-visual nil

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>> and I see no new points on either side of the debate.
>
> What's new is that you have changed the *default value*.

This was done in July 2008, and there were fairly extensive discussions
on this list then, and on several occasions afterwards.

RE: please make line-move-visual nil

[Drew Adams]

> >> I see no new points on either side of the debate.
> >
> > What's new is that you have changed the *default value*.
> 
> This was done in July 2008

So what? We're talking about what is new for Emacs 23. Every change since Emacs
22 is new, regardless of how long ago it was first implemented. In this case,
Emacs 23 has changed the default behavior from what it has always been.

And this feature, and even this option, have been modified throughout the
development period. The last change to this option was made just 4 weeks ago.

Please don't try to paint this as some long-standing tradition or inscription in
marble that it is too late to change. Emacs 23 has not even been released yet.
Many of us have still not had the chance to exercise much of it.

Re: please make line-move-visual nil

[Stefan Monnier]

> I'm coming back to this thread because I just tried the new pretest
> (23.0.94.1), where the default value of `line-move-visual' is t.

> This is insane, IMO. The default value is t even in formatted modes
> such as Buffer Menu and Info. It is t even in code modes such as
> Emacs-Lisp. If you use `define-derived-mode' to define a new mode from
> scratch - a mode that has no parent mode, it has value t in that
> mode. It has value t everywhere, by default.  This makes no sense.

> If you absolutely feel the need to make the default value be t for
> modes such as text-mode, which (you are convinced) are likely to
> benefit from it, then do so.  But PLEASE leave the rest of Emacs
> alone, by default. This is a bad choice for Emacs - please
> reconsider this.

We've talked it over repeatedly.  Add (setq line-move-visual nil) to
your .emacs and live happily ever after.


        Stefan

Re: please make line-move-visual nil

[Stephen J. Turnbull]

David Reitter writes:

 > You didn't give any reason to support your view.

Isn't that more contentious that you really mean?  It's hard to
express reasons for this kind of thing, and in any case, a change of
defaults should shoulder the burden of explanation.  It's better to be
conservative with respect to defaults.

 > I believe line-move-visual should be t because in this mode of  
 > operation, cursor movement commands correspond most closely to the  
 > visual representation of the buffer.

Are we not human?  Can we not understand more abstractions than the
two-dimensional image in front of our eyes?  Maybe we should get rid
of all cursor movement commands in favor of visually-oriented search?

So unfortunately that explanation is so weak that it arrived in a
heart-lung machine.  Emacs has *many* modes, and they *interact*.  A
proper explanation would detail *for each and every* mode of Emacs why
the default ought to be changed.

For example in Python, assembler, picture, and FORTRAN modes, where
columns are significant, that should be defaulted to nil.  In most
programmers' environments, long lines are relatively rare due to style
guidelines, and indentation is on the contrary universal and
significant.  I would argue that in that general class of cases,
cursor motion should be logical, not visual, by default.

Re: please make line-move-visual nil

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: please make line-move-visual nil

[Stephen J. Turnbull]

Chong Yidong writes:

 > This was done in July 2008, and there were fairly extensive discussions
 > on this list then, and on several occasions afterwards.

Why have prereleases then, if it's "too late" for feedback from users
who are not willing to bleed on the edge, and who don't necessarily
read emacs-devel with their morning coffee?

You should also consider that for this particular default, positive
responses will come quickly from those who use long lines a lot, while
they are unlikely to notice much aggravation in environments where
visual motion is likely to be inappropriate, because those environment
typically strongly discourage long lines anyway.  Thus the complaints
are likely to be relatively late and few---and for that very reason
should be given more weight than the positive responses.

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 24 May 2009 19:50:24 -0400
> Cc: emacs-devel@gnu.org
> 
> The pros and cons of display line motion have been debated extensively,
> and I see no new points on either side of the debate.

Well, just to add a data point: I'm a heavy Emacs user for the last 15
years, and I find this new behavior very useful in many situations.
It took a bit to get accustomed to, but I find it so convenient I
never even tried to customize it back to what it was before.

> But since several people dislike the new behavior, I think it would
> be good to add an Options menu entry to disable it easily.

I think it's too late to add menu items at this time.  It should be
good enough to make its NEWS entry prominent and near the beginning,
as much as possible under the usual structure of NEWS (first
supported/deprecated targets, then build news, then the rest).

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Mon, 25 May 2009 11:32:49 +0900
> Cc: 'Leo' <sdl.web@gmail.com>, Drew Adams <drew.adams@oracle.com>,
> 	emacs-devel@gnu.org
> 
> Chong Yidong writes:
> 
>  > This was done in July 2008, and there were fairly extensive discussions
>  > on this list then, and on several occasions afterwards.
> 
> Why have prereleases then, if it's "too late" for feedback from users
> who are not willing to bleed on the edge, and who don't necessarily
> read emacs-devel with their morning coffee?

Pretest is not for changing the default behavior.  They are for fixing
bugs before the release.  The time for users to voice their objections
and requests for improvements is after Emacs is released.  There's
always the next release.

> You should also consider that for this particular default, positive
> responses will come quickly from those who use long lines a lot, while
> they are unlikely to notice much aggravation in environments where
> visual motion is likely to be inappropriate, because those environment
> typically strongly discourage long lines anyway.  Thus the complaints
> are likely to be relatively late and few

I don't know why you assume this: I happen to use longer-than-80-column
lines quite a lot, and I'm quite sure it's not as rare as you seem to
think.  Not every text we see in Emacs is necessarily a well-formatted
program source.

Re: please make line-move-visual nil

[Alfred M. Szmidt]

   We've talked it over repeatedly.  Add (setq line-move-visual nil)
   to your .emacs and live happily ever after.

This is not a useful way to carry a conversation.  People, lots of
people, have complained about this behaviour, so it needs to be
re-examined.

Re: please make line-move-visual nil

[Alfred M. Szmidt]

   Pretest is not for changing the default behavior.  They are for
   fixing bugs before the release.

And people have found that this is a bug, so they are voicing their
objections again, since they were ignored last time.

   The time for users to voice their objections and requests for
   improvements is after Emacs is released.  There's always the next
   release.

The time is now, this is a regression in emacs, it is also not clear
cut wherter people like it or not.  It breaks several key features in
emacs, like keyboard macros.  It is a feature that should have been
voted on before.

Several people have suggested lots of good solutions, but people seem
to have ignored them completely.  Setting line-move-visual on a
per-mode basis is a excellent middle ground that will make ALL parties
happy.

Re: please make line-move-visual nil

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> Since line-move-visual has been added partly for compatibility with
> editing in other environments (like for example in Firefox where I am
> writing this) and since in those environments this behaviour is bound
> to up/down arrows I think the options for customizing this should
> reflect that by distinguishing between C-n/C-p and up/down arrow keys.

Please, no.  That's even _more_ confusing...

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: please make line-move-visual nil

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> The pros and cons of display line motion have been debated extensively,
>> and I see no new points on either side of the debate.
>
> Well, just to add a data point: I'm a heavy Emacs user for the last 15
> years, and I find this new behavior very useful in many situations.
> It took a bit to get accustomed to, but I find it so convenient I
> never even tried to customize it back to what it was before.

Me too.  I think the current defaults are good.

There simply is no setting that will be perfect in all situations, but
the current (default) settings seem a reasonable compromise.

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: please make line-move-visual nil

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> writes:
>    We've talked it over repeatedly.  Add (setq line-move-visual nil)
>    to your .emacs and live happily ever after.
>
> This is not a useful way to carry a conversation.  People, lots of
> people, have complained about this behaviour, so it needs to be
> re-examined.

I don't really get the impression that "Lots of people" are complaining
actually (seems more like a few people, at high volume).

-Miles

-- 
Monday, n. In Christian countries, the day after the baseball game.

RE: please make line-move-visual nil

[Drew Adams]

> > I'm coming back to this thread because I just tried the new pretest
> > (23.0.94.1), where the default value of `line-move-visual' is t.
> 
> > This is insane, IMO. The default value is t even in formatted modes
> > such as Buffer Menu and Info. It is t even in code modes such as
> > Emacs-Lisp. If you use `define-derived-mode' to define a 
> new mode from
> > scratch - a mode that has no parent mode, it has value t in that
> > mode. It has value t everywhere, by default.  This makes no sense.
> 
> > If you absolutely feel the need to make the default value be t for
> > modes such as text-mode, which (you are convinced) are likely to
> > benefit from it, then do so.  But PLEASE leave the rest of Emacs
> > alone, by default. This is a bad choice for Emacs - please
> > reconsider this.
> 
> We've talked it over repeatedly.

Well, I haven't. This is the first I've spoken up on it. Call me a latecomer.
Are you saying the party is over? Doesn't sound like it...

> Add (setq line-move-visual nil) to
> your .emacs and live happily ever after.

Right. Same old same old...

What is wrong with the proposal that the default be different, depending on the
type of buffer? That seems quite sensible.

We can argue over which buffer types should have a non-nil default, but at least
making some such division makes sense. I personally would argue that only a
minority of modes should have non-nil by default, but at least such a partition
could be discussed.

I would be perfectly happy with a non-nil default for text-mode and modes that
inherit from it or are similar to it - mail composition buffers, for instance.
And nil for the other modes - those that are for code or tabular or otherwise
formatted text (in the sense of laid out, not in the sense of enriched text).

That is a sensible default behavior, to me. I probably wouldn't even customize
it, if the defaults were like that. I don't particularly _want_ a nil value
everywhere. And I certainly don't want a non-nil value everywhere. Why not make
this a little more flexible, and give it reasonable defaults based on the buffer
type?

RE: please make line-move-visual nil

[Drew Adams]

> >  > This was done in July 2008, and there were fairly 
> >  > extensive discussions
> >  > on this list then, and on several occasions afterwards.
> > 
> > Why have prereleases then, if it's "too late" for feedback 
> > from users who are not willing to bleed on the edge, and
> > who don't necessarily read emacs-devel with their morning
> > coffee?
> 
> Pretest is not for changing the default behavior.  They are for fixing
> bugs before the release.  The time for users to voice their objections
> and requests for improvements is after Emacs is released.  There's
> always the next release.

I see. So if you happen not to have dug deeply into each discussion thread
before the prerelease, and spoken up about it, you're out of luck? Your voice
doesn't count because it's too late?

That's ridiculous.

There has sometimes been a tendency to regard changes that have been made during
Emacs 23 development as cast in bronze - even long, long before Emacs 23 is
released. We hear arguments such as "that's been true since last July", as if
that means it represents established practice from ancient history.

Now we are in pretest, so this too-late!-already-cast-in-bronze argument is I
suppose slightly stronger, but I still don't buy it.

FWIW, here is what Richard replied to me after I complained to Chong Yidong in
just such a situation, admittedly pre-pretest (2008-10-21, bug list, bug #1175),
but pertinent anyway, I think:

|DA. This is analogous to `find-file-noselect'. 
|   `bookmark-jump-noselect' is an obvious choice for some
|   function to call, to obtain the bookmark buffer and
|   buffer position. Without actually displaying it - perhaps 
|   because some other display mechanism is preferred or
|   perhaps because some other manipulation is to be performed.
| 
|RMS. I agree with you.
| 
|DA. Emacs 23 has not even been released, so please don't speak of
|   "changing" from the Emacs 23 behavior to what has always 
|   been the behavior before.
| 
|RMS. You are right here too.  Compatibility with past Emacs releases
| is more important, generally speaking, than avoiding changes in
| the sources now.  I am sure this function isn't used in very 
| many places in Emacs, so changing it back to be compatible won't
| be a lot of work.

No, the context wasn't exactly the same, but the spirit seems similar, to me.

Emacs 23 has not been released, so new features are really just proposals still,
no matter how long ago they were implemented. "Is this the default value we
really want?" That's a fair question up until the release. And it's actually a
fair question even after the release, IMO.

Some of you complained that Richard took too long to put out a new release,
because he insisted on bug fixes and documentation. I, for one, never had that
complaint. Quite the contrary, in fact. For all your proclaimed haste, I don't
see that we are better off.

[One thing I do wish had happened: I wish that we had produced an Emacs 23 that
had only the Unicode addition. Other changes could have come in another release
after that. No one argued against adding Unicode - it is a super-important
feature, and it should have been separated from all of the many behavioral
changes that are now accompanying it. Just one (late) opinion.]

> > You should also consider that for this particular default,
> > positive esponses will come quickly from those who use long
> > lines a lot, while they are unlikely to notice much
> > aggravation in environments where visual motion is likely
> > to be inappropriate, because those environment
> > typically strongly discourage long lines anyway.  Thus the 
> > complaints are likely to be relatively late and few
> 
> I don't know why you assume this: I happen to use 
> longer-than-80-column lines quite a lot, and I'm quite sure
> it's not as rare as you seem to think.  Not every text we
> see in Emacs is necessarily a well-formatted program source.

Stephen's point is valid. And your response doesn't really respond to it. The
point is that if you use Emacs with lines that are not long, and so do not wrap,
then you will not necessarily notice much difference.

That is my case, since I often have one buffer per frame, and I fit the frame to
the buffer. With code etc., I rarely encounter any wrapped text, so I rarely
notice visual-line movement. That doesn't mean that there is no reason to prefer
newline-oriented line movement in those contexts.

Re: please make line-move-visual nil

[Bastien]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> It is a feature that should have been
> voted on before.

+1

-- 
 Bastien

RE: please make line-move-visual nil

[Drew Adams]

> > 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).

Sure, I can see that. Sometimes (or some parts of) LaTeX, HTML, and XML,
depending on the code. Yes. (Troff, probably not. ;-))

> Using fixed-width fonts even for code is not a must

No one said it is a must. This is about finding appropriate default values. It's
not about forcing someone to use one or the other behavior. 

The point is that it makes sense for the defaults to be different, depending on
the buffer type. Then users should be able to (easily) customize the values for
different buffer types.

> >> 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.

Yessir.

> > 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.

Precisely. It all depends. On the buffer type. On personal preference. On the
moon, perhaps. Customization is there for personal preference, but it needs to
be easily tweakable for different contexts, as you point out. One size here does
not necessarily fit all contexts.

The _default_ behaviors should at least be tailored to a reasonable consensus
according to the buffer type. I suspect there might be consensus for a nil
default for code buffers. But that doesn't that mean some people won't want
non-nil there too, just as some people (as you suggested) might prefer
proportional fonts for code too.

> 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.

Yes, for worse, I already agreed. But that's what happens with plain-text mail,
isn't it?

Many of us use HTML mail outside of mailing lists. But I can tell you that I
sometimes wish I had a line-oriented mode for dealing more easily with blocks of
code or tabular text in HTML emails. The most I can do using Outlook is switch
to a fixed-width font. (Yes, I know, Emacs as mail client...)

Re: please make line-move-visual nil

[Ulrich Mueller]

>>>>> On Mon, 25 May 2009, Miles Bader wrote:

> "Alfred M. Szmidt" <ams@gnu.org> writes:
>> This is not a useful way to carry a conversation.  People, lots of
>> people, have complained about this behaviour, so it needs to be
>> re-examined.

> I don't really get the impression that "Lots of people" are
> complaining actually (seems more like a few people, at high volume).

Add me to the list of people complaining, then. I think that it's
counter-intuitive to move point horizontally when vertical movement 
was asked for. The default should be changed back to nil.

Also, at former times the user community was asked before such UI
changes were done (I remember polls about C-x 0, M-g, C-x C-w, and
C-x C-q at least). Why isn't this done any more?

Ulrich

Re: please make line-move-visual nil

[Miles Bader]

Ulrich Mueller <ulm@gentoo.org> writes:
> Also, at former times the user community was asked before such UI
> changes were done (I remember polls about C-x 0, M-g, C-x C-w, and
> C-x C-q at least). Why isn't this done any more?

It would seem quite difficult to do a poll that actually yields results
representative of the larger emacs user community (and a poll that
_doesn't_ do that seems worse than useless).

A well-supported educated guess may well be the better option.

[Of course, this is the same reason that people just posting "me too!"
in response to threads like this is pretty pointless...]

-Miles

-- 
"She looks like the wax version of herself."
     	   	    		   [Comment under a Paris Hilton fashion pic]

Re: please make line-move-visual nil

[Stefan Monnier]

>> >> I see no new points on either side of the debate.
>> > What's new is that you have changed the *default value*.
>> This was done in July 2008
> So what? We're talking about what is new for Emacs 23.

See above: "I see no new points on either side of the debate".


        Stefan

Re: please make line-move-visual nil

[Stefan Monnier]

> What is wrong with the proposal that the default be different,
> depending on the type of buffer? That seems quite sensible.

"Two" things:
1 - it's far from clear which modes should use which default.
2 - there is very little evidence that someone might want different
    behavior in different buffers.
3 - Drew would come back screaming if (setq line-move-visual nil) only
    fixes that new brain-dead behavior in some modes but not all.


-- Stefan

RE: please make line-move-visual nil

[Drew Adams]

> >> >> I see no new points on either side of the debate.
> >> > What's new is that you have changed the *default value*.
> >> This was done in July 2008
> > So what? We're talking about what is new for Emacs 23.
> 
> See above: "I see no new points on either side of the debate".

What about making the default value depend on the buffer type?

The "debate" seems not to have been definitive. Either in terms of participation
or in terms of ideas and arguments.

RE: please make line-move-visual nil

[Drew Adams]

> > What is wrong with the proposal that the default be different,
> > depending on the type of buffer? That seems quite sensible.
> 
> "Two" things:
> 1 - it's far from clear which modes should use which default.

Whoa! If that's far from clear, then it's even farther from clear that _all_
modes should always have non-nil as the default. Talk about sophistry!

> 2 - there is very little evidence that someone might want different
>     behavior in different buffers.

Evidence: I'm someone who might want different behavior in different buffers.

There is even less evidence that _everyone_ wants non-nil in _all_ buffers.

This is about choosing reasonable _default_ behavior.

> 3 - Drew would come back screaming if (setq line-move-visual nil) only
>     fixes that new brain-dead behavior in some modes but not all.

It's irrelevant whether Drew comes back screaming. Forget the ad hominem appeals
to the gallery and get back to reasoned argument.

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> CC: stephen@xemacs.org, emacs-devel@gnu.org
> Date: Mon, 25 May 2009 00:16:22 -0400
> 
>    Pretest is not for changing the default behavior.  They are for
>    fixing bugs before the release.
> 
> And people have found that this is a bug, so they are voicing their
> objections again, since they were ignored last time.

A deliberate change in behavior is not a bug, as long as the only
objection is "I don't like it".

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Mon, 25 May 2009 01:18:02 -0700
> 
> > Pretest is not for changing the default behavior.  They are for fixing
> > bugs before the release.  The time for users to voice their objections
> > and requests for improvements is after Emacs is released.  There's
> > always the next release.
> 
> I see. So if you happen not to have dug deeply into each discussion thread
> before the prerelease, and spoken up about it, you're out of luck? Your voice
> doesn't count because it's too late?

If you come too late in the pretest, yes.  If we allow non-critical
changes beyond certain point, we will either never make a release or
release a buggy version (because each change might have, and usually
has unintended consequences).

> That's ridiculous.

That's life.

And just to keep this in perspective, we are talking about the default
value of an easily customizable option.  How critical could a default
be, even if it turns out to be disliked by many?

RE: please make line-move-visual nil

[Drew Adams]

> >    Pretest is not for changing the default behavior.  They are for
> >    fixing bugs before the release.
> > 
> > And people have found that this is a bug, so they are voicing their
> > objections again, since they were ignored last time.
> 
> A deliberate change in behavior is not a bug, as long as the only
> objection is "I don't like it".

A deliberate change in behavior is not a good change, as long as the only reason
supporting it is "I like it".

Yes, let's get back to _reasons_ for the change in default behavior, _reasons_
against it, and perhaps discussion of alternatives, such as using different
defaults for different kinds of buffers. 

Discussion of reasons is good. Proposals of alternatives and their discussion is
good.

We can note that (a) some people like the currently proposed change (yes, it is
just a proposal - Emacs 23 has not yet been released) and (b) some people
dislike it. Noting that is helpful, as a reminder that we are not quite there
yet.

But we need to move beyond just that notice. That notice shows only that we have
a problem; it does not, in itself, point to a solution.

RE: please make line-move-visual nil

[Drew Adams]

> If you come too late in the pretest, yes.

Too late in which pretest? My guess is that you would have said the same thing
for the first pretest, months ago. Emacs development can drag on for years, and
it is a convenient excuse that has been used for a long time that "we are too
close to the release" to discuss this or that change or new feature.

> If we allow non-critical changes beyond certain point, we will
> either never make a release or release a buggy version (because
> each change might have, and usually has unintended consequences).

Do you really think that restoring this to the previous default behavior would
cause problems? If so, do you think we could not afford to take the time to fix
those problems? Are you sure this isn't just an excuse to ignore the question?

> > That's ridiculous.
>
> That's life.

No, it's just one possible policy choice. Please don't confuse the laws of
Nature with choices you have made.

> And just to keep this in perspective, we are talking about the default
> value of an easily customizable option.  How critical could a default
> be, even if it turns out to be disliked by many?

Using "it's not critical" as the only reason to introduce a bad choice is lame.
If you want a better perspective, that's the place from which to view this. How
about some _reasons_ supporting this change (beyond "I like it")?

Re: please make line-move-visual nil

[Stefan Monnier]

>> 1 - it's far from clear which modes should use which default.
> Whoa! If that's far from clear, then it's even farther from clear that _all_
> modes should always have non-nil as the default.  Talk about sophistry!

I don't see why the two should be correlated, so I don't se the
sophistry.  AFAIK the choice bsically depends on the user's taste,
similarly to the blinking cursor.

Please give examples of modes where the choice is clear one way or the
other (sufficiently so that it should override the user's default
choice).  We can then consider them.  I still haven't seen any argument
for any particular mode, so I think it is fair to say that it is unclear
which modes should use which default.  I've seen mention that text-mode
should use a value of t, but haven't understood why that would be
a better choice there than elsewhere.

>> 2 - there is very little evidence that someone might want different
>> behavior in different buffers.

> Evidence: I'm someone who might want different behavior in different buffers.

Which behavior where?

> There is even less evidence that _everyone_ wants non-nil in _all_ buffers.

Maybe if you explain the specific harm you see, we can start reasoning
about where/when to use what.  In my use, the new default saves me the
trouble of having to worry about long wrapped lines, and that holds in
all buffers.

> This is about choosing reasonable _default_ behavior.

Thank you for repeating the obvious.  I think we are all painfully aware
of this by now.

>> 3 - Drew would come back screaming if (setq line-move-visual nil) only
>> fixes that new brain-dead behavior in some modes but not all.

> It's irrelevant whether Drew comes back screaming.  Forget the ad
> hominem appeals to the gallery and get back to reasoned argument.

This was an attempt at humor rather than an ad-hominem.  I'm sorry if
you felt attacked/ridiculed/dimished, there was no such intention.

The inflamed tone of this thread is one of the reasons why I think more
than ever that this setting is only a question of personal taste.


        Stefan

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, May 25, 2009 at 11:14 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I've seen mention that text-mode
> should use a value of t, but haven't understood why that would be
> a better choice there than elsewhere.

I think it might be that word-wrap is also turned on by
visual-line-mode. That may perhaps give the impression that the code
was badly formatted, but in my opinion the fringe wrap symbols makes
it clear what is happening.


>>> 2 - there is very little evidence that someone might want different
>>> behavior in different buffers.
>
>> Evidence: I'm someone who might want different behavior in different buffers.
>
> Which behavior where?

Maybe I should not say this because I like the way visual-line-mode
works, but could not the concept of majo mode parents be used to get
some structure out of this?

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <stephen@xemacs.org>, <emacs-devel@gnu.org>
> Date: Mon, 25 May 2009 14:06:18 -0700
> 
> > If you come too late in the pretest, yes.
> 
> Too late in which pretest?

Any pretest.  Your question was general, so I gave a general answer.
It started with an "if".

Whether _now_ it's "too late" is not my call.

> My guess is that you would have said the same thing for the first
> pretest, months ago.

So now you are inventing what I would have said, and then argue with
your own inventions?  Is that reasonable? or fair?

> Using "it's not critical" as the only reason to introduce a bad choice is lame.

That choice was already made, and the reasons back then were certainly
not that it's not critical.  We are now arguing about unmaking it, and
it's in that context that I question the justification for such a
reversal.

Re: please make line-move-visual nil

[Richard M Stallman]

This is the sort of issue for which it is a good idea to poll the
users -- not just this mailing list.

Re: please make line-move-visual nil

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it's too late to add menu items at this time.  It should be
> good enough to make its NEWS entry prominent and near the beginning,
> as much as possible under the usual structure of NEWS (first
> supported/deprecated targets, then build news, then the rest).

It's the very first entry under Editing Changes.

Re: please make line-move-visual nil

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

Hi Stefan,

> The inflamed tone of this thread is one of the reasons why I think
> more than ever that this setting is only a question of personal taste.

I'm one of those who like the new behavior, but I agree that one might
run into troubles with keyboard macros.  IMO that's the only point where
the new behavior has some disadvantages which are not personal
preferences.  And I also agree that there are other features which may
screw up macros as well and nobody objected to them; unfortunately I
don't know which ones -- so at least they didn't bite me till now.

Ok, so what I wanted to propose instead some special handling of
line-move-visual in keyboard macros is the addition of two hook
`before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before
and after the definition and execution of keyboard macros.  Then users
can decide the value of line-move-visual and others depending on the
current buffer's mode or the lunar phase in macros, no matter the
default or user-specified value.

I think that's a reasonable solution, much better than any special
hardcoding or workarounds like `M-x toggle-word-wrap' before each macro
definition/execution.

Bye,
Tassilo

Re: please make line-move-visual nil

[Alan Mackenzie]

On Mon, May 25, 2009 at 11:29:48AM +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 25 May 2009, Miles Bader wrote:

> > "Alfred M. Szmidt" <ams@gnu.org> writes:
> >> This is not a useful way to carry a conversation.  People, lots of
> >> people, have complained about this behaviour, so it needs to be
> >> re-examined.

> > I don't really get the impression that "Lots of people" are
> > complaining actually (seems more like a few people, at high volume).

> Add me to the list of people complaining, then. I think that it's
> counter-intuitive to move point horizontally when vertical movement was
> asked for. The default should be changed back to nil.

That's most people's reasoning, I think.  Trouble is, they disagree about
what "horizontal" and "vertical" mean; is it "horizontal" in a logical
line, or "horizontal" in a visible line?  Which comes back to the
question "what do we mean by a line?".

I don't do much with wide buffers - occasionally I read log files with
long lines, occasionally I have to edit text in the
paragraph-is-a-single-very-long-line style.  For both of these scenarios,
I prefer line-move-visual enabled, since I find the shock of C-n "jumping
three lines" very disconcerting.  But that's just my personal preference;

I appreciate other people's arguments for leaving l-m-visual nil.  The
fact that somebody like Drew, who's normally so calm and collected, is so
steadfastly opposed to the change is a strong argument in itself.

I disagree with Eli that defaults are "only" defaults: they're the
settings we impose on new users, and are critically important.  If
they're bad defaults, they could irritate and exasperate users for months
or years before those users eventually change them.  (C-n adding new
lines onto the ends of files (which was the default in Emacs <= 20)
springs to mind here).

Add me to the list of people emphatically and loudly abstaining.  It's
important to get this right, though.

> Also, at former times the user community was asked before such UI
> changes were done (I remember polls about C-x 0, M-g, C-x C-w, and
> C-x C-q at least). Why isn't this done any more?

This practice was (tacitly) abandoned in spring 2008, when a much more
massive change in Emacs's defaults was committed before discussions about
it had really got underway.  Stefan and Yidong did not require that
change to be reverted during those discussions.

> Ulrich

-- 
Alan Mackenzie (Nürnberg).

Re: please make line-move-visual nil

[Deniz Dogan]

2009/5/26 Tassilo Horn <tassilo@member.fsf.org>:
> Ok, so what I wanted to propose instead some special handling of
> line-move-visual in keyboard macros is the addition of two hook
> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before
> and after the definition and execution of keyboard macros.  Then users
> can decide the value of line-move-visual and others depending on the
> current buffer's mode or the lunar phase in macros, no matter the
> default or user-specified value.

I completely support this and in my opinion it's not too late to add
these hooks.

-- 
Deniz Dogan

Re: please make line-move-visual nil

[Lennart Borgman]

On Tue, May 26, 2009 at 11:52 AM, Alan Mackenzie <acm@muc.de> wrote:
>
> I disagree with Eli that defaults are "only" defaults: they're the
> settings we impose on new users, and are critically important.  If
> they're bad defaults, they could irritate and exasperate users for months
> or years before those users eventually change them.  (C-n adding new
> lines onto the ends of files (which was the default in Emacs <= 20)
> springs to mind here).

I guess new users will in most cases appreciate the change (since it
makes Emacs behave more like other editing environments), but old
timers will a bit more often dislike it.

(This will of course make both polling and discussions like this difficult.)

Re: please make line-move-visual nil

[Lennart Borgman]

On Tue, May 26, 2009 at 1:37 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote:
> 2009/5/26 Tassilo Horn <tassilo@member.fsf.org>:
>> Ok, so what I wanted to propose instead some special handling of
>> line-move-visual in keyboard macros is the addition of two hook
>> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before
>> and after the definition and execution of keyboard macros.  Then users
>> can decide the value of line-move-visual and others depending on the
>> current buffer's mode or the lunar phase in macros, no matter the
>> default or user-specified value.
>
> I completely support this and in my opinion it's not too late to add
> these hooks.


I am not sure this is a good idea.

I believe it might be better to investigate more how certain features
(like visual-line-move) should be handled under different
circumstances. Such circumstances is (as is pointed out here) macros,
but there are others two, like printing. And what about using the
affected functions in functions that might do the editing in another
window than the selected window?

Even though I think like this I like visual-line-mode and think it
should be on by default. But thinking over the questions above and
documenting the behaviour is necessary in my opinion.

Re: please make line-move-visual nil

[Rupert Swarbrick]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Tue, May 26, 2009 at 11:52 AM, Alan Mackenzie <acm@muc.de> wrote:
>>
>> I disagree with Eli that defaults are "only" defaults: they're the
>> settings we impose on new users, and are critically important.  If
>> they're bad defaults, they could irritate and exasperate users for
>> months or years before those users eventually change them.  (C-n
>> adding new lines onto the ends of files (which was the default in
>> Emacs <= 20) springs to mind here).
>
> I guess new users will in most cases appreciate the change (since it
> makes Emacs behave more like other editing environments), but old
> timers will a bit more often dislike it.

I agree that this makes Emacs behave more like other editors. But I'm
not sure it's something that new users will feel strongly about: How
much is emacs _really_ "like other editing environments"? I mean, all
the keyboard shortcuts are different. Killing and yanking is very
different from Ctrl-C Ctrl-V. Using multiple buffers gets confusing very
quickly if you're used to the Windows-style MDI etc. etc. etc.

So my point is that making this (rather corner-case) behaviour more like
gedit or notepad isn't necessarily a relevant goal: I don't believe that
it makes much difference to new users, who are learning a significantly
different approach to editing anyway [1].

Now, this post doesn't claim to have any bearing on any of the other
arguments put forward in the discussion. My personal feeling is that
Drew's suggestion of making a distinction between "programming" and
"text" based on major-mode is very sensible.

Hope this makes some sense,

Rupert


[1] Actually, I do have some data here: I'm a Uni student and my
 housemate started using Emacs at my suggestion a couple of months ago
 to run inferior octave processes. When I mentioned this thread to him
 this morning he grinned and said he'd come across the (old) behaviour,
 but decided that it made sense on balance. So far as I know, he didn't
 read any info files or help strings about it, so if it made sense
 without maybe it's not such a bad design!

[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]

Re: please make line-move-visual nil

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On May 26, 2009, at 8:24 AM, Lennart Borgman wrote:
> I believe it might be better to investigate more how certain features
> (like visual-line-move) should be handled under different
> circumstances. Such circumstances is (as is pointed out here) macros,
> but there are others two, like printing. And what about using the
> affected functions in functions that might do the editing in another
> window than the selected window?

Rather than providing hooks so that the user can be trapped by the  
problem, diagnose it, find the hooks, and come up with the right lisp  
code (most users actually don't speak lisp) to fix it, why not turn  
off line-move-visual (and anything else of the "do what I mean"  
variety) during macro recording and playback?  That would lead to  
consistent and predictable behavior.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: please make line-move-visual nil

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Tue, May 26, 2009 at 1:37 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote:
>> 2009/5/26 Tassilo Horn <tassilo@member.fsf.org>:
>>> Ok, so what I wanted to propose instead some special handling of
>>> line-move-visual in keyboard macros is the addition of two hook
>>> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before
>>> and after the definition and execution of keyboard macros.  Then users
>>> can decide the value of line-move-visual and others depending on the
>>> current buffer's mode or the lunar phase in macros, no matter the
>>> default or user-specified value.
>>
>> I completely support this and in my opinion it's not too late to add
>> these hooks.
>
>
> I am not sure this is a good idea.
>
> I believe it might be better to investigate more how certain features
> (like visual-line-move) should be handled under different
> circumstances. Such circumstances is (as is pointed out here) macros,
> but there are others two, like printing. And what about using the
> affected functions in functions that might do the editing in another
> window than the selected window?
>
> Even though I think like this I like visual-line-mode and think it
> should be on by default. But thinking over the questions above and
> documenting the behaviour is necessary in my opinion.

I think this argument in fact supports the addition of hooks. Maybe you
need to differentiate between recording hooks and execution hooks, but
otherwise the idea seems good. It seems logical that youd want some
generic mechanism to get Emacs into a state that is good for recording
and executing macros. 


>
>
-- 
Joakim Verona

Re: please make line-move-visual nil

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On May 26, 2009, at 8:46 AM, joakim@verona.se wrote:
>> Rather than providing hooks so that the user can be trapped by the
>> problem, diagnose it, find the hooks, and come up with the right lisp
>> code (most users actually don't speak lisp) to fix it, why not turn
>> off line-move-visual (and anything else of the "do what I mean"
>> variety) during macro recording and playback?  That would lead to
>> consistent and predictable behavior.
>
> The mechanism for this could be in the form of a preloaded hook,
> right?

Yes, sounds like a good idea.  That way it can be turned off /  
tinkered with.

We should, however, take care to restore the previous value in case an  
error is signaled during Macro execution. 
  

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: please make line-move-visual nil

[Jason Rumney]

Lennart Borgman wrote:
> I believe it might be better to investigate more how certain features
> (like visual-line-move) should be handled under different
> circumstances. Such circumstances is (as is pointed out here) macros,
> but there are others two, like printing.

line-movement is not involved in printing. But any non-interactive use 
probably falls into the same category as macros.

Re: please make line-move-visual nil

[Stefan Monnier]

>> Ok, so what I wanted to propose instead some special handling of
>> line-move-visual in keyboard macros is the addition of two hook
>> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before
>> and after the definition and execution of keyboard macros.  Then users
>> can decide the value of line-move-visual and others depending on the
>> current buffer's mode or the lunar phase in macros, no matter the
>> default or user-specified value.

> I completely support this and in my opinion it's not too late to add
> these hooks.

That can be done, yes.


        Stefan

Re: please make line-move-visual nil

[Tobias C. Rittweiler]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Please give examples of modes where the choice is clear one way or the
> other (sufficiently so that it should override the user's default
> choice).  We can then consider them.  I still haven't seen any argument
> for any particular mode, so I think it is fair to say that it is unclear
> which modes should use which default.  I've seen mention that text-mode
> should use a value of t, but haven't understood why that would be
> a better choice there than elsewhere.

I think it's problematic in buffers that are supposed to be analyzed
mechanically by external programs.

A couple of weeks ago there was a scenario where I could easily have
been bitten by the bug: I was working on some code which reports error
locations as a file position + an offset in lines. When debugging that
code, I first went to the file position in the source file, and then
used `C-u NN C-n' to see if everything's working out correctly.

When the buffer happened to contain wrapped lines, I'd have got to the
wrong line, making me think that the error reporting code was at
fault. It would probably have taken a while before I'd have found out
what's actually faulty.

  -T.

Re: please make line-move-visual nil

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 720 bytes --]

   > I disagree with Eli that defaults are "only" defaults: they're
   > the settings we impose on new users, and are critically
   > important.  If they're bad defaults, they could irritate and
   > exasperate users for months or years before those users
   > eventually change them.  (C-n adding new lines onto the ends of
   > files (which was the default in Emacs <= 20) springs to mind
   > here).

   I guess new users will in most cases appreciate the change (since
   it makes Emacs behave more like other editing environments), but
   old timers will a bit more often dislike it.

Guessing is something everyone can do; instead a poll is a better
measurement of what users, new and old will like or dislike.

Re: please make line-move-visual nil

[Lennart Borgman]

On Tue, May 26, 2009 at 3:54 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> I believe it might be better to investigate more how certain features
>> (like visual-line-move) should be handled under different
>> circumstances. Such circumstances is (as is pointed out here) macros,
>> but there are others two, like printing.
>
> line-movement is not involved in printing. But any non-interactive use
> probably falls into the same category as macros.

Eh, yes, but printing is quite closely related here due to that
visual-line-move turns on word-wrap. It would be nice to be able to
get print to use that too. It is of course another problem. However I
suspect that thinking about those problems together might create
opportunities for better solutions (as you suggested).

Re: please make line-move-visual nil

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> line-movement is not involved in printing. But any non-interactive use
>> probably falls into the same category as macros.
>
> Eh, yes, but printing is quite closely related here due to that
> visual-line-move turns on word-wrap.

visual-line-mode does, but that's not what's being discussed...

[What's being discussed is the default behavior of line-movement; the
new default behavior is only controversial because it applies even when
visual-line-mode is _not_ enabled...]

-miles

-- 
Un-American, adj. Wicked, intolerable, heathenish.

Re: please make line-move-visual nil

[Andrew W. Nosenko]

On Mon, May 25, 2009 at 7:16 AM, Alfred M. Szmidt <ams@gnu.org> wrote:
> Setting line-move-visual on a
> per-mode basis is a excellent middle ground that will make ALL parties
> happy.

Please NO!!!!


First at all, after binding additional pair (M-down, M-up) to the
"phisical" lines motion,

In short: "magic" and unpredictable changing of behavior iis very
inconeinient.  At least I found it that.

You can argue that it would not be "magic" or unpredictable, but
indeed based on a mode or mode-deriviation.  But could you predict
(just as "stupid" user, not as mode's author), what deriviation tree
has Occur mode, for example?  Or Shell Output?  (Ok, I know that Shell
Command Output buffer has Fundamental mode, and what?)

Even for C code it is very useful for me to have visual navigation.

But I understand your point.  Moreover, some time ago I also was very
frustrated, because convinient way for "phisical" line navigation is
no less.  And solution is very simple: just give best from both
worlds: above in this thread alredy mentioned that AquaEmacs has
different bindings for C-n/C-p vs. down/up.  I also just bound
"phisical" line movements to the M-down and M-up in addition to the
"visual" on down and up, and have now conventient and similar bindings
to the both movement modes.  Try it!  Just don't throw away only
because it is unusual for you.  Try it first for some time (e.g. 1
week)!

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: please make line-move-visual nil

[Andrew W. Nosenko]

On Wed, May 27, 2009 at 3:48 PM, Andrew W. Nosenko
<andrew.w.nosenko@gmail.com> wrote:
> On Mon, May 25, 2009 at 7:16 AM, Alfred M. Szmidt <ams@gnu.org> wrote:
>> Setting line-move-visual on a
>> per-mode basis is a excellent middle ground that will make ALL parties
>> happy.
>
> Please NO!!!!
>
>
> First at all, after binding additional pair (M-down, M-up) to the
> "phisical" lines motion,

Sorry.  Paragraph above ("First at all...") is just artifact,
forgorren to be deleted from the "draft".

>
> In short: "magic" and unpredictable changing of behavior iis very
> inconeinient.  At least I found it that.
>
> You can argue that it would not be "magic" or unpredictable, but
> indeed based on a mode or mode-deriviation.  But could you predict
> (just as "stupid" user, not as mode's author), what deriviation tree
> has Occur mode, for example?  Or Shell Output?  (Ok, I know that Shell
> Command Output buffer has Fundamental mode, and what?)
>
> Even for C code it is very useful for me to have visual navigation.
>
> But I understand your point.  Moreover, some time ago I also was very
> frustrated, because convinient way for "phisical" line navigation is
> no less.  And solution is very simple: just give best from both
> worlds: above in this thread alredy mentioned that AquaEmacs has
> different bindings for C-n/C-p vs. down/up.  I also just bound
> "phisical" line movements to the M-down and M-up in addition to the
> "visual" on down and up, and have now conventient and similar bindings
> to the both movement modes.  Try it!  Just don't throw away only
> because it is unusual for you.  Try it first for some time (e.g. 1
> week)!
>
> --
> Andrew W. Nosenko <andrew.w.nosenko@gmail.com>
>



-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: please make line-move-visual nil

[David Kastrup]

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

> This is the sort of issue for which it is a good idea to poll the
> users -- not just this mailing list.

Putting it in a pretest is polling the users.

-- 
David Kastrup

Re: please make line-move-visual nil

[Bastien]

David Kastrup <dak@gnu.org> writes:

> Richard M Stallman <rms@gnu.org> writes:
>
>> This is the sort of issue for which it is a good idea to poll the
>> users -- not just this mailing list.
>
> Putting it in a pretest is polling the users.

Pulling is more about getting a clear yes/no answer on a specific
question.  Putting a feature in a pretest is more a way of opening
the discussion about a feature, rather than closing it efficiently.

-- 
 Bastien

Re: please make line-move-visual nil

[Werner LEMBERG]

>> This is the sort of issue for which it is a good idea to poll the
>> users -- not just this mailing list.
> 
> Putting it in a pretest is polling the users.

But the implementers apparently don't consider this as such.  Features
in pretest appear to be cast in stone.


    Werner

Re: please make line-move-visual nil

[rms]

    Putting it in a pretest is polling the users.

No, it isn't.  Only a few of the users normally try a pretest.

Polling the users means posting an announcement explicitly asking
users to try the feature now, and say what they think _and why_.

When possible, it is good to tell them a recipe to try the new
behavior in the current released Emacs, so they can try it and respond
without actually installing a pretest,

Re: please make line-move-visual nil

[Alfred M. Szmidt]

   You can argue that it would not be "magic" or unpredictable, but
   indeed based on a mode or mode-deriviation.  But could you predict
   (just as "stupid" user, not as mode's author), what deriviation
   tree has Occur mode, for example?  Or Shell Output?  (Ok, I know
   that Shell Command Output buffer has Fundamental mode, and what?)

Maybe you are right, all I would like to see is a compromise that the
majority of people will agree to.

The fact that Yidong, and Monnier simply disregard any discussion on
the topic is frustrating, specially since people have voiced strong
arguments for why the new behaviour is broken.  Hand waving arguments
are insulting to everyone on this list.

This must be resolved before the release.

   But I understand your point.  Moreover, some time ago I also was
   very frustrated, because convinient way for "phisical" line
   navigation is no less.  And solution is very simple: just give best
   from both worlds: above in this thread alredy mentioned that
   AquaEmacs has different bindings for C-n/C-p vs. down/up.  I also
   just bound "phisical" line movements to the M-down and M-up in
   addition to the "visual" on down and up, and have now conventient
   and similar bindings to the both movement modes.

Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p
or just the arrow keys (maybe someone suggested this already).  What
do people think?

Re: please make line-move-visual nil

[Andreas Schwab]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p
> or just the arrow keys (maybe someone suggested this already).  What
> do people think?

The arrow keys should always behave the same as their C- counterparts.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: please make line-move-visual nil

[Deniz Dogan]

2009/5/31 Alfred M. Szmidt <ams@gnu.org>:
> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p
> or just the arrow keys (maybe someone suggested this already).  What
> do people think?

I wouldn't be in favor of binding M-n and M-p by default as I have
bound them to forward-paragraph and backward-paragraph, respectively,
and I'm sure many other people have bound important stuff to those two
combinations as well.

Regarding the idea with the arrow keys, even though I think that
ideally the arrow keys and their C- counterparts should behave the
same at all times, it *is* a good suggestion, since newcomers often
want to move by visual lines and use the arrow keys, while
"old-timers" often want the opposite and often use C-n/C-p.

-- 
Deniz Dogan

Re: please make line-move-visual nil

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:
>> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p
>> or just the arrow keys (maybe someone suggested this already).  What
>> do people think?
>
> The arrow keys should always behave the same as their C- counterparts.

Yes.

Making them different would make things _more_ confusing (and moreover,
would discourage newbies from moving away from arrow keys -- suddenly
they wouldn't be simply a different binding, but would be "the same
thing except randomly different to stop a bunch of emacs old-timers from
whining").

-Miles

-- 
Logic, n. The art of thinking and reasoning in strict accordance with the
limitations and incapacities of the human misunderstanding.

Re: please make line-move-visual nil

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Maybe you are right, all I would like to see is a compromise that the
> majority of people will agree to.
>
> The fact that Yidong, and Monnier simply disregard any discussion on
> the topic is frustrating, specially since people have voiced strong
> arguments for why the new behaviour is broken.

I've already made one suggestion: add a menu bar entry to make
line-move-visual easier to turn on or off.  Since there were objections
to this, I haven't pursued it.  There have been no other unproblematic
suggestions AFAICT, so I think those who dislike the new behavior will,
as Stefan said, simply have to set line-move-visual to nil and move on.

> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p
> or just the arrow keys (maybe someone suggested this already).  What
> do people think?

This is a bad idea, as pointed out by Andreas and Miles.

Re: please make line-move-visual nil

[Bob Rogers]

   From: Miles Bader <miles@gnu.org>
   Date: Mon, 01 Jun 2009 02:00:46 +0900

   Andreas Schwab <schwab@linux-m68k.org> writes:
   >> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p
   >> or just the arrow keys (maybe someone suggested this already).  What
   >> do people think?
   >
   > The arrow keys should always behave the same as their C- counterparts.

   Yes.

   Making them different would make things _more_ confusing (and moreover,
   would discourage newbies from moving away from arrow keys -- suddenly
   they wouldn't be simply a different binding, but would be "the same
   thing except randomly different to stop a bunch of emacs old-timers from
   whining").

   -Miles

Why do you suppose an Emacs newbie would expect the arrow keys to be the
same as C-n/C-p?

   Personally, I would welcome binding visual movement to the arrow keys
-- the arrows do *look* visual, especially compared to C-n/C-p.  And it
would make it much easier to switch between the two modes of movement if
the visual/textual distinction was supported by distinct commands bound
to distinct keys.

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: please make line-move-visual nil

[Miles Bader]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:
> Why do you suppose an Emacs newbie would expect the arrow keys to be the
> same as C-n/C-p?

I don't think they'll "expect" that, I hope they'll learn from what we
tell them, part of which is the traditional emacs key-bindings.

That learning is what will be easier if emacs traditional key-bindings
are simply different names for familiar concepts.

>    Personally, I would welcome binding visual movement to the arrow keys
> -- the arrows do *look* visual, especially compared to C-n/C-p.  And it
> would make it much easier to switch between the two modes of movement if
> the visual/textual distinction was supported by distinct commands bound
> to distinct keys.

Perhaps, but in this case it's harmful:  whether one wants to use arrow
keys or "emacsy" bindings tends to be dictated by the physical nature of
the keyboard and one's task -- arrow keys are convenient because they're
labelled, and a single keystroke, but they're inefficient and annoying
if one is touch-typing (due to the very large hand movement required to
use them), and lack integration with the general emacs key-binding
scheme -- so it's very desirable to be able to switch between them.

Having them be "similar but subtly different" horribly confuses an
otherwise straight-forward association.

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: please make line-move-visual nil

[Miles Bader]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:
> I wouldn't be in favor of binding M-n and M-p by default as I have
> bound them to forward-paragraph and backward-paragraph, respectively,
> and I'm sure many other people have bound important stuff to those two
> combinations as well.

M-n/M-p are widely used in various modes, so it seems bad to given them
global bindings with such a general meaning.

> Regarding the idea with the arrow keys, even though I think that
> ideally the arrow keys and their C- counterparts should behave the
> same at all times, it *is* a good suggestion, since newcomers often
> want to move by visual lines and use the arrow keys, while
> "old-timers" often want the opposite and often use C-n/C-p.

It's a bad suggestion (see my other responses on this thread for an explanation).

-miles

-- 
Liberty, n. One of imagination's most precious possessions.

Re: please make line-move-visual nil

[Mathias Megyei]

On Sun, 2009-05-31 at 17:19 -0400, Chong Yidong wrote:

> I've already made one suggestion: add a menu bar entry to make
> line-move-visual easier to turn on or off.  Since there were objections
> to this, I haven't pursued it.  There have been no other unproblematic
> suggestions AFAICT, so I think those who dislike the new behavior will,
> as Stefan said, simply have to set line-move-visual to nil and move on.

What about adding a function 'toggle-visual-line-mode' to turn on/off
visual line mode in the current buffer. At least for me it would be the
best solution.

Mathias

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, Jun 1, 2009 at 4:33 AM, Miles Bader <miles@gnu.org> wrote:
> Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:
>> Why do you suppose an Emacs newbie would expect the arrow keys to be the
>> same as C-n/C-p?

> Having them be "similar but subtly different" horribly confuses an
> otherwise straight-forward association.

I do not think that is true for something that you use as often as those keys.

Re: please make line-move-visual nil

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>>> Why do you suppose an Emacs newbie would expect the arrow keys to be the
>>> same as C-n/C-p?
>
>> Having them be "similar but subtly different" horribly confuses an
>> otherwise straight-forward association.
>
> I do not think that is true for something that you use as often as those keys.

I suppose an experienced user, like me, who uses both often[*], might be
so accustomed to the differences that they would internalize them.  Then
they'd probably simply be _annoyed_ by the arbitrary differences, rather
than confused by them.

However my reply was talking about newbies.  An emacs newbie,
tentatively exploring the use of C-p/C-n instead of arrow-keys wouldn't
have that experience.  It seems pretty likely to me that they _would_
get confused (and annoyed of course) by such seemingly arbitrary
differences and that this might discourage them.

-Miles

[*] I use arrow keys and C-n/C-p/etc pretty much interchangeably,
    depending on, for example, on whether I happen to be typing some
    text with both hands, or am browsing through a file while drinking
    coffee with the other hand....

-- 
Christian, n. One who follows the teachings of Christ so long as they are not
inconsistent with a life of sin.

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, Jun 1, 2009 at 11:54 AM, Miles Bader <miles@gnu.org> wrote:
>>> Having them be "similar but subtly different" horribly confuses an
>>> otherwise straight-forward association.
>>
>> I do not think that is true for something that you use as often as those keys.
>
> I suppose an experienced user, like me, who uses both often[*], might be
> so accustomed to the differences that they would internalize them.  Then
> they'd probably simply be _annoyed_ by the arbitrary differences, rather
> than confused by them.

Is not what you feel here more of a choice? ;-)


> However my reply was talking about newbies.  An emacs newbie,
> tentatively exploring the use of C-p/C-n instead of arrow-keys wouldn't
> have that experience.  It seems pretty likely to me that they _would_
> get confused (and annoyed of course) by such seemingly arbitrary
> differences and that this might discourage them.

Confusion is not generally annoying. It can also lead to curiosness.

Otherwise people would not be playing games for example. (Did someone
notice the n-back game?)

Re: please make line-move-visual nil

[Stefan Monnier]

> This must be resolved before the release.

>    But I understand your point.  Moreover, some time ago I also was
>    very frustrated, because convinient way for "phisical" line
>    navigation is no less.

It is resolved: there is an easy and convenient way to get "physical
line navigation", which is (setq line-move-visual nil).

I do not think there is a real need to have both screen-line and
logical-line movement available at the same time with convenient keys.


        Stefan

Re: please make line-move-visual nil

[T.V. Raman]

But I'd still like to see the default behavior set so that visual line
movement is not active.
   > This must be resolved before the release.

   > But I understand your point. Moreover, some time ago I also was
   > very frustrated, because convinient way for "phisical" line
   > navigation is no less.

   It is resolved: there is an easy and convenient way to get "physical
   line navigation", which is (setq line-move-visual nil).

   I do not think there is a real need to have both screen-line and
   logical-line movement available at the same time with convenient keys.

   Stefan

-- 


On 6/1/09, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> This must be resolved before the release.
>
>>    But I understand your point.  Moreover, some time ago I also was
>>    very frustrated, because convinient way for "phisical" line
>>    navigation is no less.
>
> It is resolved: there is an easy and convenient way to get "physical
> line navigation", which is (setq line-move-visual nil).
>
> I do not think there is a real need to have both screen-line and
> logical-line movement available at the same time with convenient keys.
>
>
>         Stefan
>
>
>

RE: please make line-move-visual nil

[Drew Adams]

Please see bug report #3438. All of it is worth reading in this regard.

Note in particular his request to have a buffer-local value for
line-move-visual, and to have Dired use nil for this.

(CCing the bug OP.)

--

BTW, how's the user poll going? Where is it taking place?

Re: please make line-move-visual nil

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> Please see bug report #3438. All of it is worth reading in this regard.
>
> Note in particular his request to have a buffer-local value for
> line-move-visual, and to have Dired use nil for this.

>> In dired mode, when the cursor is near the beginning of a very long
>> filename (as in near the "AaAaAa..." below , I can't move down to the
>> next file by "n" or "cursor down" key anymore(!).

In Dired, <up> and <down> call dired-previous-line and dired-next-line,
which should not be affected by line-move-visual.  I have not been able
to reproduce the reported problem (i.e., getting point stuck in Dired).
Maybe the reporter has some unusual customizations that are getting in
the way.

RE: please make line-move-visual nil

[Drew Adams]

> > Please see bug report #3438. All of it is worth reading in 
> > this regard. Note in particular his request to have a
> > buffer-local value for line-move-visual, and to have Dired
> > use nil for this.
> 
> >> In dired mode, when the cursor is near the beginning of a very long
> >> filename (as in near the "AaAaAa..." below , I can't move 
> >> down to the next file by "n" or "cursor down" key anymore(!).
> 
> In Dired, <up> and <down> call dired-previous-line and 
> dired-next-line, which should not be affected by line-move-visual.
> I have not been able to reproduce the reported problem (i.e.,
> getting point stuck in Dired). Maybe the reporter has some unusual
> customizations that are getting in the way.

Ah, you're right. And I even remember that I started to mention Dired as an
example of a formatted buffer in my original post in this thread, and removed it
when I realized this was in fact the case (I used Info and Buffer List as
examples). But I forgot about it when I saw the bug report. Thx.

Dired is an exception in this regard among formatted buffers, so you are correct
that Dired's bindings make it irrelevant for the immediate question.

It does illustrate the general idea, however: line movement in formatted buffers
is often different (should often be different) than it is in free-form text
buffers. In Dired, it is particularly different, since we want point to stay on
the file name - we constrain it to one column for vertical movement.

IOW, Dired has its own buffer-local behavior for line movement, which is even
more reflective of the buffer formatting than usual. If anything, this
strengthens the argument for buffer-specific line movement, rather than
weakening it.

More typically (in formatted buffers), we want to reflect the use of newlines
(they are positioned intentionally) and maintain the current column for line
movement, but there is no single, privileged column (e.g. file name) that we
want to constrain point to, as there is in Dired.

Each formatted buffer could individually define its own line-movement commands,
which amounts to just binding `line-move-visual' to nil around a call to
`next-line'. But that would be a bit silly. Better to just let the variable be
buffer-local. And provide nil as the default value for most formatted buffers.

--

BTW, you didn't answer the questions about the poll. How's it coming along?
Where is it?

Re: please make line-move-visual nil

[Stefan Monnier]

> More typically (in formatted buffers), we want to reflect the use of newlines
> (they are positioned intentionally) and maintain the current column for line
> movement, but there is no single, privileged column (e.g. file name) that we
> want to constrain point to, as there is in Dired.

I don't know if it's typical, but for most of those kinds of buffers you
describe as "formatted", I think they should at least set truncate-lines.

> Each formatted buffer could individually define its own line-movement
> commands, which amounts to just binding `line-move-visual' to nil
> around a call to `next-line'.  But that would be a bit silly.
> Better to just let the variable be buffer-local.  And provide nil as
> the default value for most formatted buffers.

Any major mode is free to (set (make-local-variable 'line-move-visual) nil).
As of now, I don't think any mode bothers to do that.

> BTW, you didn't answer the questions about the poll.
> How's it coming along?  Where is it?

I can't think of any poll which would bring any satisfactory answer to
the discussion.


        Stefan

RE: please make line-move-visual nil

[Drew Adams]

> > More typically (in formatted buffers), we want to reflect 
> > the use of newlines (they are positioned intentionally)
> > and maintain the current column for line movement, but
> > there is no single, privileged column (e.g. file name)
> > that we want to constrain point to, as there is in Dired.
> 
> I don't know if it's typical, but for most of those kinds of 
> buffers you describe as "formatted", I think they should at
> least set truncate-lines.

No reason given. Why?

Why should Buffer List or Info or Man output or grep output or C code or Java
code buffers have `truncate-lines' turned on? Because newlines are intentionally
positioned in such modes, they should use `truncate-lines'? Why would that be?

Is this a diversion to some other topic? What's the relation to the topic at
hand, which is `line-move-visual'?

> > Each formatted buffer could individually define its own 
> > line-movement commands, which amounts to just binding
> > `line-move-visual' to nil around a call to `next-line'.
> > But that would be a bit silly. Better to just let the
> > variable be buffer-local.  And provide nil as
> > the default value for most formatted buffers.
> 
> Any major mode is free to (set (make-local-variable 
> 'line-move-visual) nil).

For those modes that come with Emacs, it is the Emacs code that would need to do
that. It doesn't happen by spontaneous combustion.

I proposed making the variable always buffer-local. If you don't want to do
that, then yes, each mode for which nil is appropriate would need to do that.

Or the opposite: Switch the default to nil, and let the (relatively fewer?)
modes that use primarily free-form text do (set (make-local-variable
'line-move-visual) t).

> As of now, I don't think any mode bothers to do that.

Of course not. Nothing has been done yet about this issue. That's what the
discussion is about: tailoring `line-move-visual' so that it DTRT.

Which means turn itself off, by default, for non free-text modes, that is, code
modes and modes with formatted text. IMHO.

> > BTW, you didn't answer the questions about the poll.
> > How's it coming along?  Where is it?
> 
> I can't think of any poll which would bring any satisfactory answer to
> the discussion.

"Let them eat cake!"

(Or as the right-wing French government official said back in the day, speaking
of the Nouvelle Caledonian independentistes, "Ever since we stopped listening to
them, we don't hear anything from them anymore.") Poll, what poll?

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, Jun 1, 2009 at 11:00 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> I proposed making the variable always buffer-local. If you don't want to do
> that, then yes, each mode for which nil is appropriate would need to do that.

I think this is a global feature. Making it buffer local by default is
probably not the best then. It would be on the same level as makeing
the binding of C-n/C-p buffer local by default.

RE: please make line-move-visual nil

[Drew Adams]

> > I proposed making the variable always buffer-local. If you 
> > don't want to do that, then yes, each mode for which nil
> > is appropriate would need to do that.
> 
> I think this is a global feature. Making it buffer local by default is
> probably not the best then.

Why? No reason given.

But you say "then", as if being a global variable is a reason it shouldn't have
a buffer-local value.

> It would be on the same level as makeing
> the binding of C-n/C-p buffer local by default.

Since we have apparently replaced the classic behavior of `next-line', so it
respects `line-move-visual', yes. (But I personally have no problem if we go
back to the classic behavior, with normal line movement in all buffers.)

If a non-nil value of `line-move-visual' is not appropriate for some (most?)
buffers, but (some people think) it is appropriate for some other buffers, then
that's the obvious conclusion: make it buffer-local.

Re: please make line-move-visual nil

[Lennart Borgman]

On Mon, Jun 1, 2009 at 11:33 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > I proposed making the variable always buffer-local. If you
>> > don't want to do that, then yes, each mode for which nil
>> > is appropriate would need to do that.
>>
>> I think this is a global feature. Making it buffer local by default is
>> probably not the best then.
>
> Why? No reason given.

Yes, I think so. In the next sentence. It is a behaviour that is
expected to be the same in most buffers for at least most new users.
It is on the same level as a key binding.

Re: please make line-move-visual nil

[Stefan Monnier]

>> I don't know if it's typical, but for most of those kinds of 
>> buffers you describe as "formatted", I think they should at
>> least set truncate-lines.

> No reason given. Why?

> Why should Buffer List or Info or Man output or grep output or C code
> or Java code buffers have `truncate-lines' turned on? Because newlines
> are intentionally positioned in such modes, they should use
> `truncate-lines'? Why would that be?

Just goes to show that I misunderstood your notion of "formatted".
I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, ibuffer,
... Not info, not man, not Java, not C (not sure about grep, I like to
set it in grep, but I'm not sure if it's a good idea in general).

> Is this a diversion to some other topic? What's the relation to the
> topic at hand, which is `line-move-visual'?

When truncate-lines is non-nil, visual lines and logical lines coincide,
so line-move-visual doesn't make much difference any more (other than
for proportional text, that is).

> I proposed making the variable always buffer-local.

There would be no benefit to it:
  (set (make-local-variable <foo>) <bar>)
is the standard way for major modes to set variables.


        Stefan

RE: please make line-move-visual nil

[Drew Adams]

> Just goes to show that I misunderstood your notion of "formatted".
> I was thinking of buffers like pcl-cvs, VC, dired, buffer-list,
> ibuffer, ... Not info, not man, not Java, not C (not sure about
> grep, I like to set it in grep, but I'm not sure if it's a good
> idea in general).

I mentioned Info and Buffer List from the beginning. And I mentioned code
buffers and buffers with tabular formatting as well.

The distinction I made is between buffers that are mostly free-form text, where
newlines are typically not intentionally positioned by the user or by Emacs, and
the other buffers, where they are.

Even for Buffer List, Dired, and the rest you mentioned, do you really "think
they should at least set `truncate-lines'? Is that slated for Emacs 23.2?

> > Is this a diversion to some other topic? What's the relation to the
> > topic at hand, which is `line-move-visual'?
> 
> When truncate-lines is non-nil, visual lines and logical 
> lines coincide, so line-move-visual doesn't make much
> difference any more (other than for proportional text, that is).

True, when the line is not wrapped in any way, there is no line-wrapping. Guess
that's one way to skirt the issue. ;-) The relation to this issue is that with
`truncate-lines' the issue is evacuated and the distinction no longer matters?

"We're trying to decide whether to order fish or meat for the group."
"Just don't eat, then it doesn't matter."

> > I proposed making the variable always buffer-local.
> 
> There would be no benefit to it:
>   (set (make-local-variable <foo>) <bar>)
> is the standard way for major modes to set variables.

I have no problem with _how_ the buffer-local value is set, as long as the
default value set for buffers that are not mostly free-form text is nil.

And I have no problem with it not being buffer-local at all, if the default
value is nil.

Re: please make line-move-visual nil

[Lennart Borgman]

On Tue, Jun 2, 2009 at 12:52 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> The distinction I made is between buffers that are mostly free-form text, where
> newlines are typically not intentionally positioned by the user or by Emacs, and
> the other buffers, where they are.

Is not that a difficult distinction here? (In a word processor it
would be different.) Exactly how do you do the distinction - as simple
as possible, because if it is useful it must be easy to understand?

One point I mentioned before is that code might look scrambled, but
maybe that point could be cured some way? (If it really have to be
cured ...)

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Chong Yidong'" <cyd@stupidchicken.com>,
>         "'T.V. Raman'" <tv.raman.tv@gmail.com>, <ams@gnu.org>, <eliz@gnu.org>,
>         <stephen@xemacs.org>,
>         "'Andrew W. Nosenko'" <andrew.w.nosenko@gmail.com>,
>         <emacs-devel@gnu.org>, "'ishikawa'" <chiaki.ishikawa@ubin.jp>,
>         <3438@emacsbugs.donarmstrong.com>
> Date: Mon, 1 Jun 2009 15:52:34 -0700
> 
> I mentioned Info and Buffer List from the beginning. And I mentioned code
> buffers and buffers with tabular formatting as well.
> 
> The distinction I made is between buffers that are mostly free-form text, where
> newlines are typically not intentionally positioned by the user or by Emacs, and
> the other buffers, where they are.

Emacs does not reformat text in Info buffers, except for the header
lines and the "bread-crumbs" lines.  The rest is shown as produced by
makeinfo from the Texinfo sources.

RE: please make line-move-visual nil

[Drew Adams]

> > In Dired, <up> and <down> call dired-previous-line and 
> > dired-next-line, which should not be affected by line-move-visual.

Yes, but imagine if Dired _did_ use `next-line' for <down> or `n', so it was
thus affected.

Try it: M-x local-set-key n next-line. Narrow the Dired window so file names
wrap. Try `n' with point at various horizontal positions.

Do you really think `line-move-visual' is a good fit here? No? No, and the same
is true for other buffers where newline chars and line length matter.

In buffers where a line (line of code, line of Dired, etc.) is defined by ending
in a newline, moving to the next line does not mean moving to the wrapped part
of the same line.

If `truncate-lines' is helpful in this respect (you don't even see the wrap),
then so is nil `line-move-visual' (you don't move to the wrap, even if you see
it).

RE: please make line-move-visual nil

[Drew Adams]

> Emacs does not reformat text in Info buffers, except for the header
> lines and the "bread-crumbs" lines.  The rest is shown as produced by
> makeinfo from the Texinfo sources.

Info presents the _user_ with buffers formatted that way.

How Info does that - whether the info.el code does that or makeinfo does it or
Texinfo does it or the input to Texinfo is preformatted that way - is irrelevant
here.

It's about the _user_.

RE: please make line-move-visual nil

[Drew Adams]

> > The distinction I made is between buffers that are mostly 
> > free-form text, where newlines are typically not
> > intentionally positioned by the user or by Emacs, and
> > the other buffers, where they are.
> 
> Is not that a difficult distinction here? (In a word processor it
> would be different.) Exactly how do you do the distinction - as simple
> as possible, because if it is useful it must be easy to understand?
> 
> One point I mentioned before is that code might look scrambled, but
> maybe that point could be cured some way? (If it really have to be
> cured ...)

The exact decision for any given mode is not the issue.
Please don't make the perfect into the enemy of the good.

Adjustments can always be made later, based on user feedback wrt particular
modes. The important thing is to decide that non-nil `line-move-visual' should
be reserved, by default, for buffers that mostly have free-form text. That
includes text-mode, mail message buffers, and the like.

Don't search for the gray areas as a means to ignore or avoid a useful general
distinction.

Info is such a gray area. Should Info eventually become unformatted? Sure,
maybe, because most of it is just text. Things can evolve. But today, Info's
visual lines end with newlines. It has menus and headers that end in newlines.
It has code samples. But yes, most of it is just text, for which line endings
are, a priori, meaningless. I wouldn't argue much either way, for Info. Another
gray area is *Help*, for similar reasons.

But even if we disagree about how to treat Info or *Help* today, that's not the
point. To "get" the distinction, look at the extremes, not the middle: Buffer
List vs a text paragraph like this one. Think <pre> in HTML vs <p> (no, it's not
exactly the same thing, but that might help you see the distinction).

Is there a gradient from hot to cold? Of course. But not all meals are best hot,
nor all best cold. You like to eat fried chicken cold, and I like it hot. So
what? Does that mean we must pick one, hot or cold, to apply to all food?

There's individual preference, sure, and users can define buffer-local variables
as they see fit individually. But if we're serving meals for the group then we
need to decide, based on some general rules of thumb. Salad is by default cold;
soup is by default hot.

Re: please make line-move-visual nil

[Stefan Monnier]

> Try it: M-x local-set-key n next-line.  Narrow the Dired window so file
> names wrap.

At this point I already notice that the wrapping makes the buffer
unreadable/ugly, which is why the real answer is not to change
line-move-visual but truncate-lines.

> Do you really think `line-move-visual' is a good fit here?

No worse than the other choice, actually.

> No? No, and the same is true for other buffers where newline chars and
> line length matter.

That's your taste.  Which is why you should set line-move-visual to nil.


        Stefan

Re: please make line-move-visual nil

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <cyd@stupidchicken.com>,
>         <tv.raman.tv@gmail.com>, <ams@gnu.org>, <stephen@xemacs.org>,
>         <andrew.w.nosenko@gmail.com>, <emacs-devel@gnu.org>,
>         <chiaki.ishikawa@ubin.jp>, <3438@emacsbugs.donarmstrong.com>
> Date: Mon, 1 Jun 2009 16:23:50 -0700
> 
> > Emacs does not reformat text in Info buffers, except for the header
> > lines and the "bread-crumbs" lines.  The rest is shown as produced by
> > makeinfo from the Texinfo sources.
> 
> Info presents the _user_ with buffers formatted that way.

No, it does not.  It presents the text exactly as it is on disk, as if
it were a simple text file (well, almost; see above).  There's no
formatting anywhere.

We are probably miscommunicating, because I don't imagine you really
believe that Info buffers are formatted in any way.  They are free
text.

Re: please make line-move-visual nil

[Thien-Thi Nguyen]

() Lennart Borgman <lennart.borgman@gmail.com>
() Mon, 1 Jun 2009 11:59:53 +0200

   Confusion is not generally annoying.

Sometimes people confound confusion and annoyance, and knowingly.
One newbie's topiary maze is another's orange-tinged nightmare.

Re this issue, i see the tutorial(s) strive to make the
association between the arrow keys and C-n/C-p extremely simple
(that is, w/o any "except in this situation..." subclauses).
It would be a lot of work to change the tutorials.

thi

RE: please make line-move-visual nil

[Drew Adams]

> > I proposed making the variable always buffer-local.

SM> There would be no benefit to it:
SM>   (set (make-local-variable <foo>) <bar>)
SM> is the standard way for major modes to set variables.

Irrelevant. This is not about how to set the variable, but whether the variable
should always be buffer-local.

`truncate-lines', `word-wrap', and similar variables are all always
buffer-local.  `line-move-visual' should be also, for the same reasons.

Re: please make line-move-visual nil

[Stefan Monnier]

> `truncate-lines', `word-wrap', and similar variables are all always
> buffer-local.

`truncate-lines' is always buffer-local. for historical reasons.
`word-wrap' is buffer-local by mistake.


        Stefan

RE: please make line-move-visual nil

[Drew Adams]

> > > > I proposed making the variable always buffer-local.
> > 
> > SM> There would be no benefit to it:
> > SM> (set (make-local-variable <foo>) <bar>)
> > SM> is the standard way for major modes to set variables.
> > 
> > Irrelevant. This is not about how to set the variable, but 
> > whether the variable should always be buffer-local.
> >
> > `truncate-lines', `word-wrap', and similar variables are
> > all always buffer-local.
> 
> `truncate-lines' is always buffer-local. for historical reasons.
> `word-wrap' is buffer-local by mistake.

Why do you consider the latter a mistake? Is the former a mistake too, but won't
be fixed? Why not, if it's misguided?

And `goal-column', `fill-column, `fill-prefix', `left-margin', `comment-column',
`tab-width', `require-final-newline'? Are they also mistakes?

Put it another way: Which variables that have to do with wrapping, filling,
truncating, target columns, and line/buffer endings are *NOT* always
buffer-local? Which are not mistakes?

And what's the _reason_ you call them mistakes? It's easy to dismiss -
"historical", "mistake" - but why shouldn't they be always buffer-local? What
are the criteria for your judgment?

The only reason you gave was that major modes can make variables buffer local if
they need to. That's doesn't speak to why they would or would not do that.

And if that were the answer, then we would not have _any_ variables that are
always buffer-local - we would just leave it up to major modes to make them
buffer-local as needed. Why don't we expect `comment-column' (for instance) to
simply be made buffer-local by each major mode that needs that?

Re: please make line-move-visual nil

[Stefan Monnier]

> Why do you consider the latter a mistake?

There are at least 3 kinds of variables:
- global variables (which can be made buffer-local with make-local-variable)
- automatically buffer-local vars (e.g. made with make-variable-buffer-local)
- always buffer-local vars, e.g. default-directory
  (these can be tricky to distinguish from the previous kind).

Normal variables (and the most flexible) are the first kind.  The other
kind should only ever be used when there's a really good reason for it.

> And `goal-column', `fill-column, `fill-prefix', `left-margin',
> `comment-column', `tab-width', `require-final-newline'? Are they
> also mistakes?

These are old, so they may have been mistakes, but since I wasn't there
back then, I can only say that it's due to historical reasons.

> Put it another way: Which variables that have to do with wrapping, filling,
> truncating, target columns, and line/buffer endings are *NOT* always
> buffer-local? Which are not mistakes?

paragraph-start and friends?
Buffer-localness has nothing to do with whether a variable is linked to
filling or whatever other activity.  Instead it has to do with how that
variable is set, which kinds of values it holds, whether it is
meaningful to talk about a "global" value for that variable, ...

> And what's the _reason_ you call them mistakes?

It's a lot easier to `make-local-variable' than to undo
`make-variable-buffer-local'.

Also make-variable-buffer-local can have tricky behaviors: e.g. if you
`setq' a variable before loading the file that calls
make-variable-buffer-local, it will be set globally, which would
probably not be the intention.

> "historical", "mistake" - but why shouldn't they be always buffer-local? What
> are the criteria for your judgment?

To me the main question is "why should the be automatically buffer-local
when it's so easy to call make-local-variable?".

> Why don't we expect `comment-column' (for instance) to
> simply be made buffer-local by each major mode that needs that?

I actually do expect just that.  And in most cases, I expect major modes
to not change comment-column (it usually reflects a user's preference,
rather than the nature of the language handled by the major mode).


        Stefan