Re: line-move-visual

Re: line-move-visual

[Uday S Reddy]

On 6/3/2010 11:11 PM, Mark Crispin wrote:

>
> I wasted hours trying to figure out what the hell was wrong with my
> file, or my terminal emulator window, or my system. The fact that the
> problem went away on a different system added further confusion. It was
> only when I did ESC <n> CTRL/N and saw that it moved me the wrong number
> of lines, but only on one system, that I realized that emacs changed.
> And that's when I did ESC X describe-key CTRL/N and read about
> line-mode-visual, although it did not mention that this was now the
> default.
>
> Surprise. Grr.

Having used Emacs for some 30 years myself, I always expect a few surprises with a new major version of Emacs.  It takes me a few months to read through all the change logs and the new manual sections to become comfortable with all the new and changed features.  Our sys admins realize that it takes time to get up to speed with a new version of Emacs, and generally install the new version along side the old version.  They maintain the two for several months before removing the old version.  Sometimes when there are significant new features, the old version just stays, because several users are uncomfortable with the new version.   The good thing about free software is that you can do that!

I would say your ire should be directed at your downstream distributions which don't seem to understand what a version change means to users.  An Emacs major version upgrade should never be done as part of a "routine" update.  They should never be installing Emacs without the news file.  And, you can't assume that you can reliably use a new version without reading through the change log at least.

Reading through the emacs-developers list yesterday, I also discovered that there is an Options -> Customize -> New Options menu, which asks you for an old version number and lists all the new options that have been added since then.  That may be a good way to figure out what has changed.

---

As I said before, the line-move-visual setting has been a complex decision for the developers.  I have a virtual folder of "visual" messages from the emacs-developers list, which shows some 40+ threads over the last couple of years, with each one having been extremely contentious.  I am still trying to figure out what it all means.

It would help the rest of us if you could tell us what problem you ran into with the default setting of line-move-visual, and why it is important for what you do.

Cheers,
Uday

Re: line-move-visual

[Uday S Reddy]

On 6/4/2010 9:39 AM, Tassilo Horn wrote:

>
> For normal editing, I like visual-line-mode sometimes (for example when
> working on a TeX document with colleagues, which write paragraphs one
> one single line).  With that, *all* motion commands operate on visual
> lines.  Its default is off.

Just curiious.  If they write whole paragraphs as lines, how do they do version control?

Cheers,
Uday

Re: line-move-visual

[Tassilo Horn]

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

>> For normal editing, I like visual-line-mode sometimes (for example
>> when working on a TeX document with colleagues, which write
>> paragraphs one one single line).  With that, *all* motion commands
>> operate on visual lines.  Its default is off.
>
> Just curiious.  If they write whole paragraphs as lines, how do they
> do version control?

It's a good style to write short and to the point paragraphs.  But
still, the diffs are usually a bit larger than with hard line breaks.

But on docs I write with hard breaks after 79 chars, my diffs are also
bigger than they must be, cause I cannot refrain from pressing M-q when
editing something in the middle of a paragraph. ;-)

Anyway, when writing text I've never felt the need to use version
control for anything except collaborative but sequential editing and
backup.  I can't even imagine forking some document, writing an
"experimental" paragraph and merging that back to trunk some time
later. ;-)

Bye,
Tassilo

Re: line-move-visual

[Joseph Brenner]

Tassilo Horn <tassilo@member.fsf.org> writes:
> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>
>>> For normal editing, I like visual-line-mode sometimes (for example
>>> when working on a TeX document with colleagues, which write
>>> paragraphs one one single line).  With that, *all* motion commands
>>> operate on visual lines.  Its default is off.
>>
>> Just curiious.  If they write whole paragraphs as lines, how do they
>> do version control?
>
> It's a good style to write short and to the point paragraphs.  But
> still, the diffs are usually a bit larger than with hard line breaks.

A subject I wonder about some times is why we don't have whitespace
insensitive diffs.

That one simple change could make the tab wars go away.

> Anyway, when writing text I've never felt the need to use version
> control for anything except collaborative but sequential editing and
> backup.  I can't even imagine forking some document, writing an
> "experimental" paragraph and merging that back to trunk some time
> later. ;-)

Oddly enough, it seems that the features we use for code development
are something like what Ted Nelson wanted for writing text back
when he was first thinking about hypertext, Xanadu, etc.  He
really wanted "complex intercomparison" of multiple versions.

I gather that he was envisioning a style of writing where you write a
document in multiple possible ways, and then try to decide which one
is best.

This has never struck me as one of his better ideas... but on the other
hand, wikipedia would be much less useable without it's history and
diff features.

Re: line-move-visual

[Brendan Halpin]

On Wed, Jun 09 2010, Joseph Brenner wrote:

> A subject I wonder about some times is why we don't have whitespace
> insensitive diffs.

I know it's not the same, but I get great mileage out of "C-u M-x
compare-windows", to say nothing of ediff. 

Brendan
-- 
Brendan Halpin,  Department of Sociology,  University of Limerick,  Ireland
Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F2-025 x 3147
mailto:brendan.halpin@ul.ie  http://www.ul.ie/sociology/brendan.halpin.html

Re: line-move-visual

[Stefan Monnier]

> A subject I wonder about some times is why we don't have whitespace
> insensitive diffs.

You might want to try the diff-refine-hunk command, or to set
diff-auto-refine-mode to t.

I wrote this while working on LaTeX documents where diffs tend to be
difficult to read because of all the refilling.  It won't "simplify" the
diff in any sense, but it will highlight the words that have been
added/changed/removed which is not bad.
Of course, ediff gives you similar results, so if you like ediff's
interface that's another option (I personally find ediff a bit too
heavyweight, so I only use it for particular circumstances, but
otherwise prefer smerge-mode and diff-mode to look at changes and
handle merges).


        Stefan

Re: line-move-visual

[Tassilo Horn]

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

>> With line-move-visual set to t (the default), only vertical motion
>> commands use visual lines, but for example C-a / C-e still use
>> logical lines.  From my point of view, that's a silly compromise.
>
> Agreed.  That means that line-move-visual is not doing what it says on
> the box.  I don't see a compelling reason why C-n and C-p should move
> by "visual lines" outside of visual-line-mode.  Perhaps it was a bad
> idea.

I remember that people (including RMS) tested line-move-visual and
concluded that this is ok, but full visual-line-mode would be too
radical.

> In the emacs-developers list, I see that line-move-visual came first
> and visual-line-mode was invented later.

I'm not completely sure about that.

>> But all visual line behavior break keyboard macros.  Define a macro,
>> then change your window size (so that lines are differently visually
>> wrapped), and *bang* your macro messes up your text.  It's semantics
>> change with the frame/window size.  That's silly.
>
> If these macros are dealing with visual-line-mode then I wonder what
> yo do that is sensitive to the line length.
>
> If they are dealing with normal text with line breaks, then perhaps
> all that you need to do is to use forward-line instead of next-line?

Well, the save solution is to enable `truncate-lines' (M-x
toggle-truncate-lines) before defining and executing a keyboard macro.
Then lines aren't wrapped, and there's no difference between logical and
visual lines anymore.

IMO, that should be done automatically.  But others argue, that a
keyboard macro should act exactly as doing the same stuff manually. Then
it's correct that a macro executed with VLM on or line-move-visual set
to t behaves differently depending on how text is visualized, which
includes window width, font size and other pitfalls you haven' thought
about...

Bye,
Tassilo

Re: line-move-visual

[Stefan Monnier]

> IMO, that should be done automatically.  But others argue, that a
> keyboard macro should act exactly as doing the same stuff manually. Then

There's a tension here, indeed: OT1H keyboard macros only record
a sequence of keys, so they should really be equivalent to having the
user hit the same keys in the same order, but OTOH they correspond to
mechanical execution, i.e. to code, so they need simple&reliable
semantics in order to work well.

As Emacs commands tend to get more complex over time (more DWIMish,
usually), we have more cases of commands that should really only ever be
used interactively because they require the user to see the result
before making the next step.

This tension for keyboard macros is made evident if you ever try to turn
a keyboard macro into a piece of Elisp code.  A job which would seem
simple enough that a little Elisp package could do it for you, right?

I would encourage people to try and write up a new keyboard-macro
package which would be closer to writing Elisp code: instead of
recording keys, it would record commands, and would do so in a submode
where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode,
... you name it) are disabled.


        Stefan

Re: line-move-visual

[Tassilo Horn]

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

Hi Stefan,

> I would encourage people to try and write up a new keyboard-macro
> package which would be closer to writing Elisp code: instead of
> recording keys, it would record commands, and would do so in a submode
> where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode,
> ... you name it) are disabled.

Sounds like a very good idea.  But for the time being, it would be a
good to have some before/after-kbd-macro-hooks that one could use to
prepare a safe environment and switch back to whatever was before.

Bye,
Tassilo

proposed keyboard-macro to record to elisp (was Re: line-move-visual)

[Joseph Brenner]

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

>> IMO, that should be done automatically.  But others argue, that a
>> keyboard macro should act exactly as doing the same stuff manually. Then
>
> There's a tension here, indeed: OT1H keyboard macros only record
> a sequence of keys, so they should really be equivalent to having the
> user hit the same keys in the same order, but OTOH they correspond to
> mechanical execution, i.e. to code, so they need simple&reliable
> semantics in order to work well.
>
> As Emacs commands tend to get more complex over time (more DWIMish,
> usually), we have more cases of commands that should really only ever be
> used interactively because they require the user to see the result
> before making the next step.
>
> This tension for keyboard macros is made evident if you ever try to turn
> a keyboard macro into a piece of Elisp code.  A job which would seem
> simple enough that a little Elisp package could do it for you, right?
>
> I would encourage people to try and write up a new keyboard-macro
> package which would be closer to writing Elisp code: instead of
> recording keys, it would record commands, and would do so in a submode
> where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode,
> ... you name it) are disabled.

The existing keyboard-macro recorder is funky in a number of respects.

(1) saving your work is not the default, and in fact takes several
    additional steps that are not very obvious. I might suggest:

   (a) automatic naming of macros ("keyboard-macro-1", "keyboard-macro-2"...)
   (b) a standard init file where keyboard-macros accumulate:
       ~/.emacs.d/user-generated-macros.el

       alternately: a standard directory: ~/emacs.d/key-macros/,
       where macros are saved one-per-file, and old and unloved
       ones can be expired

   (c) a follow-on command to fixup macros you expect to use in the
       future, which encourages/simplifies the process of:
         o  renaming
         o  assign key binding
         o  documenting

(2) There's no easy way to recover from errors during macro recording.
    The user can type very carefully for hundreds of commands, and then
    a single mistake can trash all of their work and require starting
    from scratch.

(3) There is indeed too high a barrier between creating a keyboard-macro
    and converting it to emacs lisp code.  There's an easy way to do
    customizations (keyboard-macros) and a more powerful, but harder way
    (write elisp) and the user sees the switch between the two as a big
    leap.

Re: proposed keyboard-macro to record to elisp (was Re: line-move-visual)

[LanX]

Hi Joe

On 9 Jun., 21:42, Joseph Brenner <d...@kzsu.stanford.edu> wrote:
> The existing keyboard-macro recorder is funky in a number of respects.
> ...

IMHO most of these features exists or would be easy to achieve, there
is a macro ring and there are options to edit macros, and another to
view a macro as elisp code...

(but I can't remember how... hmm naming a macro and describing the
function shows a vector  of pressed keys)

Whats really missing is a menu and/or a toolbar too assist macro
creation.

The possibilities are just too complex to remember them easily...

Cheers
  Rolf

Re: line-move-visual

[Brendan Halpin]

On Fri, Jun 04 2010, Uday S Reddy wrote:

> The visual-line-mode is supposed to be more general, and is meant to replace the longlines-mode eventually.

Interesting. Using window-width to determine where to word-wrap seems
arguably more consistent with other software than using fill-column, but
I have to say I prefer the latter.

Brendan

-- 
Brendan Halpin,  Department of Sociology,  University of Limerick,  Ireland
Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F2-025 x 3147
mailto:brendan.halpin@ul.ie  http://www.ul.ie/sociology/brendan.halpin.html

Re: line-move-visual

[Xah Lee]

On Jun 4, 6:39 am, brendan.hal...@ul.ie (Brendan Halpin) wrote:
> Attempted thread-jack: why use visual-line-mode instead of
> longlines-mode?

longlines-mode has serious bugs, i believe still so even i haven't
used it since emacs 23.1 a year or 2 ago.

basically, whenever large chunk of text is inserted or removed in a
buffer (either manually, or sometimes automatically by commands such
as patch and version control etc), then the text will be screwed up...
missing parts or something i forgot.

there are 1 or more bug reports of it in emacs bug track. If i recall
correctly, the situation is that it's hard to fix, because longlines-
mode was a hack for lack of visual line move, and i think it is done
by basically just inserting line-breaks in the background but display
and save it otherwise. (i haven't actually looked at the code though)

the visual line move feature is a critical feature in emacs. Before
emacs 23, there are a few packages or code that tries to introduce the
visual line move feature (see emacswiki), and longlines-mode is one of
them. However, because it is such a fundamental feature, it is hard
for a 3rd-party elisp package to get it correct. They all have major
problems...

i think Emacs 23.2's move by visual line feature is great because:

• it fixed a frequently asked feature. (e.g. i think ALL editors/IDEs
after mid 1990s, move by visual line )

• it fixed a issue that 3rd party elisp packages cannot address well.

Btw, who actually coded the visual line mode? I can't find the info. I
like to document it in my emacs pages.

--------------------------------------------------

Personally, i find moving by visual line is not just a good feature,
but a critical one, with consequences that effect the evolution of
language design and thinking, long term. The hard-coded lines is
fundamentally introduced by unix and C gang, and brain damaged a whole
generation of coders.

I've written about 7 essays addressing this point in the past 10
years. See:

• Xah on Programing Languages
  http://xahlee.org/Periodic_dosage_dir/comp_lang.html

See the articles under the Formatting section.

Each of these is written in a different context, but they essentially
discuss the same thing. That is, the importance of separating
appearance/formatting from semantic or logical structure.

Here's a synapses on how each article relates to the line move visual
issue.

------------------------------

• The Harm of Hard-wrapping Lines
  http://xahlee.org/UnixResource_dir/writ/hard-wrap.html

A introduction. (written as a diatribe )

------------------------------

• Tabs versus Spaces in Source Code
  http://xahlee.org/UnixResource_dir/writ/tabs_vs_spaces.html

introduces the idea as semantic based formatting vs hard-coded
formatting.

------------------------------

• Plain-Text Email Fetish
  http://xahlee.org/UnixResource_dir/writ/plain_text.html

• Unix, RFC, and Line Truncation
  http://xahlee.org/UnixResource_dir/writ/truncate_line.html

Shows some connection of the hard-coded habit from unix.

------------------------------

• A Simple Lisp Code Formatter
  http://xahlee.org/emacs/lisp_formatter.html

A example of what actually can happen when hard-coded formatting
hasn't become the conventional thought.

------------------------------

• A Text Editor Feature: Extend Selection By Semantic Unit
  http://xahlee.org/emacs/syntax_tree_walk.html

Another example of what could happen if unix didn't made people to
think about hard-coded short lines.

------------------------------

• Fundamental Problems of Lisp
  http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

Half of the essay, discuss the above issues with respect to lisp the
language, and consequences.

  Xah
∑ http://xahlee.org/

☄

Re: line-move-visual

[Mark Crispin]

On Fri, 4 Jun 2010, Xah Lee posted:
> Personally, i find moving by visual line is not just a good feature,
> but a critical one, with consequences that effect the evolution of
> language design and thinking, long term. The hard-coded lines is
> fundamentally introduced by unix and C gang, and brain damaged a whole
> generation of coders.

This is why UNIX and C accomplish things.  They were based upon 
accomplishing something useful rather than promoting an ideology.

It sounds like Microsoft Word is more suitable for the sort of work that 
you do.  Perhaps you ought to use Word instead of seeking to make emacs 
become more like Word.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Xah Lee]

hi Mark Crispin,

On Jun 4, 11:18 am, Mark Crispin <m...@panda.com> wrote:
> This is why UNIX and C accomplish things.  They were based upon
> accomplishing something useful rather than promoting an ideology.

maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix,
and the whole lisp culture and thinking is contrary to unix and C.

> It sounds like Microsoft Word is more suitable for the sort of work that
> you do.  Perhaps you ought to use Word instead of seeking to make emacs
> become more like Word.

speaking of Microsoft Word, i wait for dinosaurs like u to die. The
question is, can we recruit enough new generation of coders to emacs
fast enough before emacs extinguishes.

LOL!

  Xah
∑ http://xahlee.org/

☄

Re: line-move-visual

[Uday S Reddy]

On 6/5/2010 11:28 PM, Xah Lee wrote:

> I respect your recognized contribution to humanity as a computer
> programer. However, not sure if you are aware, that i've argued with
> well known emacs and lisp old timers for the past 10 years

Thank God that some civility has returned to this thread!

> to argue, first let's be precise what we are arguing about. Here's few
> points:
>
> • emacs 23's introduction of line-move-visual feature is good (or
> bad).
>
> • emacs 23's default of line-move-visual t good (or bad)
>
> • the very concep of move by screen line is good (or bad).

No, I don't think that these are the questions that this debate is about.  (When we start debating what the debate is about, we should realize that we are hopelessly knotted up in circles!)

Emacs 23 has a *visual line mode* and a *logical line mode* (the default mode that you have whenever the visual-line-mode is /not/ turned on).

Everybody understands and expects that C-n moves by visual line in the visual line mode.  The question is, do you want it to move by visual line or logical line in the *logical line mode*?

Let me repeat:  do you want C-n to move by visual line or logical in the *logical line mode*?

In the megabytes of debate that has gone on on this issue, I haven't seen a single point mentioned as to why it should move by visual line in the logical line mode.  Yet, that is the default in Emacs 23!  Worse, it *changes* the semantics of C-n which as, Mark Crispin points out, has been here the 70's.

So, there are three things that an old-timer is annoyed about:

1. Change of established semantics.

2. Inconsistency.

3. Pointlessness.

Coupled with these real technical issues, there are the attitudinal problems of holier-than-thou, smarter-than-thou and modern-than-thou and what have you.  In another part of this thread, we have also seen the astonishing idea that the developers don't have to care about what the users want/need. If that is the attitude that open source developers take, then I will be the first to give up open source!

Cheers,
Uday

Re: line-move-visual

[David Kastrup]

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

> Coupled with these real technical issues, there are the attitudinal
> problems of holier-than-thou, smarter-than-thou and modern-than-thou
> and what have you.

Everybody is free to join the discussions on the Emacs developer lists.
Those who choose not to help with the work don't get to criticize the
results.  A common democratic principle.

> In another part of this thread, we have also seen the astonishing idea
> that the developers don't have to care about what the users
> want/need. If that is the attitude that open source developers take,
> then I will be the first to give up open source!

An excellent idea.  The Free Software Foundation cares principally about
free software, not open source.

Open source sports the notion of creating superior software by
significantly different processes than common.

Free software is based on the premise of empowering the recipient of
software to change and adapting it according to his own needs.

Pampering to the needs of users who are not interested in changing and
adapting the software according to their needs is not a major priority.

Feel free to fork any free software which does not behave like you want
it: you have the power.  You are not dependent on upstream developers.

If you tie yourself to distribution channels that take this power from
you effectively, you are doing it by choice.  If you think you are in a
suitable majority, tell your distribution channel to change the upstream
decision for you if you don't feel like discussing this in a civilized
manner on the developer discussion lists created for that purpose.

-- 
David Kastrup

Re: line-move-visual

[Tim X]

David Kastrup <dak@gnu.org> writes:

> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>
>> Coupled with these real technical issues, there are the attitudinal
>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>> and what have you.
>
> Everybody is free to join the discussions on the Emacs developer lists.
> Those who choose not to help with the work don't get to criticize the
> results.  A common democratic principle.
>

Common democratic principal! What a load of crap. 

Anyone can criticise any decision at any time. Whether the
maintainers want to take any notice is another matter. 

For the record, I dislike the default of enabling move by visual lines
rather than logical ones. However, as it is trivial to revert behavior
back to the old default, this whole thread is largely poinless moaning
that is unlikely to change anything. 

I do agree that if you are someone who is going to get upset about
changes that you don't agree with, then you should participate in the
devel discussions. If you don't want to, then you are just going to have
to suck it up and either accept it or use something else. Moaning about
it without putting in any effort to find out why the change was made and
what discussions took place indicates low emotional maturity and/or
someone who just wants to have a childish dummy spit because somehting
in their world changed without their permission.

Despite the fact I don't agree witht he change in default behavior, I
also want to make it very clear, I DO NOT support what has been
posted regarding the motivation, care and competancy of the emacs
developers and maintainers. To those of you who have done this I would
say that making all sorts of assumptions regarding the motivations and
considerations of the devel team without actually looking at what
discussions did take place is an unjustified and unwarranted attack on
those few people who put in the hard word to develop and maintain this
free software. It is a cheap dishonarable swipe. It lumps all the
developers together as if they are all in agreement regarding every
change made and ignores the effort put in to try and get the right
outcome and do the difficult job of balancing many different views. 

If you don't like what they have done, either 

   a) get on the devel list and present a case and maybe build support
   to have the default changed., 
   b) Make the trivial config change to restore the old behavior and
   move on
   C) Use an old version and maintain it yourself the way you want
   d) Give up and go away.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Uday S Reddy]

>> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>>
>>> Coupled with these real technical issues, there are the attitudinal
>>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>>> and what have you.
>
> Despite the fact I don't agree witht he change in default behavior, I
> also want to make it very clear, I DO NOT support what has been
> posted regarding the motivation, care and competancy of the emacs
> developers and maintainers. To those of you who have done this I would
> say that making all sorts of assumptions regarding the motivations and
> considerations of the devel team without actually looking at what
> discussions did take place is an unjustified and unwarranted attack on
> those few people who put in the hard word to develop and maintain this
> free software. It is a cheap dishonarable swipe. It lumps all the
> developers together as if they are all in agreement regarding every
> change made and ignores the effort put in to try and get the right
> outcome and do the difficult job of balancing many different views. 

Oh, dear!  Sorry for the misunderstanding.  I didn't mean to imply that
the Emacs developers have shown the "attitudinal problems" that I
mentioned.  It had more to do with the attitudes expressed by some of
the "spokesmen" here (in Joseph Brenner's good words).

In themselves, the devs have been nothing less than professional and
polite, either here or on the emacs-devel list.  They do an incredible
amount of work, quite silently, and we all owe a great debt of gratitude
to them!

The thinking behind the line-move-visual decision went something like
this.  If C-n moves by logical lines then the new users would be
confused.  If it moves by visual lines then the experienced users would
be bothered.  But we have a flag whereby experienced users can revert to
the old behavior.  The new users won't know enough to set a flag.  So,
let us go with the default that helps out the new users.  See this
thread for example:

  http://thread.gmane.org/gmane.emacs.devel/101551/focus=101560

or tens of other threads that discussed line-move-visual.

I don't think there is any reason to attribute arrogance or carelessness
on the part of the developers in reaching that decision.  At worst, it
was a technical mistake in thinking that both the defaults are equally
bad.  Or, perhaps an error of judgement that the experienced users will
know enough to change the default.

---

Now that this thread has gone for this long and still seems to have some
life left, why don't we come up with some constructive ideas?  I have a
few of them here, mostly colored by my experience with maintaining VM.

The first suggestion I have is that the Emacs developers can find a way
to consult the user community about potential changes.  It is not
reasonable to expect that all users should take part in the developers
discussion in order to provide their input.  It seems like an additional
imposition on top of all the work that the developers already do, but
having an open discussion about visible behavior changes ahead of time
can save from unnecessary heartburn later on.  I do this kind of thing
regularly for VM.  See this discussion for example:

http://groups.google.com/group/gnu.emacs.vm.info/browse_thread/thread/1297bd3ab1de78d9/2361a430ee7e7bc3?lnk=raot#2361a430ee7e7bc3

The second suggestion, which Stefan seems to be thinking about already,
is to clearly label changes in the NEWS file.  This is also something I
have been doing in VM.  See, for example, the NEWS file here:

  https://launchpad.net/vm/+download

I am constantly irritated by the fact that some of the downstream
distributions omit the the NEWS files from installations.  I have
resorted to putting the NEWS file as an independent download on the web
site so that the downstream users can get it directly.  I think we
should try and impress upon the downstream guys the importance of NEWS
files.

A third suggestion is that we should start thinking of Emacs as
mission-critical software.  "Text editor" is a lousy description
which has long been out of date.  It is really platform on which a
number of critical services are delivered, for development of projects
or for running of teams and organizations.  A lot rides on it and any
changes that potentially cause corruption of files or data can be quite
serious. 

Finally, and I might be a bit OTT here, I think we should think of free
software as community-owned software.  It is not developer-owned
software (despite the aberration caused by the existence of FSF as a
copyright-owner).  Lots of people contribute, and they come and go.  The
software will live on for long after they are gone.  Free software isn't
"free-to-fork" software, even though the right to fork exists as a last
resort and as a foundation for everything else.  If that right needs to
be exercised, it is a signal that the community-ownership of the
software has broken down and that is not good for any of us.

Cheers,
Uday

Re: line-move-visual

[Stefan Monnier]

> The thinking behind the line-move-visual decision went something like
> this.  If C-n moves by logical lines then the new users would be
> confused.  If it moves by visual lines then the experienced users would
> be bothered.  But we have a flag whereby experienced users can revert to
> the old behavior.  The new users won't know enough to set a flag.  So,
> let us go with the default that helps out the new users.  See this
> thread for example:

Choosing defaults is very difficult indeed.  You can never please
everyone.  In this specific case, I'm the main guy to blame: I wrote the
original patch for line-move-visual (oddly enough, since it touches
parts of the code I still am not at all familiar with), mostly because
it seemed it would be important for proper support of word-wrap (which
I didn't care for much, but many users cared about it).

After writing the patch, I tried it out, mostly for debugging purposes,
and much to my surprise I discovered that I actually liked it.

Yes, it occasionally doesn't do what I want, but in practice, it does
what I want more often than the previous case:
- when no line wraps, it either makes no difference, or it works
  slightly better because it correctly accounts for
  variable-pitch fonts.
- when lines are long (typically the "single-line paragraph" text coming
  from people who either use word-wrap or longlines-mode or an editor
  that behaves similarly, but can also happen in many other cases like
  binary files, or mechanically-generated files), the new behavior is
  much better (how did you move to "that spot I see about 10
  visual-lines down from point" in a single logical line in
  previous Emacsen?).
- when the buffer mostly fits without wrapping, except for a few
  exceptions, then yes, the new behavior is less good for those
  wrapped-lines.  In my particular case, such lines are usually (very
  minor) bugs anyway, so it's not that important, but I understand that
  some people get annoyed.  And of course, if you use C-100 C-n instead
  of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100
  instead ;-), you'll be disappointed, and if you use keyboard macros
  you'll also be disappointed.

Depending on your particular circumstances, the second case will only
rarely happen whereas the third will be very common, so you'll be
really annoyed.  Sorry about that.  Please (setq line-move-visual nil)
in your .emacs and/or try to come up with some idea how we could keep
the advantages in cases 1 and 2 without suffering in case 3.


        Stefan

Re: line-move-visual

[Uday S Reddy]

Stefan Monnier wrote:

> Choosing defaults is very difficult indeed.  You can never please
> everyone.  In this specific case, I'm the main guy to blame: I wrote the
> original patch for line-move-visual (oddly enough, since it touches
> parts of the code I still am not at all familiar with), mostly because
> it seemed it would be important for proper support of word-wrap (which
> I didn't care for much, but many users cared about it).

Isn't word-wrap the ideal solution for dealing with the single-line paragraphs 
that you mention in the second bullet point below?

> 
> Yes, it occasionally doesn't do what I want, but in practice, it does
> what I want more often than the previous case:
> - when no line wraps, it either makes no difference, or it works
>   slightly better because it correctly accounts for
>   variable-pitch fonts.
> - when lines are long (typically the "single-line paragraph" text coming
>   from people who either use word-wrap or longlines-mode or an editor
>   that behaves similarly, but can also happen in many other cases like
>   binary files, or mechanically-generated files), the new behavior is
>   much better (how did you move to "that spot I see about 10
>   visual-lines down from point" in a single logical line in
>   previous Emacsen?).
> - when the buffer mostly fits without wrapping, except for a few
>   exceptions, then yes, the new behavior is less good for those
>   wrapped-lines.  In my particular case, such lines are usually (very
>   minor) bugs anyway, so it's not that important, but I understand that
>   some people get annoyed.  And of course, if you use C-100 C-n instead
>   of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100
>   instead ;-), you'll be disappointed, and if you use keyboard macros
>   you'll also be disappointed.
> 
> Depending on your particular circumstances, the second case will only
> rarely happen whereas the third will be very common, so you'll be
> really annoyed.  Sorry about that.  Please (setq line-move-visual nil)
> in your .emacs and/or try to come up with some idea how we could keep
> the advantages in cases 1 and 2 without suffering in case 3.

If line-move-visual is nil by default, the users that care about 1 and 2 can 
set it to t, can't they?  It is the same issue from the other side of the 
fence.  They don't need the default set in a particular way to get their behaviour.

Moreover, the people dealing with single-line paragraphs (me being one of them) 
will normally use visual-line-mode, which does visual line motion anyway.  So, 
they are not affected by the default at all.

So, this particular decision doesn't seem to be all that difficult.

Cheers,
Uday

Re: line-move-visual

[Stefan Monnier]

>> Choosing defaults is very difficult indeed.  You can never please
>> everyone.  In this specific case, I'm the main guy to blame: I wrote the
>> original patch for line-move-visual (oddly enough, since it touches
>> parts of the code I still am not at all familiar with), mostly because
>> it seemed it would be important for proper support of word-wrap (which
>> I didn't care for much, but many users cared about it).
> Isn't word-wrap the ideal solution for dealing with the single-line
> paragraphs that you mention in the second bullet point below?

Only for the display part: it doesn't help navigation.

> So, this particular decision doesn't seem to be all that difficult.

Leaving line-move-visual as nil would have been an easy decision to
satisfy old users who already like Emacs.  But setting it to t (without
switching all the way to visual-line-mode) seemed like
a good compromise.

Given the reactions we've seen since Emacs-23.1 was released,
I don't regret the decision.


        Stefan

Re: line-move-visual

[despen]

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

>> The thinking behind the line-move-visual decision went something like
>> this.  If C-n moves by logical lines then the new users would be
>> confused.  If it moves by visual lines then the experienced users would
>> be bothered.  But we have a flag whereby experienced users can revert to
>> the old behavior.  The new users won't know enough to set a flag.  So,
>> let us go with the default that helps out the new users.  See this
>> thread for example:
>
> Choosing defaults is very difficult indeed.  You can never please
> everyone.  In this specific case, I'm the main guy to blame:

Good, then I have something to contribute to this thread.

Nice work and I support the idea of making this a default.

For me, it was easy to spot the new behavior, and I assumed I
would find a description and override in the NEWS file.

So far I've found no reason to do so.

I hope the complainers get a full refund of all the money they
paid for your hard work and nothing else.

Re: line-move-visual

[Tassilo Horn]

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

> - when no line wraps, it either makes no difference, or it works
>   slightly better because it correctly accounts for
>   variable-pitch fonts.
> - when lines are long [...], the new behavior is much better (how did
>   you move to "that spot I see about 10 visual-lines down from point" in
>   a single logical line in previous Emacsen?).

I agree, and with the macro exception I'm in favour of operating on
visual lines by default.  But what I don't understand is why there are
two levels of operating on visual lines: line-move-visual and
visual-line-mode.  IMO, the former is confusing, because C-a/e (and
probably others) still operate on logical lines.

I guess, that's because VLM is more invasive, i.e. keys get bound to new
functions.  But then, why not drop VLM altogether and make
`move-beginning/end-of-line' obey line-move-visual, too?

Bye,
Tassilo

Re: line-move-visual

[Uday S Reddy]

On 6/10/2010 11:02 PM, Tassilo Horn wrote:

>
> I guess, that's because VLM is more invasive, i.e. keys get bound to new
> functions.

Hi Tassilo, Can you or anybody else give us some examples of how 
visual-line-mode is invasive?  I haven't been able to understand this point.

Cheers,
Uday

Re: line-move-visual

[Evans Winner]

In my opinion, the question should never be what new users
of Emacs want.  What new users want is an editor that is 5%
better than notepad.exe because that is per-force the limit
of their imagination.  They generally do no know 1% of what
Emacs can do, so are not in a position to intelligently
decide what the defaults should be.  They /should/ want to
rely on experienced users for that, and they should be
willing to spend the extra tiny bit of effort up-front to
learn the reasoning behind it.  If they aren't, then Emacs
isn't for them.  Let them go.  Changing defaults to whatever
makes the least friction for those who switch to Emacs is
not a service to new users; the principle is that people
tend to stick with what they learn first, so dumbed-down
defaults produces dumbed-down users, who will, after a few
months or years, show up on emacs-devel demanding even more
dumbed-down defaults, because that would make it even easier
for the next generation of Microsoft/IBM/CUA refugees.

