Re: line-move-visual

[Tim X <timx@nospam.dev.null>]

Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

> On 6/15/2010 10:20 AM, Tim X wrote:
>
>> I still don't understand the question you referred to when you wrote
>>
>> "When I asked "do you want C-n to move by logical line or visual line in
>> the logical line mode", the gallery has been silent."
>>
>> Perhaps I don't understand what you mean by logical line mode. My
>> interpretation was that logical line mode referred to what some would
>> call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp
>> moved to the next and previous lines where a line would be defined by
>> standard eol characters.
>
> By "logical line mode," I meant the state of Emacs whenever visual-line-mode
> is nil.  When you fire up Emacs with 'emacs -Q', it is in this mode.  This is
> not standard terminology.  It is something I made up to describe the situation
> we expect to have when Emacs is not in visual-line-mode.
>

I think I understand what you mean now, but I still think your over
complicating it somewhat. 

Forget about visual-line-mode. This is just confusing the situation. 

What you have is a logical line mode i.e. line-move-visual = nil and a
visual line mode i.e. line-move-visual = t. The emacs mode called
visual-line-mode is just the latter with a few enhancements, such as
word wrap and the ability to have the previous 'state' restored when you
turn it off. 

So, by default, emacs 23.1 starts in visual line mode. If you want it to
start in logical line mode, you set line-move-visual to t and you have
exactly the same behavior you had before. 

> By your terminology, "logical line mode" existed in Emacs 22, but it doesn't
> exist in Emacs 23.  

No, it still exists, it just isn't the default. 

> When you fire up 'emacs -Q' you get some kind of an "emacs
> default mode with a funny mixture of logical and visual lines".  

Where do you get the funny mix? Either line-move-visual is the default
of t and you have movement by visual lines or it has been set to nil and
you have the same logical line movement that you always had.

> From this point of view, the problem is more simply stated: the Emacs
> default is not logical line mode any more.

Correct. Nobody has claimed otherwise. 

>

> Perhaps my more important point is that, if we intend for Emacs to continue as
> a dependable system component (as opposed to a personal text editor), these
> kinds of incompatible changes should not be made.
>

If we had more than one contentious example, I might agree. However, the
reality is that emacs has been improving and evolving considerably and
remains incredibly stable. For the last 5 years or so, I've been running
from the latest development sources and have yet to encounter anything
other than minor trivial issues. Considering this has included quite
substantial updates to core elements, such as GUI interface libraries,
font rendering, character encoding etc. I think the maintainers have
done an excellent job. 

Given that you agree the addition of the ability to move by visual lines
is a good one and that possible issues exist, its worth noting that such
issues would exist whether the change was made the default or not.
Personally, I would have been more conservative and not made it the
default initially. My preference would have been to make it an option
and then, in a later release, if it turned out that having it as a
default was justified, change it then. At the very least, this would
somewhat rreduce possible negative impact as we would have understood
the real impact and scope of issues better and maintainers would have
had time to fix any issues (though there may be an arguement that
developers wouldn't do anything until forced - I frequently see packages
that still throw warnings for functions and variables that have been
deprecated for years which never seem to get 'fixed' despite the release
of new versions). However, that is all academic now. We have what we
have and will have to wait and see to what extent it actually does cause
all the issues that have been suggested. The bottom line is that there
isn't a way to make this sort of development such that it is painless
for everyone.

Tim


-- 
tcross (at) rapttech dot com dot au