It sometimes surprises me to find that even some experienced
users of Emacs don't use and even sometimes don't know how
to use keyboard macros.  The name Emacs does, after all,
come from the phrase "Editor MACroS."  It is a fundamental
part of the user experience.  The question with regards to
new users and line-move-visual is whether the slight savings
in initial cognitive friction comes and the price of making
it more difficult for new users to learn to create and use
typical line-at-a-time-type keyboard macros.  I don't claim
to know the answer to this particular question, but I think
the principle above is the right one to consider in this
kind of case.

Re: HOWTO: Cowtow to old farts

[Xah Lee]

for those who may not know, Ilya Zakharevich is the guy to perl's
regex engine, and author of cperl-mode. (8.1 k non-comment lines.),
among tens of other perl modules.

On Jun 29, 1:04 am, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> Re: HOWTO: Cowtow to old farts
> ...
> So, what do you think?

I think you are joking. lol.

am curious, what are your emacs configs? are they public somewhere? I
didn't seem to see it in your perl home page. Thanks in advance.

  Xah
∑ http://xahlee.org/

☄

On Jun 29, 1:04 am, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> On 2010-06-10, Evans Winner <tho...@unm.edu> wrote:
>
> > In my opinion, the question should never be what new users
> > of Emacs want.  What new users want is an editor that is 5%
> > better than notepad.exe because that is per-force the limit
> > of their imagination.  They generally do no know 1% of what
> > Emacs can do, so are not in a position to intelligently
> > decide what the defaults should be.  They /should/ want to
> > rely on experienced users for that, and they should be
> > willing to spend the extra tiny bit of effort up-front to
> > learn the reasoning behind it.  If they aren't, then Emacs
> > isn't for them.  Let them go.
>
> Do not think you would find many people agreeing with you.  Anyway:
>
> =======================================================
>
> I applaud the stand of emacs developers in this thread: facing with
> (extremely rude, unsubstantiated and, IMO, just plain stupid) attacks from
> a handful of self-righteous ... - Well, there is no need to stack epithets
> here, if you read this, you probably have read the other 176 messages in
> this thread, and had a possibility to see what the attackers consider to be
> "arguments".
>
> Anyway, I'm really proud of how the developers behaved in this situation -
> and how they understand their responsibilities in maintaining Emacs.  Myself,
> I never used Emacs23, so cannot comment on the particular feature in question;
> however, I cannot skip commenting on the general question of maintainance of
> Emacs defaults.  (In 1/2 of what follows, there is going to be nothing new
> w.r.t. my other runts on this topic; skip to '----' if you cannot stand this
> habit of mine.)
>
> For several decades, Emacs was practically unusable as a text editor AS
> SHIPPED.  Mostly, this was due to the old-guard developers having no clue
> in questions of UI design.  The situation started to change about 10 years
> ago (and now I expect I may be able to remove more than half of those
> MEGABYTES of customizations I needed to make Emacs bearable for me - and many
> people using my customizations).  I attribute it to inflow of new blood the
> camp of developers - and, as I said, I'm proud of them having great
> contributions to this thread.
>
> Being "unusable-as-shipped" makes the question of preserving the old defaults
> moot - the ONLY way ahead is to change the defaults as quick as possible.
> This would make the `hidden wonders' of Emacs accessible to most of the users.
>
> In my experience (and let me stress that this thread proves me wrong - see
> below), Emacs users come in two large categories: the silent majority (>70%,
> in my estimates): the people who operate in n00b's mode (as in "how do I edit
> .emacs if it is not there?" [*] ;-): they know better use of their brains
> than learning hundreds of keyboard command, learning how to program Emacs,
> and/or what is the name of configuration file of Emacs.
>
>  (In my experience, most users also share another feature: most of them are
>   not interested in "typing as quick as they think".  They are more
>   interested in following the "when you say what you think, think what you
>   say" maxim.  Quality [and prudence] over speed...  Few of they would be
>   interested in "minimizing leaving home row keys".)
>
> The other category consists of us, old guard old farts, who consider it an
> investement of time to read the NEWS file (at least when things break ;-),
> who are visible on c.e.emacs, are not intimidated by running `F1 k' if things
> are not working as we expect, and for whom it is absolutely not a nuisance
> to insert a line into .emacs once in several years.
>
> Facing these two categories, the policy is obvious: the default should cater
> to those who won't be able to change them: newbies and eternal-newbies.
> And for the old farts, there should be a clear pathway to navigate to HOWTO
> on undoing these changes.  (And: this thread contained many suggestions how
> to make this navigation easier.)
>
> ----  And now the new part  ----
>
> However, as this thread shows, there is another category which was
> overlooked in my list (in my 15 years on this newsgroup, I do not recollect
> hearing from it before): "hapless" old farts - those who have a pretty good
> idea how Emacs works, but do not know how to find their way out of their
> pants^H^H^H^Hroblems.
>
> In this thread, their rudeness and obvious haplessness in the skill of
> persuation hides an important consideration: it is POSSIBLE AND EASY to cater
> to their needs as well.  And if it is possible and easy, I think ti is our
> obligation to implement it.
>
> The solution may be as easy as having one function and one variable.  Use them
> by replacing the defaults value by
>
>   (choose-by-version
>     emacs-principal-UI-freeze
>     nil
>     "23.2" t
>     "21.1" 'skip)
>
> with arguments being VERSION DEFAULT_VAL VERSION1 VALUE1 VERSION2 VALUE2 ....
> One may require VERSIONn's going in decreasing order, so nil, t, 'skip
> would be the "current default", "previous default", "default before this" etc.
>
> Even if there is only a handful of people who would actually want to freeze
> the "principal parts" of UI, such a trick may have a major role.  Just a
> POSSIBILITY to freeze allows one much more freedom in CHANGING the defaults.
> And I expect that there may be many more useful ways to make defaults yet more
> user-friendly than they are now.
>
> So, what do you think?
> Ilya
>
> [*]  BTW: why not have an option "Edit configuration file" in the Help menu?
>      Or maybe it is already there?  Not here, in 21.4...
>
>      One may even insert some meaningful header there if the file is
>      not present (sp?):
>
>          ;;; This file is loaded by Emacs before-this/after-that;
>          ;;; it should contain Emacs-Lisp code customizing Emacs to your taste.
>          ;;; To debug problems in this file, one may skip loading it
>          ;;; by giving option -q to emacs.  Alternatively, uncomment
>          ;;; the following line (or give --debug-init option to Emacs):
>          ; (....)
>          ;;; For further details, Choose XYZT from Emacs menu, or type ....

Re: line-move-visual

[Mark Crispin]

On Thu, 10 Jun 2010, Uday S Reddy posted:
> A third suggestion is that we should start thinking of Emacs as
> mission-critical software.

It amazes me that anyone would think otherwise.

> It is really platform on which a
> number of critical services are delivered, for development of projects
> or for running of teams and organizations.  A lot rides on it and any
> changes that potentially cause corruption of files or data can be quite
> serious.

As the kids say, "well, duh!"

This discussion is rapidly leading to "is free software suitable as 
mission-critical software?".

Some people would be more comfortable is the answer is "no".  Then they 
don't have to deal with the responsibility of mission-critical software.

> Finally, and I might be a bit OTT here, I think we should think of free
> software as community-owned software.  It is not developer-owned
> software (despite the aberration caused by the existence of FSF as a
> copyright-owner).

The notion of "community-owned software" works as ideology, but not as 
reality.  If emacs was really community-owned software, I as a community 
member could revert the change in the official distribution sources.  And 
then there could be revert wars ala Wikipedia.

That existed once upon a time in the mid-1970s, at MIT (the ITS systems) 
and elsewhere.  It didn't end well.

The dichotomy between "the cathedral and the bazaar" that ESR postulated 
doesn't really exist.  The full-fledged bazaar option doesn't scale and 
never actually happened.  It's just two types of cathedrals, one run by a 
pope and the other run by a board of laymen.

But even the laymen become power-corrupted.

> Free software isn't
> "free-to-fork" software, even though the right to fork exists as a last
> resort and as a foundation for everything else.  If that right needs to
> be exercised, it is a signal that the community-ownership of the
> software has broken down and that is not good for any of us.

That is certainly true.  Again, BSD serves as an example.

Another sign of a process breakdown is when a developer's answer to user 
complaints about changes in a new version is "so just run the old 
version".  The need to revert to an old version means that the new version 
is broken.

The corrolary to this is that the standard developer's answer to 
complaints about bugs in an old version is "upgrade to the new version". 
This only works if the upgrade is a viable option.

Developers can't have it both ways.  If they create a new version that is 
unacceptable to some portion of the user community, they they have 
effectively forked the software.

Responsible developers figure this out after a while.  It takes maturity. 
Generally, they want their users to be using one, and only one, version; 
and they do what is necessary to ensure that there are no barriers to 
upgrade.

Since user interface surprise is a barrier to upgrade, they make sure 
there aren't any such surprises.

In the real world, people get fired for inflicting surprises in 
mission-critical software.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Uday S Reddy]

Mark Crispin wrote:

> The notion of "community-owned software" works as ideology, but not as 
> reality.  If emacs was really community-owned software, I as a community 
> member could revert the change in the official distribution sources.  
> And then there could be revert wars ala Wikipedia.

Exactly!  By "community-owned", I don't mean community-developed.  There needs 
to be control and discipline etc in the development team.  Otherwise, there 
will be chaos, and mission-critical fitness will go out of the window.

By community ownership, I only mean that all the people that have a stake in 
the system have a voice in the matter and we all feel ownership of the system. 
  When the community is divided, as seems to be the case on this issue, the 
developers have to make a decision and move on.

In any case, I think we have reached a point where you and Stefan need to talk 
to each other directly and sort it out.  In my humble opinion, it is easy to 
argue that the current default was ill-chosen.  But it is not so easy to argue 
that it should be changed.  If we change it, then we face all the same issues 
all over again affecting the other users that are depending on the current 
default.  So, it seems best to leave things as they are and make a note of all 
the lessons learned.

> But even the laymen become power-corrupted.

I think that is a bit of an exaggeration.  They have a responsibility to bear 
and sometimes they get carried away.

> Since user interface surprise is a barrier to upgrade, they make sure 
> there aren't any such surprises.

Yes, that point is well-made.  But, the same argument now suggests that the 
default should not be changed yet again.

Cheers,
Uday

Re: line-move-visual

[Mark Crispin]

On Thu, 10 Jun 2010, Uday S Reddy posted:
> By community ownership, I only mean that all the people that have a stake in 
> the system have a voice in the matter and we all feel ownership of the 
> system.  When the community is divided, as seems to be the case on this 
> issue, the developers have to make a decision and move on.

The problem is that nobody ever asked the existing users whether or not 
they wanted this global change foisted upon them.  Rather, it was done 
unilaterally, and the individuals responsible are saying "See!  Some 
people like it!  It was a good change."

This sort of thing happened in the past as well.  The difference was that 
there was accountability in the past that is absent today.

> In my humble opinion, it is 
> easy to argue that the current default was ill-chosen.  But it is not so easy 
> to argue that it should be changed.  If we change it, then we face all the 
> same issues all over again affecting the other users that are depending on 
> the current default.  So, it seems best to leave things as they are and make 
> a note of all the lessons learned.

I agree that we are probably screwed, and royally so.

I have a new task on my list: replace emacs in the procedures for my 
target audience since emacs is no longer suitable for that purpose.  I 
simply can not tell these users "make sure that you set line-move-visual 
to nil"; they would have no clue what that means.  More likely than not, I 
will end up being obliged to write a program for the task; and there will 
be one less way those users will be exposed to emacs.

One of the advantages of the "software tools" mindset of the past was that 
you did not have to write a program for every task.  Instead, you could 
leverage the existing tools.  That falls apart when those tools are 
corrupted so that they no longer can be relied upon to produce predictable 
results.

>> But even the laymen become power-corrupted.
> I think that is a bit of an exaggeration.  They have a responsibility to bear 
> and sometimes they get carried away.

Every young programmer wants to put his own mark on things.  The problem 
is that these changes are frequently ill-considered and sometimes have bad 
consequences.

>> Since user interface surprise is a barrier to upgrade, they make sure there 
>> aren't any such surprises.
> Yes, that point is well-made.  But, the same argument now suggests that the 
> default should not be changed yet again.

Yup.  We're probably screwed.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Wojciech Meyer]

Mark Crispin <mrc@panda.com> writes:

> On Thu, 10 Jun 2010, Uday S Reddy posted:
>> By community ownership, I only mean that all the people that have a
>> stake in the system have a voice in the matter and we all feel
>> ownership of the system.  When the community is divided, as seems to
>> be the case on this issue, the developers have to make a decision
>> and move on.

Well it is certainly possible, one can use mailing list and the NEWS
file, which was suggested before.

> This sort of thing happened in the past as well.  The difference was
> that there was accountability in the past that is absent today.

What sort of acountability, I think unhappy `customers' is enough
punishment.

> I have a new task on my list: replace emacs in the procedures for my
> target audience since emacs is no longer suitable for that purpose.  I
> simply can not tell these users "make sure that you set
> line-move-visual to nil"; they would have no clue what that means.
> More likely than not, I will end up being obliged to write a program
> for the task; and there will be one less way those users will be
> exposed to emacs.

What kind of Emacs users are they? Isn't possible to place on every
machine a stub containing: (setq line-move-visual nil).

>
> One of the advantages of the "software tools" mindset of the past was
> that you did not have to write a program for every task.  Instead, you
> could leverage the existing tools.  That falls apart when those tools
> are corrupted so that they no longer can be relied upon to produce
> predictable results.

It is ever more true now.

>
>>> But even the laymen become power-corrupted.
>> I think that is a bit of an exaggeration.  They have a
>> responsibility to bear and sometimes they get carried away.
>
> Every young programmer wants to put his own mark on things.  The
> problem is that these changes are frequently ill-considered and
> sometimes have bad consequences.

There is nothing wrong in being young and creative, that makes often
things better. Young people often do care more about things then Senior
Architects, they are also more flexible for changes.

The reason why this setting wasn't kept by default is to fix the
fundamental problem, without additional cost of keeping this setting
hidden. People have full rights to receive the fixes like this, as you
have full rights to complain about them. This is part of the game, IMHO
Emacs does not change that often, and really keeps things the same, just
because there is nothing to fix apart from things that need to be
changed in order to guarantee future of Emacs.

Wojciech

Re: line-move-visual

[Mark Crispin]

On Sat, 12 Jun 2010, Wojciech Meyer posted:
> Well it is certainly possible, one can use mailing list and the NEWS
> file, which was suggested before.

Please read the first chapter of the Hitchhiker's Guide to the Galaxy to 
understand the flaw in that reasoning.

>> This sort of thing happened in the past as well.  The difference was
>> that there was accountability in the past that is absent today.
> What sort of acountability, I think unhappy `customers' is enough
> punishment.

Apparently not, if the "customers" are told that it's their fault for not 
being on the development list.

> What kind of Emacs users are they? Isn't possible to place on every
> machine a stub containing: (setq line-move-visual nil).

There include people who never use emacs, except to follow the procedure 
that I outline (which is literally a cookbook "do these steps exactly"). 
I have no control or access to the machines in question.

Perhaps I should have written a program to begin with.  But it was so much 
simpler to leverage upon emacs back in the days when emacs had a reliable 
interface.  Now that it no longer does, I'm now forced to write the 
program.

> There is nothing wrong in being young and creative, that makes often
> things better. Young people often do care more about things then Senior
> Architects, they are also more flexible for changes.

Yes, but they lack the wisdom and experience of their elders.  This in 
turn leads them to address complex problems with simple solutions that 
backfire (sometimes disastrously).

> The reason why this setting wasn't kept by default is to fix the
> fundamental problem,

Yeah, right.  The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N, 
CTRL/P, etc. moved to predictable places in the file no matter what the 
screen width, and thus could be relied upon for a cookbook procedure.

We can't have predictability and reliability.  We have to do pretty-pretty 
to be just like Word, and destroy the one attribute that made emacs 
superior to other choices.

Bletch.

This wouldn't have been a problem had the arrow keys been changed to the 
new semantics and CTRL-A/E/N/P been left alone.  The new semantics are 
even arguably right for arrow keys (although I would go further and say 
that they should also treat tabs as the equivalent number of spaces).  It 
isn't as if we're still in the 1970s and have keyboards without arrow 
keys.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Alan Mackenzie]

In comp.emacs Mark Crispin <mrc@panda.com> wrote:
> On Sat, 12 Jun 2010, Wojciech Meyer posted:
>> Well it is certainly possible, one can use mailing list and the NEWS
>> file, which was suggested before.

> Please read the first chapter of the Hitchhiker's Guide to the Galaxy to 
> understand the flaw in that reasoning.

Please feel free to suggest a way the development team could have
canvassed users, particularly the vast majority who don't keep up with
project mailing lists.  It seems like a difficult problem.

> Apparently not, if the "customers" are told that it's their fault for
> not being on the development list.

It seems like a difficult problem.

>> What kind of Emacs users are they? Isn't possible to place on every
>> machine a stub containing: (setq line-move-visual nil).

> There include people who never use emacs, except to follow the procedure 
> that I outline (which is literally a cookbook "do these steps exactly"). 
> I have no control or access to the machines in question.

> Perhaps I should have written a program to begin with.  But it was so much 
> simpler to leverage upon emacs back in the days when emacs had a reliable 
> interface.  Now that it no longer does, I'm now forced to write the 
> program.

It seems you're exaggerating your predicament ever so slightly.  I'd
guess you could code up the replacement program (in elisp?  in sed?  in
whatever?) in less time than you've spent discussing the problem here.

It's far from obvious that this change (line-visual-mode being set) is a
Bad Thing.  Without it, moving around things like log files with 300
character lines was an utter pain.  I'd suggest it was more of a pain
than the one you're suffering, because it hit users using Emacs in its
principal way of working, rather than in special cases in some obscure feature
(keyboard macros).

since Emacs 23, I haven't felt any need whatsoever to restore l-v-m to nil,
and I haven't seen anybody else asking for it.

>> There is nothing wrong in being young and creative, that makes often
>> things better. Young people often do care more about things then
>> Senior Architects, they are also more flexible for changes.

> Yes, but they lack the wisdom and experience of their elders.  This in
> turn leads them to address complex problems with simple solutions that
> backfire (sometimes disastrously).

Hence the best team for writing something contains both
stuck-in-the-groove maturity and feckless youth.  Not that the Emacs team
is lacking in solid wisdom.

>> The reason why this setting wasn't kept by default is to fix the
>> fundamental problem,

> Yeah, right.  The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N, 
> CTRL/P, etc. moved to predictable places in the file no matter what the 
> screen width, and thus could be relied upon for a cookbook procedure.

Now you've got to take screen width into account.  Big deal.

And it was dashed near impossible to move easily to the middle of long,
long lines.  I suspect this need to be commoner than using keyboard
macros on long lines.

> We can't have predictability and reliability.  We have to do
> pretty-pretty  to be just like Word, and destroy the one attribute that
> made emacs  superior to other choices.

You're exaggerating at least a little bit here.  There are lots and lots
of attributes that make Emacs superior, some of them in contention with
some others.  You could easily enough amend your instructions, prefixing
them with "M-: (setq visual-line-mode nil)".  Or you could rewrite the
thing (what does it do, exactly?) in elisp or whatever.

> Bletch.

> This wouldn't have been a problem had the arrow keys been changed to
> the new semantics and CTRL-A/E/N/P been left alone.  The new semantics
> are even arguably right for arrow keys (although I would go further and
> say that they should also treat tabs as the equivalent number of
> spaces).  It isn't as if we're still in the 1970s and have keyboards
> without arrow keys.

The arrow keys are a long way away from the home position on the
keyboard.  You're surely not suggesting rebinding those four key
sequences to something else?

> -- Mark --

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: line-move-visual

[Jim Diamond]

On 2010-06-13 at 17:56 ADT, Alan Mackenzie <acm@muc.de> wrote:
> In comp.emacs Mark Crispin <mrc@panda.com> wrote:

>> This wouldn't have been a problem had the arrow keys been changed to
>> the new semantics and CTRL-A/E/N/P been left alone.  The new semantics
>> are even arguably right for arrow keys (although I would go further and
>> say that they should also treat tabs as the equivalent number of
>> spaces).  It isn't as if we're still in the 1970s and have keyboards
>> without arrow keys.

> The arrow keys are a long way away from the home position on the
> keyboard.  You're surely not suggesting rebinding those four key
> sequences to something else?

Why not?  Presumably (*) the idea of having long lines and moving to
the next visual line (as the default) is to placate word-processor
refugees, who are probably used to using arrow keys (regardless of how
far they are from the home position) and not interested in using
Ctrl-A,E,N,P.

(*) Wild speculation, since I didn't read the discussion on the
developer list.  Mea culpa.

				Jim

Re: line-move-visual

[Uday S Reddy]

Alan Mackenzie wrote:

> It's far from obvious that this change (line-visual-mode being set) is a
> Bad Thing.  Without it, moving around things like log files with 300
> character lines was an utter pain.  I'd suggest it was more of a pain
> than the one you're suffering, because it hit users using Emacs in its
> principal way of working, rather than in special cases in some obscure feature
> (keyboard macros).

If line-move-visual was nil by default, would you have been able to set it to t 
in order to move around the log files?

Cheers,
Uday

Re: line-move-visual

[Alan Mackenzie]

In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote:
> Alan Mackenzie wrote:

>> It's far from obvious that this change (line-visual-mode being set) is
>> a Bad Thing.  Without it, moving around things like log files with 300
>> character lines was an utter pain.  I'd suggest it was more of a pain
>> than the one you're suffering, because it hit users using Emacs in its
>> principal way of working, rather than in special cases in some obscure
>> feature (keyboard macros).

> If line-move-visual was nil by default, would you have been able to set
> it to t  in order to move around the log files?

WADR, that's a silly question.  This entire thread has been solely about
default settings, as are many discussions on the devlopers' mailing list.

However, the fact is that I didn't actually set line-visual-mode in any
Emacs before 23.  That suggests I either wasn't aware of this setting, or
the pain it caused me, whilst real, didn't cross some sort of (fairly
high) threshold.  I honestly can't remember any more.

When using Emacs as a full screen editor (how it's used most of the
time), a key binding is needed to go to the next/previous visual line.
Using C-p/C-n (or <up>/<down>) seems as good a choice as any.

> Cheers,
> Uday

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: line-move-visual

[Uday S Reddy]

Alan Mackenzie wrote:

> 
>> If line-move-visual was nil by default, would you have been able to set
>> it to t  in order to move around the log files?
> 
> WADR, that's a silly question.  This entire thread has been solely about
> default settings, as are many discussions on the devlopers' mailing list.

Sorry if it sounded silly.  The setting of the default to t was precisely 
targeted to help people like you.

Neither the setting nor the functionality existed before Emacs 23.  So, you 
didn't miss anything.  But, after having added this functionality, I think the 
developers believed that people like you might not have been able to discover 
the new functionality on your own, unless it was made the default.  Are you 
agreeing with that assessment?

Other than changing defaults, is there some other form of "advertising" the 
Emacs devs could have used to bring it to your attention?

Cheers,
Uday

Re: line-move-visual

[Tim X]

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

> Alan Mackenzie wrote:
>
>> It's far from obvious that this change (line-visual-mode being set) is a
>> Bad Thing.  Without it, moving around things like log files with 300
>> character lines was an utter pain.  I'd suggest it was more of a pain
>> than the one you're suffering, because it hit users using Emacs in its
>> principal way of working, rather than in special cases in some obscure feature
>> (keyboard macros).
>
> If line-move-visual was nil by default, would you have been able to set it to
> t in order to move around the log files?
>

This sentiment I agree with. The default for line-move-visual should
have been nil not t, especially as there are some things that still need
more thought (i.e. macros) and if for no other reason, to give
maintainers of other packages time to fix potentially broken code. 

The introduciton of this facility was in itself a good idea. How it has
been introduced was not.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Stefan Monnier]

> more thought (i.e. macros) and if for no other reason, to give
> maintainers of other packages time to fix potentially broken code. 

I don't know of any bug caused by this.


        Stefan "of course, it probably wouldn't have been reported to
                us, and often third-party package authors prefer to
                workaround problems than contact us to try and have them
                addressed"

Re: line-move-visual

[Stefan Monnier]

> I think keyboard macros are a potential source of problems.  Unless I'm
> missing somehting, a macro recorded while line-move-visual is enabled
> and then playedback when it is not could easily exhibit different
> behavior.

A keyboard macro only records the keys you hit.  So, not only the above
will do something odd, but if you record a keyboard macro in your foo.el
buffer and then play it back in a Dired buffer ... better make backups first.

> However, to what extent this potential issue would actually arise in
> reality is questionable. For one thing, most users are unlikely to be
> setting/unsetting line-move-visual frequently. Also, the same issue can

The problem with line-move-visual and keyboard macros, is that if you
record your macro on a piece of that text that fits just fine without
line-wrapping, and then play it somewhere where lines are wrapped, you
may find your macro doesn't do what you wanted any more.  In itself,
this is no big deal, but it's easy for people to forget (or to not know)
about this detail because line-movement has been "mostly logical" for
many years.


        Stefan

Re: line-move-visual

[Pascal J. Bourguignon]

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

>>> principal way of working, rather than in special cases in some obscure
>>> feature (keyboard macros).
>>      Keyboard macros are far from obscure.
>
> Indeed.
>
>>> And it was dashed near impossible to move easily to the middle of
>>> long, long lines.
>>      C-u <some number> right-arrow
>
> How convenient!
> Say you're in a window and want to go down 3 visual lines on the same
> long logical line.  What number do you use?  Ok, let's make it easier
> and say that you happen to know that the window is 76-chars wide.
> So 76 by 3? quick? quick?

240. You can refine later.

> Now let's do that again but with 13 lines, where you don't actually know
> it's "13": you first have to count it.

Let's say you can't even count the lines!

You can always, and only with emacs, type:

M-: (forward-char (/ (- (progn (end-of-line) (point)) (progn (beginning-of-line) (point))) 2)) RET


> The best I could come up with, is C-76 C-f and then C-x z z z ... until
> you reach the line.

> Now this all becomes a lot more interesting once you add word-wrap into
> the mix, or TABs, or bytes displayed \NNN, or the presence of various
> fonts and/or font-sizes on that long line, or variable-pitch fonts, ...

Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
cursor reaches the column you want, you don't even need to count
76.  And keep C-n pressed until the cursor reaches the line you want.


>         Stefan "who reached for the mouse in all those cases, tho
>                 typically only after first unconsciously hitting C-n
>                 a few times and then realizing that C-n jumped way
>                 further than intended"

WFM.  So far.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: line-move-visual

[Uday S Reddy]

On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:

>
> Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
> cursor reaches the column you want, you don't even need to count
> 76.  And keep C-n pressed until the cursor reaches the line you want.

Except that pressing control-key for that long with your pinky is a health risk!

But I feel this discussion is tangential.  Most of us accept that visual line 
movement is a /good/ idea and we find it useful in lots of contexts.  We are 
grateful for Stefan & co for thinking of it and implementing it.

The question is really whether it should have been made the default.

Every time I narrowed down to that issue in this thread, the participants have 
fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan 
himself).  I guess there is no good answer to it.

There is no need for us to beat a dead horse.  If the developers accept that it 
is a bad idea to introduce backward-incompatible changes for flimsy reasons, 
Emacs will be a more useful system for all of us than it currently is.

Fortunately, nothing major is going to fall apart as a result of `next-line' 
changing its meaning.  But I hope that we can arrest this trend right here so 
that we don't have to put up with more pain in future.

Cheers,
Uday

Re: line-move-visual

[David Kastrup]

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

> The question is really whether it should have been made the default.
>
> Every time I narrowed down to that issue in this thread, the
> participants have fallen silent (first Xah Lee then Tim Cross, Alan
> Mackenzie and Stefan himself).  I guess there is no good answer to it.

There is no simple answer.  And there is no point in working on the
aspects of a complex answer where it is not relevant.

The relevant place is the developer list.

> There is no need for us to beat a dead horse.  If the developers
> accept that it is a bad idea to introduce backward-incompatible
> changes for flimsy reasons, Emacs will be a more useful system for all
> of us than it currently is.

That's beating a dead horse, and an imaginary one as well.

> Fortunately, nothing major is going to fall apart as a result of
> next-line' changing its meaning.  But I hope that we can arrest this
> trend right here so that we don't have to put up with more pain in
> future.

You are not going to stop development of Emacs single-handedly, and you
will not be "arresting" any trend without working with developers when
the design decisions are being discussed and made.

Venting may be fun, but it will not change things.

-- 
David Kastrup

Re: line-move-visual

[Tim X]

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

> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
>
> The question is really whether it should have been made the default.
>
> Every time I narrowed down to that issue in this thread, the participants have
> fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
> himself).  I guess there is no good answer to it.
>

WTF. I believe I've responded to every single one of your posts directed
to me. 

I've lost count of how many times I've posted in this thread saying
that I DO NOT AGREE WITH IT BEING MADE THE DEFAULT. I agree with the
functionality and I agree with introducing changes that change the
existing semantics of next-line etc in order to provide the valuable
addition of visual line editing (which BTW I seem to remember you or
Mark rejecting outright). I suggest you need to take some of your own
advice and go back and read the posts again.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Stefan Monnier]

> Every time I narrowed down to that issue in this thread, the participants
> have fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
> himself).  I guess there is no good answer to it.

I did give you the answer: I tried it and found to my surprise that
I liked it, so I suggested it and people said "no way", then they tried
it and some people hated it, while others really liked it.

So in the end it was a judgment call, and I decided that the added
convenience of being able to deal with very-long-lines without having to
change mode was more important.  I.e. I decided that case 3 (in my
earlier long post about it) was less common and less important.


        Stefan

Re: line-move-visual

[David Kastrup]

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

>> Every time I narrowed down to that issue in this thread, the participants
>> have fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
>> himself).  I guess there is no good answer to it.
>
> I did give you the answer: I tried it and found to my surprise that I
> liked it, so I suggested it and people said "no way", then they tried
> it and some people hated it, while others really liked it.
>
> So in the end it was a judgment call, and I decided that the added
> convenience of being able to deal with very-long-lines without having
> to change mode was more important.  I.e. I decided that case 3 (in my
> earlier long post about it) was less common and less important.

I should think that changing to logical mode when recording and
replaying macros would be an improvement.  I can't imagine anybody
wanting visual mode in that case.

There is already one such change: vertical movement does not use vscroll
in order to go smoothly through vertical material when macro recording
or playback is active.

-- 
David Kastrup

Re: line-move-visual

[David Kastrup]

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

>> I should think that changing to logical mode when recording and
>> replaying macros would be an improvement.  I can't imagine anybody
>> wanting visual mode in that case.
>
> I remember we discussed it and somehow it got rejected.  I can't
> remember the reason for it, and I personally don't care much either way
> (my macros tend to use C-[aefb], and sexp-based movement but not much
> C-[np]).
>
>> There is already one such change: vertical movement does not use vscroll
>> in order to go smoothly through vertical material when macro recording
>> or playback is active.
>
> Didn't know about that.  Can you point me to the relevant piece of code?

See around the
	       ;; But don't vscroll in a keyboard macro.
comment in lisp/simple.el:

;; This is like line-move-1 except that it also performs
;; vertical scrolling of tall images if appropriate.
;; That is not really a clean thing to do, since it mixes
;; scrolling with cursor motion.  But so far we don't have
;; a cleaner solution to the problem of making C-n do something
;; useful given a tall image.
(defun line-move (arg &optional noerror to-end try-vscroll)
  (unless (and auto-window-vscroll try-vscroll
	       ;; Only vscroll for single line moves
	       (= (abs arg) 1)
	       ;; But don't vscroll in a keyboard macro.
	       (not defining-kbd-macro)
	       (not executing-kbd-macro)
	       (line-move-partial arg noerror to-end))
    (set-window-vscroll nil 0 t)
    (if line-move-visual
	(line-move-visual arg noerror)
      (line-move-1 arg noerror to-end))))


-- 
David Kastrup

Re: line-move-visual

[Leo]

On 2010-06-15 20:02 +0100, Alan Mackenzie wrote:

Let's forget about this line-move-visual. It has happened and just
turned it off in your site-start.el for good or even patch emacs source
locally to get rid of it. It was targeting potential new users.

I think what would be interesting is to clean up the mess in elisp. We
have cl and eieio that provide half-assed compatibility for common lisp.
Why not use the real thing instead by rebasing emacs onto common lisp
and gradually phase out elisp? That would bring in some good new users
to the community.

Leo

Re: Emacs language

[Leo]

On 2010-06-15 21:13 +0100, Teemu Likonen wrote:
> I think Common Lisp would be a great choice but I don't think there is
> much hope for it. It seems that Emacs developers want to use Guile
> (GNU's own Scheme implementation) instead. Guile aims to support Emacs
> Lisp but I believe that in practice it would be a quite much more
> backwards-incompatible change than line-move-visual=t. :-)

I just read the links you posted.

There are some people from guile camp strongly arguing for guile while
none of important figures in the common lisp camp does that. There were
at one episode discussing re-using the HyperSpec. I wouldn't entirely
rule out the possibility of common lisp.

Leo

Re: Emacs language

[Teemu Likonen]

* 2010-06-16 13:37 (+0100), Leo wrote:

> I just read the links you posted.
>
> There are some people from guile camp strongly arguing for guile while
> none of important figures in the common lisp camp does that. There
> were at one episode discussing re-using the HyperSpec. I wouldn't
> entirely rule out the possibility of common lisp.

Perhaps not completely but the political camp tends to win in FSF and
core GNU circles. In my opinion they sometimes they make stupid choices
because of politics. My bet is that the real options for Emacs language
are (1) continue to use (and possibly improve a bit) the current Emacs
Lisp or (2) switch to Guile.

Re: line-move-visual

[Uday S Reddy]

Alan Mackenzie wrote:

> 
>> You can set your own defaults in your .emacs to get the behaviour you
>> like and  so can all the other people.
> 
> This garbage again.  When we're talking only about the best settings for
> defaults, going on about .emacs is stupid.

Interesting.  When I raised the issue of defaults in the developers list, I was 
advised by Stefan to set my own default.  Apparently, he didn't think it was 
stupid to do so.

When I said this morning that you had fallen silent, my meaning was that you 
did not provide an answer.  Calling the question "silly" or "stupid" does not 
amount to an answer, does it?

Why don't you leave it to Stefan to speak for himself?  I am sure that Stefan 
and I are able to have a perfectly normal, professional conversation without 
your help.

Cheers,
Uday

Re: line-move-visual

[Alan Mackenzie]

In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote:
> Alan Mackenzie wrote:


>>> You can set your own defaults in your .emacs to get the behaviour you
>>> like and so can all the other people.

>> This garbage again.  When we're talking only about the best settings
>> for defaults, going on about .emacs is stupid.

> Interesting.  When I raised the issue of defaults in the developers
> list, I was  advised by Stefan to set my own default.  Apparently, he
> didn't think it was  stupid to do so.

Not whilst addressing somebody wearing a user's hat.  It's a stupid
distraction for the maintainers whilst pondering defaults.

> When I said this morning that you had fallen silent, my meaning was
> that you  did not provide an answer.  Calling the question "silly" or
> "stupid" does not  amount to an answer, does it?

It can do.  There are questions which can be used to derail a discussion,
should the questioner wish this.  I have a suspicion this is one of your
aims here.  If you're not trolling, then please accept my apologies and
carefully review your posts to see where that impression came from.

> Why don't you leave it to Stefan to speak for himself?  I am sure that
> Stefan  and I are able to have a perfectly normal, professional
> conversation without  your help.

Yet more snide remarks, yes?  I'm not going to rise to it this time.

> Cheers,
> Uday

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: line-move-visual

[Uday S Reddy]

On 6/16/2010 4:33 PM, Alan Mackenzie wrote:

>
> It can do.  There are questions which can be used to derail a discussion,
> should the questioner wish this.  I have a suspicion this is one of your
> aims here.  If you're not trolling, then please accept my apologies and
> carefully review your posts to see where that impression came from.

I wasn't trolling.  Apology accepted.

Cheers,
Uday

Re: line-move-visual

[Stefan Monnier]

> Judgment call is ok, and none of us can claim that we are perfect at that.
> But what concerns me is that after seeing all the discussion here, you still
> maintain that you "don't regret the decision" because a lot of people like
> it. So, are you opening Emacs to potentially unsafe changes in an effort to
> get people to like it?

Getting people to like Emacs is one of the goals, of course.  But I tend
to think more of "what would be the best settings for most users" (note
that I said "best", not "least controversial", nor "easiest to adapt
to").
Of course, this has to be balanced against "don't alienate existing
users" (which is also spelled "preserve backward compatibility of the
UI").

For the same kind of reason, Emacs-24 will change the way minor-modes
react when called with a nil argument (in Emacs-23, it toggles the mode,
in Emacs-24 it turns it ON unconditionally).  In this case, this doesn't
change the UI (when called interactively, the arg is never nil), but for
some users, their .emacs will end up doing something else than what they
intended.  This was deemed OK, because for many more users this change
will make their .emacs DTRT (i.e. it will silently fix a lurking bug in
their config), and it also makes it easier to add minor modes on hooks,
without having to rely on the existence of a turn-on-foo-mode or the use
of the more verbose (lambda () (foo-mode 1)).
I know some people will complain.  We always hear them a lot more than
those who benefit from such changes.

> You also haven't acknowledged that Emacs gets used as a platform on which
> other services are delivered, such as programming environments or mail
> clients.  Your response only touches upon the use of Emacs for personal text
> editing. Imagine, for instance, that your favourite mail client happened to
> use `next-line' instead of `forward-line' somewhere in handling the mail
> headers.

The byte-compiler flags this, luckily.

> It could damage the mail folders irretrievably over a period of time
> before it ever gets noticed.  Is that kind of trouble an appropriate
> price to pay for the "convenience" you talk about?

Every Emacs release brings in incompatibilities for Elisp code, many of
which aren't ever flagged by the byte-compiler.  So this particular
`next-line' change for Elisp code is but one of many other such
problems, and experience has shown it was not particularly serious.


        Stefan

Re: minor mode on/off/toggle with t/nil question

[Stefan Monnier]

> May i ask how does one toggle the mode in elisp code with the new
> scheme?

Here's one way:

   (foo-mode (if foo-mode -1 1))

it works with the new scheme as well as the old scheme.

> some question about elisp:  when calling a function interactively
> without any arg, how does emacs lisp engine distinguish it from with a
> nil argument?

The Emacs Lisp engine is only called after the `interactive' spec was
used to build the actual arguments.  So the interactive spec is set up
such that it doesn't pass nil but something else (e.g. `toggle').


        Stefan

Re: line-move-visual

[Alan Mackenzie]

In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote:
> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:

> But I feel this discussion is tangential.  Most of us accept that
> visual line  movement is a /good/ idea and we find it useful in lots of
> contexts.  We are  grateful for Stefan & co for thinking of it and
> implementing it.

> The question is really whether it should have been made the default.

Yes.  That is a very difficult question.  Most contentious issues
discussed on the developers' list are about changing defaults.  This was
one of these.

> Every time I narrowed down to that issue in this thread, the
> participants have  fallen silent (first Xah Lee then Tim Cross, Alan
> Mackenzie and Stefan  himself).  I guess there is no good answer to it.

Ooh, talk about trolling!  ;-)  I have "fallen silent" because I've
nothing much fresh to say.

> There is no need for us to beat a dead horse.  If the developers accept
> that it  is a bad idea to introduce backward-incompatible changes for
> flimsy reasons,  Emacs will be a more useful system for all of us than
> it currently is.

Normally I'd find myself arguing strongly in the camp of the
"traditionalists" when fighting over a change in defaults.  For this
particular change, I'm ambivalent.  The hassle with directly editing long
lines is, I believe, more painful than that of navigating keyboard macros
through them.  Somebody had to decide this issue, and that somebody was
Stefan.  I think, on balance, he made the right choice.  I wouldn't have
been complaining if he had decided the opposite.

> Fortunately, nothing major is going to fall apart as a result of
> `next-line'  changing its meaning.  But I hope that we can arrest this
> trend right here so  that we don't have to put up with more pain in
> future.

"Trend"?  You are getting polemic!  Emacs will continue to evolve
steadily, and some of the changes will cause you minor pain, as they will
me.  You're surely used to tweaking your .emacs on every major release,
so what's new?

> Cheers,
> Uday

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: line-move-visual

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote:
>
>> Every time I narrowed down to that issue in this thread, the
>> participants have fallen silent (first Xah Lee then Tim Cross, Alan
>> Mackenzie and Stefan himself).  I guess there is no good answer to
>> it.
>
> Ooh, talk about trolling!  ;-)  I have "fallen silent" because I've
> nothing much fresh to say.

Huh? Did you think that a discussion involves anything apart from
everybody repeating himself until all but one have given up?

Are you old-fashioned or what?

-- 
David Kastrup

Re: line-move-visual

[Xah Lee]

On Jun 15, 1:42 am, Uday S Reddy <uDOTsDOTre...@cs.bham.ac.uk> wrote:
> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
>
>
>
> > Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
> > cursor reaches the column you want, you don't even need to count
> > 76.  And keep C-n pressed until the cursor reaches the line you want.
>
> Except that pressing control-key for that long with your pinky is a health risk!
>
> But I feel this discussion is tangential.  Most of us accept that visual line
> movement is a /good/ idea and we find it useful in lots of contexts.  We are
> grateful for Stefan & co for thinking of it and implementing it.
>
> The question is really whether it should have been made the default.
>
> Every time I narrowed down to that issue in this thread, the participants have
> fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
> himself).  I guess there is no good answer to it.

i find it great that line-move-visual defaults to t. And i find it
good that nothing else is changed about Ctrl+n, with the result that
it just move lines visually in emacs 23.x. All things considered. I
thought about it for a while when you presented a perspective of what
we are arguing about. But the more i think about it, the more the
conclusion above.

i find many discussions here silly... writing here takes a lot time.
Typically, just 2 posts take out the whole day. Same as elsewhere in
mailing lists or private communication with co-workers in a company...
Answering a few emails or exchanging opinions takes out the whole
day...

i find it silly that Mark Crispin insists this is so bad or breaks
backward compatibility or his attacks on commercial software and
opinions on certain “FOSS” or “FUD” jargons ... etc. It'd be endless
flame war to argue one way or another. Usually fruitless.

but i enjoyed the thread anyway. I enjoyed having to cite my essays,
enjoyed knowing about Mark Crispin, enjoyed to have learned who
contributed the code for the line-move-visual feature. (in fact spent
a hour or two to link to home pages of all i found who contributed
major features in 23.x) If i have more time at leisure, i'd sure enjoy
throwing flames to annoy Mark and few of you acquaintances. LOL.

maybe we can start another flamewar of a diff subject. I'm quite
annoyed that emacs 23.2 has chosen the trivial espresso mode as the
javascript mode and screwed Steve Yegg's far much ambitious, talented,
and revolutionary and modern and WORKING js mode the js2-mode that
includes a on-the-fly js language parser. I attribute it to the now
bureaucratic inefficiency of gnu.org management... i was on the gnu
dev list when this thread was discussed, was rather pissed that the
espresso mode author young 20 something bigshot talking shit about how
emacs font lock myth this or that. I can write a espresso mode myself
in a day. But i doubt most who have coded elisp for 10 years can pull
off Steve's js2-mode. Not me.

  Xah
∑ http://xahlee.org/

☄

espresso-mode (was: line-move-visual)

[Stefan Monnier]

> maybe we can start another flamewar of a diff subject. I'm quite
> annoyed that emacs 23.2 has chosen the trivial espresso mode as the
> javascript mode and screwed Steve Yegg's far much ambitious, talented,
> and revolutionary and modern and WORKING js mode the js2-mode that
> includes a on-the-fly js language parser. I attribute it to the now
> bureaucratic inefficiency of gnu.org management... i was on the gnu

Haha!
We first installed Steve's js2-mode, and then some people complained
about missing features, then a long thread ensued, which ended up with
"let's merge the two" and that this was to be made by switching to
espresso and then adding js2's features to it (at least that's my
recollection, and Steve was part of that decision).
Of course, the "add js2's features" part hasn't materialized.


        Stefan

Re: line-move-visual

[Xah Lee]

On Jun 15, 3:27 pm, Thad Floryan <t...@thadlabs.com> wrote:
> On 6/15/2010 1:42 AM, Uday S Reddy wrote:
>
> > On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
>
> >> Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
> >> cursor reaches the column you want, you don't even need to count
> >> 76.  And keep C-n pressed until the cursor reaches the line you want.
>
> > Except that pressing control-key for that long with your pinky is a
> > health risk!
> > [...]
>
> That's why remapping the [Caps Lock] to be a [Ctrl] is very useful.
>

swapping Caps Lock with Ctrl is not good.

• Why You Should Not Swap Caps Lock With Control
  http://xahlee.org/emacs/swap_CapsLock_Ctrl.html

plain text version follows:
------------------------------------------------------------------------

Why You Should Not Swap Caps Lock With Control

Xah Lee, 2008-07-10

Swapping the Caps Lock key with the Control key is one of the bad
advice in keyboarding. It's one of the myth that perpetuate bad
practice. It does damage to your finger's health. Here are the reasons
why:

    * On a typical PC keyboard of today, the Caps Lock is the most
difficult modifier key to press, and is pressed by the weakest finger
pinky. The Control key can be easily pressed with palm.
    * It makes the left pinky do 2 pinkies's work. (try to pick out
your right Shift key and type for a week and see how you feel)
    * It forces the left hand to strain into spider legs positions.
Or, it forces your right hand to flies about wildly if the letter key
is near the middle of the keyboard (example: CapsLock+T, CapsLock+G,
CapsLock+B).
    * It renders many Ctrl+‹key› spots void, since now with only one
pinky many otherwise good Ctrl+‹key› spots are hard to use.
    * The left hand now constantly shift from home position.

The above assumes that you do TOUCH TYPE. If you do not touch type,
you really need to learn that first before you can talk about hand
health.

The above also assumes that you are using a full sized keyboard, not
the keyboard on laptops. If you are stuck with a laptop computer keys,
then you need to get a full PC keyboard first. Prolonged typing on
laptop sized computer is sure way to damage your hands.

--------------------------------------------------
Good Tips

    * If you use the Ctrl key much more frequently than Alt, then do
swap them. Because, Alt is much easy to press, with the thumb. (See:
How To Swap Caps Lock, Alt, Control Keys On Windows, How to Swap
Modifier Keys on OS X)
    * Buy a keyboard with Control on both sides of keyboard.
    * Buy a keyboard such that the modifier keys are placed
symmetrically with respect to F and J keys. (That is, the distance
between Left Control to F should be the same as right Control to J.)
    * Press modifier keys using both hands, in the same way of using
Shift key in touch typing. If the letter is on the left side, use the
Ctrl key on the right side, and vice versa.
    * On most full sized PC keyboard, it's very easy to use palm or
semi-fist to press Control key. Do this and save the Pinky.


--------------------------------------------------
Why You Should Not Swap Caps Lock With Control

Among tech geeking circles, it's widely recommended like a dogma, to
swap Caps Lock and Ctrl keys. However, remapping Control to Caps Lock
seriously violates some basic ergonomic principles.

In touch typing, modifiers comes in pairs, such as Shift. The accepted
ergonomic way to press them is using one hand to press the modifier
and the other to press the letter key.

You can see how it is otherwise by disabling one of the Shift key.
With just one modifier, you are heavily handicapped. As a example, try
this exercise:

TYPE THIS SENTENCE WITH ONLY THE LEFT SHIFT KEY AND WITHOUT USING CAPS
LOCK.

Quickly, you'll see the pain.

Similar is with other modifier keys such as Alt and Ctrl. The reason
they are not noticed only because they are seldom used. However, in
emacs, it is heavily used. So, by mapping Ctrl to the Caps Lock key,
you put a severe handicap by putting all work into the left pinky, and
restrict the number of keys you can comfortably use with Ctrl.

The reason that many tech geekers still recommend it is because the
Ctrl key is traditionally on the corner of keyboard and rather
difficult to press. Also, many keyboards does not have right Ctrl. So,
in a sense, Caps Lock as Ctrl is a improvement. It is especially a
good solution on laptop's keyboards.

There are 2 ways to remedy the problem of pressing of Ctrl.

One is to buy a good keyboard that has big Alt and Ctrl keys, and on
both sides of the keyboard, and symmetrically placed with respect to
your thumbs when hands in home position. (some keyboards, such as
Apple keyboard, has the right side modifiers far to the right,
rendering them unusable for touch typing) Microsoft's ergonomic
keyboard are very good with respect to this, and also vast majority of
generic PC keyboards.

The other way is to learn to type the corner Ctrl by pressing down
your palm or semi fist, instead of poking it with your pinky. This can
be comfortably done on most PC keyboards. (See: photo of generic PC
keyboard)

To see which is better, you can type this sentence and press Ctrl for
every letter. (do it outside of emacs) You can quickly find out which
way is better for you.

The above assumes you touch type. If you don't, some tips may not
apply, and you really should learn touch typing first.

--------------------------------------------------
Anecdotes vs Ergonomics

Joel wrote: «... do not use two fingers on the same hand at the same
time, except in emergencies. ...».

YSK wrote: «Seriously? I do this all the time. Some of my favorite
(non-emacs) shortcuts include stuff like C-M-S-e, all done with my
left hand. Is that bad?».

--------------------------------
One Modifier Key

Yes and no. In general, if you just have one modifier key and one
letter key, the proper touch typing guidline is to use one hand on the
modifier and the other on the letter. Choose the modifier on the other
side of the letter key.

You can test this out.

Try to type this whole sentence in captical letters (but without using
Caps Lock).

First, try it using just the left Shift key. Then try it using the
touch type guidline as above. You'll see how using single hand creates
pain. Similarly, you can try the above with the Control key as
modifier.

--------------------------------
Multiple Modifier Keys

When you have multiple modifier, it gets a bit more complex and the
rule applies less. Ultimately, there are several factors involved. For
example, the keyboard hardware is not well designed due to historical
reasons. (See: Keyboard Hardware Design Flaws) Secondly, many
keyboards such as Apple's that has the right hand side's modifier far
to the right, making them less usable for touch type. Lastly, the
principles of ergonomics presumes you are doing the task repeatitively
for a prolonged time. Else it doesn't apply. For example, for vast
majority of computer users (say 95%), they only type maybe for 1 hour
per day, and there's not much activity of continued typing more than 5
min. Lots of professional programers don't even touch type; partly
because heavy duty data-entry is not really part of programing.

And when it comes to Control key, or multiple modifiers, they are not
used that much often, so whichever works for you is ok. However, this
does not mean it's completely a personal issue without any scientific
criterion on what is better. For example, of all the styles and
anecdotes you hear about how you should press modifier, you can easily
test them out and find the better one, by say, force yourself to
continuously operate it for 10 min using one way, then do the same
test with another way. You'll quickly see which one is more tiring and
which is faster with less effort.

  Xah
∑ http://xahlee.org/

☄

Re: line-move-visual

[Thad Floryan]

On 6/15/2010 3:45 PM, Xah Lee wrote:
> On Jun 15, 3:27 pm, Thad Floryan <t...@thadlabs.com> wrote:
>> On 6/15/2010 1:42 AM, Uday S Reddy wrote:
>>
>>> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
>>>> Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
>>>> cursor reaches the column you want, you don't even need to count
>>>> 76.  And keep C-n pressed until the cursor reaches the line you want.
>>> Except that pressing control-key for that long with your pinky is a
>>> health risk!
>>> [...]
>> That's why remapping the [Caps Lock] to be a [Ctrl] is very useful.
>>
> 
> swapping Caps Lock with Ctrl is not good.
> 
> • Why You Should Not Swap Caps Lock With Control
>   http://xahlee.org/emacs/swap_CapsLock_Ctrl.html
> [...]

Your opinion which neither I nor 100,000s of others share -- you stand alone.

A [Ctrl] to the left of [A] is natural and what I've been using since the
mid-1960s with absolutely NO problems or RSI whatsoever beginning with a
TTY ASR33 and continuing with a Datapoint 3300, DEC VT100, Datamedia DT80
and others along the way to today.

Mapping and using the [Caps Lock] as a [Ctrl] to the immediate left of [A]
is no different than the ["] to the immediate right of [;] re: pinkies.

The (dumb) PC standard of a [Ctrl] key at the lower-left of a keyboard is
ridiculous and WILL cause pinky problems if one uses Emacs as an editor and
bash as a shell.

Re: line-move-visual

[Evans Winner]

,------ Thad Floryan wrote ------
|   Your opinion which neither I nor 100,000s of others
|   share -- you stand alone.

Not alone.  I've read similar advice in the past.

What I would like to try is a situation in which holding
down SPC and then hitting something else causes SPC to act
like Control.  But if nothing is hit along with SPC then it
sends a Space character on key-up.  Obviously this would
have the drawback that one could not get repeated spaces by
holding down the space key, but I would like to at least
experiment with it.  I don't know if it is possible to map
the keys that way, though.  I've looked into it a bit, but
not figured it out.

Failing that, I do use Caps-Lock and Control swapped and
have for some time.  It doesn't seem terribly harmful to me.
The idea of palming the Control key is interesting, but it
seems as if it would require tiny hands to really do
comfortably.  For me, I do have to move my hands awkwardly
from the home row to do that, whereas I don't really have to
move from the home row to hit the key to the left of `A'.
Maybe it was all the piano playing back in the day, but my
fifth finger moves the slight bit sideways pretty fluently.

Re: line-move-visual

[Xah Lee]

On Jun 15, 8:30 pm, Evans Winner <tho...@unm.edu> wrote:
> ,------ Thad Floryan wrote ------
> |   Your opinion which neither I nor 100,000s of others
> |   share -- you stand alone.
>
> Not alone.  I've read similar advice in the past.
>
> What I would like to try is a situation in which holding
> down SPC and then hitting something else causes SPC to act
> like Control.  But if nothing is hit along with SPC then it
> sends a Space character on key-up.  Obviously this would
> have the drawback that one could not get repeated spaces by
> holding down the space key, but I would like to at least
> experiment with it.  I don't know if it is possible to map
> the keys that way, though.  I've looked into it a bit, but
> not figured it out.
>
> Failing that, I do use Caps-Lock and Control swapped and
> have for some time.  It doesn't seem terribly harmful to me.
> The idea of palming the Control key is interesting, but it
> seems as if it would require tiny hands to really do
> comfortably.  For me, I do have to move my hands awkwardly
> from the home row to do that, whereas I don't really have to
> move from the home row to hit the key to the left of `A'.
> Maybe it was all the piano playing back in the day, but my
> fifth finger moves the slight bit sideways pretty fluently.

whether you can use the palm edge to hit control key depends on your
keyboard of course.

On vast majority of generic PC keyboard, that can be trivially done,
regardless if you have large or small hands.

You can see picts of several keyboards here, including a generic PC
one that's usually just $6.

• Computer Keyboards Gallery
  http://xahlee.org/emacs/keyboards.html

you can also see a pict and video of the Daz Keyboard, which follows
the standard generic PC keyboard shape:

• The Idiocy of Hacker Keyboards
  http://xahlee.org/emacs/keyboards_hacker_idiocy.html

you can also see the classic IBM keyboard there with its huge Control
key.

it is so easy to hit with the palm. Just push down your palm and you
hit it. Almost easier than pressing keys with index finger on the home
row.

 Xah

Re: line-move-visual

[Chris F.A. Johnson]

On 2010-06-15, Thad Floryan wrote:
...
> The (dumb) PC standard of a [Ctrl] key at the lower-left of a keyboard is
> ridiculous and WILL cause pinky problems if one uses Emacs as an editor and
> bash as a shell.

   I have no problems using the Ctrl keys (left and right) with emacs
   and bash.

   I also have the CapsLock key as Ctrl, but I never use it; the
   change is mostly to disable CapsLock, which I have never used, and
   which is annoying when hit accidentally.

-- 
   Chris F.A. Johnson, <http://cfajohnson.com>
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Keyboard Hardware's Influence on Keyboard Shortcut Design

[Xah Lee]

Extended my post from this thread.

• Keyboard Hardware's Influence on Keyboard Shortcut Design
  http://xahlee.org/emacs/keyboard_hardware_and_key_choices.html

plain text version follows.
----------------------------------------------------------------------

Keyboard Hardware's Influence on Keyboard Shortcut Design

Xah Lee, 2010-06-16

In my study of keyboarding in the past 20 years, i've noticed that the
choices of many shortcuts in many apps are adopted to the many aspects
of the keyboard hardware of the time in use by the community. Emacs's
keybindings are not simply based on the first letter of commands, but
the qwerty layout's key positions have significant influence on it.
This also applies to the letter choice of unix's shell commands. Much
of this influences of design are unconscious.

--------------------------------------------------
Emacs's Meta and Control

As a example, emacs's notion of “Meta”, and heavy use of Control as
primary modifier, and avoiding any Ctrl+Shift+‹letter› in its keyboard
shortcuts, are caused by the lisp keyboard hardware and dumb terminals
of 1980s.
lisp-machine-keyboard-2-left

Symbolics's lisp machine keyboard PN 365407 Rev C. full keyboard❐.
right side close up❐. Photo by Joey Devilla. Used with permission.

For detail, see: Why Emacs's Keyboard Shortcuts Are Painful.

--------------------------------------------------
vi's Esc key and J K H I

Unix vi's use of j k h i for cursor movement, and the choice of Esc
key for mode switching, came from the keyboard it was developed on,
the ADM3A terminal.
terminal ADM3A vi

The ADM3A terminal. Source
terminal ADM3A keyboard layout

The ADM3A terminal's keyboard layout. Source

--------------------------------------------------
Gaming's W A S D

The gaming's convention of W A S D for character movement keys, is
also shaped by the PC keyboard's physical key layout used at the time.

Most people need to use the right hand for the mouse for operating a
gun or view, this leave the left hand for the less accuracy intensive
task of controlling the character.

This leaves the physical arrow keys, but those have some problems. The
arrow keys are on the right side of the keyboard, making it awkward to
use with left hand. So, some inverted T cluster of keys on the main
section of the keyboard is chosen.

But why not say

   E
 S D F

keys? They are in the standard typing position. Instead, W A S D is
more suitable, because W A S D is on the neighbor of Caps Lock, Tab,
Shift, Control, Alt, that gamers needs to use for Firing, Shield,
Jump, change weapon, etc. So, W A S D becomes the convention.

Also note that the common layout is QWERTY. W A S D is inverted T on
QWERTY layout. For those using the The Dvorak Keyboard Layout, the W A
S D keys are scattered and is a problem. In fact, in the early days,
many games do not respect user's choice of key layout in Operating
System, nor does it provide ways for users to change the keys. Even
today, some game software still have this problem, notably Second
Life. (In the early days, say mid 1990s, Operating systems such as
Windows hardly have a consistent keyboard layout API for programers)

--------------------------------------------------
The X C V for Cut Copy Paste

Another history is the convention of X C V keys for Cut Copy Paste.
This came from Apple.

Apple computer, in the late 1980s and early 1990s, popularized the
undo, cut, copy, paste concepts, and in general the computer keyboard
shortcuts concept. These keys are chosen because they are all adjacent
and on the left side of the keyboard. Also in this set are Quit (q),
Close (w), Select All (a), Save (s), Duplicate (d), and Undo (z). The
only exceptions are Open (o) and Print (p) on the right side of
keyboard.

Q W
 A S D
 Z X C V

All these keys have become universally the standard on about all
applications on Windows, Mac, Linux today, possibly except the Z for
undo and D for Duplicate.

See: Cut, copy, and paste.

--------------------------------------------------
Windows's PrtScn/SysRq for Screenshot

On today's PC keyboard, you'll find quite a few relic keys. PrtScn/
SysRq, ScrLk, Pause/Break, Insert. They used to have meaningful
purposes in the 1980 or earlier, some of them are separate keys. But
computer hardware changes, and software changes, dramatically over the
past 20 years. Keyboard itself does not change as fast. So, these keys
became defunct. Because the key name PrtScn somewhat relates to
screenshot capture, so Windows has chose it to be the key for saving
screenshots. Similarly, the “Backspace” key, was chosen as browser's
back to previous page shortcut. Note that this key is labeled “Delete”
on Apple's keyboards, even they sent the exact same signal. In Apple's
operating system, in Mac Classic of the 1990s or Mac OS X since early
2000s, this key was not used for browser's back function, only so in
mid 2000s when Apple started to adopt many Windows's conventions.

See also: Difference Between Apple and PC keyboards.

--------------------------------------------------
Conclusion?

If there's any conclusion, it is that many keyboard shortcut or hotkey
choices are based on what is practical at the time. Issues of logical
design, ergonomics, consistency, efficiency, are less important when
it conflict with practicality. Some of these concept didn't even exist
at the time, and some choices was good at the time but computer
keyboard has changed long since.

In retrospect, many of the choices are not the best today. For
example, qwerty layout was practical at the time, but the Dvorak
Layout was invented too late, when a convention was already
established, and ergonomics isn't as big a concern at the time since
not that many people need to use typewriters, but typing on computer
is done by everyone today, and programing have become a field that's
some million times more than the number of typists in the past.

Emacs's primary modifier the Ctrl is much better at the Alt position
on today's PC keyboards.

“vi”'s Esc might be better today at PC keyboard's Alt or Caps Lock.
“vi”'s H J K L is still pretty good, but arguably better with:

   I
 J K L

The QWERTY really should be Dvorak today.

The defunct keys, Insert, ScrLk, Pause, Break, really should be gone.
There needs to be keys to switch to previous next app/window/tab, or
toggle Show/Hide current window. The Num Lock on the number keypad
also is a relic, from a time long past that keyboards doesn't have
dedicate arrow keys and Page up/down Home/End etc keys.

  Xah
∑ http://xahlee.org/

☄

Re: line-move-visual

[Stefan Monnier]

> The above assumes that you do TOUCH TYPE.  If you do not touch type,
> you really need to learn that first before you can talk about hand
> health.

Another way to look at it: if you have hand-health problems, first try
to unlearn to touch-type.


        Stefan "who doesn't touch type"

Re: line-move-visual

[Stefan Monnier]

> I would be very interested if you were willing to expand on this.
> Do you mean to say that touch typing is unhealthy in general, or just
> more pragmatically that if it hurts when you do X, then don't do X?

Just that I've known several people who suffered from RSI and several
people who can't touch-type and the two sets are disjoint.
A correlation between the two is expected (people who type a lot are
more likely to know how to touch-type), but the fact that the two sets
are actually disjoint is I think more than a coincidence.

If you look at people who don't touch-type (like me), you'll see their
hands move a lot, so their arms work more and their hands and fingers
work less.


        Stefan

Re: line-move-visual

[Chris F.A. Johnson]

On 2010-06-17, Stefan Monnier wrote:
>> I would be very interested if you were willing to expand on this.
>> Do you mean to say that touch typing is unhealthy in general, or just
>> more pragmatically that if it hurts when you do X, then don't do X?
>
> Just that I've known several people who suffered from RSI and several
> people who can't touch-type and the two sets are disjoint.
> A correlation between the two is expected (people who type a lot are
> more likely to know how to touch-type), but the fact that the two sets
> are actually disjoint is I think more than a coincidence.
>
> If you look at people who don't touch-type (like me), you'll see their
> hands move a lot, so their arms work more and their hands and fingers
> work less.

   The home position for a touch typist is an awkward one, and, I
   suspect, contributes significantly to wrist problems.

   I've been using a typewriter for 50 years, and for the last 30 I
   have almost lived at one, both at work and at home, but still don't
   touch type. I have had no problems with my wrists.

-- 
   Chris F.A. Johnson, <http://cfajohnson.com>
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Re: line-move-visual

[Uday S Reddy]

On 6/16/2010 8:55 PM, Evans Winner wrote:
> ,------ Stefan Monnier wrote ------

>
> |   Another way to look at it: if you have hand-health
> |   problems, first try to unlearn to touch-type.
>
> I would be very interested if you were willing to expand on
> this.  Do you mean to say that touch typing is unhealthy in
> general, or just more pragmatically that if it hurts when
> you do X, then don't do X?

As somebody that does touch typing and have had heavy RSI problems, I can throw 
some light on this.

Touch typing is perfectly fine normal text, but it wasn't designed for Emacs. 
The heavy use of the little finger for Control and Meta keys puts undue load on 
it.  Keyboards that had single Control or Meta keys worsened the problem by 
making the hands stretch over long distances.

As part of my recovery from RSI, I had to retrain myself to avoid the use of 
Control/Meta keys for long periods (for instance by using the arrow keys or the 
mouse), and also to get away from the "home position" when needed so that I can 
use other fingers for Control/Meta keys.

I am now perfectly fine for typing normal text, but I get sore tendons when I 
have to do TeX/LaTeX.  They make a heavy use of '\' which is placed on lousy 
positions on most keyboards.

Cheers,
Uday

Re: line-move-visual

[B. T. Raven]

Uday S Reddy wrote:
> On 6/16/2010 8:55 PM, Evans Winner wrote:
>> ,------ Stefan Monnier wrote ------
> 
>>
>> |   Another way to look at it: if you have hand-health
>> |   problems, first try to unlearn to touch-type.
>>
>> I would be very interested if you were willing to expand on
>> this.  Do you mean to say that touch typing is unhealthy in
>> general, or just more pragmatically that if it hurts when
>> you do X, then don't do X?
> 
> As somebody that does touch typing and have had heavy RSI problems, I
> can throw some light on this.
> 
> Touch typing is perfectly fine normal text, but it wasn't designed for
> Emacs. The heavy use of the little finger for Control and Meta keys puts
> undue load on it.  Keyboards that had single Control or Meta keys
> worsened the problem by making the hands stretch over long distances.

Either Keytweak (w32) or xmodmap (Gnu-Linux) can swap all modifier (or
most other) keys. An important consideration in the keyboard layout is
that it be strictly bilaterally symetrical, so that modifier keys are
used exactly the way shift keys are. E.g. Right-shift, a to make A,
right-control, a to go to beginning of line, and the same for all other
combos: right-control x left-control f to find-file. [On Dvorak
layout]It may sound unworkable until you try it. Bottom row is (left to
right) super, alt, ctl spacebar ctl, alt, super. Even more comfortable
would be slpit spacebar with backspace on left half. Since the process
of moving a tiny plastic dome down 1/4 inch doesn't require any vigorous
motion (unlike for instance in playing the piano) it might even be
useful to move the shift key between ctl and left-space-bar (backspace).
This could be accomplished by stealing from space-bar real estate and
moving it half a key to the right. This optimum (for me anyway) layout
would be:

Super[1] Alt[1] Ctl[1] Shift[1] Backspace[2] Space[2] Shift[1] Ctl[1]
Alt[1] Super[1] (Numbers are widths in standard alpha keywidth units)

Now all modifier keys are on the same row and the keyboard can be played
instead of worked. Remember, the key justs sends a scancode; it doesn't
have to move any heavy metal around.

> 
> As part of my recovery from RSI, I had to retrain myself to avoid the
> use of Control/Meta keys for long periods (for instance by using the
> arrow keys or the mouse), and also to get away from the "home position"
> when needed so that I can use other fingers for Control/Meta keys.

But the RSI is caused either by a key layout inappropriate to the
application or by grueling gruntwork like typing from hard-copy, data
input, or dictaphone transcription. If a sane keyboard layout is a
temptation to work too hard then we'll just have to add a subroutine to
get out of the chair every 15 minutes to say prayers, thumb wrestle, or
what have you.


> 
> I am now perfectly fine for typing normal text, but I get sore tendons
> when I have to do TeX/LaTeX.  They make a heavy use of '\' which is
> placed on lousy positions on most keyboards.

Try putting |\ on the Caps Lock key. The dash-underscore is already in a
good place for Emacs on the Dvorak layout. In my dream keyboard (vide
supra) the open and close parentheses could be mapped to Right-Shift
back-space and Left-Shift Space, respectively. Such a keyboard would
cost about $5 to manufacture and would be worth $200 to me.

Ed



> 
> Cheers,
> Uday
> 
> 

Re: line-move-visual

[B. T. Raven]

Stefan Monnier wrote:
>>> principal way of working, rather than in special cases in some obscure
>>> feature (keyboard macros).
>>      Keyboard macros are far from obscure.
> 
> Indeed.
> 
>>> And it was dashed near impossible to move easily to the middle of
>>> long, long lines.
>>      C-u <some number> right-arrow

Or more conveniently:

C-s <some chars> [C-s ad libitum] RET

> 
> How convenient!
> Say you're in a window and want to go down 3 visual lines on the same
> long logical line.  What number do you use?  Ok, let's make it easier
> and say that you happen to know that the window is 76-chars wide.
> So 76 by 3? quick? quick?
> Now let's do that again but with 13 lines, where you don't actually know
> it's "13": you first have to count it.
> The best I could come up with, is C-76 C-f and then C-x z z z ... until
> you reach the line.
> 
> Now this all becomes a lot more interesting once you add word-wrap into
> the mix, or TABs, or bytes displayed \NNN, or the presence of various
> fonts and/or font-sizes on that long line, or variable-pitch fonts, ...
> 
> Clearly visual line movement is really handy in such long lines.
> So rather than "C-u <some number> right-arrow", the better answer would
> have been: M-x visual-line-mode RET C-n ...
> 
> 
>         Stefan "who reached for the mouse in all those cases, tho
>                 typically only after first unconsciously hitting C-n
>                 a few times and then realizing that C-n jumped way
>                 further than intended"

Or, since text editors are trying to wean themselves of everything that
smacks of word processing, it might be better to follow Mark Crispin's
suggestion to make line-move-visual default to nil and to bind the up
-down arrow keys to long-lines navigation.

Ed

Re: line-move-visual

[Tim X]

Mark Crispin <mrc@panda.com> writes:

> On Thu, 10 Jun 2010, Uday S Reddy posted:
>> By community ownership, I only mean that all the people that have a stake in
>> the system have a voice in the matter and we all feel ownership of the
>> system.  When the community is divided, as seems to be the case on this
>> issue, the developers have to make a decision and move on.
>
> The problem is that nobody ever asked the existing users whether or not they
> wanted this global change foisted upon them.  Rather, it was done
> unilaterally, and the individuals responsible are saying "See!  Some people
> like it!  It was a good change."
>

This is not really correct. The change was discussed in a forum that is
open to anyone who is interested. More accurately, a criticism could be
that it wasn't discussed in the correct forum. However, that in itself
is extremely difficult to identify. For example, how would most of the
users feel if every discussion regarding emacs development, even if
restricted to discussions that directly impact on basic/core behavior
(however that would be defined). was posted to this list? I suspect that
many would be irritated as this is supposed to be an emacs help forum,
not a discussion forum for developments.

A possible solution would be to ensure a page is maintained on the emacs
wiki that discussed some of the proposed developments, especailly those
that may be contentious. A regular post could go to this list pointing
to the relevant page. This would possibly let those who are interested
know about propsed changes and enable them to participate. 

Of course this won't reach everyone and there will still be some who are
surprised by changes and possibly get upset. This is unavoidable. All
that can be done is to make it clear what forums are available and try
harder to get wider discussion, particularly with changes that are
likely to have a big impact. 

> This sort of thing happened in the past as well.  The difference was that
> there was accountability in the past that is absent today.
>
>> In my humble opinion, it is easy to argue that the current default was
>> ill-chosen.  But it is not so easy to argue that it should be changed.  If
>> we change it, then we face all the same issues all over again affecting the
>> other users that are depending on the current default.  So, it seems best to
>> leave things as they are and make a note of all the lessons learned.
>
> I agree that we are probably screwed, and royally so.
>
> I have a new task on my list: replace emacs in the procedures for my target
> audience since emacs is no longer suitable for that purpose.  I simply can not
> tell these users "make sure that you set line-move-visual to nil"; they would
> have no clue what that means.  More likely than not, I will end up being
> obliged to write a program for the task; and there will be one less way those
> users will be exposed to emacs.
>

Why not just set it back to its previous default in a site startup file?
Most distributions already have one of these - all that is required is a
single line!

> One of the advantages of the "software tools" mindset of the past was that you
> did not have to write a program for every task.  Instead, you could leverage
> the existing tools.  That falls apart when those tools are corrupted so that
> they no longer can be relied upon to produce predictable results.
>
>>> But even the laymen become power-corrupted.
>> I think that is a bit of an exaggeration.  They have a responsibility to
>> bear and sometimes they get carried away.
>
> Every young programmer wants to put his own mark on things.  The problem is
> that these changes are frequently ill-considered and sometimes have bad
> consequences.
>

Even well considered changes can have bad consequences. Hindsight is a
wonderful thing!

This personal attack you continue to make on the developers is very
tiresome. Emacs is developed by a large range of people. They vary in
age, vary in location and native language and vary in experience. Not
many of them are regular posters to this list. You seem to be under the
illusion that the developers are some closed powerful group sitting in a
room somewhere together making random changes. GNU Emacs is open to
anyone who wants to get involved. Patches and improvements come from all
over the place - some are minor, some are major, some accepted and some
rejected. Changes are discussed in an open forum that anyone can
participate in. 

Valid points have been raised regarding the change in default behavior
and possibly the developers may consider ways to improve discussion and
communication (though I'm not sure how aware they are since this
discussion has occured largely on the wrong forum). Nothing is gained by
continued attacks. If you still feel the need to whinge, then perhaps
you might show the backbone to actualy make your accusations to the
developers and perhaps both get some real facts and just possibly
contribute to improving how future changes are handled. 


>>> Since user interface surprise is a barrier to upgrade, they make sure there
>>> aren't any such surprises.
>> Yes, that point is well-made.  But, the same argument now suggests that the
>> default should not be changed yet again.
>
> Yup.  We're probably screwed.
>

Your arguments all suggest an environment where interfaces never change.
This just doesn't exist and never has. Frequently improvements and new
functionality require changes to existing interfaces, both programming
and user. This is the reason most programs have a major and minor
revision number. It gives an end user an idea of how the program may
have changed. It is also why any professional setup will put new
software through evaluation and testing before putting it into
production. This can result in considerable maintenance overheads, but
cannot be avoided. It is also why many vendors, such as Red hat and
Ubuntu provide versions that are extremely stable and supported for
extended periods of time where the only changes/updates are for critical
security fixes. As a professional, I'm sure, when deciding to upgrade a
major version of some key software, you checked out the release notes to
familiarise yourself with what has changed and any known problems and
used this information to formulate your test plan that wold ensure no
nasty surprises in your production environments. Luckily, the emacs
developers made sure this was all clearly documented and where the
changes involved modified defaults, clearly explained how to reset tot
he previous default. 


Tim


-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Evans Winner]

,------ Tim X wrote ------
|   For example, how would most of the users feel if every
|   discussion regarding emacs development, even if
|   restricted to discussions that directly impact on
|   basic/core behavior (however that would be defined). was
|   posted to this list? I suspect that many would be
|   irritated as this is supposed to be an emacs help forum,
|   not a discussion forum for developments.

Actually I think that would be a great idea -- I think
that's exactly what ought to be done.  I have read a number
of posts on the devel list discussing the question of how to
communicate with Emacs users about things like proposed
changes to defaults.  Most of the messages on the devel list
would not be relevant here -- only a tiny fraction, and
readers can always ignore threads that don't interest them.
They could have subject lines that were the equivalent of
"[RFC] Blah blah."

I agree that there is a limit to what complaining about it
after the fact can accomplish, but it is also true that most
users can't realistically monitor such a high-traffic, and
generally technical list like emacs-devel.  Posting the
occasional thread here about proposed changes might get
useful feedback, since a lot of people do monitor
gnu.emacs.help. 

Re: line-move-visual

[David Kastrup]

Evans Winner <thorne@unm.edu> writes:

> ,------ Tim X wrote ------
> |   For example, how would most of the users feel if every
> |   discussion regarding emacs development, even if
> |   restricted to discussions that directly impact on
> |   basic/core behavior (however that would be defined). was
> |   posted to this list? I suspect that many would be
> |   irritated as this is supposed to be an emacs help forum,
> |   not a discussion forum for developments.
>
> Actually I think that would be a great idea -- I think
> that's exactly what ought to be done.

It would mean mechanically routing the developer list here.  That's
nonsensical.  Anybody really wanting this sort of mixup can tell his
newsreader to create a virtual group that does it.

-- 
David Kastrup

Re: line-move-visual

[Evans Winner]

,------ David Kastrup wrote ------
|   It would mean mechanically routing the developer list
|   here.  That's nonsensical.  Anybody really wanting this
|   sort of mixup can tell his newsreader to create a
|   virtual group that does it.

You didn't read what I wrote very carefully.

Re: line-move-visual

[Uday S Reddy]

On 6/12/2010 9:30 AM, David Kastrup wrote:

> It would mean mechanically routing the developer list here.  That's
> nonsensical.  Anybody really wanting this sort of mixup can tell his
> newsreader to create a virtual group that does it.

No, not really.

The discussion that needs to be routed here is about potential changes to the 
user's manual.  How those changes are *implemented* can continue to stay on the 
developer list.  Evans suggested "RFC" which I think is a great term for these 
kinds of things.

Ideas that add bits to the user's manual can also be brought here, perhaps 
selectively.  For instance, there is a discussion going on there right now 
about how to deliver "bidirectional text" editing, for buffers that intermix 
English and Arabic, say.  There are lots of tricky issues there about key 
bindings and functionality.  The discussion is impoverished by the dearth of 
people that actually do bidirectional editing.  I don't see why that discussion 
could not be brought here, where there is some chance of running into people 
that might actually do bidirectional editing and who might provide valuable input.

In any organization, virtual or real, there are decisions that should be taken 
by small groups of people and there are decisions that can benefit from broad 
participation.  The organizations that can't figure out the difference usually 
decline over time.

Cheers,
Uday

Re: line-move-visual

[Tim X]

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

> On 6/12/2010 9:30 AM, David Kastrup wrote:
>
>> It would mean mechanically routing the developer list here.  That's
>> nonsensical.  Anybody really wanting this sort of mixup can tell his
>> newsreader to create a virtual group that does it.
>
> No, not really.
>
> The discussion that needs to be routed here is about potential changes to the
> user's manual.  How those changes are *implemented* can continue to stay on
> the developer list.  Evans suggested "RFC" which I think is a great term for
> these kinds of things.
>
> Ideas that add bits to the user's manual can also be brought here, perhaps
> selectively.  For instance, there is a discussion going on there right now
> about how to deliver "bidirectional text" editing, for buffers that intermix
> English and Arabic, say.  There are lots of tricky issues there about key
> bindings and functionality.  The discussion is impoverished by the dearth of
> people that actually do bidirectional editing.  I don't see why that
> discussion could not be brought here, where there is some chance of running
> into people that might actually do bidirectional editing and who might provide
> valuable input.
>
> In any organization, virtual or real, there are decisions that should be taken
> by small groups of people and there are decisions that can benefit from broad
> participation.  The organizations that can't figure out the difference usually
> decline over time.
>

My only concern here is with identification of what should and should
not be posted in g.e.h as well as on the developer mail list. While I
think Evans suggestion is worth consideration, I still see it failing
because it relies too much on everyone doing the 'right thing' and as
can be seen from this discussion, knowing what is the right thing is not
that straight-forward. However, discussions on possibilities are
certainly worthwhile and essentila to finding the right balance.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Joseph Brenner]

Evans Winner <thorne@unm.edu> writes:
> Tim X wrote:
> |   For example, how would most of the users feel if every
> |   discussion regarding emacs development, even if
> |   restricted to discussions that directly impact on
> |   basic/core behavior (however that would be defined). was
> |   posted to this list? I suspect that many would be
> |   irritated as this is supposed to be an emacs help forum,
> |   not a discussion forum for developments.
>
> Actually I think that would be a great idea -- I think
> that's exactly what ought to be done.

Some software projects publish summaries of what's been
happening on the developers list.  If you can find a volunteer
to do the job, these weekly newsletters are obviously a good
thing to have.

But this isn't the solution to the problem at hand.

> I have read a number of posts on the devel list discussing the
> question of how to communicate with Emacs users about things like
> proposed changes to defaults.

The right answer is that you should not be changing the defaults.

If we really can't convince the developers that they need to respect
backwards compatibility, an actual solution to the problem might
be something like creating a switch that needs to be flipped on to
get the new whizzy behavior, something like:

  (setq modernize-emacs t)

You then recommend that the default ~/.emacs for *new* users should
include that line.

Existing users should never have their existing ~/.emacs over-written
the default, so they should only see the old behavior (unless, of
course, they choose to add that line).

Documentation for "modernize-emacs" should make it clear that it's
under development, and that for the immediate future at least,
the behavior it imposes may change.

Doing something like this would be far better than the current
practices, though it's obviously not perfect.  Problems include:

  o  A third-party developer may be suprised by the need to ask
     users not to flip on "modernize-emacs", and may have to
     write code to shut it off and live with some user confusion
     when the "modernized" behavior goes away temporarily.

  o  It's effectively a project fork that at the very least
     complicates documentation and testing.

> I agree that there is a limit to what complaining about it
> after the fact can accomplish,

If you minimize UI changes, then these complaints are minimized.
If you eliminate UI changes, then these complaints are eliminated.

Re: line-move-visual

[Tim X]

Joseph Brenner <doom@kzsu.stanford.edu> writes:

> Evans Winner <thorne@unm.edu> writes:
>> Tim X wrote:
>> |   For example, how would most of the users feel if every
>> |   discussion regarding emacs development, even if
>> |   restricted to discussions that directly impact on
>> |   basic/core behavior (however that would be defined). was
>> |   posted to this list? I suspect that many would be
>> |   irritated as this is supposed to be an emacs help forum,
>> |   not a discussion forum for developments.
>>
>> Actually I think that would be a great idea -- I think
>> that's exactly what ought to be done.
>
> Some software projects publish summaries of what's been
> happening on the developers list.  If you can find a volunteer
> to do the job, these weekly newsletters are obviously a good
> thing to have.
>

A good idea if someone is prepared to step up and do it.

> But this isn't the solution to the problem at hand.
>
>> I have read a number of posts on the devel list discussing the
>> question of how to communicate with Emacs users about things like
>> proposed changes to defaults.
>
> The right answer is that you should not be changing the defaults.

I tend to agree that defaults should usually not change. However, you
cannot anticipate all possible situations and should avoid absolutes.
Defaults should only change after serious consideration and discussion
and should be as inclusive of users as possible. However, they should
not be treated as sacred and can never be changed. 

>
> If we really can't convince the developers that they need to respect
> backwards compatibility, an actual solution to the problem might
> be something like creating a switch that needs to be flipped on to
> get the new whizzy behavior, something like:
>
>   (setq modernize-emacs t)
>
> You then recommend that the default ~/.emacs for *new* users should
> include that line.
>
> Existing users should never have their existing ~/.emacs over-written
> the default, so they should only see the old behavior (unless, of
> course, they choose to add that line).
>
> Documentation for "modernize-emacs" should make it clear that it's
> under development, and that for the immediate future at least,
> the behavior it imposes may change.
>
> Doing something like this would be far better than the current
> practices, though it's obviously not perfect.  Problems include:
>
>   o  A third-party developer may be suprised by the need to ask
>      users not to flip on "modernize-emacs", and may have to
>      write code to shut it off and live with some user confusion
>      when the "modernized" behavior goes away temporarily.
>
>   o  It's effectively a project fork that at the very least
>      complicates documentation and testing.
>
>> I agree that there is a limit to what complaining about it
>> after the fact can accomplish,
>
> If you minimize UI changes, then these complaints are minimized.
> If you eliminate UI changes, then these complaints are eliminated.

Again, we need to be very wary of any absolute such as UI will never
chnage or defaults can never change. We live in an environment that
changes and need to be able to adapt.

It would be a mistake to eliminate UI changes. There have been a number
of improvements in the emacs UI over the last couple of versions. Many
of htem I don't like, such as using dialog boxes for find file and
yes-no questions if you use the menu etc, but many others, think they
are excellent improvements that helps emacs reamin current and of
interest to new developers (who are important as some of them will
likely be future dev/maintainers). You also have things like the current
work on bi-directional editing, which will obviously be a UI change. The
developments in handling various character encodings also had some
impact on the UI. Many of these were positive and some of them were
important and some are necessary. 

Change is not the issue. Change can be positive and is necessary. The
issue is managing that change. Any attempt to enforce a static
unchanging environment will fail.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Uday S Reddy]

On 6/13/2010 2:41 AM, Tim X wrote:

> Change is not the issue. Change can be positive and is necessary. The
> issue is managing that change. Any attempt to enforce a static
> unchanging environment will fail.

You are demolishing a strawman.  None of us ever said that change is 
unnecessary.  The thought that was in my mind when I wrote the previous message 
is better expressed as follows:

In the OS & network protocols world /where Mark Crispin comes from/ things can 
never change essentially.

So, Mark has every right to blow up when things have changed essentially. 
Emacs devs needed that lesson and, judging from Stefan's last post, I think 
they continue to need it.  Do you disagree?  (Don't be too focused on surface 
niceties and etiquette and all that.  Different people have different ways of 
expressing themselves.  The substance is what matters in the end.)

The reason that things can never change in the OS & network protocols world is 
that all the services interface to other systems and services.  So, if you 
change one thing, however inconsequential it might seem, you can end up 
breaking everything.  Somebody once told me that, if you want to change one 
line of code in the kernel of an on-board computer system, you have to produce 
thousands of pages of documentation analyzing how it will affect everything 
else on the aircraft.  It is so hard to do it that it is almost never done.

In the Emacs world, it is easy to think that we are delivering services to the 
human user, who is clever enough to figure things out.  Emacs is a /text 
editor/ after all.  So, change is ok.  But the problem is that Emacs is not 
just a text editor any more.  Unbeknownst to the developers, or perhaps even 
known to them in some instances, it is being used as a critical system 
component in other applications or services.  Emacs has certainly earned the 
right to be such a component.  It is some 30-40 years old.  Its core is rock 
solid.  Who has ever had a file corrupted by Emacs?  (On the other hand, I have 
had files corrupted by file servers sold by even reputable companies.)  We use 
Emacs for email in VM, which I regard as mission-critical, because all hell can 
break loose if a mail folder gets corrupted or somebody can't read their email. 
  We regularly use Emacs to develop code with all kinds additional 
functionality from editing modes and interfaces to code repositories.  If 
something goes wrong there, other developed software can break, with untold 
consequences.  I am dying to figure out what application Mark Crispin is 
putting Emacs to that makes it so hard for him to accommodate the 
line-move-visual change.  So, changes that can potentially break things are 
*not* ok.  We don't have to be as diligent as the on-board kernel hackers, but 
we certainly have to be a lot more careful than we seem to be at the moment. 
Emacs devs have to grow up into this real world.

Changing the meaning of next-line has consequences far beyond what the Emacs 
devs have been able to grasp.  I have mentioned previously that I found three 
calls to `next-line' in VM.  They were not in VM core, in third party 
contributions, but try telling that to somebody whose mail folder gets 
corrupted!  Emacs devs might say one should never have used `next-line' in 
elisp code, but that is not really good enough, is it?  Emacs manual never said 
one *must not* use next-line in elisp code.  It only said that there are better 
ways of doing it.  So, an elisp programmer cannot be faulted for using 
`next-line'.

(As an aside, Microsoft used to say that the problems faced by the users with 
Windows weren't their fault but rather those of third party device drivers. 
Microsoft had hoisted complicated protocols on the device driver writers, who 
couldn't manage them properly.  Microsoft has now developed sophisticated 
driver verification tools - some of the best in the field - to verify that the 
device drivers satisfy the protocols.  Good for them!  And good for the users!)

Imagine what I have to say in the next release notes of VM: "Emacs 23 has 
introduced an incompatible change to the meaning of `next-line' which can cause 
folder corruption.  This release of VM is the first safe version of VM for use 
with Emacs 23".  This doesn't stop other users still using older versions of VM 
from facing folder corruption.  Nor will it stop some downstream distribution 
from packaging an old version of VM with the later version of Emacs.  Is that 
the kind of situation we want to be in?

Stefan says, perhaps half-jokingly, that he never uses Emacs while being root. 
  Does RMS think the same?  Do all the trustees of FSF accept that Emacs is 
unfit to be used while being root?  What other Gnu software is similarly unfit 
to be used as root?  Mark Crispin's criticism has to be taken seriously, even 
if it comes with a heavy dose of vitriole, because he is a top-level systems 
programmer who knows better.

When you say that this change has been around for a year and no complaints were 
raised, you are not being clear about how software changes are propagated.  It 
takes years for changes to go through the pipeline of downstream distributions 
and even longer for users to upgrade their systems.  Smart users who want to 
play safe are always careful to let the dust settle before upgrading.  Our 
local sys admins haven't even installed Emacs 23.1 yet on our departmental 
machines.  That will probably happen during this summer.  If I was a normal 
user, rather than a developer, I would have probably taken an additional year 
or so to make the switch.  So, these late complaints are the most important 
ones.  They come from the more serious and conservative users.  Emacs devs are 
going to have to face the heat for quite a while to come.

Mark Crispin is not satisfied with Stefan's response.  Neither am I, to tell 
you the truth.  When says, "Given the reactions we've seen since Emacs-23.1 was 
released, I don't regret the decision", he is indicating that he is happy to 
play to the gallery, and quite an uninformed gallery at that.  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.  If this is the measure of support needed to 
introduce incompatible changes in Emacs, then Emacs does seem to be in trouble!

Cheers,
Uday

Re: line-move-visual

[David Kastrup]

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

> So, Mark has every right to blow up when things have changed
> essentially. Emacs devs needed that lesson and, judging from Stefan's
> last post, I think they continue to need it.  Do you disagree?

I should think that if your attitude towards Emacs developers seemed a
bit less similar to manipulating unthinking apes into doing useful
tricks according to your bidding, you might get a better return for the
amount of stuff you write.

If you want some response from the developers, the right way is to talk
with them like normal human beings would rather than trying to view them
as laboratory rats and discuss your findings about their reactions with
other superior life forms.

If you have questions about the intent behind a post of Stefan, the
person to ask is Stefan.  And trying to get a consensus about Stefan and
other developers needing further lessons is not what I consider a
discourse worthy for respectful human beings.

The question is not how to manipulate Emacs developers into doing things
the way you'd like them to do.  The question is how to argue against the
priorities and reasons (readily accessible in the developer list
archives) that lead to the current decision, and come up with additional
data that may shift the balance.

"It makes obnoxious and insolent people raise a stink elsewhere" is, at
least in my book, not a particularly important consideration for
choosing defaults.  So there is not much to be gained by you and in
particular Mark trying to increase their efforts in that area.

-- 
David Kastrup

Re: line-move-visual

[Uday S Reddy]

On 6/13/2010 11:51 AM, David Kastrup wrote:

>
> If you want some response from the developers, the right way is to talk
> with them like normal human beings would rather than trying to view them
> as laboratory rats and discuss your findings about their reactions with
> other superior life forms.
>
> If you have questions about the intent behind a post of Stefan, the
> person to ask is Stefan.

Hmm.  A bit unfair, but good point.  I will.

> The question is not how to manipulate Emacs developers into doing things
> the way you'd like them to do.  The question is how to argue against the
> priorities and reasons (readily accessible in the developer list
> archives) that lead to the current decision, and come up with additional
> data that may shift the balance.

Ok, I have indicated how the change to the semantics of `next-line' affects VM 
and perhaps other similar packages.

Mark, if you are still around, can you tell us how it affects you?  Why kind of 
users do you have and why can't set line-move-visual to nil?

Cheers,
Uday

Re: line-move-visual

[Tim X]

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

> On 6/13/2010 2:41 AM, Tim X wrote:
>
>> Change is not the issue. Change can be positive and is necessary. The
>> issue is managing that change. Any attempt to enforce a static
>> unchanging environment will fail.
>
> You are demolishing a strawman.  None of us ever said that change is
> unnecessary.  The thought that was in my mind when I wrote the previous
> message is better expressed as follows:
>

Not at all. It was suggested that mature reliable software that is
maintained by competant, mature and experienced programmers /never/
changes its interface. This implies that change is not only unnecessary,
but cannot occur in a mature system. The implication was that because
visual line mode changes the interface, the developers and maintainers
were immature, inexperienced and arrogant. I reject this assertion that
interfaces cannot change and that any change in an interface
automatically means the software is immature, unreliable and/or
maintained by incompetant developers. I would go further and argue that
in some situations, changing the interface is actually the correct and
responsible thing to do. 

Changing the interface is not the problem, it is how that change is
implemented that is the issue. If we accept a generalisation that
interfaces cannot change, we run the risk of artificially constraining
possibilities and fail to focus on the important challenge of
establishing processes that will allow the itnerface to develop and
mature without undesirable side effects. Arguing that the interface can
never change is over simplifying the situation and encourages a mindsset
where change is feared and raises the real possiblity that the software
will stagnate and fail to either keep pace with evolving technology or
user expectations. 

>
> In the OS & network protocols world /where Mark Crispin comes from/ things can
> never change essentially.

I don't disagree. Different domains have different constraints. However,
just because the domain someone works in has specific constraints does
not mean that those constraints should be automatically applied to other
domains. 

> So, Mark has every right to blow up when things have changed essentially.
> Emacs devs needed that lesson and, judging from Stefan's last post, I think
> they continue to need it.  Do you disagree?  (Don't be too focused on surface
> niceties and etiquette and all that.  Different people have different ways of
> expressing themselves.  The substance is what matters in the end.)

I have stated repeatably that I agree that making visual line mode the
default was a mistake. I also agree that the maintainers probably need
to create better channels of communication to get more feedback from end
users. I totally disagree with the arguments that introduction of visual
line mode was a mistake. I totally disagree with the persoanl attacks on
the developers and insinuations regarding their maturity, competance and
experience and charges of arrogance. I totally disagree with absolutes
such as interfaces should never change and defaults should never change.
I do accept that interfaces should be treated in a very conservative
manner and that any change should be considered extremely carefully. I
even have trouble coming up with an example that wold support changing
of defaults. However, I see a big difference between saying that we
should be very conservative regarding change in these areas and saying
that these areas should /never/ change. 

I expect some will respond with "well yes, there are exceptions where
change would be OK if blah blah" etc and "you are being too literal,
there are always exceptions to the rule" etc. In which case, I would say
that it is better to be clearer regarding what is meant. Avoid setting
up 'rules' that deal in absolutes which distract from core issues and
create false constraints. Say that interfaces and defaults should be
treated extremely conservatively and should not change without clear
justification. Once we accept that change is possible in this respect,
we can then focus on how to assess when a change to the interface is
justified, how such changes should be implemented, how end users should
be consulted and how to roll the change out. Denying that change is
possible means that we don't properly consider the implications of the
change and don't establish propper processes for dealing with it.

[snip]

> In the Emacs world, it is easy to think that we are delivering services to the
> human user, who is clever enough to figure things out.  Emacs is a /text
> editor/ after all.  So, change is ok.  But the problem is that Emacs is not
> just a text editor any more.  Unbeknownst to the developers, or perhaps even
> known to them in some instances, it is being used as a critical system
> component in other applications or services.  Emacs has certainly earned the
> right to be such a component.  It is some 30-40 years old.  Its core is rock
> solid.  Who has ever had a file corrupted by Emacs?  (On the other hand, I
> have had files corrupted by file servers sold by even reputable
> companies.)

I have had files currupted by emacs and I have had files currupted by
VM. In both cases, they were bugs in production versions. However, given
that I've been using emacs pretty much all day, everyday for 15 years, I
do consider it very stable. 

> We use Emacs for email in VM, which I regard as mission-critical, because all
> hell can break loose if a mail folder gets corrupted or somebody can't read
> their email. We regularly use Emacs to develop code with all kinds additional
> functionality from editing modes and interfaces to code repositories.  If
> something goes wrong there, other developed software can break, with untold
> consequences.  

I have had VM fail on a number of occasions and have had it currupt my
mail folder at least once. Yes, it has been mostly very stable and
reliable. However, problems/bugs do occur regardless of how mission
critical you assume it is. Likewise, you cannot make assumptions
regarding how mission critical developers view a system based on a
bug or single decision. 

> I am dying to figure out what application Mark Crispin is
> putting Emacs to that makes it so hard for him to accommodate the
> line-move-visual change.  

To be honest, while I believe Mark raised a valid issue regarding visual
line mode being the default, I think he over reacted and his somewhat
personal attacks on the emacs developer community only distracted form
the important issues he raised. There have been a couple of suggestions
regarding how he can work around the issue, which he does not seem to
respond to and I suspect that he may be "throwing the baby out with the
bath water". 

> So, changes that can potentially break things are
> *not* ok.  

Sounds nice, but the reality is that any change can potentially break
things. We can certainly establish processes that help mitigate this.
However, we need to first accept that change is possible and sometimes
needed in order to then establish these processes. This is why I reject
the claim that the interface should never change and/or defaults should
never change. 

> We don't have to be as diligent as the on-board kernel hackers, but
> we certainly have to be a lot more careful than we seem to be at the moment.
> Emacs devs have to grow up into this real world.

I still think this is all being wildly over stated. We are talking about
one change largely implemented by one developer. We cannot make
assumptions about all the developers and what they do or do not need
based on a single change. Consider the substantial interface changes
that have occured between emacs 22 and emacs 23. Given how stable emacs
has remained despite all these changes, I would suggest the developers
need to be congratulated for doing an excellent job.  

There has been a lot of theorizing about how badly visual line mode will
break things, but I've not actually seen much evidence of people who are
using visual line mode experiencing problems. Furthermore, if you
disable visual line mode, the impact is absolutely nil. 

The issue is not that visual line mode was a mistake, but rather that it
was introduced as a default and that implications of doing so were not
well thought out, especially with respect to keyboard macros etc and
that this change in default was not adequately communicated. 

>
> Changing the meaning of next-line has consequences far beyond what the Emacs
> devs have been able to grasp.  I have mentioned previously that I found three
> calls to `next-line' in VM.  They were not in VM core, in third party
> contributions, but try telling that to somebody whose mail folder gets
> corrupted!  Emacs devs might say one should never have used `next-line' in
> elisp code, but that is not really good enough, is it?  Emacs manual never
> said one *must not* use next-line in elisp code.  It only said that there are
> better ways of doing it.  So, an elisp programmer cannot be faulted for using
> next-line'.
>

[snip]

>
> Imagine what I have to say in the next release notes of VM: "Emacs 23 has
> introduced an incompatible change to the meaning of `next-line' which can
> cause folder corruption.  This release of VM is the first safe version of VM
> for use with Emacs 23".  This doesn't stop other users still using older
> versions of VM from facing folder corruption.  Nor will it stop some
> downstream distribution from packaging an old version of VM with the later
> version of Emacs.  Is that the kind of situation we want to be in?

There is nothing new here. We have always been in this position. Look at
the emacs NEWS files. They contain a section on incompatible lisp
changes. There is always the potential for existing packages to break
with new versions of emacs and it isn't uncommon for packages to need
changes in order to work with a new major version. 

I also think your over stating the situation. The potential problem only
occurs if you enable visual line mode. 

>
> Stefan says, perhaps half-jokingly, that he never uses Emacs while being root.
> Does RMS think the same?  Do all the trustees of FSF accept that Emacs is
> unfit to be used while being root?  What other Gnu software is similarly unfit
> to be used as root?  Mark Crispin's criticism has to be taken seriously, even
> if it comes with a heavy dose of vitriole, because he is a top-level systems
> programmer who knows better.

Mark's criticism regarding visual line mode being the default is valid.
His heavy does of vitriole against the whole emacs developer community
is not. As I don't know him and have not worked with him, I cannot judge
his credentials as a programmer and would never presume to do so. 

>
> When you say that this change has been around for a year and no complaints
> were raised, you are not being clear about how software changes are
> propagated.  It takes years for changes to go through the pipeline of
> downstream distributions and even longer for users to upgrade their systems.
> Smart users who want to play safe are always careful to let the dust settle
> before upgrading.  Our local sys admins haven't even installed Emacs 23.1 yet
> on our departmental machines.  That will probably happen during this summer.
> If I was a normal user, rather than a developer, I would have probably taken
> an additional year or so to make the switch.  So, these late complaints are
> the most important ones.  They come from the more serious and conservative
> users.  Emacs devs are going to have to face the heat for quite a while to
> come.
>

That is a fair point. However, I would also suggest that many of the
experienced and active users are also the first ones to adopt or trial
emacs versions. At work, I run emacs 23.1. However, at home and for most
of my personal development work, I run the latest development system,
which I upgrade at least once a week. 

> Mark Crispin is not satisfied with Stefan's response.  Neither am I, to tell
> you the truth.  When says, "Given the reactions we've seen since Emacs-23.1
> was released, I don't regret the decision", he is indicating that he is happy
> to play to the gallery, and quite an uninformed gallery at that.  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.  If this is the measure of support needed
> to introduce incompatible changes in Emacs, then Emacs does seem to be in
> trouble!
>

That isn't how I interpreted Stefan's response at all. My interpretation
was that he believes, based on feedback, that many users found visual
line mode a beneficial new feature, but he acknowledges that it hasn't
come without some problems. 

I don't understand why you are asking if C-n should move by logical line
or visual line in logical line mode. Isn't this what the difference is
between the two modes? In logical line mode, the behavior is exactly the
same as it has always been - C-n moves by logical line. In visual line
mode, it moves by visual line. I don't see any issue here and there is
no evidence anywhere that I am aware of that proposes any changes to
line movement when not in visual line mode. 

There are two issues I am aware of where it appears there has been a
lack of in-depth analysis. The first and I think most serious is the
impact of visual line mode on existing saved keyboard macros. More
thought is required in this area. Personally, I would be inclined to
somehow restrict macros in such a way that they won't work if the buffer
is in a different line mode to the one it was in when the macro was
defined.

The second issue, which /may/ be a problem is the impact of next-line in
packages people use while also using visual line mode. I would suggest
that both of these are enough justification for not setting visual line
mode as the default - at least not yet. It definitely should have been
introduced as an optional non-default feature. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Tim X]

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

> On 6/14/2010 1:46 AM, Tim X wrote:
>
>> Not at all. It was suggested that mature reliable software that is
>> maintained by competant, mature and experienced programmers /never/
>> changes its interface. This implies that change is not only unnecessary,
>> but cannot occur in a mature system.... I reject this assertion that
>> interfaces cannot change and that any change in an interface
>> automatically means the software is immature, unreliable and/or
>> maintained by incompetant developers. I would go further and argue that
>> in some situations, changing the interface is actually the correct and
>> responsible thing to do.
>
> Sorry, Tim.  Your rejection would carry some weight if you mentioned the
> situations where changing the interface is "the correct and responsible" thing
> to do.
>
> You also seem to believe that the `line-move-visual' issue did not present
> such a situation where changing the interface was the correct and responsible
> thing to do.  So, I am not sure what your point is, other than providing some
> political support to the developers.
>

OK, fair criticism. I have muddied the waters too much by trying to
address to many issues in a sigle thread. I should probably have put
things in different threads to avoid confusion. I also should have been
more careful with some terminology and phrasing. I will attempt to clarify.

The issues I've tried to address are

    1. The suggestion that interfaces for mature software packages never
    change and that such change means the software is immature or poorly
    maintained. 
    2. The issue of line-move-visual and whether it in itself is a bad
    idea or whether the way it was implemented was a mistake
    3. The frequently personal, overly general and somewhat arrogant
    criticisms of emacs maintainers based largely on unsubstantiated
    assumptions. 

1. While we would like to believe interfaces of mature software packages
never change, this simply isn't reality. If it were, we would always
have backwards compatibility, which we don't. Likewise, it would not be
necessary for programs to use version numbering schemes that incorporate
this information. For example, the Apache scheme uses a format of
'x.y.z' where 'x' indicates significant interface changes that are not
backwards compatible, 'y' indicates a version with interface changes
that are extensions and are backwards compatible and 'z' indicates a
patch. In this context, interface can refer to either API changes or UI
changes.  

While I cannot think of specific examples of interface changes in emacs,
I can certainly recall changes in many other mature packages. For
example, Apache has changed the interface for external modules, Java has
changed its interface for core classes, Microsoft has changed some of
its low level OS interfaces, breaking backwards compatibility for 16 bit
programs and Linux has changed its interface in a number of areas. With
this last one, I have run into issues with a driver I used to use that
is no longer compatible with current 2.6.x kernels. 

I have maintained that interface changes are not something that should
be done unnecessarily. The interface should be treated conservatively
and changes should be avoided where possible. However, I think it is a
mistake to ignore or deny the possibility of interface change because
doing so results in failing to understand and consider the consequences.
This is necessary to know how to properly manage such changes and
minimize impact. It is also necessary because different domains have
different requirements and constraints. For these reasons, I reject
blanket statements that say the interface of mature software packages
must never change. 

> Regarding your questions, yes, I do regard /all/ changes to *existing*
> behavior of mature software systems as bad.  Under exceptional circumstances,
> they could be the *lesser evil* and then we accept them as being unfortunately
> necessary.
>

Right. However, this doesn't fit with the claim of /never/ changing or
with the simplistic view that a change in interface indicates software
that is immature. 

> This does not mean that you can't add new features or extend the existing
> behavior.  Extend it as much as you please, without changing what already
> exists.
>

Agree. Extension is not what I would call change as it doesn't usually affect
backwards compatibility. However, in some cases, most notably user
interfaces, extensions and enhancements can be seen as a change that
breaks backwards compatibility because it modifies the interface to such
an extent that the user feels they no longer recognize it or know how to
use the system despite the fact core operations and APIs have not been
modified. However, this is an edge case. Adding functionality etc
usually doesn't have the level of impact as modifying what already
exists. 

> The Emacs NEWS file currently does not make any distinction between *changes*,
> meaning changes to the existing behavior, and *extensions* (or improvements or
> new features).  All of them are generically labelled as "Changes" (meaning
> changes to the software system, not changes to the behavior of features).
> This is probably a hangover from the time when the file might have been called
> a ChangeLog, rather than NEWS.  Please don't confuse "changes" in this generic
> sense to be actual changes.
>

Hmmm, I don't think I agree. While it could be possible to improve the
labelling, its nowhere as bad as you indicate. Here are the top level
headings from the current NEWS file for the dev version (these basic
headings have been in all the NEWS files I've seen for the past 15
years)

* Installation Changes in Emacs 24.1
* Startup Changes in Emacs 24.1
* Changes in Emacs 24.1
* Editing Changes in Emacs 24.1
* Changes in Specialized Modes and Packages in Emacs 24.1
* New Modes and Packages in Emacs 24.1
* Incompatible Lisp Changes in Emacs 24.1
* Lisp changes in Emacs 24.1
* Changes in Emacs 24.1 on non-free operating systems

>> That isn't how I interpreted Stefan's response at all. My interpretation
>> was that he believes, based on feedback, that many users found visual
>> line mode a beneficial new feature, but he acknowledges that it hasn't
>> come without some problems.
>>
>> I don't understand why you are asking if C-n should move by logical line
>> or visual line in logical line mode. Isn't this what the difference is
>> between the two modes? In logical line mode, the behavior is exactly the
>> same as it has always been - C-n moves by logical line. In visual line
>> mode, it moves by visual line. I don't see any issue here and there is
>> no evidence anywhere that I am aware of that proposes any changes to
>> line movement when not in visual line mode.
>
> These two paragraphs suggest that you don't really know what the issue is.
> Perhaps you should read the manual sections on line-move-visual and
> visual-line-mode  and try them out before discussing them?
>

That was poor expression and haste on my part. I meant line-move-visual
and not visual-line-mode. I suspect the confusion is with the general
use of 'mode' and the emacs specific definition of a buffer mode. 

After what you wrote, I thought it would be a good idea to check my
facts and experiment a bit. My understanding wasn't too far off the
mark. I would suggest you have a look at the code for visual-line-mode
as it uses line-move-visual - essentially, setting it to t locally in
the buffer when you turn the mode on. If it was nil before starting
visual-line-mode, it sets it back to nil when you turn off the mode. So,
it seems that visual-line-mode uses line-move-visual to alter the next
line/previous line definitions when in visual line mode.

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. If you had line wrap on for a long line that
filled 10 visual lines in your window, a single C-n would move down to
the 11th visual line i.e. C-n moves to next logical line. In visual line
mode or with line-move-visual enabled, C-n would move to the second
visual screen line i.e. you would have to do multiple C-n to get past
the 'logical line'.

For convenience of argument, since visual line mode uses
line-move-visual, lets just call it visual line mode. Noting that I
expect all the possible problems that line-move-visual would cause with
macros will also exist if you are using visual line mode as they both
redefine the movement semantics in the same way. 

From this perspective, for me, the semantics of the movement keys are
what determine which mode you are operating in. It makes no sense to ask
if C-n should move by logical lines or visual lines in logical line mode
because moving by logical lines is what defines logical line mode. If
you move by visual lines, your not in logical line mode, your in visual
line mode (using the term mode in its general sense, not its emacs
sense).

So, I still don't understand your question and I suspect I'm not alone.
This could explain the lack of response to your question and provides an
alternative to your rather negative and somewhat arrogant assertion
regarding an 'ill informed gallery'. A failure to illicit a response to
a question can easily be due to the way it is presented and does not in
itself tell you anything about the audience. 

To again make my position clear. I believe that setting line-move-visual
to t by default was a mistake. I believe the introduction of the ability
to change the semantics of line movement is a good addition, despite some
of the negative consequences and the fact that I think there is still
some work to be done to handle things like macros in a reliable
consistent manner. This ability to change the movement semantics has
enabled improved support for a number of activities, many of which have
been mentioned elsewhere in this thread. I agree that its introduction
does come with some pain, but I think its worth it. From a theoretical
basis, I can see where some of the concerns are coming from, but I've
yet to hear of an actual example where the change has caused the
cataclysmic disasters that have been predicted. I think despite some
valid points, things have been over stated. 

Which brings me to my final issue and the one that actually dragged me
into this thread. The arrogance, derogatory comments about the emacs
maintainers, sweeping generalizations and assumptions regarding
everything from their personal motivations, experience, egos and even
age has been quite outrageous. Arrogant claims of teaching them lessons
and demands for more accountability etc have been over the top and all
of this due essentially to one poor decision to change the default
behavior. There has been no recognition for all the recent improvements
in font handling, support for GTK, dbus, etc, X window support
enhancements, emacsclient improvements, improved and extended support
for different character encodings, support for larger buffers and much
more. I'm quite amazed at the development and improvements we have been
seeing. Remember how slow it was to go from emacs 20 to 21? Remember the
constant frustrations of an emacs that frequently ran into limitations
that other systems didn't experience? I think the work that has been
done over the last few years has been quite remarkable.

>
> I hope you understand the issue better now.  If you still think this is an
> acceptable change, let us know.

I understood it before, thank you master! I hope you now understand my
position better!

Tim

-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Uday S Reddy]

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.

By your terminology, "logical line mode" existed in Emacs 22, but it doesn't 
exist in Emacs 23.  When you fire up 'emacs -Q' you get some kind of an "emacs 
default mode with a funny mixture of logical and visual lines".  From this 
point of view, the problem is more simply stated: the Emacs default is not 
logical line mode any more.

> So, I still don't understand your question and I suspect I'm not alone.
> This could explain the lack of response to your question and provides an
> alternative to your rather negative and somewhat arrogant assertion
> regarding an 'ill informed gallery'. A failure to illicit a response to
> a question can easily be due to the way it is presented and does not in
> itself tell you anything about the audience.

Sorry, arrogance was not my intent.  The reason for calling the people that 
gave positive feedback "ill informed" is that either they don't realize that 
they can get the behavior they want by setting line-move-visual to t or they 
don't understand that things can break in unforeseen ways by changing the 
default behavior.  I was myself "ill informed" in this sense until this thread 
started.  So, if I happened to give positive feedback on this issue, it would 
have been worth nothing.

> To again make my position clear. I believe that setting line-move-visual
> to t by default was a mistake. I believe the introduction of the ability
> to change the semantics of line movement is a good addition, despite some
> of the negative consequences and the fact that I think there is still
> some work to be done to handle things like macros in a reliable
> consistent manner. This ability to change the movement semantics has
> enabled improved support for a number of activities, many of which have
> been mentioned elsewhere in this thread. I agree that its introduction
> does come with some pain, but I think its worth it. From a theoretical
> basis, I can see where some of the concerns are coming from, but I've
> yet to hear of an actual example where the change has caused the
> cataclysmic disasters that have been predicted. I think despite some
> valid points, things have been over stated.

I think we agree on all of this.  However, I don't think I predicted 
"cataclysmic disasters".  I only said that file corruption is possible. 
Whether it actually happens or not depends on how much code or macro collection 
is out there in circulation which uses `next-line'.  As a developer, I avoid 
the possibility of file corruption at all cost.  I don't expect myself to be 
proved or disproved about cataclysmic disasters.

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.

> Which brings me to my final issue and the one that actually dragged me
> into this thread. The arrogance, derogatory comments about the emacs
> maintainers, sweeping generalizations and assumptions regarding
> everything from their personal motivations, experience, egos and even
> age has been quite outrageous. Arrogant claims of teaching them lessons
> and demands for more accountability etc have been over the top and all
> of this due essentially to one poor decision to change the default
> behavior. There has been no recognition for all the recent improvements
> in font handling, support for GTK, dbus, etc, X window support
> enhancements, emacsclient improvements, improved and extended support
> for different character encodings, support for larger buffers and much
> more. I'm quite amazed at the development and improvements we have been
> seeing. Remember how slow it was to go from emacs 20 to 21? Remember the
> constant frustrations of an emacs that frequently ran into limitations
> that other systems didn't experience? I think the work that has been
> done over the last few years has been quite remarkable.

On this, we disagree.  To set the record straight, neither I nor anybody else 
has used the phrase "teaching them a lesson" which has a very different 
meaning.  I have talked about taking a lesson, which is something smart people 
do throughout their lives, by learning from experience and users' feedback. 
Nothing derogatory was intended here.  Anybody who thinks that they don't need 
a lesson every now and then are probably arrogant themselves!

I haven't made any comments on Mark Crispin's language or etiquette.  Neither 
have I made such comments about anybody else.  My feeling is that it is a waste 
of time to talk about etiquette on newsgroups.  We are all adults and we are 
not going to change our behaviour patterns just because somebody commented on 
it in a newsgroup.  It is much more productive to focus on the substance and 
the issues, and try to figure out what is being talked about rather than how it 
is talked about.

If you want to acclaim the great progress being made in Emacs, please by all 
means start a thread and we will all join in.  But you can't fault us for not 
doing it in this thread which has a particular purpose, to discuss 
line-move-visual.

---

I wrote my last message to essentially sum up the discussion of this thread, 
which has been rather long by all standards.  I don't intend to prolong it 
further unless anybody comes up with some reasons for why the current default 
setting was good idea.

Cheers,
Uday

Re: line-move-visual

[Tim X]

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

Re: line-move-visual

[Tim X]

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

> On 6/13/2010 2:41 AM, Tim X wrote:
>

> I am dying to figure out what application Mark Crispin is
> putting Emacs to that makes it so hard for him to accommodate the
> line-move-visual change.  >
>

It seems, from a post I've just seen from Mark, that it isn't an
application at all. What he has are some recipes/processes that staff
follow using emacs. He has previously stated that asking them to set
line=move-visual to nil was not acceptable as his users would be
confused and that he has no access to the emacs software they are
running. Therefore, it would be reasonable to assume that if they cannot
add a simple line to set a variable and he does not have access to the
machines, that the users are not installing any specialised packages or
code and there is no elisp involved at all. His issue appears to be with
how to update his processes/recipes in a clear manner so that they will
still work regardless. This is a legitimate issue.

I now think he has overstated the impact. Setting line movement to its
old default is easily done via the options menu and doesn't require the
user editing .emacs or even using M-x customize. It wouldn't be too
difficult to add this to his recipes. (I do wonder how he deals with
users who select other options, such as CUA mode, that are also likely
to impact on his recipes). 

His point about setting visual line mode as the default being a poor
decision is valid. Likewise, his concern that this is a sign of possible
problems for his setup if more changes that affect basic commands occur
in future versions is legitimate, though possibly over stated when based
on a single contentious change (noting also that its not like a new major
version of emacs comes out every other week. 4 major versions released
in over 15 years!). However, discussion of such change is certainly
beneficial, even if it only makes developers aware of the need to be
conservative when proposing changes to interfaces or especially
defaults.

Unfortunately, over stating of the issue, derogatory assertions about
the developers, baseless assumptions about their ages, motivation and
expertise have tended to obscure the valid points he has raised. Instead
of coming across well, much of it has come across as nothing more than a
dummy spit. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Joseph Brenner]

Helmut Eller <eller.helmut@gmail.com> writes:
> Uday S Reddy wore:
>> Helmut Eller wrote:

>>> If you or Mark Crispin are so dependent on Emacs why don't you have test
>>> suites for your programs
>>
>> Why do you think Mark Crispin and I are the only ones "so dependent"
>> on Emacs?
>
> I don't think that you are the only ones (and never said that).  But it
> seems to me that it's your own fault to use keyboard macros for
> "mission-critical" stuff and not testing them.

Right.  So we hack our own test library, and we use it to determine that
emacs 23 will break our code.  We then put up a notice telling the end
users that they shouldn't uprade their version of emacs. They do it
anyway, and begin complaining, but everything's cool, because we can
point at the notice we put up.

Note that in this case, you'd have to have pretty good test coverage
to have a hope of noticing this problem, because it's not the kind of
breakage that anyone would've anticipated as being at all likely.

Re: line-move-visual

[Helmut Eller]

* Joseph Brenner [2010-06-16 04:11+0200] writes:

>> I don't think that you are the only ones (and never said that).  But it
>> seems to me that it's your own fault to use keyboard macros for
>> "mission-critical" stuff and not testing them.
>
> Right.  So we hack our own test library, and we use it to determine that
> emacs 23 will break our code.  We then put up a notice telling the end
> users that they shouldn't uprade their version of emacs. They do it
> anyway, and begin complaining, but everything's cool, because we can
> point at the notice we put up.

Maybe we could fix our code and put up a version that works with
Emacs23.  Oh wait, that doesn't work because users can't be bothered to
upgrade our code since it is oh so mission-critical.  Yes you're right:
it's better to not test anything and simply assume that Emacs never
changes.  Since Emacs is 20 years old it doesn't change anymore; we can
just close our eyes and we don't need to see the reality.  All our
assumptions about Emacs are correct and our code is perfect.

> Note that in this case, you'd have to have pretty good test coverage
> to have a hope of noticing this problem, because it's not the kind of
> breakage that anyone would've anticipated as being at all likely.

A test with lines longer than screen width would notice it.  Seems like
a simple and common test to me.

Helmut

Re: line-move-visual

[David Kastrup]

Joseph Brenner <doom@kzsu.stanford.edu> writes:

> Evans Winner <thorne@unm.edu> writes:
>
> But this isn't the solution to the problem at hand.
>
>> I have read a number of posts on the devel list discussing the
>> question of how to communicate with Emacs users about things like
>> proposed changes to defaults.
>
> The right answer is that you should not be changing the defaults.
>
> If we really can't convince the developers that they need to respect
> backwards compatibility, an actual solution to the problem might
> be something like creating a switch that needs to be flipped on to
> get the new whizzy behavior, something like:
>
>   (setq modernize-emacs t)
>
> You then recommend that the default ~/.emacs for *new* users should
> include that line.

That means that new users live in a separate universe where they can't
expect older users to be able to help them with their setup and usage
problems.  Because the older users don't even have a clue about what new
users might be working with.

It also means that older users never will get to see newer user
interface features, even if they might better fit their workflow.

"In your face" is a strategy where people actually get to see things and
make a conscious decision about keeping or leaving them.  It is a matter
of courtesy to make any feature work as well as possible before
confronting users with it by default.

Something like font-locking required a lot of work before Emacs
developers felt it could be made the default (while it has been the
default for much longer with XEmacs, with partly dire consequences
because of less maturity).

Emacs evolves, and its community evolves and grows.  And there is
something to be said for the community members to know what they are
roughly talking about when having an exchange about Emacs.

And that implies a choice between evolution or stagnation of the default
behavior.  Emacs should show the best and most consistent behavior out
of the box, whether or not that implies change.

And that's what the discussion, if it is to be taken seriously, is
supposed to be about.

My personal preference would be that when recording and replaying
macros, the used functions for arrow keys should be logical rather than
visual mode commands.

The current state is not satisfactory with regard to macro recording.
Which does not mean that I don't like it as a default behavior
otherwise.

-- 
David Kastrup

Re: line-move-visual

[Joseph Brenner]

David Kastrup <dak@gnu.org> writes:
> Joseph Brenner <doom@kzsu.stanford.edu> writes:

>> If we really can't convince the developers that they need to respect
>> backwards compatibility, an actual solution to the problem might
>> be something like creating a switch that needs to be flipped on to
>> get the new whizzy behavior, something like:
>>
>>   (setq modernize-emacs t)
>>
>> You then recommend that the default ~/.emacs for *new* users should
>> include that line.
>
> That means that new users live in a separate universe where they can't
> expect older users to be able to help them with their setup and usage
> problems.  Because the older users don't even have a clue about what new
> users might be working with.

Yes, and if I'd thought about that issue at all, I might've said
something like:

     Doing something like this would be far better than the current
     practices, though it's obviously not perfect.  Problems include:

       o  A third-party developer may be suprised by the need to ask
          users not to flip on "modernize-emacs", and may have to
          write code to shut it off and live with some user confusion
          when the "modernized" behavior goes away temporarily.

       o  It's effectively a project fork that at the very least
          complicates documentation and testing.

> "In your face" is a strategy where people actually get to see things
> and make a conscious decision about keeping or leaving them.

They can also make a conscious decision about dropping an unstable piece
of software.

Re: line-move-visual

[Tim X]

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

> On 6/12/2010 5:18 AM, Tim X wrote:
>
>> Your arguments all suggest an environment where interfaces never change.
>> This just doesn't exist and never has. Frequently improvements and new
>> functionality require changes to existing interfaces, both programming
>> and user.
>
> That is not quite true.  In the OS & network protocols world, things can never
> change essentially.  We still live with the possibility of 7bit mail transport
> even though nobody knows for sure whether there are any 7bit mail transport
> systems anywhere.  New protocols are designed that work around the limitations
> of the old protocols.  It has taken Unix some 15 years to figure out how to
> retrofit Unicode into its byte-oriented view of the world.  Things get messy
> but that is the price we pay for backward-compatibility.
>

I don't disagree, but the mere fact new protocols are developed to
handle the new as well as theold is in itself a change in the interface.
Citing an example that shows no interface change doesn't really counter
the arguement, but citing one that has changed would seem to. 

> In the Emacs world, we don't need to go that far.  But there is no reason why
> we can't expect the stability of the basic editing operations.

I agree it is important to keep stability in basic editing operations
and I agree the choice to make visual line mode the default was probably
a mistake. However, I disagree with the arguemment that all the
stability has been lost. If the new feature could not be disabled, then
I would agree. However, the fact you can revert back to the old 'stable'
behavior with only a minimal configuration means you can have exactly
the same behavior and stability as before. What is really at issue isn't
the change as much as making the chang ethe default behavior.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Joseph Brenner]

Tim X <timx@nospam.dev.null> writes:
> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>> Tim X wrote:

>>> Your arguments all suggest an environment where interfaces never change.
>>> This just doesn't exist and never has. Frequently improvements and new
>>> functionality require changes to existing interfaces, both programming
>>> and user.
>>
>> That is not quite true.  In the OS & network protocols world, things can never
>> change essentially.  We still live with the possibility of 7bit mail transport
>> even though nobody knows for sure whether there are any 7bit mail transport
>> systems anywhere.  New protocols are designed that work around the limitations
>> of the old protocols.  It has taken Unix some 15 years to figure out how to
>> retrofit Unicode into its byte-oriented view of the world.  Things get messy
>> but that is the price we pay for backward-compatibility.

> I don't disagree, but the mere fact new protocols are developed to
> handle the new as well as theold is in itself a change in the interface.

Now you're playing semantic games.  The subject under discussion is a
decision where the developers intentionally messed with experienced
users on the theory that they can deal with the pain.

That's the kind of change we're talking about.

If someone working on "ls" made a change that broke dired, you might see
the situation differently.

> Citing an example that shows no interface change doesn't really counter
> the arguement, but citing one that has changed would seem to.

Yes, the switch to unicode and utf-8 was difficult to accomplish without
any pain to existing users, because of the nature of utf-8.  Even if
this case, many developers worked hard at making things Just Work, and
they *almost* succeeded.

Re: line-move-visual

[Stefan Monnier]

>> A third suggestion is that we should start thinking of Emacs as
>> mission-critical software.
> It amazes me that anyone would think otherwise.

Based on the amount of bugs in Emacs, the wishy-washy semantics of most
of its operations, the quick&dirty half-solutions seen in most of its
packages, it amazes me that someone would consider Emacs as
mission-critical ;-)


        Stefan "who never uses Emacs while root"

Re: line-move-visual

[Uday S Reddy]

On 6/10/2010 8:57 PM, Stefan Monnier wrote:

>
> Based on the amount of bugs in Emacs, the wishy-washy semantics of most
> of its operations, the quick&dirty half-solutions seen in most of its
> packages, it amazes me that someone would consider Emacs as
> mission-critical ;-)

Mission-critical software isn't necessarily perfect software.  What software is?

Mission-critical software requires a clean architecture, attention to 
fundamental notions of reliability, a design that can isolate any potential 
problems and an ability to recover from them.  Even though you seem to think 
the semantics of the Emacs operations is wishy-washy (and I have pointed out 
some of them to you myself), the Emacs manuals - both the user's manual and the 
programming manual - are of quite high-quality and do an excellent job of 
defining things.  We can generally spot the portions that are wishy-washy or 
too complicated for comfort and stay away from them.  The use of Lisp with type 
safety and memory safety means that even inexperienced programmers can usually 
deliver code of decent quality.  The various fail-safe mechanisms, such as 
autosave, backups, movemail etc, help for failure recovery.  The large, 
professional user base, along with its age, imply that most problems have been 
identified and fixed a long time ago.  The small developer community might also 
mean that it grows at a manageable pace (even though that seems to be changing 
now).

When I was trawling through the net, I found somebody say that nobody ever lost 
an email message in VM (the Emacs package for email that I currently maintain). 
  When I enquired about it, it was pretty much true.  There is only one known 
instance of mail folder corruption, which happened due to the unibyte-multibyte 
transition of Emacs around the same time that Kyle Jones was retiring from VM. 
  So, the transition was apparently half-done and wasn't discovered until much 
later.

In comparison, I have lost loads of emails in Microsoft tools, lost files or 
changes to files in the Office Suite, had files damaged by Sun-Microsoft file 
servers, and had damaging system crashes due to hardware/device driver faults. 
  On the whole, Emacs has been among the most reliable of all the tools I use. 
  And, I suspect that must be true for almost all of us here.  So, please do 
own up to this proud heritage!

>
>          Stefan "who never uses Emacs while root"

I guess you will have to amplify this point for us to draw the right 
conclusions from it.

Cheers,
Uday

Re: line-move-visual

[Tassilo Horn]

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

Hi Uday,

> In this particular instance, the customization needed is not a big
> deal: set line-move-visual to nil.  Almost everybody can do it.  But
> the time they had to spend in discovering that they needed to change
> it is what has been significant.

IMO, the first thing a new emacs user should learn is using the help
facilities.  So after seeing that `C-n' moved point not to the next
(logical) line as it always did should be a reflexive `C-h C-n':

,----[ C-h k C-n ]
| C-n runs the command next-line, which is an interactive compiled Lisp function
| in `simple.el'.
| 
| It is bound to C-n, <down>.
| 
| (next-line &optional ARG TRY-VSCROLL)
| 
| Move cursor vertically down ARG lines.
| [...]
| If the variable `line-move-visual' is non-nil, this command moves
| by display lines.  Otherwise, it moves by buffer lines, without
| taking variable-width characters or continued lines into account.
| [...]
| 
| If you are thinking of using this in a Lisp program, consider
| using `forward-line' instead.  It is usually easier to use
| and more reliable (no dependence on goal column, etc.).
`----

> (In fact, after this thread started, I began to wonder if VM might be
> vulnerable to the problem as well, and went and checked if there were
> calls to next-line anywhere.  There were three of them!)

As you can see in the docs above, `next-line' wasn't the right function
to call from lisp even before visual line movement.

> By the way, I think that the Emacs 23 visual-line-mode and word
> wrapping are a great addition to Emacs.  A civilized way of dealing
> with longlines has long been needed.  But the default setting of
> line-move-visual is an independent issue to that.

I agree with all of that.

Bye,
Tassilo

Re: line-move-visual

[Uday S Reddy]

On 6/6/2010 4:21 PM, Tassilo Horn wrote:

>> In this particular instance, the customization needed is not a big
>> deal: set line-move-visual to nil.  Almost everybody can do it.  But
>> the time they had to spend in discovering that they needed to change
>> it is what has been significant.
>
> IMO, the first thing a new emacs user should learn is using the help
> facilities.  So after seeing that `C-n' moved point not to the next
> (logical) line as it always did should be a reflexive `C-h C-n':

Note that we are talking about the old emacs users, not the new ones.  (The C-n 
compromise was apparently made to help the new Emacs users!)

An old emacs user might see a long logical line only very rarely, and he might 
take quite a while to realize that anything had changed.  As Mark Crispin 
explained, he had to purposefully go looking for it by doing M-<large number> 
C-n on a number of Emacs versions to discover that something had changed.   I 
had to hear of Mark's experience before I started suspecting that there could 
be vulnerabilities in VM.  (I accept that using `next-line' in elisp code is 
not a clever thing to do, but we live in the world of "free software" where 
lots of people contribute.)  How much elisp code might still be there that has 
this vulnerability?  We won't know.  Just as an experiment, I went to the 
emacs-23.2 lisp directory and did a grep for next-line.  There were 91 hits. 
How many of them are safe?

I myself noticed the changed C-n very quickly because I work with Emacs 
debugger a lot, where long lines are common.  First I thought it was kind of 
cute, then I got annoyed because I had to find new ways of skipping over 
bytecode pieces that span lots of lines, and now I am alarmed as I think of the 
vulnerabilities that might exist in elisp code.  If I used keyboard macros a 
whole lot (which I don't), then I would have been even more affected.

However, it didn't occur to me that I could freely set `line-move-visual' to 
nil and all the problems would disappear.  I thought that the setting was 
probably mixed up with word wrapping and visual-line-mode and all that stuff 
that I care about.  It was only after Stefan himself said:

"Yes, it's inconsistent, yes, it's a compromise, no not everybody likes it. 
Then (setq line-move-visual nil) in your .emacs and live happily ever after."

... only then did I understand that the emacs devs had done a completely 
pointless thing that I could easily revert.

Cheers,
Uday

Re: line-move-visual

[Stefan Monnier]

> The byte-compiler already warns about uses of next-line because it
> rarely makes sense to use next-line in lisp code anyway (forward-line is
> usually more appropriate, especially for parsing).  So it's very likely
> that the remaining occurrences have been inspected by developers very
> carefully.

Not sure about "very" since we've had some bug reports after the
warnings were fixed, but yes.  BTW my grep only finds 22 occurrences
(in Emacs trunk rather 23.2, but the difference should be small).


        Stefan

Re: line-move-visual

[Alain Ketterlin]

Sorry to break the thread, but...

The message I'm following up to has been sent from Thunderbird with
format=flowed, i.e., it contains very long lines, much longer than the
usual 80-column text. It's painful to read, cite in replies, etc.

Is there any way to make gnus reformat such messages to make them fit
the standard Usenet width? My current gnus config is the absolute
minimum. Any help is welcome, even if it takes the form of a few
keywords to help me search the doc. Thanks,

-- Alain.

P/S: I've removed comp.lang.lisp from the Newsgroups:

Re: Wrong use of format=flowed antidote

[Uday S Reddy]

On 6/6/2010 6:09 PM, Reiner Steib wrote:

>
> That is because the user misconfigured Thunderbird.  format=flowed
> applied as intended doesn't suffer from this problem.

You were right.  I have discovered that one has to set mailnews.wraplength to 
get format=flowed to kick in.  I have now set my wraplength to 79 (leaving an 
extra column for the last space).  Let us hope this works ok.

In general, my principle is to put as few line breaks as possible because your 
editor can add line breaks easily wherever you want it to.  On the other hand, 
if I put too many line breaks and you want them removed, your editor won't know 
which ones to remove.

Format=flowed is a good compromise.

Cheers,
Uday

Re: line-move-visual

[Joost Kremers]

Alain Ketterlin wrote:
> The message I'm following up to has been sent from Thunderbird with
> format=flowed, i.e., it contains very long lines, much longer than the
> usual 80-column text. It's painful to read, cite in replies, etc.

then that's not actually format=flowed. format=flowed means that the text is
still wrapped, but each line ends in a space followed by a newline. the
receiving client can then choose to reformat the message.

But paragraphs without line breaks (i.e., unwrapped) is *not* format=flowed.


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: line-move-visual

[Mark Crispin]

On Sun, 6 Jun 2010, Uday S Reddy posted:
> In this particular instance, the customization needed is not a big deal: set 
> line-move-visual to nil.  Almost everybody can do it.  But the time they had 
> to spend in discovering that they needed to change it is what has been 
> significant.

An additional significant burden is the need to update .emacs files on 
dozens of machines in order to keep common functionality.  There is a huge 
scalability problem.

There are things that you can do to avoid 2^n synchronization, such as 
designating one system as having the "master" copy from which all others 
are updated.  But then, each time you encounter a problem on a "slave" 
that necessitates a change to the slave, you must:
  [1] make the corresponding change to the master
  [2] test on the master
  [3] test on at least one other slave
  [4] push the update from the master to all other slaves

The fun and laughter proceeds apace if you don't have access to the master 
at that point of time.  Then you have to make a note that you needed this 
change, and subsequently find that note when you can get to the master 
again.

And all this presumes that it's a set that is harmless in old versions. 
The true joy comes in when the change has an unintended bad effect in 
some other slave and you didn't catch it in step [3].

The best case wastes a great deal of time, repeated for each affected 
user.  The worst case is a nightmare.

Part of the maturing process is learning to recognize when a simple 
cookbook solution is neither simple nor cookbook nor solution.

> (In fact, after this thread started, I began to wonder if VM 
> might be vulnerable to the problem as well, and went and checked if there 
> were calls to next-line anywhere.  There were three of them!)

I hope that you didn't have any corrupted files as a result.

> It is not for nothing that we have ideas like standards and 
> backward-compatibility.  It didn't seem to me that the discussion on the 
> developers list showed much appreciation to these issues, despite them having 
> been raised repeatedly.

A clueless developer is a very bad thing.

> By the way, I think that the Emacs 23 visual-line-mode and word wrapping are 
> a great addition to Emacs.  A civilized way of dealing with longlines has 
> long been needed.  But the default setting of line-move-visual is an 
> independent issue to that.

Let me be clear; I have no objection whatsoever to the feature having been 
added and made available.

The issue is it having been made the default, particularly in modes where 
it is pointless.

It is also important to realize that there are many editors that handle 
long lines in a "civilized" way.  However, in certain circumstances, it is 
desirable and necessary to handle long lines the "uncivilized" way; and it 
is a feature of emacs that it can do that.

No amount of raving about how the "civilized" way is better will change 
those circumstances.  The only effect of enforcing the "civilized" way is 
to render emacs unsuitable for those applications.

For example, I have a scripted procedure which depends upon emacs' 
"uncivilized" behavior.  It is followed by individuals who never use emacs 
for any other reason.  I have no control over what version they use, but 
that had always been alright since every program that ever called itself 
emacs worked the same way with it.  Until now.

I don't know what I'm going to about that procedure.  I'm probably going 
to have to write a program and/or a sed script to replace it.  This is 
unfortunate, since an advantage of the emacs method was that the user 
could see what the procedure was doing.

All because of clueless developers who broke emacs in version 23.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Mark Crispin]

On Sun, 6 Jun 2010, Thad Floryan posted:
> This is OT so I'll keep it short.  Similar braindamage recently with
> Fedora where a developer stated "I don't particularly care how UNIX
> has always worked."

Wow.

I've dealt with broken "improvements" in RedHat/Fedora before; they don't 
seem to have a very good review process for functionality changes.  The 
two that I remember the most are making flock() return ENOLCK for an NFS 
file (instead of no-op) and getaddrinfo() doing a reverse DNS lookup for 
the ai_canonname return value.  In both cases, the developer insisted that 
the change was a "fix", never mind all the applications that were broken 
by it.  Eventually, both of these changes were reverted after a huge hue 
and cry.

This one takes the cake.

I don't know which amazes me more, the fact that such an ill-conceived 
change was made in the first place, or the developer's reaction when 
called to account.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Tim X]

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

> On 6/6/2010 10:39 AM, David Kastrup wrote:
>
>> Free software is based on the premise of empowering the recipient of
>> software to change and adapting it according to his own needs.
>>
>> Pampering to the needs of users who are not interested in changing and
>> adapting the software according to their needs is not a major priority.
>>
>> Feel free to fork any free software which does not behave like you want
>> it: you have the power.  You are not dependent on upstream developers.
>
> Good point.  But not all users have the time or the ability to do their own changing or forking or even significant customization.  Allowing the *possibility* of users to change things is not the same as *expecting* them to change things.
>
> In this particular instance, the customization needed is not a big deal: set line-move-visual to nil.  Almost everybody can do it.  But the time they had to spend in discovering that they needed to change it is what has been significant.  (In fact, after this thread started, I began to wonder if VM might be vulnerable to the problem as well, and went and checked if there were calls to next-line anywhere.  There were three of them!)
>

The change was clearly documented in the NEWS file, which also explained
how to restore the old behavior. Any user who upgrades to a new version
and is too lazy to check the NEWS file (and the PROBLEMS file for that
matter), especially after observing unexpected or different behavior
gets what they deserve. 

Tim



-- 
tcross (at) rapttech dot com dot au

Re: line-move-visual

[Stefan Monnier]

> The change was clearly documented in the NEWS file, which also explained
> how to restore the old behavior.

Admittedly, this file is loong.  We should probably try to make
a "revert to old defaults" section somewhere so it's easier to find
those things.


        Stefan

Re: line-move-visual

[Joseph Brenner]

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

>> The change was clearly documented in the NEWS file, which also explained
>> how to restore the old behavior.
>
> Admittedly, this file is loong.  We should probably try to make
> a "revert to old defaults" section somewhere so it's easier to find
> those things.

Actually... if you're planning of having a section like that, 
I'd suggest there's already a bigger problem. 

Re: line-move-visual

[Joseph Brenner]

David Kastrup <dak@gnu.org> writes:
> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>
>> Coupled with these real technical issues, there are the attitudinal
>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>> and what have you.
>
> Everybody is free to join the discussions on the Emacs developer lists.
> Those who choose not to help with the work don't get to criticize the
> results.  A common democratic principle.

So... if I want to avoid breakage-on-upgrade on my system, I need to
become a member of the development process of:

  emacs
  linux kernel
  ubuntu (and presumably debian)
  x windows

Not to mention:

  apache
  postgresql
  perl
  mh-e
  mh

...and much more.

If I thought everyone in the free and/or open world really believed this,
I would've voted with my feet a long time ago.

(Maybe you should stop pretending you're our spokesman, huh?)

Re: line-move-visual

[Mark Crispin]

On Wed, 9 Jun 2010, Jim Diamond posted:
> David: the message (about fundamental features changing being a Bad
> Thing) was delivered in a less than gentle way,

I proved that it was necessary.  His sort will stonewall - it's their 
nature - but now he has egg on his face.

> but I think you should
> re-consider the idea, as opposed to the way it was delivered.

He won't.

But perhaps he will think twice before making future pointless changes 
like this.

> Further, your comment "Those who choose ... A common democratic
> principle." is just plain wrong.  But I assume you know that.

He doesn't.  You have to take him at his word.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[Mark Crispin]

On Fri, 4 Jun 2010, Uday S Reddy posted:
> Having used Emacs for some 30 years myself, I always expect a few surprises 
> with a new major version of Emacs.

Why should users expect surprises?

> It takes me a few months to read through 
> all the change logs and the new manual sections to become comfortable with 
> all the new and changed features.

Why should users - who presumably have work to do - be obliged to do this?

> Sometimes when there are significant new 
> features, the old version just stays, because several users are uncomfortable 
> with the new version.   The good thing about free software is that you can do 
> that!

Until there is some support issue with the old version, such as a major 
security bug, and the software developers refuse to fix it - "update that 
ancient version you stupid idiot."

> Reading through the emacs-developers list yesterday,

It's nice that you have time to do that.

> I also discovered that 
> there is an Options -> Customize -> New Options menu

I turned off that stupid menu years ago.  I need every screen line.  I 
want to use emacs, not MS Word.

> As I said before, the line-move-visual setting has been a complex decision 
> for the developers.

And they screwed it up.

This is getting ridiculous.  My .emacs file is getting bigger and bigger, 
not to do any customizations but rather [1] to restore behaviors that some 
arrogant and irresponsible software developer decided to change; and [2] 
so that emacs on the dozens of machines I routinely use works the same on 
each and every one of them for the very basic command set that I use.

It does no good whatsoever to tell me that I should get used to the 
change.  Other machines don't have that change.  Some are still in emacs 
18.  Others are bleeding edge.

I should not have to customize emacs so that CTRL/A, CTRL/E, CTRL/N, and 
CTRL/P continue to work the way they've done since the mid-1970s.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[David Kastrup]

Mark Crispin <mrc@panda.com> writes:

> On Fri, 4 Jun 2010, Uday S Reddy posted:
>> Having used Emacs for some 30 years myself, I always expect a few
>> surprises with a new major version of Emacs.
>
> Why should users expect surprises?
>
>> It takes me a few months to read through all the change logs and the
>> new manual sections to become comfortable with all the new and
>> changed features.
>
> Why should users - who presumably have work to do - be obliged to do
> this?

Why should they install newer versions if they don't want things to
change?

>> I also discovered that there is an Options -> Customize -> New
>> Options menu
>
> I turned off that stupid menu years ago.  I need every screen line.  I
> want to use emacs, not MS Word.

Why don't you get and install a suitably old version and stay with it?

> It does no good whatsoever to tell me that I should get used to the
> change.  Other machines don't have that change.  Some are still in
> emacs 18.  Others are bleeding edge.

Install Emacs 18 everywhere and you are finished.

> I should not have to customize emacs so that CTRL/A, CTRL/E, CTRL/N,
> and CTRL/P continue to work the way they've done since the mid-1970s.

Install a version of Emacs from the mid-1970s, and you get the behavior
of Emacs from the mid-1970s.  What is so hard about that?

-- 
David Kastrup

Re: line-move-visual

[Mark Crispin]

On Sun, 6 Jun 2010, David Kastrup posted:
> So you think that Emacs development should stop in order to save
> helpless end users from having new versions installed to them?

No.  I think that developers have a responsibility not to make changes to 
fundamental functionality.

> What makes you think that Emacs developers are responsible for end users
> subjected to restrictive administrations?

Any developer who does not feel responsible to the end users has no 
business being a developer.

> To a degree where you think heaping abuse on them is the right answer
> for your problems with authorities?

They deserve it when they do something that is abusive to the end users. 
Hopefully they learn from the mistake and not repeat it.

> What makes you think that Emacs developers are responsible for
> maintaining the rug of end users?

Any emacs developer who does not feel responsible for maintaining the rug 
of end users has no business being an emacs developer.

The open source community spent a long time trying to obtain credibility 
in the face of PHBs who claim that open source is "unreliable hacker 
code."  If it weren't for the intense efforts of the Ubuntus of the world 
to get stuff "ready for prime time", open source software would languish 
in obscurity.

Developers who pull antics such as changes to fundamental functionality 
destroy this hard-won credibility.

Don't kid yourself.  The opponents of open source are pushing back.  Part 
of the "embrace, extend, destroy" strategy of proprietary vendors is to 
attack open source as being "unreliable hacker code."

I have, in my collection of papers, a remarkable document which basically 
argues that nobody should run open source software because only 
proprietary software (which is "written by professional programmers") is 
trustworthy.  It's laughable, except when an open source developer does 
something irresponsible that make PHBs go "a-ha!"

There needs to be some soul-searching.  There are reasons why proprietary 
systems occupy the majority of end user platforms.  Not all of those 
reasons are due to vendor FUD.

Now, if it's a design goal that open source software be the exclusive 
tools of the elite, then perhaps it's alright to make unilateral changes 
to default functionality for everybody.  But in that case, don't expect 
the "l33t" to be more than a very small community.  Don't expect that your 
work will end up being particularly significant either.

Being a developer requires humility.

>>> Install a version of Emacs from the mid-1970s, and you get the
>>> behavior of Emacs from the mid-1970s.  What is so hard about that?
>> Have you done it?
> In the mid-70s?  No.

Perhaps you ought to be quiet when you don't have a clue.

> That's the point of time _you_ mentioned.

I referred to this incompatible change as being something that changed 
fundamental functionality that had been there since the 1970s.

You were the one who went off snidely about "install a version of emacs 
from the mid-1970s".

>> Do you have a clue as to what the task entails?
> Yes.

I doubt it.

>> Do you know what you made a completely idiotic statement?
> Well, _you_ were the one talking about the mid-70s.

Perhaps you ought to be quiet when you don't have a clue.

>> I can answer "yes" to all three questions.
> Congratulations.  Compiling and installing GNU Emacs before its
> existence is indeed an impressive feat.

I assure you that I compiled, installed, and used emacs in the mid-1970s.

Too bad that you are so lacking in a clue that you do not know that GNU 
emacs was not the first emacs.  Nor was it the second.  Nor even the 
third.

> You really don't want to start a dick size contest in these categories
> with me.

Sorry, I'm straight.  Look for your boyfriends someplace else.

> Oh, by the way: for somebody claiming to work with Emacs since the 70s,
> it is a somewhat unimpressive track record for Emacs to not contain a
> single code contribution by you.

This, coming from the same gnu.org people who claim credit for the work of 
others ("call it GNU/Linux"!), and have promised (for 30 years!) but never 
deliver on their new wonderful operating system that will have all the 
features of ITS.  Yawn.

Maybe, just maybe, people have other projects than a text editor.  Far 
more people use the work that I have done than have/will ever use emacs.

A text editor is not an end unto inself.  It is at best a means to an end. 
Very few people today use emacs for document preparation; that is not, nor 
has it ever been, its strength.

Since you asked, the UI principle of functional symmetry in which C-<x> 
operates on a character and M-<x> operates on a word was mine.  I had 
C-M-<x> operate on a sentence, but that was changed to S-expression early 
on when it turned out that nobody used the sentence operators and nobody 
defended those key bindings either.  I did this in my proto-emacs macro 
library (which predated emacs by about 6 months) and convinced RMS (it 
didn't take much convincing) that this was the way to go.

You can also thank me for things like file operators prompting for their 
value instead of putting you in a program minibuffer with a bunch of TECO 
(or LISP code) with the cursor at where you should type the file name. 
Once upon a time, most commands simply preloaded a minibuffer with the 
contents of the macro to do it.  It didn't take much argument from me to 
convince RMS on that matter either.  But I was the one who went and said 
that dumping the user in code in a minibuffer sucks.

I wrote some code in the original PDP-10 version, but I have long since 
forgotten what it was and it doesn't matter anyway since that code is 
extinct for all practical purposes.

emacs was the fusion of many people's ideas.  I would not presume to claim 
that I made a major contribution; it wasn't.  But it wasn't zero either. 
Probably those design elements would have happened anyway.  But they 
hadn't happened until I talked RMS into them.

Design elements live on.  GNU emacs' advantage was that it was a 
functional superset (substantial) of the PDP-10 version yet required no 
retraining for users of the old version.

More important, just about every program that calls itself emacs behaves 
in predictable ways on a certain basic set of command keys.  All of a 
sudden, GNU emacs has broken this by default.

It's as if someone were to decide that GCC should change "/" to get an 
APL-style reduce operator, since division is just multiplication by the 
inverse.  And, when a user complains, the developer says "if you don't 
like the way the current version of GCC works then install an older 
version."

> Do you really think you are in the best position to call the developers
> names?

When developers do something idiotic and irresponsible, it is perfectly 
proper to call them on it.

If you are the irresponsible idiot that make this change, then you deserve 
it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[David Kastrup]

Mark Crispin <mrc@panda.com> writes:

> On Wed, 9 Jun 2010, Joseph Brenner posted:
>> May I suggest that:
>>  (1) Backwards compatibility is important.
>>  (2) Gratuitious changes should be avoided.
>>  (3) Breakage on upgrade is Not Good.
>> I can't believe we even need to argue about this.
>
> With arrogant system programmers, you do.

If you like beating up strawmen.  The actual question is what
constitutes "gratuitious" and how to weigh different categories.  That
is decided in discussions on the developer lists which everybody can
participate in.

Spouting abuse in other lists, in contrast, is not going to cause a
difference except to self-importancy.

-- 
David Kastrup

Re: line-move-visual

[Stefan Monnier]

>> Having used Emacs for some 30 years myself, I always expect a few
>> surprises with a new major version of Emacs.
> Why should users expect surprises?

To spice things up, of course.

>> I also discovered that there is an Options -> Customize -> New Options
>> menu
> I turned off that stupid menu years ago.  I need every screen line.  I want
> to use emacs, not MS Word.

C-mouse-3 shows you the menu, even when it's not displayed.

>> As I said before, the line-move-visual setting has been a complex decision
>> for the developers.
> And they screwed it up.

Yup, big time,


        Stefan

Re: line-move-visual

[Mark Crispin]

On Fri, 4 Jun 2010, Stefan Monnier posted:
>> Why should users expect surprises?
> To spice things up, of course.

Young system programmers seem to do this a lot, before they acquire the 
judgement to know better.

>>> As I said before, the line-move-visual setting has been a complex decision
>>> for the developers.
>> And they screwed it up.
> Yup, big time,

Indeed.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: line-move-visual

[sable]

On Jun 3, 6:11 pm, Mark Crispin <m...@panda.com> wrote:

> I don't care if M-X fart-noisily-with-spray changes its default scent from
> skunk to lemon.  

LOL!!!

line-move-visual

[Johan Myréen]

Could somebody please explain to me what the idea behind the new concept of 
"visual lines" in Emacs is?

Emacs has always been a "line-oriented" editor, i.e. the buffer consists of 
logical lines. These lines can occasionally wrap so that they spill over to 
the next visual line, but the main concept is still the logical line. This has 
been the mindset of Emacs users since the dawn of time. 

I was shocked to find out that this doesn't seem to be true anymore: by 
default C-n and C-p do not move to the next and previous logical lines, but 
instead place the cursor on the next or previous visible line. I find this 
totally counterintuitive. If I press C-n five times, I expect to find the 
cursor five (logical) lines down, regardless if they happen to be wrapped or 
not. It is not consistent either: why don't C-a and C-e then move to the 
beginning and end of the visual line. Or why does C-k kill until the end of 
the logical line, and not the visual line?

Yes, I know the old behaviour can be restored: after some digging I found out 
about the line-move-visual variable. Couldn't the default be nil instead of t?

Please do not forget what Gnu Emacs stands for: Generally Not Used, Except by 
Middle-Aged Computer Scientists. With changes like this you risk alienating 
the few of us that are left.

Johan Myreen
Emacs user since the mid 1980s

Re: line-move-visual

[Bastien]

Johan Myréen <jem@iki.fi> writes:

> Could somebody please explain to me what the idea behind the new concept of 
> "visual lines" in Emacs is?

Take your breath and deep into this discussion:

  http://article.gmane.org/gmane.emacs.devel/101560

I also agree the default for `line-move-visual' should be nil.
Some other developers expressed their dislike about visual line 
mode in many ways.  See this recent comment on orgmode list:

  http://article.gmane.org/gmane.emacs.orgmode/15224

> Emacs has always been a "line-oriented" editor, i.e. the buffer consists of 
> logical lines. These lines can occasionally wrap so that they spill over to 
> the next visual line, but the main concept is still the logical line. This has 
> been the mindset of Emacs users since the dawn of time. 
>
> I was shocked to find out that this doesn't seem to be true anymore: by 
> default C-n and C-p do not move to the next and previous logical lines, but 
> instead place the cursor on the next or previous visible line. I find this 
> totally counterintuitive. 

So do I.

IIRC we never had a vote about this issue - maybe it's time to have it.

> Yes, I know the old behaviour can be restored: after some digging I found out 
> about the line-move-visual variable. Couldn't the default be nil instead of t?
>
> Please do not forget what Gnu Emacs stands for: Generally Not Used, Except by 
> Middle-Aged Computer Scientists. With changes like this you risk alienating 
> the few of us that are left.

Hey!  Stay here.  I hope we'll fix this.

-- 
 Bastien

Re: line-move-visual

[Miles Bader]

Bastien <bastienguerry@googlemail.com> writes:
> IIRC we never had a vote about this issue - maybe it's time to have it.

It's almost impossible to get a representative sample of Emacs users, so
what would be the point?

Emacs is not a democracy, although the maintainers generally pay a lot
of attention to the opinions and arguments of others.  In the face of
contentious changes, it's the job of the maintainers to understand the
arguments on both sides and make a judgement call as to what the best
solution for the entire Emacs user base is.

I guess if you think you have arguments that nobody has seen before, you
could present them (it seems a bit unlikely though).

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish
are breaking up??!  Shit, white people oughtta understand, their job is to
GIVE people the blues, not to get them!  -- George Carlin

Re: line-move-visual

[Bastien]

Miles Bader <miles@gnu.org> writes:

> Bastien <bastienguerry@googlemail.com> writes:
>> IIRC we never had a vote about this issue - maybe it's time to have it.
>
> It's almost impossible to get a representative sample of Emacs users, so
> what would be the point?

The vote is a way to know the opinion of a subset of Emacs users.
Whether this subset is representative or not may be a good question, 
but a poll can still be useful without an answer to this question.

> Emacs is not a democracy, although the maintainers generally pay a lot
> of attention to the opinions and arguments of others.  In the face of
> contentious changes, it's the job of the maintainers to understand the
> arguments on both sides and make a judgement call as to what the best
> solution for the entire Emacs user base is.

Agreed.  A vote is a tool to help maintainers pay attention.  

> I guess if you think you have arguments that nobody has seen before, you
> could present them (it seems a bit unlikely though).

I didn't enter this discussion because basically my arguments were
already stated by others.  A vote is also great for sparing the time of
everyone: express an opinion once and let X person vote for it without
the need to express their arguments for this opinion again and again.

Anyway.  

I created a poll.  The result are send by email to me.  Would be better
to send the results to the maintainers, though - but it's just sort of a
proof of concept.

  "Should line-move-visual default to nil or t?"
   http://www.micropoll.com/akira/mpview/623312-182840

If people are interested in launching such a poll, please do so.

-- 
 Bastien

Re: line-move-visual

[Kenichi Handa]

In article <87ocrtulzd.fsf@bzg.ath.cx>, Bastien <bastienguerry@googlemail.com> writes:
> I created a poll.  The result are send by email to me.  Would be better
> to send the results to the maintainers, though - but it's just sort of a
> proof of concept.

>   "Should line-move-visual default to nil or t?"
>    http://www.micropoll.com/akira/mpview/623312-182840

Options should be "nil" and "t", or the question should be
"Should line-move-visual default to nil".

---
Kenichi Handa
handa@m17n.org

Re: line-move-visual

[Bastien]

Kenichi Handa <handa@m17n.org> writes:

> In article <87ocrtulzd.fsf@bzg.ath.cx>, Bastien <bastienguerry@googlemail.com> writes:
>> I created a poll.  The result are send by email to me.  Would be better
>> to send the results to the maintainers, though - but it's just sort of a
>> proof of concept.
>
>>   "Should line-move-visual default to nil or t?"
>>    http://www.micropoll.com/akira/mpview/623312-182840
>
> Options should be "nil" and "t", or the question should be
> "Should line-move-visual default to nil".

Er, yes.  Another try:

  http://www.micropoll.com/akira/mpview/623323-182852

-- 
 Bastien

Re: line-move-visual

[Alfred M. Szmidt]

Would it be posisble to do such a poll by email?

Re: line-move-visual

[Bastien]

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

> Would it be posisble to do such a poll by email?

Sure.

-- 
 Bastien

Re: line-move-visual

[Scot Becker]

Good defaults are important.  They are not the answer.

Discoverability is key.  This could be done through a customize
interface, as Stephen suggests or simply through a piece of startup
documentation called "Things you might want to tweak."   This would
contain not just the  "wacky new variables that dazzle old-timers,"
but also the flip side, the so-called "crufty unixy defaults which
trip up newbies".  As well as the "defaults more for writers of
natural languages" and "defaults more for coders," and so on.

The Emacs developers take obvious care in making thoughtful defaults,
and this list takes impassioned (!) care to help them do it.  But the
real issue for a variable like this is that the user knows that it's
there and can set it to get what s/he wants with a minimum amount of
work.

There exist beginner customization helps (e.g. on the EmacsWiki or in
the many init files on the web), but I think it would be worth it to
identify a set of 10-30 variables and tweaks which are most
significant in helping new users (or new users of a given release) get
Emacs to broadly behave in ways that are congenial to them.  These can
be put into a customize buffer or a new Quick-Start-Tweaks doc (or
best: in both).  This should be taken in to the official Emacs
distribution, and linked to on the open Splash screen.

The set should include not recently-introduced, but also things of
broad impact on the user experience which broad sections of our target
audience may reasonably need one way or the other.

Scot

Vim user from 1997-2008.  Emacs user since the introduction of visual-line-mode.

Re: line-move-visual

[Eli Zaretskii]

> Date: Fri, 10 Jul 2009 09:43:37 +0100
> From: Scot Becker <scot.becker@gmail.com>
> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
> 	Kenichi Handa <handa@m17n.org>
> 
> Discoverability is key.  This could be done through a customize
> interface, as Stephen suggests or simply through a piece of startup
> documentation called "Things you might want to tweak."

We already have a feature that is close to that:

  Options->Customize Emacs->New Options

It asks for an old version, and presents a Customize buffer with all
options changed or introduced since that version.

Re: line-move-visual

[Lennart Borgman]

On Fri, Jul 10, 2009 at 10:57 AM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>> From: Scot Becker <scot.becker@gmail.com>
>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>>       Kenichi Handa <handa@m17n.org>
>>
>> Discoverability is key.  This could be done through a customize
>> interface, as Stephen suggests or simply through a piece of startup
>> documentation called "Things you might want to tweak."
>
> We already have a feature that is close to that:
>
>  Options->Customize Emacs->New Options
>
> It asks for an old version, and presents a Customize buffer with all
> options changed or introduced since that version.

Yes, that is good, but I think that Scot more asked for function to
"explain and customize options a new Emacs user might want to tweak".

I think it is a good suggestion.

Re: line-move-visual

[Bastien]

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

> Yes, that is good, but I think that Scot more asked for function to
> "explain and customize options a new Emacs user might want to tweak".
>
> I think it is a good suggestion.

+1

Org-mode has such a beginner's guide to customization:

  http://orgmode.org/worg/org-configs/index.php
  http://orgmode.org/worg/org-customization-guide.php

It can be a good source of inspiration.

-- 
 Bastien

Re: line-move-visual

[Scot Becker]

Right.  I know about "New Options"  It's Good, and to my mind
basically answers the OP's concern.  But I wanted to shift the
discussion slightly from just the 'new options' to 'significant
options (new or not) for which different usage scenarios might dictate
different defaults.'  Of course ANY of the user configurable variables
might count *to someone* as belonging to that category.  But it seems
that there are things that come up on this list that are genuinely
(and earnestly) disputed, since multiple defaults make sense, each for
a different (broad) portion of the Emacs community.  These should be
easier to find than they are.  This then would make the agonizing
issue of what the proper default should be a little less agonizing.

Scot


On Fri, Jul 10, 2009 at 9:57 AM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>> From: Scot Becker <scot.becker@gmail.com>
>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>>       Kenichi Handa <handa@m17n.org>
>>
>> Discoverability is key.  This could be done through a customize
>> interface, as Stephen suggests or simply through a piece of startup
>> documentation called "Things you might want to tweak."
>
> We already have a feature that is close to that:
>
>  Options->Customize Emacs->New Options
>
> It asks for an old version, and presents a Customize buffer with all
> options changed or introduced since that version.
>

Re: line-move-visual

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>> From: Scot Becker <scot.becker@gmail.com>
>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>> 	Kenichi Handa <handa@m17n.org>
>> 
>> Discoverability is key.  This could be done through a customize
>> interface, as Stephen suggests or simply through a piece of startup
>> documentation called "Things you might want to tweak."
>
> We already have a feature that is close to that:
>
>   Options->Customize Emacs->New Options
>
> It asks for an old version, and presents a Customize buffer with all
> options changed or introduced since that version.
>

It would be nice to have something similar to the "skinnability feature"
some other applications have.

It would make use of Custom, and would allow to group together
Customizable features in a coherent theme.

So, the default for "line visual" would be nil in the "emacs oldtimer"
skin, and t in "emacs newbie" skin. There would also be a "Windoze for
the w*n" skin that would have cua defaults, etc.

Just as the "emacs->new options" feature, the skin feature would keep
track of defaults that are new in this particular emacs for this
particular skin.

It would also keep track of for which options the user has decided to
diverge from the customize options from the default.

The feature could also support trying out different themes. Also purely
cosmetical options like those supported by "color-theme" should be
provided.


-- 
Joakim Verona

Re: line-move-visual

[Scot Becker]

On "skinnability"   Yes.  Something like that is good, especially if
all of the changed variables can be brought together into one place
for tweaking.   I have wondered whether 'customize' is capable of
letting a user collect an arbitrary set of variables for the attention
of other users. (Seems that the groups a variable belongs to are hard
coded, though).   I'm playing with developing an 'Emacs configuration
for writers', which could benefit from this kind of thing.  And it
would be a good approach to solving the present problem of 'sensible
defaults' for different kinds of users.

Scot


On Fri, Jul 10, 2009 at 10:13 AM, <joakim@verona.se> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>>> From: Scot Becker <scot.becker@gmail.com>
>>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>>>      Kenichi Handa <handa@m17n.org>
>>>
>>> Discoverability is key.  This could be done through a customize
>>> interface, as Stephen suggests or simply through a piece of startup
>>> documentation called "Things you might want to tweak."
>>
>> We already have a feature that is close to that:
>>
>>   Options->Customize Emacs->New Options
>>
>> It asks for an old version, and presents a Customize buffer with all
>> options changed or introduced since that version.
>>
>
> It would be nice to have something similar to the "skinnability feature"
> some other applications have.
>
> It would make use of Custom, and would allow to group together
> Customizable features in a coherent theme.
>
> So, the default for "line visual" would be nil in the "emacs oldtimer"
> skin, and t in "emacs newbie" skin. There would also be a "Windoze for
> the w*n" skin that would have cua defaults, etc.
>
> Just as the "emacs->new options" feature, the skin feature would keep
> track of defaults that are new in this particular emacs for this
> particular skin.
>
> It would also keep track of for which options the user has decided to
> diverge from the customize options from the default.
>
> The feature could also support trying out different themes. Also purely
> cosmetical options like those supported by "color-theme" should be
> provided.
>
>
> --
> Joakim Verona
>

RE: line-move-visual

[Drew Adams]

> I have wondered whether 'customize' is capable of
> letting a user collect an arbitrary set of variables for the attention
> of other users. (Seems that the groups a variable belongs to are hard
> coded, though).

Something like an `add-group' function that would let you easily add a Customize
group to a given option or face? Yes, that could be useful.

And for those who don't want to mess with any Lisp, Customize could have a
button or whatever to let you add a group for an option/face or for all of the
options and faces in the current Customize buffer.

I agree that this kind of thing would help users "package" things together,
including for sharing. The fact that the set of Customize groups for an
option/face is pretty much hard-coded is a (minor) limitation.

(OTOH, if we provide that, be prepared for more worms in the can. But I still
think it's a good idea.)

Re: line-move-visual

[Lennart Borgman]

On Fri, Jul 10, 2009 at 6:11 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> I have wondered whether 'customize' is capable of
>> letting a user collect an arbitrary set of variables for the attention
>> of other users. (Seems that the groups a variable belongs to are hard
>> coded, though).
>
> Something like an `add-group' function that would let you easily add a Customize
> group to a given option or face? Yes, that could be useful.

    (custom-add-to-group 'my-group 'my-variable 'custom-variable))

RE: line-move-visual

[Drew Adams]

> >> I have wondered whether 'customize' is capable of
> >> letting a user collect an arbitrary set of variables for 
> >> the attention of other users. (Seems that the groups a
> >> variable belongs to are hard coded, though).
> >
> > Something like an `add-group' function that would let you 
> > easily add a Customize group to a given option or face?
> > Yes, that could be useful.
> 
>     (custom-add-to-group 'my-group 'my-variable 'custom-variable))

Well, whaddya know?! Forgot about it, I guess.

So all that's missing in this regard is an easy, non-Lisp way for users to do
the same thing - e.g. a button in Customize.

And then perhaps a good way for users to share their groups (a la skins). Maybe
just create an EmacsWiki page (e.g. GroupsAsSkins) where people can upload their
groups to share.

But that would mean also having Customize produce a `custom-add-to-group' entry
when you add a group to an option, so you could then extract that code from your
custom-file to share.

RE: line-move-visual

[Drew Adams]

> And then perhaps a good way for users to share their groups 
> (a la skins). Maybe just create an EmacsWiki page (e.g.
> GroupsAsSkins) where people can upload their groups to share.
> 
> But that would mean also having Customize produce a 
> `custom-add-to-group' entry when you add a group to an option,
> so you could then extract that code from your custom-file to share.

Or maybe there already is a function that, given a Customize group name, returns
a list of all options and faces in that group (directly, not by inheritance)?

If so, then people could use that to get the list for a given "skin", and upload
it for others to see (or to try, by mapping over it using
`custom-add-to-group').

I thought maybe `custom-group-members' would do that, but it seems to list only
groups (even with nil GROUPS-ONLY), not options and faces.

Re: line-move-visual

[Miles Bader]

joakim@verona.se writes:
> It would be nice to have something similar to the "skinnability feature"
> some other applications have.
>
> It would make use of Custom, and would allow to group together
> Customizable features in a coherent theme.
>
> So, the default for "line visual" would be nil in the "emacs oldtimer"
> skin, and t in "emacs newbie" skin. There would also be a "Windoze for
> the w*n" skin that would have cua defaults, etc.

The name "skin" may be a misnomer, as typically they're basically
all-or-nothing groups of settings.

I don't think that's a good idea, nor is is a good idea to automatically
change lots of defaults without user-participation -- while we want to
allow the user to customize things easily, there's _also_ some advantage
if they stick to the standard defaults, both for the user (in his
ability to come to terms with emacs in the long term, and be part of the
emacs community), and for Emacs maintainers.

So, instead of changing lots of settings en-masse, (which would tend to
leave the user a bit ignorant of what just happened), how about just
having simple themed customization groups ("get off my lawn", "windows
luser", ...), which present focused groups of settings for the user to
tweak at his pleasure -- but, crucially, don't actually any tweaking for
him.

-Miles

-- 
Erudition, n. Dust shaken out of a book into an empty skull.

RE: line-move-visual

[Drew Adams]

> The name "skin" may be a misnomer, as typically they're basically
> all-or-nothing groups of settings.
> 
> I don't think that's a good idea, nor is is a good idea to 
> automatically change lots of defaults without user-participation
> -- while we want to allow the user to customize things easily,
> there's _also_ some advantage if they stick to the standard
> defaults, both for the user (in his ability to come to terms
> with emacs in the long term, and be part of the
> emacs community), and for Emacs maintainers.

FWIW, I agree.

Re: line-move-visual

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > We already have a feature that is close to that:
 > 
 >   Options->Customize Emacs->New Options
 > 
 > It asks for an old version, and presents a Customize buffer with all
 > options changed or introduced since that version.

This is good, but the crucial feature that improves discoverability is
the ability for the user to identify changes to classic behavior,
which is not necessarily all the new options.  Presumably the majority
of options that appear here relate to behavior of newly added
libraries, that don't represent a change to existing behavior.

Also, that must be a pretty big set of options if you compare, say, v
23 to v 21.

Re: line-move-visual

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Scot Becker <scot.becker@gmail.com>,
>     bastienguerry@googlemail.com,
>     emacs-devel@gnu.org,
>     jem@iki.fi,
>     handa@m17n.org,
>     miles@gnu.org
> Date: Fri, 10 Jul 2009 20:35:49 +0900
> 
> Also, that must be a pretty big set of options if you compare, say, v
> 23 to v 21.

It's very big even if you compare to 22.3.  But that's Emacs, I don't
see how anything can be done about the sheer quantity of new features
in a major release.

What bothers me a lot is that there doesn't seem to be a good way of
finding options relevant to some topic.  The various `apropos'
commands we have are ad-hoc and rely on strings in symbol names or
documentation.  What is missing is the ability to associate keywords
with symbols, akin to index entries we put in manuals.  But first and
foremost, someone will have to come up with a useful set of keywords
(those used by finder.el are not even close).

RE: line-move-visual

[Drew Adams]

> What bothers me a lot is that there doesn't seem to be a good way of
> finding options relevant to some topic.  The various `apropos'
> commands we have are ad-hoc and rely on strings in symbol names or
> documentation.  What is missing is the ability to associate keywords
> with symbols, akin to index entries we put in manuals.  But first and
> foremost, someone will have to come up with a useful set of keywords
> (those used by finder.el are not even close).

The words in doc strings serve pretty well as (ad-hoc) keywords -
`apropos-documentation'.

Re: line-move-visual

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <bastienguerry@googlemail.com>, <jem@iki.fi>, <scot.becker@gmail.com>,
>         <emacs-devel@gnu.org>
> Date: Fri, 10 Jul 2009 09:11:44 -0700
> 
> > What bothers me a lot is that there doesn't seem to be a good way of
> > finding options relevant to some topic.  The various `apropos'
> > commands we have are ad-hoc and rely on strings in symbol names or
> > documentation.  What is missing is the ability to associate keywords
> > with symbols, akin to index entries we put in manuals.  But first and
> > foremost, someone will have to come up with a useful set of keywords
> > (those used by finder.el are not even close).
> 
> The words in doc strings serve pretty well as (ad-hoc) keywords -
> `apropos-documentation'.

Not well enough, IMO.

RE: line-move-visual

[Drew Adams]

> > The words in doc strings serve pretty well as (ad-hoc) keywords -
> > `apropos-documentation'.
> 
> Not well enough, IMO.

Right. You need `icicle-vardoc'. ;-)

http://www.emacswiki.org/emacs/Icicles_-_Multi-Completions

Re: line-move-visual

[Juri Linkov]

> What bothers me a lot is that there doesn't seem to be a good way of
> finding options relevant to some topic.  The various `apropos'
> commands we have are ad-hoc and rely on strings in symbol names or
> documentation.  What is missing is the ability to associate keywords
> with symbols, akin to index entries we put in manuals.  But first and
> foremost, someone will have to come up with a useful set of keywords
> (those used by finder.el are not even close).

I started working on a dynamic keyword system where the first step was
porting the current finder.el to Info.  I'll post a patch very soon.

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

Re: line-move-visual

[Lennart Borgman]

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

On Fri, Jul 10, 2009 at 1:35 PM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> Eli Zaretskii writes:
>
>  > We already have a feature that is close to that:
>  >
>  >   Options->Customize Emacs->New Options
>  >
>  > It asks for an old version, and presents a Customize buffer with all
>  > options changed or introduced since that version.
>
> This is good, but the crucial feature that improves discoverability is
> the ability for the user to identify changes to classic behavior,
> which is not necessarily all the new options.

Here is a try to structure this in a custom buffer. It is not like
"skins" right now, but that could be added later.

I have set some new defaults, like showing the help links underlined
and making the "tabable". I think they should look and behave like
that.

Also I have cut out part from help-make-xrefs that someone put a
common on saying

   ;; The following should probably be abstracted out.

So I did that and suggest using that for widgets.

Do "M-x customize-for-new-user" to test and tell me what you think.
Please ignore that nothing in the custom buffer created works at the
moment... ;-)

[-- Attachment #2: cus-new-user.el --]
[-- Type: text/plain, Size: 16198 bytes --]

;;; cus-new-user.el --- Customize some important options
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2009-07-10 Fri
;; Version: 0.2
;; Last-Updated: 2009-07-10 Fri
;; URL:
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;;    Customize significant options for which different user
;;    environment expectations might dictate different defaults.
;;
;;    After an idea of Scot Becker on Emacs Devel.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 3, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

;;(customize-for-new-user)
;;;###autoload
(defun customize-for-new-user (&optional name)
  "Show special customization page for new user.
"
  (interactive)
  ;;(setq debug-on-error t)
  ;;(setq buffer-read-only t)
  (require 'cus-edit)
  (let ((inhibit-read-only t)
        fill-pos)
    (pop-to-buffer (custom-get-fresh-buffer (or name "*Customizations for New Users*")))
    (Custom-mode)
    (erase-buffer)
    (setq fill-pos (point))
    (widget-insert
     "Below are some custom options that new users often may want to
tweak since they may make Emacs a bit more like what they expect from using other software in their environment.

Since Emacs runs in many environment and an Emacs user may use
several of them it is hard to decide by default what a user
wants/expects.  Therefor you are given the possibility to easily
do those changes here.

Note that this is just a collection of normal custom options.
There are no new options here.

")
    (fill-region fill-pos (point))

    ;; Normal custom buffer header
    (let ((init-file (or custom-file user-init-file)))
      ;; Insert verbose help at the top of the custom buffer.
      (when custom-buffer-verbose-help
        (widget-insert "Editing a setting changes only the text in this buffer."
                       (if init-file
                           "
To apply your changes, use the Save or Set buttons.
Saving a change normally works by editing your init file."
                         "
Currently, these settings cannot be saved for future Emacs sessions,
possibly because you started Emacs with `-q'.")
                       "\nFor details, see ")
        (widget-create 'custom-manual
                       :tag "Saving Customizations"
                       "(emacs)Saving Customizations")
        (widget-insert " in the ")
        (widget-create 'custom-manual
                       :tag "Emacs manual"
                       :help-echo "Read the Emacs manual."
                       "(emacs)Top")
        (widget-insert "."))
      (widget-insert "\n")
      ;; The custom command buttons are also in the toolbar, so for a
      ;; time they were not inserted in the buffer if the toolbar was in use.
      ;; But it can be a little confusing for the buffer layout to
      ;; change according to whether or nor the toolbar is on, not to
      ;; mention that a custom buffer can in theory be created in a
      ;; frame with a toolbar, then later viewed in one without.
      ;; So now the buttons are always inserted in the buffer.  (Bug#1326)
;;;    (when (not (and (bound-and-true-p tool-bar-mode) (display-graphic-p)))
      (if custom-buffer-verbose-help
          (widget-insert "\n
 Operate on all settings in this buffer that are not marked HIDDEN:\n"))
      (let ((button (lambda (tag action active help icon)
                      (widget-insert " ")
                      (if (eval active)
                          (widget-create 'push-button :tag tag
                                         :help-echo help :action action))))
            (commands custom-commands))
        (apply button (pop commands)) ; Set for current session
        (apply button (pop commands)) ; Save for future sessions
        (if custom-reset-button-menu
            (progn
              (widget-insert " ")
              (widget-create 'push-button
                             :tag "Reset buffer"
                             :help-echo "Show a menu with reset operations."
                             :mouse-down-action 'ignore
                             :action 'custom-reset))
          (widget-insert "\n")
          (apply button (pop commands)) ; Undo edits
          (apply button (pop commands)) ; Reset to saved
          (apply button (pop commands)) ; Erase customization
          (widget-insert "  ")
          (pop commands) ; Help (omitted)
          (apply button (pop commands)))) ; Exit
      (widget-insert "\n\n")

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; Editor emulator level

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"Emacs can emulate some common editing behaviours (and some uncommon too).
For the most common ones you can decide if you want to use them here:
")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))
      (widget-insert "\n")

      ;; CUA Mode
      (cusnu-insert-options '((cua-mode custom-variable)))

      ;; Viper Mode
      (widget-insert "\n")
      (widget-insert (propertize "Viper Mode" 'face 'custom-variable-tag))
      (widget-insert ":")
      (setq fill-pos (point))
      (widget-insert "
   Viper is currently set up in a special way, please see the
   command `viper-mode'.
")
      (fill-region fill-pos (point))

      (cusnu-make-xrefs)
      )))

(defun cusnu-mark-part-desc (beg end)
  (let ((ovl (make-overlay beg end)))
    (overlay-put ovl 'face 'highlight)))

(defun cusnu-make-xrefs (&optional beg end)
  (save-restriction
    (when (or beg end)
      (unless beg (setq beg (point-min)))
      (unless end (setq end (point-max)))
      (narrow-to-region beg end))
    (goto-char (point-min))
    (cusnu-help-insert-xrefs 'cusnu-help-xref-button)))

(defun cusnu-help-xref-button (match-number type &rest args)
  (let ((beg (match-beginning match-number))
        (end (match-end match-number)))
  (if nil
      (let ((ovl (make-overlay beg end)))
        (overlay-put ovl 'face 'highlight))
    (let ((tag (match-string match-number))
          (wid-type (cond
                     ((eq type 'help-variable)
                      'variable-link)
                     ((eq type 'help-function)
                      'function-link)
                     ((eq type 'help-info)
                      'custom-manual)
                     (t nil)))
          )
      (when wid-type
        (delete-region beg end)
        (backward-char)
        ;;(tag action active help icon)
        (widget-create wid-type
                       ;;tag
                       :tag tag
                       :keymap custom-mode-link-map
                       :follow-link 'mouse-face
                       :button-face 'custom-link
                       :mouse-face 'highlight
                       :pressed-face 'highlight
                       ;;:help-echo help
                       )))))
    )

;; Override default ... ;-)
(define-widget 'documentation-link 'link
  "Link type used in documentation strings."
  ;;:tab-order -1
  :help-echo "Describe this symbol"
  :button-face 'custom-link
  :action 'widget-documentation-link-action)

(defun cusnu-xref-niy (&rest ignore)
  (message "Not implemented yet"))

(defun cusnu-describe-function (wid &rest ignore)
  (let ((fun (widget-get wid :what))
        )
    (describe-function fun)))

(defun cusnu-help-insert-xrefs (help-xref-button)
  ;; The following should probably be abstracted out.
  (unwind-protect
      (progn
        ;; Info references
        (save-excursion
          (while (re-search-forward help-xref-info-regexp nil t)
            (let ((data (match-string 2)))
              (save-match-data
                (unless (string-match "^([^)]+)" data)
                  (setq data (concat "(emacs)" data))))
              (funcall help-xref-button 2 'help-info data))))
        ;; URLs
        (save-excursion
          (while (re-search-forward help-xref-url-regexp nil t)
            (let ((data (match-string 1)))
              (funcall help-xref-button 1 'help-url data))))
        ;; Mule related keywords.  Do this before trying
        ;; `help-xref-symbol-regexp' because some of Mule
        ;; keywords have variable or function definitions.
        (if help-xref-mule-regexp
            (save-excursion
              (while (re-search-forward help-xref-mule-regexp nil t)
                (let* ((data (match-string 7))
                       (sym (intern-soft data)))
                  (cond
                   ((match-string 3) ; coding system
                    (and sym (coding-system-p sym)
                         (funcall help-xref-button 6 'help-coding-system sym)))
                   ((match-string 4) ; input method
                    (and (assoc data input-method-alist)
                         (funcall help-xref-button 7 'help-input-method data)))
                   ((or (match-string 5) (match-string 6)) ; charset
                    (and sym (charsetp sym)
                         (funcall help-xref-button 7 'help-character-set sym)))
                   ((assoc data input-method-alist)
                    (funcall help-xref-button 7 'help-character-set data))
                   ((and sym (coding-system-p sym))
                    (funcall help-xref-button 7 'help-coding-system sym))
                   ((and sym (charsetp sym))
                    (funcall help-xref-button 7 'help-character-set sym)))))))
        ;; Quoted symbols
        (save-excursion
          (while (re-search-forward help-xref-symbol-regexp nil t)
            (let* ((data (match-string 8))
                   (sym (intern-soft data)))
              (if sym
                  (cond
                   ((match-string 3)  ; `variable' &c
                    (and (or (boundp sym) ; `variable' doesn't ensure
                                        ; it's actually bound
                             (get sym 'variable-documentation))
                         (funcall help-xref-button 8 'help-variable sym)))
                   ((match-string 4)   ; `function' &c
                    (and (fboundp sym) ; similarly
                         (funcall help-xref-button 8 'help-function sym)))
                   ((match-string 5) ; `face'
                    (and (facep sym)
                         (funcall help-xref-button 8 'help-face sym)))
                   ((match-string 6)) ; nothing for `symbol'
                   ((match-string 7)
;;;  this used:
;;; 			  #'(lambda (arg)
;;; 			      (let ((location
;;; 				     (find-function-noselect arg)))
;;; 				(pop-to-buffer (car location))
;;; 				(goto-char (cdr location))))
                    (funcall help-xref-button 8 'help-function-def sym))
                   ((and
                     (facep sym)
                     (save-match-data (looking-at "[ \t\n]+face\\W")))
                    (funcall help-xref-button 8 'help-face sym))
                   ((and (or (boundp sym)
                             (get sym 'variable-documentation))
                         (fboundp sym))
                    ;; We can't intuit whether to use the
                    ;; variable or function doc -- supply both.
                    (funcall help-xref-button 8 'help-symbol sym))
                   ((and
                     (or (boundp sym)
                         (get sym 'variable-documentation))
                     (or
                      (documentation-property
                       sym 'variable-documentation)
                      (condition-case nil
                          (documentation-property
                           (indirect-variable sym)
                           'variable-documentation)
                        (cyclic-variable-indirection nil))))
                    (funcall help-xref-button 8 'help-variable sym))
                   ((fboundp sym)
                    (funcall help-xref-button 8 'help-function sym)))))))
        ;; An obvious case of a key substitution:
        (save-excursion
          (while (re-search-forward
                  ;; Assume command name is only word and symbol
                  ;; characters to get things like `use M-x foo->bar'.
                  ;; Command required to end with word constituent
                  ;; to avoid `.' at end of a sentence.
                  "\\<M-x\\s-+\\(\\sw\\(\\sw\\|\\s_\\)*\\sw\\)" nil t)
            (let ((sym (intern-soft (match-string 1))))
              (if (fboundp sym)
                  (funcall help-xref-button 1 'help-function sym)))))
        ;; Look for commands in whole keymap substitutions:
        (save-excursion
          ;; Make sure to find the first keymap.
          (goto-char (point-min))
          ;; Find a header and the column at which the command
          ;; name will be found.

          ;; If the keymap substitution isn't the last thing in
          ;; the doc string, and if there is anything on the
          ;; same line after it, this code won't recognize the end of it.
          (while (re-search-forward "^key +binding\n\\(-+ +\\)-+\n\n"
                                    nil t)
            (let ((col (- (match-end 1) (match-beginning 1))))
              (while
                  (and (not (eobp))
                       ;; Stop at a pair of blank lines.
                       (not (looking-at "\n\\s-*\n")))
                ;; Skip a single blank line.
                (and (eolp) (forward-line))
                (end-of-line)
                (skip-chars-backward "^ \t\n")
                (if (and (>= (current-column) col)
                         (looking-at "\\(\\sw\\|\\s_\\)+$"))
                    (let ((sym (intern-soft (match-string 0))))
                      (if (fboundp sym)
                          (funcall help-xref-button 0 'help-function sym))))
                (forward-line))))))
    ;;(set-syntax-table stab)
    ))

(defun cusnu-insert-options (options)
  (buffer-disable-undo)
  (setq custom-options
	(if (= (length options) 1)
	    (mapcar (lambda (entry)
		      (widget-create (nth 1 entry)
				     :documentation-shown t
				     :custom-state 'unknown
				     :tag (custom-unlispify-tag-name
					   (nth 0 entry))
				     :value (nth 0 entry)))
		    options)
	  (let ((count 0)
		(length (length options)))
	    (mapcar (lambda (entry)
		      (prog2
			  (message "Creating customization items ...%2d%%"
				   (/ (* 100.0 count) length))
			  (widget-create (nth 1 entry)
					 :tag (custom-unlispify-tag-name
					       (nth 0 entry))
					 :value (nth 0 entry))
			(setq count (1+ count))
			(unless (eq (preceding-char) ?\n)
			  (widget-insert "\n"))
			(widget-insert "\n")))
		    options))))
  (unless (eq (preceding-char) ?\n)
    (widget-insert "\n"))
  )

(provide 'cus-new-user)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; cus-new-user.el ends here

Re: line-move-visual

[Scot Becker]

Lennart,

That was quick!   I think a library like that would do a lot, since
you could create custom customization buffers for all the purposes we
have discussed.  I like it.  Of course for a new user, the
customization buffer itself is quite 'busy', but that's not a problem
we can do anything about at the moment.  And the sooner they warm up
to it, probably the better for them, since it's one of the better
forms we have of interface discoverability at the moment.

I tried adding new variables to customize, which seems to work. I
assume it's possible to add documentation by adding  it between the
commands.  And typical lisp logic to only present some options if
we're on a certain OS, or have a certain package loaded.

This is really nice, Lennart.   I assume it's far too late to include
something like this in v. 23.1, but I could imagine various
'customization groups' making it into a future version.  If I manage
to produce an Emacs 'customization package for writers.'  I will most
certainly use this (especially if line-move-visual gets set to nil!)
.
So aside from the ongoing need to pick good defaults, how well does
something like this address the discoverability issue?  What do the
rest of you think?

Scot

Re: line-move-visual

[Lennart Borgman]

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

On Fri, Jul 10, 2009 at 5:07 PM, Scot Becker<scot.becker@gmail.com> wrote:
> Lennart,
>
> That was quick!   I think a library like that would do a lot, since
> you could create custom customization buffers for all the purposes we
> have discussed.  I like it.  Of course for a new user, the
> customization buffer itself is quite 'busy', but that's not a problem
> we can do anything about at the moment.  And the sooner they warm up
> to it, probably the better for them, since it's one of the better
> forms we have of interface discoverability at the moment.
>
> I tried adding new variables to customize, which seems to work. I
> assume it's possible to add documentation by adding  it between the
> commands.  And typical lisp logic to only present some options if
> we're on a certain OS, or have a certain package loaded.
>
> This is really nice, Lennart.   I assume it's far too late to include
> something like this in v. 23.1, but I could imagine various
> 'customization groups' making it into a future version.  If I manage
> to produce an Emacs 'customization package for writers.'  I will most
> certainly use this (especially if line-move-visual gets set to nil!)
> .
> So aside from the ongoing need to pick good defaults, how well does
> something like this address the discoverability issue?  What do the
> rest of you think?


Pointing out some important options is perhaps good. Also exporting
"my important options/my skin options" is probably good. See the new
version below (a working version).

I guess it is not ready, but maybe a discussion point at least.

[-- Attachment #2: cus-new-user.el --]
[-- Type: text/plain, Size: 23181 bytes --]

;;; cus-new-user.el --- Customize some important options
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2009-07-10 Fri
;; Version: 0.2
;; Last-Updated: 2009-07-10 Fri
;; URL:
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;;    Customize significant options for which different user
;;    environment expectations might dictate different defaults.
;;
;;    After an idea of Scot Becker on Emacs Devel.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 3, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

;;(customize-for-new-user)
;;;###autoload
(defun customize-for-new-user (&optional name)
  "Show special customization page for new user.
"
  (interactive)
  ;;(setq debug-on-error t)
  ;;(setq buffer-read-only t)
  (require 'cus-edit)
  (let ((inhibit-read-only t)
        fill-pos)
    (pop-to-buffer (custom-get-fresh-buffer (or name "*Customizations for New Users*")))
    (buffer-disable-undo)
    (Custom-mode)
    (erase-buffer)
    (setq fill-pos (point))
    (widget-insert
     "Below are some custom options that new users often may want to
tweak since they may make Emacs a bit more like what they expect from using other software in their environment.

Since Emacs runs in many environment and an Emacs user may use
several of them it is hard to decide by default what a user
wants/expects.  Therefor you are given the possibility to easily
do those changes here.

Note that this is just a collection of normal custom options.
There are no new options here.

")
    (fill-region fill-pos (point))

    ;; Normal custom buffer header
    (let ((init-file (or custom-file user-init-file)))
      ;; Insert verbose help at the top of the custom buffer.
      (when custom-buffer-verbose-help
        (widget-insert "Editing a setting changes only the text in this buffer."
                       (if init-file
                           "
To apply your changes, use the Save or Set buttons.
Saving a change normally works by editing your init file."
                         "
Currently, these settings cannot be saved for future Emacs sessions,
possibly because you started Emacs with `-q'.")
                       "\nFor details, see ")
        (widget-create 'custom-manual
                       :tag "Saving Customizations"
                       "(emacs)Saving Customizations")
        (widget-insert " in the ")
        (widget-create 'custom-manual
                       :tag "Emacs manual"
                       :help-echo "Read the Emacs manual."
                       "(emacs)Top")
        (widget-insert "."))
      (widget-insert "\n")
      ;; The custom command buttons are also in the toolbar, so for a
      ;; time they were not inserted in the buffer if the toolbar was in use.
      ;; But it can be a little confusing for the buffer layout to
      ;; change according to whether or nor the toolbar is on, not to
      ;; mention that a custom buffer can in theory be created in a
      ;; frame with a toolbar, then later viewed in one without.
      ;; So now the buttons are always inserted in the buffer.  (Bug#1326)
;;;    (when (not (and (bound-and-true-p tool-bar-mode) (display-graphic-p)))
      (if custom-buffer-verbose-help
          (widget-insert "\n
 Operate on all settings in this buffer that are not marked HIDDEN:\n"))
      (let ((button (lambda (tag action active help icon)
                      (widget-insert " ")
                      (if (eval active)
                          (widget-create 'push-button :tag tag
                                         :help-echo help :action action))))
            (commands custom-commands))
        (apply button (pop commands)) ; Set for current session
        (apply button (pop commands)) ; Save for future sessions
        (if custom-reset-button-menu
            (progn
              (widget-insert " ")
              (widget-create 'push-button
                             :tag "Reset buffer"
                             :help-echo "Show a menu with reset operations."
                             :mouse-down-action 'ignore
                             :action 'custom-reset))
          (widget-insert "\n")
          (apply button (pop commands)) ; Undo edits
          (apply button (pop commands)) ; Reset to saved
          (apply button (pop commands)) ; Erase customization
          (widget-insert "  ")
          (pop commands) ; Help (omitted)
          (apply button (pop commands)))) ; Exit
      (widget-insert "\n\n")

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; Editor emulator level

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"Emacs can emulate some common editing behaviours (and some uncommon too).
For the most common ones you can decide if you want to use them here:
")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      ;; CUA Mode
      (cusnu-insert-options '((cua-mode custom-variable)))

      ;; Viper Mode
      (widget-insert "\n")
      (widget-insert (propertize "Viper" 'face 'custom-variable-tag))
      (widget-insert ":")
      (setq fill-pos (point))
      (widget-insert "
   Viper is currently set up in a special way, please see the
   command `viper-mode'.  You can use custom to set up most of
   it.  However if you want to load Viper at startup you must
   explicitly include \(require 'viper) in your .emacs.
")
      (fill-region fill-pos (point))

      ;; Viper Mode
      (backward-delete-char 1)
      (cusnu-insert-options '((viper-mode custom-variable)))

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; OS specific

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert (format "OS specific options (%s): \n" system-type))
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      (if cusno-insert-os-spec-fun
          (funcall cusno-insert-os-spec-fun)
       (widget-insert "No OS specific customizations.\n"))

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; Disputed settings

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"Some old time Emacs users want to change the options below:
")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      (cusnu-insert-options '((global-visual-line-mode custom-variable)))
      (cusnu-insert-options '((word-wrap custom-variable)))
      (cusnu-insert-options '((blink-cursor-mode custom-variable)))
      (cusnu-insert-options '((tool-bar-mode custom-variable)))
      (cusnu-insert-options '((tooltip-mode custom-variable)))
      ;;(cusnu-insert-options '((initial-scratch-message custom-variable)))

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"My skin options - for exporting custom options to other users (or yourself on another computer)")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      (widget-insert "\n")
      (cusnu-insert-options '((cusnu-my-skin-options custom-variable)))
      (widget-insert "\n")
      (widget-create 'push-button
                     :tag "Export my skin options"
                     :action (lambda (&rest ignore)
                               (let ((use-dialog-box nil))
                                 (call-interactively 'cusnu-export-my-skin-options))))

      ;; Finish setup buffer
      (mapc 'custom-magic-reset custom-options)
      (cusnu-make-xrefs)
      (widget-setup)
      (buffer-enable-undo)
      (goto-char (point-min)))))

(defvar cusno-insert-os-spec-fun nil)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Example on Emacs+Emacw32
(when (boundp 'emacsw32-version)
  (defun cusnu-emacsw32-show-custstart (&rest args)
    (emacsw32-show-custstart))
  (setq cusno-insert-os-spec-fun 'cusnu-insert-emacsw32-specific-part)
  (defun cusnu-insert-emacsw32-specific-part ()
    (cusnu-insert-options '((w32-meta-style custom-variable)))
    (widget-insert "\n")
    (widget-insert (propertize "EmacsW32" 'face 'custom-variable-tag))
    (widget-insert "
   Easy setup for Emacs+EmacsW32.")
    (widget-insert "\n   ")
    (widget-create 'push-button :tag "Customize EmacsW32"
                   ;;:help-echo help
                   :action 'cusnu-emacsw32-show-custstart)
    (widget-insert "\n")))
;; End example
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defun cusnu-mark-part-desc (beg end)
  (let ((ovl (make-overlay beg end)))
    (overlay-put ovl 'face 'highlight)))

(defun cusnu-make-xrefs (&optional beg end)
  (save-restriction
    (when (or beg end)
      (unless beg (setq beg (point-min)))
      (unless end (setq end (point-max)))
      (narrow-to-region beg end))
    (let ((here (point)))
      (goto-char (point-min))
      (cusnu-help-insert-xrefs 'cusnu-help-xref-button)
      (goto-char here))))

(defun widget-info-link-action (widget &optional event)
  "Open the info node specified by WIDGET."
  (info-other-window (widget-value widget)))

(defun widget-documentation-string-value-create (widget)
  ;; Insert documentation string.
  (let ((doc (widget-value widget))
	(indent (widget-get widget :indent))
	(shown (widget-get (widget-get widget :parent) :documentation-shown))
	(start (point)))
    (if (string-match "\n" doc)
	(let ((before (substring doc 0 (match-beginning 0)))
	      (after (substring doc (match-beginning 0)))
	      button)
	  (when (and indent (not (zerop indent)))
	    (insert-char ?\s indent))
	  (insert before ?\s)
	  (widget-documentation-link-add widget start (point))
	  (setq button
		(widget-create-child-and-convert
		 widget (widget-get widget :visibility-widget)
		 :help-echo "Show or hide rest of the documentation."
		 :on "Hide Rest"
		 :off "More"
		 :always-active t
		 :action 'widget-parent-action
		 shown))
	  (when shown
	    (setq start (point))
	    (when (and indent (not (zerop indent)))
	      (insert-char ?\s indent))
	    (insert after)
	    (widget-documentation-link-add widget start (point))
            (cusnu-make-xrefs start (point))
            )
	  (widget-put widget :buttons (list button)))
      (when (and indent (not (zerop indent)))
	(insert-char ?\s indent))
      (insert doc)
      (widget-documentation-link-add widget start (point))))
  (insert ?\n))
(defun cusnu-help-xref-button (match-number type what &rest args)
  (let ((beg (match-beginning match-number))
        (end (match-end match-number)))
  (if nil
      (let ((ovl (make-overlay beg end)))
        (overlay-put ovl 'face 'highlight))
    (let* ((tag (match-string match-number))
           (value what)
            (wid-type (cond
                       ((eq type 'help-variable)
                        'variable-link)
                       ((eq type 'help-function)
                        'function-link)
                       ((eq type 'help-info)
                        'custom-manual)
                       (t nil)))
          )
      (when wid-type
        (delete-region beg end)
        (backward-char)
        ;;(tag action active help icon)
        (widget-create wid-type
                       ;;tag
                       :value value
                       :tag tag
                       :keymap custom-mode-link-map
                       :follow-link 'mouse-face
                       :button-face 'custom-link
                       :mouse-face 'highlight
                       :pressed-face 'highlight
                       ;;:help-echo help
                       )))))
    )

;; Override default ... ;-)
(define-widget 'documentation-link 'link
  "Link type used in documentation strings."
  ;;:tab-order -1
  :help-echo "Describe this symbol"
  :button-face 'custom-link
  :action 'widget-documentation-link-action)

(defun cusnu-xref-niy (&rest ignore)
  (message "Not implemented yet"))

(defun cusnu-describe-function (wid &rest ignore)
  (let ((fun (widget-get wid :what))
        )
    (describe-function fun)))

(defun cusnu-help-insert-xrefs (help-xref-button)
  ;; The following should probably be abstracted out.
  (unwind-protect
      (progn
        ;; Info references
        (save-excursion
          (while (re-search-forward help-xref-info-regexp nil t)
            (let ((data (match-string 2)))
              (save-match-data
                (unless (string-match "^([^)]+)" data)
                  (setq data (concat "(emacs)" data))))
              (funcall help-xref-button 2 'help-info data))))
        ;; URLs
        (save-excursion
          (while (re-search-forward help-xref-url-regexp nil t)
            (let ((data (match-string 1)))
              (funcall help-xref-button 1 'help-url data))))
        ;; Mule related keywords.  Do this before trying
        ;; `help-xref-symbol-regexp' because some of Mule
        ;; keywords have variable or function definitions.
        (if help-xref-mule-regexp
            (save-excursion
              (while (re-search-forward help-xref-mule-regexp nil t)
                (let* ((data (match-string 7))
                       (sym (intern-soft data)))
                  (cond
                   ((match-string 3) ; coding system
                    (and sym (coding-system-p sym)
                         (funcall help-xref-button 6 'help-coding-system sym)))
                   ((match-string 4) ; input method
                    (and (assoc data input-method-alist)
                         (funcall help-xref-button 7 'help-input-method data)))
                   ((or (match-string 5) (match-string 6)) ; charset
                    (and sym (charsetp sym)
                         (funcall help-xref-button 7 'help-character-set sym)))
                   ((assoc data input-method-alist)
                    (funcall help-xref-button 7 'help-character-set data))
                   ((and sym (coding-system-p sym))
                    (funcall help-xref-button 7 'help-coding-system sym))
                   ((and sym (charsetp sym))
                    (funcall help-xref-button 7 'help-character-set sym)))))))
        ;; Quoted symbols
        (save-excursion
          (while (re-search-forward help-xref-symbol-regexp nil t)
            (let* ((data (match-string 8))
                   (sym (intern-soft data)))
              (if sym
                  (cond
                   ((match-string 3)  ; `variable' &c
                    (and (or (boundp sym) ; `variable' doesn't ensure
                                        ; it's actually bound
                             (get sym 'variable-documentation))
                         (funcall help-xref-button 8 'help-variable sym)))
                   ((match-string 4)   ; `function' &c
                    (and (fboundp sym) ; similarly
                         (funcall help-xref-button 8 'help-function sym)))
                   ((match-string 5) ; `face'
                    (and (facep sym)
                         (funcall help-xref-button 8 'help-face sym)))
                   ((match-string 6)) ; nothing for `symbol'
                   ((match-string 7)
;;;  this used:
;;; 			  #'(lambda (arg)
;;; 			      (let ((location
;;; 				     (find-function-noselect arg)))
;;; 				(pop-to-buffer (car location))
;;; 				(goto-char (cdr location))))
                    (funcall help-xref-button 8 'help-function-def sym))
                   ((and
                     (facep sym)
                     (save-match-data (looking-at "[ \t\n]+face\\W")))
                    (funcall help-xref-button 8 'help-face sym))
                   ((and (or (boundp sym)
                             (get sym 'variable-documentation))
                         (fboundp sym))
                    ;; We can't intuit whether to use the
                    ;; variable or function doc -- supply both.
                    (funcall help-xref-button 8 'help-symbol sym))
                   ((and
                     (or (boundp sym)
                         (get sym 'variable-documentation))
                     (or
                      (documentation-property
                       sym 'variable-documentation)
                      (condition-case nil
                          (documentation-property
                           (indirect-variable sym)
                           'variable-documentation)
                        (cyclic-variable-indirection nil))))
                    (funcall help-xref-button 8 'help-variable sym))
                   ((fboundp sym)
                    (funcall help-xref-button 8 'help-function sym)))))))
        ;; An obvious case of a key substitution:
        (save-excursion
          (while (re-search-forward
                  ;; Assume command name is only word and symbol
                  ;; characters to get things like `use M-x foo->bar'.
                  ;; Command required to end with word constituent
                  ;; to avoid `.' at end of a sentence.
                  "\\<M-x\\s-+\\(\\sw\\(\\sw\\|\\s_\\)*\\sw\\)" nil t)
            (let ((sym (intern-soft (match-string 1))))
              (if (fboundp sym)
                  (funcall help-xref-button 1 'help-function sym)))))
        ;; Look for commands in whole keymap substitutions:
        (save-excursion
          ;; Make sure to find the first keymap.
          (goto-char (point-min))
          ;; Find a header and the column at which the command
          ;; name will be found.

          ;; If the keymap substitution isn't the last thing in
          ;; the doc string, and if there is anything on the
          ;; same line after it, this code won't recognize the end of it.
          (while (re-search-forward "^key +binding\n\\(-+ +\\)-+\n\n"
                                    nil t)
            (let ((col (- (match-end 1) (match-beginning 1))))
              (while
                  (and (not (eobp))
                       ;; Stop at a pair of blank lines.
                       (not (looking-at "\n\\s-*\n")))
                ;; Skip a single blank line.
                (and (eolp) (forward-line))
                (end-of-line)
                (skip-chars-backward "^ \t\n")
                (if (and (>= (current-column) col)
                         (looking-at "\\(\\sw\\|\\s_\\)+$"))
                    (let ((sym (intern-soft (match-string 0))))
                      (if (fboundp sym)
                          (funcall help-xref-button 0 'help-function sym))))
                (forward-line))))))
    ;;(set-syntax-table stab)
    ))

(defun cusnu-insert-options (options)
  (widget-insert "\n")
  (setq custom-options
        (append
         (if (= (length options) 1)
             (mapcar (lambda (entry)
                       (widget-create (nth 1 entry)
                                      ;;:documentation-shown t
                                      :custom-state 'unknown
                                      :tag (custom-unlispify-tag-name
                                            (nth 0 entry))
                                      :value (nth 0 entry)))
                     options)
           (let ((count 0)
                 (length (length options)))
             (mapcar (lambda (entry)
                       (prog2
                           (message "Creating customization items ...%2d%%"
                                    (/ (* 100.0 count) length))
                           (widget-create (nth 1 entry)
                                          :tag (custom-unlispify-tag-name
                                                (nth 0 entry))
                                          :value (nth 0 entry))
                         (setq count (1+ count))
                         (unless (eq (preceding-char) ?\n)
                           (widget-insert "\n"))
                         (widget-insert "\n")))
                     options)))
         custom-options))
  (unless (eq (preceding-char) ?\n)
    (widget-insert "\n"))
  )

(define-widget 'custom-symbol 'symbol
  "A Custom option."
  :prompt-match (lambda (sym) (get sym 'custom-type))
  :prompt-history 'widget-variable-prompt-value-history
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol (lambda (sym) (get sym 'custom-type))))
  :tag "Custom option")

(defcustom cusnu-my-skin-options nil
  "My custum options.
You can export these to a file with
`cusnu-export-my-skin-options' so that others can use them."
  :type '(repeat custom-symbol)
  )

(defun cusnu-export-my-skin-options (file)
  "Export to file FILE custom options in `cusnu-my-skin-options'."
  (interactive "FTo file: ")
  (when (file-exists-p file)
    (error "File %s already exists" file))
  (let ((buf (find-file file))
        start)
    (with-current-buffer buf
      (erase-buffer)
      (insert (format-time-string ";; Here are my default options values %Y-%m-%d.\n"))
      (insert
";; Eval this elisp file to test them and then do
;;
;;    M-x customize-save-customized
;;
;; if you want to keep them.
;;
;; Here are the options I have choosen to export:\n")
      (insert (format ";;(customize-set-variable 'cusnu-my-skin-options\n"))
      (setq start (point))
      (insert (format ";;        %S)\n\n" cusnu-my-skin-options))
      (emacs-lisp-mode)
      (fill-region start (point))
      (dolist (opt cusnu-my-skin-options)
        (let ((my-val (car-safe
                       (or (get opt 'saved-value)
                           (get opt 'customized-value)))))
          (when my-val
            (insert (format "(customize-set-variable '%s %S)\n" opt my-val)))))
      )))

(provide 'cus-new-user)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; cus-new-user.el ends here

Re: line-move-visual

[Alfred M. Szmidt]

   > Discoverability is key.  This could be done through a customize
   > interface, as Stephen suggests or simply through a piece of
   > startup documentation called "Things you might want to tweak."

   We already have a feature that is close to that:

     Options->Customize Emacs->New Options

Maybe it is a good idea to add it to the startup-buffer?

Re: line-move-visual

[Sean O'Rourke]

Just to chime in, 

Scot Becker <scot.becker@gmail.com> writes:
> Discoverability is key.

Indeed.  The "antinews" node in the Emacs info is useful here,
but it would be nice for it to include links for how to undo
major and/or controversial recent changes.  There's a chance it
would shorten these kinds of discussions if there were an
obvious place to look for controversial changes, which also
explained how to revert them.  Just for reference, here's the
relevant section of my .emacs [1] (not all of those changed
with 21.x, and most Emacs changes are more good than bad, but
I've been reverting a few things for a long time).

Sean

[1]

;; Undo some of the suck of version 21.x
(blink-cursor-mode		0)
(tool-bar-mode			0)
(when (fboundp 'tooltip-mode)
  (tooltip-mode			0))
(with-current-buffer (get-buffer-create "*scratch*")
  (setq buffer-offer-save nil))
(setq
 line-move-visual		nil
 initial-scratch-message	nil)

Re: line-move-visual

[Tassilo Horn]

Bastien <bastienguerry@googlemail.com> writes:

Hi!

>> Options should be "nil" and "t", or the question should be "Should
>> line-move-visual default to nil".
>
> Er, yes.  Another try:
>
>   http://www.micropoll.com/akira/mpview/623323-182852

I'm missing this vote option:

  Yes and no.  Either it should be disabled completely, or full
  visual-line-mode should be enabled by default.  These inconsistencies
  between visual lines with C-n/C-p and logical lines with C-k/C-e/C-e
  are the worst-case default.

Bye,
Tassilo

Re: line-move-visual

[Miles Bader]

Tassilo Horn <tassilo@member.fsf.org> writes:
> I'm missing this vote option:
>
>   Yes and no.  Either it should be disabled completely, or full
>   visual-line-mode should be enabled by default.  These inconsistencies
>   between visual lines with C-n/C-p and logical lines with C-k/C-e/C-e
>   are the worst-case default.

BTW, I really hope that vote page points to the discussion threads about
this stuff (which discuss, for instance, exactly the above issue...).

Ok, I know even if it does, people won't bother to read anyof it and
will vote with their gut.  Sigh...

-Miles

-- 
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere
islands of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

Re: line-move-visual

[Scot Becker]

by Miles:
...simple themed customization groups ("get off my lawn", "windows
luser", ...), which present focused groups of settings for the user to
tweak at his pleasure

Sure, that'd be great. And fair enough with 'coaching users through
incremental changes' rather than 'changing a raft of things in one
fell swoop'.   A few helpful additions would be that (1) there would
be a way for users to create such customization groups for
distribution to other users.  They wouldn't be hard-coded, like
today's customization groups (apparently are).

And (2) ideally there'd be the opportunity to optionally include
extended user documentation in amongst the variables to give guidance
beyond what one might find in the docstrings.  The docstrings can be a
bit minimal if what you want to do is explain the significance of
various choices to a user who is only now encountering some new
concept lying behind a variable.

Lastly, it would be nice to have a way for such customization groups
to specify: "If external library X is available, customize variable
ext-lib-X-groovy, and fail gracefully if not ("If you had optional
package X loaded, you would also be able to customize these variables
here:")

This way it would be useful for the present purpose, as well as for
package writers who want to draw attention to a set of variables whose
interaction with their package the user might want to consider.  It
could also be useful for my  "Emacs for writers" config-file disto,
and someone else's "Emacs for coders in functional languages"
config-distro, etc.

And your names are great (get off my lawn and windows luser).

Scot

RE: line-move-visual

[Drew Adams]

> A few helpful additions would be that (1) there would
> be a way for users to create such customization groups for
> distribution to other users.  They wouldn't be hard-coded, like
> today's customization groups (apparently are).

Yes; see my other reply. It would help to make it easier for users to group
options (and faces).

> And (2) ideally there'd be the opportunity to optionally include
> extended user documentation in amongst the variables to give guidance
> beyond what one might find in the docstrings.  The docstrings can be a
> bit minimal if what you want to do is explain the significance of
> various choices to a user who is only now encountering some new
> concept lying behind a variable.

That's OK, but it's the sharing of such annotations that is most helpful. Your
adding helpful info to a doc string locally doesn't help me understand it better
where I am.

It's helpful to send a bug report with the suggestion, so it can be incorporated
for others to see too. The problem with that is that the official doc must be a
one-size-fits-all, to some extent.

An alternative is to share your extra doc using Emacs Wiki.

One possibility might be (_might_ be - just thinking out loud) to have a doc
string link to an EmacsWiki page that details only that variable, function, or
whatever. This would be somewhat like a doc string link to the manual, but the
difference is that anyone can participate in any way in editing the wiki page.

Just half-baked food for thought.

Re: line-move-visual

[Ulrich Mueller]

There's another poll in the Gentoo forums:
<http://forums.gentoo.org/viewtopic-t-779324.html>

Ulrich

Re: line-move-visual

[Eli Zaretskii]

> Date: Fri, 10 Jul 2009 12:36:48 +0200
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: Bastien <bastienguerry@googlemail.com>, Kenichi Handa <handa@m17n.org>,
> 	jem@iki.fi, Miles Bader <miles@gnu.org>
> 
> There's another poll in the Gentoo forums:
> <http://forums.gentoo.org/viewtopic-t-779324.html>

But there doesn't seem to be a way of voting there without some extra
fuss.

Re: line-move-visual

[Christian Faulhammer]

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

Hi,

Eli Zaretskii <eliz@gnu.org>:

> > Date: Fri, 10 Jul 2009 12:36:48 +0200
> > From: Ulrich Mueller <ulm@gentoo.org>
> > Cc: Bastien <bastienguerry@googlemail.com>, Kenichi Handa
> > <handa@m17n.org>, jem@iki.fi, Miles Bader <miles@gnu.org>
> > 
> > There's another poll in the Gentoo forums:
> > <http://forums.gentoo.org/viewtopic-t-779324.html>
> 
> But there doesn't seem to be a way of voting there without some extra
> fuss.

 If you are a Gentoo user you should have an account...it is an
internal vote in the end if we disregard upstream's defaults.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: line-move-visual

[Ulrich Mueller]

>>>>> On Fri, 10 Jul 2009, Eli Zaretskii wrote:

>> There's another poll in the Gentoo forums:
>> <http://forums.gentoo.org/viewtopic-t-779324.html>

> But there doesn't seem to be a way of voting there without some
> extra fuss.

Yes, because as you already see from the list of options, it's
primarily intended for Gentoo users (registration to our forums is
open for everyone though). But I thought that its outcome might be
interesting for the readers of this list.

Ulrich

Re: line-move-visual

[Bastien]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Fri, 10 Jul 2009, Eli Zaretskii wrote:
>
>>> There's another poll in the Gentoo forums:
>>> <http://forums.gentoo.org/viewtopic-t-779324.html>
>
>> But there doesn't seem to be a way of voting there without some
>> extra fuss.
>
> Yes, because as you already see from the list of options, it's
> primarily intended for Gentoo users (registration to our forums is
> open for everyone though). But I thought that its outcome might be
> interesting for the readers of this list.

I think it is.  If a poll is a tool for maintainers to make their
choice, several polls are just several tools, all interesting.

-- 
 Bastien

Re: line-move-visual

[Richard Stallman]

    Emacs is not a democracy, although the maintainers generally pay a lot
    of attention to the opinions and arguments of others.  In the face of
    contentious changes, it's the job of the maintainers to understand the
    arguments on both sides and make a judgement call as to what the best
    solution for the entire Emacs user base is.

This is true.  However, polling the users is a good way for the
maintainers to learn how users think about a proposed change.

Re: line-move-visual

[Stephen J. Turnbull]

Richard Stallman writes:

 > However, polling the users is a good way for the maintainers to
 > learn how users think about a proposed change.

The problem is that the pollsters rarely design the poll in a way that
encourages thinking at all, let alone conveying the line of thought to
the pollster.  And pollsters generally just report the numerical
results.

Eg, the Gentoo poll is actually a sort of non-binding vote, as I
understand it.  For their purposes, it makes sense to just report
numerical results, and they do allow comments.  A quick perusal of the
comments resulted in zero interesting content beyond the votes (there
was a long subthread that depended on the misconception that LaTeX
source is divided into paragraphs by newlines, the rest of the
comments just reiterated "I do/don't like the feature").  I don't
think it is of much interest to the Emacs maintainers.

If you want to encourage use of polls, then you should set standards
for design and reporting of these polls.

Re: line-move-visual

[Miles Bader]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
>  > However, polling the users is a good way for the maintainers to
>  > learn how users think about a proposed change.
>
> The problem is that the pollsters rarely design the poll in a way that
> encourages thinking at all, let alone conveying the line of thought to
> the pollster.  And pollsters generally just report the numerical
> results.

I seem to recall that Richard has said in the past that the most useful
part of polls was not really any numerical tally, but the comments
people made; it can be useful tool in getting input from people that
aren't normally part of the discussion.

For the reasons you state, and others, of course, mere "votes" (without
a kind of rigor and scope which is more or less impossible for us to
achieve) seem almost useless.

-Miles

-- 
Cat, n. A soft, indestructible automaton provided by nature to be kicked when
things go wrong in the domestic circle.

Re: line-move-visual

[Bastien]

Miles Bader <miles@gnu.org> writes:

> For the reasons you state, and others, of course, mere "votes" (without
> a kind of rigor and scope which is more or less impossible for us to
> achieve) seem almost useless.

What about:

- have a poll by email on the emacs mailing list, which lets people
  add their comments; 

- and have as many other polls as possible on any medium (web forum,
  etc.) and don't presume about their relevance before we have them;

?

IMHO, we have had too many comments and too few figures.  Let's go
pragmatic.  I really look forward the maintainers comments on this.

-- 
 Bastien

Re: line-move-visual

[Richard Stallman]

    - have a poll by email on the emacs mailing list, which lets people
      add their comments; 

When we did polls, we announced them on info-gnu-emacs and anywhere
else that seemed useful, to reach the broadest group of Emacs users.

But we did not do them "on" any mailing list.  We asked users to send
their responses to a special address which dumped mail into a file.
We checked the answers at the end.

We always asked people to say why they prefer a certain behavior,
rather than just voting for or against.  And sometimes we suggested
more than two options.

    - and have as many other polls as possible on any medium (web forum,
      etc.) and don't presume about their relevance before we have them;

It makes no sense to have multiple (different) polls about one topic.
It is easier and better to annouce the one poll in multiple places.

Re: line-move-visual

[Stephen J. Turnbull]

Bastien writes:
 > Johan Myréen <jem@iki.fi> writes:

 > > Could somebody please explain to me what the idea behind the new
 > > concept of "visual lines" in Emacs is?

What's new about it?  It's been around for decades, even in Emacs for
a decade or so (long-lines mode). :-)  It's only new as a default.

As Bastien says, here's the long explanation:

 > Take your breath and deep into this discussion:
 > 
 >   http://article.gmane.org/gmane.emacs.devel/101560

 > > Yes, I know the old behaviour can be restored: after some digging
 > > I found out about the line-move-visual variable. Couldn't the
 > > default be nil instead of t?
 > >
 > > Please do not forget what Gnu Emacs stands for: Generally Not
 > > Used, Except by Middle-Aged Computer Scientists.

The "idea" behind this change is to fix that. :-)

 > > With changes like this you risk alienating the few of us that are
 > > left.

Hey!  Not that way!  By attracting a New Generation of users who have
never seen the "carriage" that "carriage return" refers to.  "What,
were typewriters horse-powered?" ;-)

Sure, a lot of us agree that this isn't what we want, at least at
first, but Miles is fairly typical as a long-time user who finds it
"rather convenient".  So in some sense the "right way" to fix this is
not by refusing to change the defaults, but by making newly variable
behaviors like this one more discoverable.  How about a custom group
called "customizations-we-have-recently-introduced", with subgroups of
the form "in-version-XX.YY", and "version-XX.YY" tags for the previous
behavior if different from default?

It also ought to be possible to revert to "classic Emacs" behavior,
for values of "classic" that are user-defined. :-)

The "recently introduced" idea would be trivial to implement.  In
fact, here's an implementation:

(defgroup customizations-we-have-recently-introduced nil
  "A list of customizations introduced recently, by version of Emacs.

Each customization in this group has a value tagged \"classic\" to make it
easy for users to revert to older behavior after trying the new behavior and
deciding they do not like it."
  :version "23.2")

(defgroup introduced-in-version-23.2 nil
  "Customizations introduced in Emacs version 23.2."
  :group 'customizations-we-have-recently-introduced
  :version "23.2")

This implementation is obviously buggy, I seem to have forgotten some
members. :-)  But nevermind, the bugs can be fixed incrementally. :-)

"Reverting to classic Emacs" could be implemented approximately by
providing a toggle that returned all customizations on a page to the
pre-customizability values.  I say "approximately" because (1) it's
not clear that's what the user means by "classic behavior"; there are
probably some "obvious wins", and IMHO *the* classic behavior of Emacs
par excellance is to make it possible to incorporate obvious wins in
your own environment, easily and cleanly.  Reverting those blindly
would be unfortunate.  (2) Some of the new customizations don't have
values that correspond exactly to any "classic" Emacs.  (3) There will
be interactions, and disentangling those probably will require effort
on the part of the programmers of the feature implementations.

Re: line-move-visual

[Johan Myréen]

On Friday 10 July 2009 09:12:23 Stephen J. Turnbull wrote:

> Hey!  Not that way!  By attracting a New Generation of users who have
> never seen the "carriage" that "carriage return" refers to.  "What,
> were typewriters horse-powered?" ;-)

Ok, I seem to have stirred up some conversation here, and at the same time 
made me appear a grumpy old man. I hope to present more rational 
arguments in this message.

I still haven't quite figured out what the goal here is:

(1)  to keep the mental model of a buffer containing logical lines, but change 
the behaviour of C-n when moving within occasional continued lines

or

(2)  to move away from the "lines" model to a "paragraph" model, where there 
are no logical lines, but Emacs presents the paragraph using visual lines, 
like a word processor does

If (2) is the goal then ok, the behaviour of C-n makes sense. But you should 
go all the way and change the behaviour of C-a, C-e, C-k and probably a lot of 
other stuff too. You should also get rid of the continuation marks, and make 
the lines wrap at a more sensible place than the right edge of the window. 
Wrapping should also occur at word boundaries.

Also note that you can't completely get rid of the lines model: programming 
language source code files consist of (logical) lines. The above mentioned New 
Generation users who haven't seen the "carriage" still bang on their Carriage 
Return keys even in more modern environments than Emacs, like Eclipse or 
Visual Studio.

If (1) is the goal, I don't see how this change makes editing that much more 
convenient. Continued lines are normally quite rare, and I find movement by 
visual lines to be both nonintuitive and inconsistent with the behaviour of C-
a and C-e. (By the way, if the behaviour of C-e would be changed to respect 
visual lines, what would it do--move the insertion point _in front_ of the 
last character of the visual line?)

Johan Myreen

Re: line-move-visual

[Scot Becker]

@ Johan

Yes, thanks for stirring up this conversation.

I would have thought that 'the goal here' should be conceived as a
third option: making both linewise and paragraph-wise work possible,
each in its appropriate setting (or for the users who want it). In
coding, working linewise makes the most sense.  In writing natural
language texts, it's an unsemantic cludge, which we made work for a
while.  (We still need to output hardwrapped paragraphs for certain
purposes, but that can be a matter of export.)

It makes sense that many people want to see a dual default.  Code
should work linewise, unless you don't want it to, text should
soft-wrap (as with v-l-m), except when you don't want it to.  The
current default doesn't do that AFAIK, and you're not the only one
that doesn't like that.

So the introduction of visual-line-mode and line-move-visual is (I
don't think) intended to move towards any new mental model, but rather
to make a new one possible.  Exactly how the defaults are set up is a
separate matter.  Some (like me) will like a dual default, depending
on the mode.  Others will want consistent behaviour across modes.
Since the options will be there for either, we need ways to make it
easy for the user to identify what they want, where they want it, and
to understand any implications of their choices they may not easily
think of.  That can be done with good purpose-written documentation,
or with some kind of assisted settings modification mechanism like the
'custom' customize buffers which Lennnart has hacked up.

@Lennart,

I like it.  It could be a matter of my Emacs installation
(emacs-snapshot on ubuntu) but the Info link doesn't go through to
"Easy Customization", though I have the node.  Likewise the links to
the cua-mode function, give the error "You didn't specify a function."
 Otherwise, the new version seems like it would work for assembling
custom lists of settings for users to consider.

Thanks also for drawing our attention to
      (custom-add-to-group 'my-group 'my-variable 'custom-variable))
This seems like another way to accomplish something similar, if I'm
not mistaken.

Scot

Re: line-move-visual

[Miles Bader]

Please go read the past threads, all of the points you bring up have
been discussed before, at great length.

-Miles

-- 
Corporation, n. An ingenious device for obtaining individual profit without
individual responsibility.

Re: line-move-visual

[Bastien]

Johan Myréen <jem@iki.fi> writes:

> If (2) is the goal then ok, the behaviour of C-n makes sense. But you should 
> go all the way and change the behaviour of C-a, C-e, C-k and probably a lot of 
> other stuff too. You should also get rid of the continuation marks, and make 
> the lines wrap at a more sensible place than the right edge of the window. 
> Wrapping should also occur at word boundaries.

There are two problems: (1) the inconsistency you are pointing at
between C-n/C-p and C-a/C-e (Tassilo also mentioned this) and (2)
whether `line-move-visual' should default to nil.

Solving (1) would be good, and the two issues are independant.

-- 
 Bastien

Re: line-move-visual

[Miles Bader]

Bastien <bastienguerry@googlemail.com> writes:
> There are two problems: (1) the inconsistency you are pointing at
> between C-n/C-p and C-a/C-e (Tassilo also mentioned this) and (2)
> whether `line-move-visual' should default to nil.
>
> Solving (1) would be good, and the two issues are independant.

Please read the previous discussions.

The "C-n/C-p and C-a/C-e inconsistency" of the default settings is intentional.

Having used the current defaults for a fairly long period, and of course
"traditional" emacs for untold eons before that, I've come to the
conclusion that Chong made the right choice.

I get annoyed sometimes too by C-n/C-p's behavior -- but the traditional
behavior annoyed me _more_ often.  I think there is _no_ setting which
will please all people, or even one person all the time, but the current
compromise seems to be pretty decent.

I know some people will feel different "annoyance tradeoffs" than me,
but for those complaining about the change, I at least hope you've given
yourself some time to get used to it -- way too often, people seem to
fire off a flame about some change about 34 seconds after they've
installed the new version implementing it!

-Miles

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

Re: line-move-visual

[Kenichi Handa]

In article <87iqhzokpd.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:

> The "C-n/C-p and C-a/C-e inconsistency" of the default settings is intentional.

> Having used the current defaults for a fairly long period, and of course
> "traditional" emacs for untold eons before that, I've come to the
> conclusion that Chong made the right choice.

> I get annoyed sometimes too by C-n/C-p's behavior -- but the traditional
> behavior annoyed me _more_ often.  I think there is _no_ setting which
> will please all people, or even one person all the time, but the current
> compromise seems to be pretty decent.

If we need two different operations, the normal way is to
use two different keys.

I'm using <up> and <down> (arrow keys) for visual line move,
and C-p and C-n for logical line move.  At least, this
setting please myself all the time.

I'm also using <C-left> and <C-right> for
beginning-of-visual-line and end-of-visual-line
respectively.  This is very convenient too.

---
Kenichi Handa
handa@m17n.org

Re: line-move-visual

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> I'm using <up> and <down> (arrow keys) for visual line move,
> and C-p and C-n for logical line move.  At least, this
> setting please myself all the time.

I actually used to do this myself -- I had my own "visual line move"
commands, bound to C-S-p / C-S-n.

However even that was annoying, mostly because since wrapped lines are
in fact, rare, I would almost always first do the wrong thing and then
have to correct it:  C-p, end up in the wrong place, curse, move back
down with C-n, and then visually move up again with C-S-p.

In other words, despite knowing about the issue and having my fingers
trained for over 20 years using traditional C-p, _still_ I would often
instinctively expect visual behavior.  It was a palpable relief when
Emacs adopted its current behavior.

-Miles

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Re: line-move-visual

[Bastien]

Miles Bader <miles@gnu.org> writes:

> Bastien <bastienguerry@googlemail.com> writes:
>> There are two problems: (1) the inconsistency you are pointing at
>> between C-n/C-p and C-a/C-e (Tassilo also mentioned this) and (2)
>> whether `line-move-visual' should default to nil.
>>
>> Solving (1) would be good, and the two issues are independant.
>
> Please read the previous discussions.
>
> The "C-n/C-p and C-a/C-e inconsistency" of the default settings is intentional.
>
> Having used the current defaults for a fairly long period, and of course
> "traditional" emacs for untold eons before that, I've come to the
> conclusion that Chong made the right choice.
>
> I get annoyed sometimes too by C-n/C-p's behavior -- but the traditional
> behavior annoyed me _more_ often.  I think there is _no_ setting which
> will please all people, or even one person all the time, but the current
> compromise seems to be pretty decent.
>
> I know some people will feel different "annoyance tradeoffs" than me,
> but for those complaining about the change, I at least hope you've given
> yourself some time to get used to it -- way too often, people seem to
> fire off a flame about some change about 34 seconds after they've
> installed the new version implementing it!

I don't read any argument against an official poll, and this is just
what I'm asking for.

PS: I've been using this default for a while.  Since I'm using a lot
of macros, I had to switch to (setq line-move-visual nil) because I
didn't to use M-x visual-line-mode to turn it off each time.

-- 
 Bastien

Re: line-move-visual

[Miles Bader]

Johan Myréen <jem@iki.fi> writes:
> Could somebody please explain to me what the idea behind the new concept of 
> "visual lines" in Emacs is?

To incite flames by infuriated users.

As a side-benefit of course, it's rather convenient.

-Miles
Emacs user since '83

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: line-move-visual

[Chong Yidong]

Johan Myréen <jem@iki.fi> writes:

> Please do not forget what Gnu Emacs stands for: Generally Not Used,
> Except by Middle-Aged Computer Scientists.  With changes like this you
> risk alienating the few of us that are left.

I think you misunderestimate the population of Emacs users.

Re: line-move-visual

[Andrey Paramonov]

Johan Myréen <jem <at> iki.fi> writes:
> Couldn't the default be nil instead of t?

I'm sure many users (especially younger ones ;-) would appreciate the idea of
Visual Lines mode. However, making it default would expose some current
usability problems, like this one:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3695

From this point, you may wish to not enable the Visual Lines mode by default
until it matures (23.1 ?).

Andrey Paramonov

Re: line-move-visual

[Teemu Likonen]

On 2009-07-11 06:42 (UTC), Andrey Paramonov wrote:

> I'm sure many users (especially younger ones ;-) would appreciate the
> idea of Visual Lines mode. However, making it default would expose
> some current usability problems, like this one:
>
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3695
>
> From this point, you may wish to not enable the Visual Lines mode by
> default until it matures (23.1 ?).

I think this discussion is mostly about variable line-move-visual.
Anyway, even though I like global line-move-visual=t indeed the feature
isn't completely mature yet. These both bugs appear only when
line-move-visual=t and are present in 23.0.96 and 23.1.50:

    "next-line and previous-line don't keep the column in text-scale-mode"
    http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3668

    "Strange cursor movement in truncation mode"
    http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3805