f



line-move-visual

What mindless cretin thought that it should be a good idea to make 
line-move-visual be the default in emacs 23?

I just found out about this charming "improvement" in the worst possible 
way.  Investigation determined that a "routine" software update had just 
installed emacs 23 and gave me this "improvement".

People wonder why everybody hasn't dumped proprietary desktop software. 
This is an example why.  Emacs' line behavior has well over 30 years of 
history, and some bagbiter goes and changes it BY DEFAULT.

Add all the cute new features you want.  But leave the goddamn defaults 
alone.

If you want to have your own playpen where you twiddle defaults to your 
hearts content, have at it.  But don't pretend that you produce software 
for a production environment, and stop telling the Linux distributions 
that they should "upgrade" to your "improved" versions.  People doing real 
work depend upon those distributions.

It does no good to say "read the release notes" when the affected users 
don't get the release notes and don't even know that a new release 
happened.  It is also unreasonable to expect users to subscribe to every 
obscure newsgroup, forum, and wiki to hear about changes that will turn 
their expectations upside down.

Yes, I fixed my .emacs file.  And I'm putting in the same change to all 
the .emacs files on all the dozens of other machines I use, even though 
they still have emacs 22, because otherwise this unpleasant surprise will 
repeat itself over and over again.

Grr.

-- 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.
0
Mark
6/3/2010 6:33:24 PM
comp.emacs 4822 articles. 1 followers. Post Follow

145 Replies
3730 Views

Similar Articles

[PageSpeed] 42

Mark Crispin wrote:

> It does no good to say "read the release notes" when the affected users
> don't get the release notes and don't even know that a new release
> happened.  It is also unreasonable to expect users to subscribe to every
> obscure newsgroup, forum, and wiki to hear about changes that will turn
> their expectations upside down.

Emacs release notes is obtained by doing C-h n, or by picking "Emacs
news" on the Help menu.  Are you saying that you are using Linux
distributions that break these features?

I am not taking sides on the line-move-visual issue.  But I do know that
it was a complex decision for the Emacs developers and it wasn't made
easily.

However, I am concerned about downstream distributions that omit the
release notes.  That seems to be a real disservice to the users.

Cheers,
Uday Reddy
0
Uday
6/3/2010 8:09:31 PM
On Thu, 3 Jun 2010, Uday S Reddy posted:
> I am not taking sides on the line-move-visual issue.  But I do know that
> it was a complex decision for the Emacs developers and it wasn't made
> easily.

They made the wrong decision.  Changes to default behavior are a bad idea. 
Changes to default behavior of the most basic functionality are an 
extremely bad idea.

I don't care if M-X fart-noisily-with-spray changes its default scent from 
skunk to lemon.  But I damn well do care about the most basic operations: 
all CTRL single letter and ESC single letter.  After 33+ years of using 
emacs, I expect these to be reliable and not suddenly change.

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.

> However, I am concerned about downstream distributions that omit the
> release notes.  That seems to be a real disservice to the users.

So I find a system with the release notes.  And the reference to this 
incompatible change is buried 300+ lines deep, after numerous pointless 
entries such as emacs having a character set 4 times bigger than Unicode.

-- 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.
0
Mark
6/3/2010 10:11:03 PM
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
0
Uday
6/4/2010 7:59:01 AM
Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

Hi Uday,

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

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.

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.

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.

Because keyboard macros are important to me, I set line-move-visual to
nil.

Bye,
Tassilo
0
Tassilo
6/4/2010 8:39:11 AM
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.

Yes, it seems fairly uncontentious that the visual-line-mode is a useful feature.

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

In the emacs-developers list, I see that line-move-visual came first and visual-line-mode was invented later.  But, after visual-line-mode wasin, they should have perhaps gone back and put line-move-visual in the trash bin.

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

Cheers,
Uday
0
Uday
6/4/2010 10:44:01 AM
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
0
Uday
6/4/2010 11:24:31 AM
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
0
Tassilo
6/4/2010 12:49:07 PM
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
0
Tassilo
6/4/2010 1:00:39 PM
On Jun 3, 6:11=A0pm, Mark Crispin <m...@panda.com> wrote:

> I don't care if M-X fart-noisily-with-spray changes its default scent fro=
m
> skunk to lemon. =A0

LOL!!!
0
sable
6/4/2010 1:20:49 PM
On Fri, Jun 04 2010, Tassilo Horn wrote:

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

Attempted thread-jack: why use visual-line-mode instead of
longlines-mode?

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
0
brendan
6/4/2010 1:39:38 PM
On 6/4/2010 2:39 PM, Brendan Halpin wrote:

> Attempted thread-jack: why use visual-line-mode instead of
> longlines-mode?

Apparently, there are contexts in which longlines-mode isn't effective.  I forget the details now.

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

Cheers,
Uday
0
Uday
6/4/2010 2:34:05 PM
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
0
brendan
6/4/2010 2:45:17 PM
> 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
0
Stefan
6/4/2010 2:51:54 PM
On Fri, 4 Jun 2010, Tassilo Horn posted:
> 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.

This is precisely how I got screwed by this incompatible change.  But the 
change in behavior also confused the hell out of me.  Almost all of my 
editing is C source code.

> Because keyboard macros are important to me, I set line-move-visual to
> nil.

Yes.

-- 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.
0
Mark
6/4/2010 4:28:12 PM
On Jun 4, 6:39=C2=A0am, 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:

=E2=80=A2 it fixed a frequently asked feature. (e.g. i think ALL editors/ID=
Es
after mid 1990s, move by visual line )

=E2=80=A2 it fixed a issue that 3rd party elisp packages cannot address wel=
l.

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:

=E2=80=A2 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.

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

=E2=80=A2 The Harm of Hard-wrapping Lines
  http://xahlee.org/UnixResource_dir/writ/hard-wrap.html

A introduction. (written as a diatribe )

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

=E2=80=A2 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.

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

=E2=80=A2 Plain-Text Email Fetish
  http://xahlee.org/UnixResource_dir/writ/plain_text.html

=E2=80=A2 Unix, RFC, and Line Truncation
  http://xahlee.org/UnixResource_dir/writ/truncate_line.html

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

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

=E2=80=A2 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.

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

=E2=80=A2 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.

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

=E2=80=A2 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
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/4/2010 5:49:08 PM
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.
0
Mark
6/4/2010 5:52:38 PM
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.
0
Mark
6/4/2010 6:18:02 PM
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
0
David
6/4/2010 6:28:44 PM
hi Mark Crispin,

On Jun 4, 11:18=C2=A0am, Mark Crispin <m...@panda.com> wrote:
> This is why UNIX and C accomplish things. =C2=A0They 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. =C2=A0Perhaps you ought to use Word instead of seeking to make em=
acs
> 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
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/4/2010 7:19:47 PM
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
0
Tassilo
6/4/2010 8:53:08 PM
>> 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
0
Stefan
6/4/2010 9:16:09 PM
On Fri, 4 Jun 2010, David Kastrup posted:
> Why should they install newer versions if they don't want things to
> change?

What makes you assume that the end user has any choice in the matter?

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

What makes you assume that the end user has that option?

> Install Emacs 18 everywhere and you are finished.

What makes you assume that the end user should be obligated to install a 
particular version of a massive package "everywhere" in order not to get 
the rug pulled from under him?

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

Do you have a clue as to what the task entails?

Do you know what you made a completely idiotic statement?

I can answer "yes" to all three questions.  I suspect from the tone of 
your remarks that you can not.

-- 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.
0
Mark
6/5/2010 1:23:16 AM
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.
0
Mark
6/5/2010 1:29:12 AM
On Fri, 4 Jun 2010, Xah Lee posted:
> maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix,

emacs predates GNU by several years.

I was there at emacs' creation, and I used its predecessors.  I had only a 
very minor role in its software development, but I had an influence on the 
design of some of the basic commands (I remember, although RMS may have 
forgotten).

> and the whole lisp culture and thinking is contrary to unix and C.

emacs was not originally written in LISP.  It was many years later that it 
was ported to LISP.

Not that I dislike LISP.  Quite the contrary; my history with LISP is 
longer than with C.  I wrote the first IMAP client in LISP, and years 
later (1989) reimplemented it in Objective-C.

On the other hand, I acknowledge Richard Gabriel's essay about why "Worse 
is Better".  I doubt that anyone would be presumptous enough to imply that 
Gabriel is ignorant about LISP!  He convincingly demonstrates why UNIX and 
C won, while ITS and LISP lost.  That essay was a particularly bitter pill 
to swallow for those of us who spent many years in the MIT/Stanford 
environment (nearly 15 years for me); but it was spot-on.

> speaking of Microsoft Word, i wait for dinosaurs like u to die.

You seem to have some serious psychological problems.

> The
> question is, can we recruit enough new generation of coders to emacs
> fast enough before emacs extinguishes.

If emacs "extinguishes", it will because it no longer provides a benefit 
that overcomes its demerits.

There are many word processors, most of which perform that task quite a 
bit better than emacs.  emacs provides a particular benefit, and fills a 
niche that is not served by word processors.

The world is not made a better place by undermining that benefit in order 
to transform emacs from a superior text editor to an inferior word 
processor.

I can understand the frustration of being unable to convince a word 
processor user to try emacs.  Nonetheless, it is unwise to alienate the 
core constituency when purposing to expand the constituency.

-- 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.
0
Mark
6/5/2010 2:33:10 AM
>>> 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.

Somehow embracing boredom seem to only be able to come with age, yes.


        Stefan
0
Stefan
6/5/2010 1:57:21 PM
>> 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?

Don't know about mid-70s nor about Emacs-18, but I do have Emacs-19
installed on my Debian testing systems (and no, I didn't compile it,
I "just" kept the emacs19 package installed (well, for some of those
machines, I manually (re)installed it long after it had "disappeared").

> Do you have a clue as to what the task entails?

Yup.  I had to create one dummy package that explains to dpkg that some
X11 libs have been renamed.  IIRC that was about it, but yes, it took me
a bit of time to figure it out.


        Stefan
0
Stefan
6/5/2010 2:00:43 PM
On Sat, 5 Jun 2010, Stefan Monnier posted:
> Don't know about mid-70s nor about Emacs-18

emacs 18 and emacs 19 are creations of much later than the mid-1970s.

For mid-1970s emacs, you have to have a CPU (and operating system) capable 
of running TECO.  And not just any old TECO.

>> Do you have a clue as to what the task entails?
> Yup.  I had to create one dummy package that explains to dpkg that some
> X11 libs have been renamed.  IIRC that was about it, but yes, it took me
> a bit of time to figure it out.

As you noted, even these relatively recent versions require effort.  It 
gets worse the further back you go.  The only way to run mid-1970s emacs 
is via a virtual machine.

The point was that it is ridiculous to tell someone to "install a version 
of emacs from the mid-1970s" in answer to a complaint about a change that 
broke behavior dating from the mid-1970s.

Nobody would seriously suggest changing the "/" operator of C to work like 
APL's reduce operator, on the grounds that division is simply 
multiplication by the inverse and thus does not need an operator on its 
own.  The semantics of the motion operators in emacs have just as much 
history.

-- 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.
0
Mark
6/5/2010 7:16:52 PM
On 6/5/2010 7:00 AM, Stefan Monnier wrote:
>>> 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?
>> [...]

I have. It required hardware from DEC to run it (PDP-10, DEC-20).
I still have a tape of the sources, executables and docs of the
EMACS version 150 but no way to (conveniently) read the tape. The
manual for that version is here (scanned a few years ago):

<http://thadlabs.com/FILES/Emacs-150_1980.09.05.pdf> [210p, 9MB]

I actually had been using Emacs back in the mid-/late-1970s but
got it from the Pentagon; version 150 was handed to me by RMS in
John McCarthy's office at Stanford.

> Don't know about mid-70s nor about Emacs-18,

Looking right now at the GNU Emacs Manual, Version 18, it's dated
March 1987 and 284 pages.

I have some version of GNU Emacs on every one of the 40+ systems
here and they all operate essentially identically. I understand
and agree with Mark Crispin's comments about line-move-visual
and the idiocy of changing the behavior of fundamental keystrokes.

I recall back in the early-/mid-1980s every secretary and just about
everyone else at HP Labs (Palo Alto CA) used Emacs on HP's DEC-20s;
they had about 6 or 7 (2060s and something else (? 2065 or 2080 ?)).
0
Thad
6/5/2010 9:11:15 PM
On Jun 5, 2:11=A0pm, Thad Floryan <t...@thadlabs.com> wrote:
> I have some version of GNU Emacs on every one of the 40+ systems
> here and they all operate essentially identically. I understand
> and agree with Mark Crispin's comments about line-move-visual
> and the idiocy of changing the behavior of fundamental keystrokes.

here's a essay that might help.

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

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

The Harm of Hard-wrapping Lines

Xah Lee, 2005-02-22

Computing Folks of the industry:

please spread the debunking of the truncating line business of the
fucking unix-loving fuckheads, as outlines here:
http://xahlee.org/UnixResource_dir/writ/truncate_line.html

if this myth-debunking is known widely enough, there wouldn't be any
more line truncating business.

emacs community has always been a thinking community as opposed to the
unix criminals. However by historical happenstance, the emacs of GNU's
Not Unix is essentially a program for unixes, so unavoidable it has to
deal with and inherit some of the ill shits of unix, if for nothing
but to be practical.

However, as of today, emacs don't really have reason to have
arrow-down behavior to be dependent on the hard-coded line wraps. I
want the next emacs version's down-arrow behavior to be fixed. (and
optionally as another mode to move by EOL.)

The reason for this change is easy. For those habituated with hard
wrapped lines, this would cause no difference. However, for those who
have lines that return at logical places, this would be an
improvement. (This is the intuitive way, and all non-geek editors
behave this way, even most editors or IDEs designed for programing.)

The need in this change is significant. By the current behavior of
down-arrow by EOL char, it discourages logical line breaking,
encourages hard-coded line breaking, and engenders the huge and
wide-spread problems as a consequence (as partially detailed in the
url given above): Programs posted online are broken, the who-said-what
quoting systems are a mess to process and comprehend, and needless
complex programs that processes and re-process the hard-wrapped
lines... And also it seeds the bad notions by creation of a generation
of imperative languages based on hard-line wraps (e.g. many
languages's line comment; and cannot be nested), and the misleading
and harmful habituation in Info Tech of sizing software by
EOL-counting. (both of these are hindrances to the prosperity of
functional programing.)

Further, in programing there's large chapters and energy spent on
what's called =93coding style=94, which refers to the petty issue of when
and how to press a return so the lines all jag in some uniform
way. This ubiquitous =93coding style=94 activity is helped by the
hard-wrap habit of thinking, which created these EOL-centric language
syntaxes in the first place.

(When coding in a programing language, programers should never have to
enter returns for the sake of display-formatting. The language's
syntax and the editor should be able to display the code well on the
fly by a brainless parsing. Some 70% of EOL in codes today are there
manually entered by programer that does not serve any function other
than hard-coded pretty-printing.
 (as oppose to the sometimes a intentional return to make a point in
  the code, either as logical break, or emphasizing a section.)

And as a psychological and practical effects of these EOL-centric
languages is that attention are put on code by the lines, instead of
functional or logical units. For example, comments tends to be based
on lines of code, as opposed to on a functional unit or algorithmic
block. Boolean clauses inside IF clause each span a line, as opposed
to being together as a predicate unit.
 (which smother new developments of such predicate unit in language
  syntax or semantics)
IF blocks almost always span multiple lines, as opposed to the idea of
a single coherent unit of =93if PREDICATE do BLOCK=94.
 (and such EOL-centric code tends to engender practices such as
  calling and setting global variables here and there inside code
  blocks).
 Temporary variables occupy a line by themselves, as oppose to tucked
 inconspicuously inside its functional unit...etc and so on.

 (a example of a language that is not EOL-centric is Mathematica,
  which displays the code with sensible justification, all done
  automatically behind the scenes, just as a word processor is to
  writing.

  Similar mileu are in LISP languages, but they did not push this idea
  further.

  (That is to say, in LISP communities, they on occasion still do and
   talk about the petty issues of manual return-pressing for style,
even
   their languages are potentially immune to the hard-wrap
psychology.)
 )
)

I hope the above is some elucidation on the hard-wrap and
line-truncation business. Please spread the info.

--------------------------------------------------
The Harm of Manual Code Formating

The following is a newsgroup post (edited), at comp.emacs, Xah Lee,
2007-10-11.

....

Someone wrote: =ABAs for your code, I don't know why you are indenting
interactive differently than the further forms;=BB

just sloppy... never really pay much attention about any so-called
=93coding style=94 (which often means the code fomatting habit) Actualy, i
consider the rampant reference and concern about =93coding style=94, is a
egregious fuck up that can be attributed significantly to unix and C.
The damage is far and wide, and also influenced negatively the lisp
community.

In general, a programer should never have to press any returns, tabs,
etc for the purpose of formatting his code. The editor should
automatically wrap the code properly for display formatting. Many
language, esp those turds from Unix/C's family (tcsh,Perl,C++,Java)
has a syntax that this is impossible for this at a lex level. For Lisp
the lang it is is possible, but the thinking isn't there.

In Mathematica, i never have to spend time to fiddle with code
formatting. (and when i do actually insert a indent or return, it is
intentional and means something (usually indicating a semantic/
algorithmic/code unit/break)) It's quite interesting to note that
Mathematica not only formats codes automatically, but the fact that
its code can contain 2-dimentional type-set mathematics (i.e.
fractions, roots, powers, subs, parens, nesting, integrals, ...
variously combined.), and auto-wrap such type-set expressions on the
fly. This feature, started in Mathematica version 3 about 1997, is
today a decade-old technology. Most coders today (e.g. Perl) are still
arguing and wallowing about the fine points of how many spaces a
indent should be. (not just innanely in newsgroups, but there are
entire literature (e.g. guides) devoted to it. Fucking morons and
holes.)

As to lisp, it would be nice, if a programer can press a button in
emacs, then the current code block would be formatted by a simple
lexical analysis. (similar to how fill-paragraph would work) I think
it is relatively trivial to code his command, but to my surprise, it
is not done. I was told by one Scheme expert Taylor R Campbell (aka
Riastradh, author of paren-edit mode) that this is non-trivial, but i
couldn't believe it and maybe he misunderstood what i wanted about
this command.

In fact when i gained more lisp experience in mid 2000s, i was
surprised to find that the concept of auto-wrap is basically non-
existant among lispers. Lispers, to a lesser degree than C/Perl
morons, still do discuss and debate now and then about formatting
trivia.

For a outline of how this lisp formatter would work, see: A Simple
Lisp Code Formatter.
0
Xah
6/5/2010 9:54:40 PM
Mark Crispin <mrc@panda.com> writes:

> On Fri, 4 Jun 2010, David Kastrup posted:
>> Why should they install newer versions if they don't want things to
>> change?
>
> What makes you assume that the end user has any choice in the matter?

So you think that Emacs development should stop in order to save
helpless end users from having new versions installed to them?

>> Why don't you get and install a suitably old version and stay with it?
>
> What makes you assume that the end user has that option?

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

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

>> Install Emacs 18 everywhere and you are finished.
>
> What makes you assume that the end user should be obligated to install
> a particular version of a massive package "everywhere" in order not to
> get the rug pulled from under him?

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

>> 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.  That's the point of time _you_ mentioned.  GNU
Emacs was not released before 1985.  And yes, I compiled and used
versions in the 80s.

> Do you have a clue as to what the task entails?

Yes.

> Do you know what you made a completely idiotic statement?

Well, _you_ were the one talking about the mid-70s.

> I can answer "yes" to all three questions.

Congratulations.  Compiling and installing GNU Emacs before its
existence is indeed an impressive feat.

> I suspect from the tone of your remarks that you can not.

I actually started my computing work with Fortran and punch cards on a
Cyber 175.  My application "preview-latex" was responsible for most of
the bug reports (and fixes) in the image display system of Emacs-21
before its release.

You really don't want to start a dick size contest in these categories
with me.

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.

Do you really think you are in the best position to call the developers
names?

-- 
David Kastrup
0
David
6/5/2010 10:11:59 PM
2010-06-04

On Jun 4, 7:33=C2=A0pm, Mark Crispin <m...@panda.com> wrote:
> On Fri, 4 Jun 2010, Xah Lee posted:
>
> > maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix,
>
> emacs predates GNU by several years.
>
> I was there at emacs' creation, and I used its predecessors. =C2=A0I had =
only a
> very minor role in its software development, but I had an influence on th=
e
> design of some of the basic commands (I remember, although RMS may have
> forgotten).

am curious, if you know Daniel Weinreb, and who used emacs first. Am
curious just to satisfy a fun quote, about who can claim being the
oldest emacs user.

Daniel wrote: =C2=ABNobody has been using Emacs longer than I have (I was
one of the original beta-testers.  I refer here to the original Emacs,
written in ITS TECO for the DEC 10.) =C2=BB

source: http://groups.google.com/group/comp.emacs/msg/0342e0bc1aa05c0d
2008-06-01 on comp.emacs

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

I see you also have a Wikipedia entry, at http://en.wikipedia.org/wiki/Mark=
_Crispin

nice.

> > speaking of Microsoft Word, i wait for dinosaurs like u to die.
>
> You seem to have some serious psychological problems.
>
> > The
> > question is, can we recruit enough new generation of coders to emacs
> > fast enough before emacs extinguishes.
>
> If emacs "extinguishes", it will because it no longer provides a benefit
> that overcomes its demerits.
>
> There are many word processors, most of which perform that task quite a
> bit better than emacs. =C2=A0emacs provides a particular benefit, and fil=
ls a
> niche that is not served by word processors.
>
> The world is not made a better place by undermining that benefit in order
> to transform emacs from a superior text editor to an inferior word
> processor.

the question is what is superior and inferior.

for example, in this thread, i consider that the move by screen line
as a new feature is absolutely good. You disagree, but didn't seems to
provide counter to the reasons i gave. You started to cite about me
wanting emacs to become Microsoft Word.

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

for examples:

=E2=80=A2 Larry Wall and Cults
  http://xahlee.org/UnixResource_dir/writ/larry_wall_n_cults.html

=E2=80=A2 Laziness, Perl, and Larry Wall
  http://xahlee.org/UnixResource_dir/writ/perl_laziness.html

=E2=80=A2 On the Survival Strategies of Larry Wall vs Richard Stallman
  http://xahlee.org/UnixResource_dir/writ/wall_stallman.html

=E2=80=A2 Language, Purity, Cult, and Deception
  http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html

=E2=80=A2 =E2=80=9CFree=E2=80=9D Software Morality, Richard Stallman, and P=
aperwork
Bureaucracy
  http://xahlee.org/UnixResource_dir/writ2/FSF_philosophy.html

=E2=80=A2 Why Software Suck
  http://xahlee.org/UnixResource_dir/writ/why_software_suck.html

  (Kent Pitman)
=E2=80=A2 Why You should Not Use The Jargon Lisp1 and Lisp2
  http://xahlee.org/emacs/lisp1_vs_lisp2.html

=E2=80=A2 Paul Graham's Infatuation with the Concept of Hacker
  http://xahlee.org/comp/Paul_Graham_language_design.html

you can try also to search newsgroup archive on Richard Fateman,
Richard Gabriel, Kent Pitman, on my conversation with them in
comp.lang.lisp.

The point being, doesn't matter how famous or how expert one is about
particular subject, he can always be wrong, and statically, they are
often quite wrong about many of their opinionated views outside the
very narrow field they have expertise a single human animal can
possibly achieve, as documented in history. (this counts in for
example some big mouthers who's got strong opinion on everything once
they got a Nobel) Also, they tend to be more wrong when they are old,
usually happens when it is long past the years they were recognized
for.

So, here, we have a argument about a issue of emacs. We disagree.

I have writen quite a few criticisms of emacs in the past. They are
documented here:

=E2=80=A2 Emacs Modernization
  http://xahlee.org/emacs/emacs_modernization.html

often with suggested solution and sometimes code.

it is my firm belief, that each of my claim or reasons of suggestion
can be verified in some scientific way by most reasonable judgments.

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

to argue, first let's be precise what we are arguing about. Here's few
points:

=E2=80=A2 emacs 23's introduction of line-move-visual feature is good (or
bad).

=E2=80=A2 emacs 23's default of line-move-visual t good (or bad)

=E2=80=A2 the very concep of move by screen line is good (or bad).

You may disagree with all of them. But to be fruitful in our debate,
lets pick just one of the topic, and we can argue about it rationally.

please don't just claim about how it is like Microsoft Word. That's
not a good argument. Because, for example, i can then retort that you
are a dinosaur.

also, don't just say that people are getting dumb. Older people, may
it be grandpa or college professors, tend to say that a lot, but it is
usually uttered as a sigh of life without much basis. Part of it is
simply because people get old and they envy the young. Generally
speaking, newer generation are smarter, healthier, more informed,
throughout history.

The good old days, my ass. LOL.

Btw, i'm 42. Not exactly the young thing you want to grab.

Am happy to have become acquainted with you. However, i'm sorry i'm
not the typical normal people when it comes to human animal
relationships and argument resolution. You started a aggressive
bitching about a issue i care about, then throw the typical =E2=80=9CMicros=
oft
Word=E2=80=9D slur when i gave a list of essays i've written in the past 10
years that reason about why i think it is a good feature.

  Xah
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/5/2010 10:28:28 PM
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.
0
Mark
6/6/2010 2:25:36 AM
On Sat, 5 Jun 2010, Thad Floryan posted:
> I have. It required hardware from DEC to run it (PDP-10, DEC-20).
> I still have a tape of the sources, executables and docs of the
> EMACS version 150 but no way to (conveniently) read the tape.

It went up to version 165 or so.  You can get a runnable TOPS-20 system 
under a virtual PDP-10 with EMACS 165 from:

 	http://panda.trailing-edge.com/

> I have some version of GNU Emacs on every one of the 40+ systems
> here and they all operate essentially identically.

I go even further, and have some program called "emacs" (not necessarily 
GNU emacs) on about the same number of machines.  This includes some 
embedded devices.  They all have that property!  It's a valuable property.

I daresay that RMS would not recognize some of these "emacs" programs as 
being emacs; some are very basic programs.  But, by golly, if you stick to 
the basic functional set of command keys they all work the same.

> I understand
> and agree with Mark Crispin's comments about line-move-visual
> and the idiocy of changing the behavior of fundamental keystrokes.

Thank you.

-- 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.
0
Mark
6/6/2010 2:32:29 AM
On Sat, 5 Jun 2010, Xah Lee posted:
> am curious, if you know Daniel Weinreb, and who used emacs first.
> Daniel wrote: "Nobody has been using Emacs longer than I have (I was
> one of the original beta-testers.  I refer here to the original Emacs,
> written in ITS TECO for the DEC 10.) "

DLW was there, and was quite a bit closer to the thick of things than I 
was.  I had returned to complete my undergraduate education in another 
state a few months before.

In reading his quote, DLW does not claim to be "the first"; he simply 
says that nobody has used it longer than he has.

There was no single person who was "first".  I can think of at least a 
half dozen individuals without trying who would share the spot with him. 
The actual number is probably at least twice that.

I started using emacs within a couple of days of DLW.  I knew of the 
project (it had started the previous summer).  When I started noticing (I 
was remote via ARPAnet on a 300 bps dialup) that people were running "E", 
instead of what they were running before, I put two and two together at 
once and joined the fun.

This would have been December 1976 - January 1977.

emacs was barely usable then, with frequent crashes, but it improved very 
quickly.  It was also somewhat difficult to use, as I did not have a 
cursor-addressed display terminal (yes, it was possible to use it in 
"glass teletype" mode).  It may have been a couple of months after that 
before I finally was able to try emacs in full display mode.

I know that by the spring of 1977 I had access to an ADM-3A which had 
cursor addressing...but very little else good to say about it as a display 
terminal.  I wrote a term paper using emacs on it, at 300 baud.  Today, 
such torture would probably be banned by UN treaty.

I used the predecessors of emacs for at least a year before DLW arrived. 
My macro library, with its symmetry between control and meta that emacs 
copied, was an extension of the TECMAC library.  TECMAC and another 
library called TMACS were the two main streams that became emacs.

Most of emacs' fundamental key bindings came from TECMAC, but there were 
significant differences.  For example, TECMAC used C-Y C-Y for what in 
emacs was first C-X C-R and later became C-X C-F.  TMACS' influence was 
especially felt in the M-X commands.  emacs fused these.

The fundamental behaviors of C-A, C-E, C-N, and C-P were all in TECMAC. 
Now that I think about it, I think that they were in ^R mode in TECO 
before that.  They're very old behaviors.

I'm not certain now - DLW will definitely correct me if I am wrong - but I 
am pretty sure that DLW wrote the first clone of emacs.  It was on the 
Lisp Machine, written in Lisp Machine LISP (a superset of MacLISP; Common 
LISP didn't exist yet) and was called EINE (Eine Is Not Emacs).  Its 
successor was ZWEI.

DLW is a good guy and a very bright programmer.

-- 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.
0
Mark
6/6/2010 2:56:42 AM
Mark Crispin <mrc@panda.com> writes:

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

Since you never contributed to Emacs, it is none of your business who
may or may not be an Emacs developer.

> Being a developer requires humility.

That must be why you are no Emacs developer.

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

Why should GNU Emacs try to keep compatibility to its predecessors?

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

Well, so don't use any software of theirs.  Problem solved.

> If you are the irresponsible idiot that make this change, then you
> deserve it.

I recommend you check the discussion on the developer list.  It was a
decision formed after discussion.  You did not participate in it.

-- 
David Kastrup
0
David
6/6/2010 6:58:43 AM
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
0
Uday
6/6/2010 9:12:11 AM
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
0
David
6/6/2010 9:39:25 AM
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!)

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.

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.

Cheers,
Uday
0
Uday
6/6/2010 1:04:51 PM
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
0
Tassilo
6/6/2010 3:21:03 PM
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:
0
Alain
6/6/2010 3:43:05 PM
On Sun, Jun 06 2010, Alain Ketterlin wrote:

> Sorry to break the thread, but...

Why not change the subject then?

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

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

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

,----[ `C-h k W Q' ]
| W Q runs the command gnus-article-fill-long-lines
|   which is an interactive Lisp function in `gnus-art.el'.
| It is bound to W Q, <menu-bar> <Article> <Washing> <Fill long lines>.
| (gnus-article-fill-long-lines &optional INTERACTIVE &rest ARGS)
| 
| Fill lines that are wider than the window width.
`----

> Any help is welcome, even if it takes the form of a few keywords to
> help me search the doc. Thanks,

Try an index search for long-lines in the Gnus manual.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
6/6/2010 5:09:28 PM
On Sun, 6 Jun 2010, Uday S Reddy posted:
> 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.

And breaks key macros.

> So, there are three things that an old-timer is annoyed about:
> 1. Change of established semantics.
> 2. Inconsistency.
> 3. Pointlessness.

4. Breaking long-standing key macros and procedures, which in turn leads 
to file corruption based upon the current screen width (= "random and 
unpredictable").

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

It seems to be a common problem among some Gen-X types.  John Xenakis (a 
colorful character if ever there was one!) writes a good essay related to 
the topic:

http://www.generationaldynamics.com/cgi-bin/D.PL?d=ww2010.i.java080701

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

This attitude has always been a problem, but in the past it would be 
corrected.  In a lab where everybody was under one roof, the users would 
gang up (often with the lead developer) and discipline the offending young 
developer.

Today, the only recourse is to spawn a fork.  The problem is that each 
fork erodes the credibility of open source.  The classic example is BSD, 
which committed suicide by fork.

-- 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.
0
Mark
6/6/2010 5:24:42 PM
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.
0
Mark
6/6/2010 6:17:19 PM
On 6/6/2010 4:43 PM, Alain Ketterlin wrote:
>
> 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.

Right.  Now you know what I mean by treating long lines in a civilized way!

I am not an active Gnus user, but I have this setting in my .gnus.el file:

(setq gnus-treat-fill-long-lines t)

This is not quite fully civilized though.  If my message happened to have some code or a table, this will end up treating it as a paragraph.

If you turn on visual-line-mode in your article buffer, you will get a proper treatment of long lines.  But, I have no idea how to make Gnus turn it on by default.

---

By the way, Thunderbird is sending out a format=flowed header, but I haven't seen any evidence that it is actually using the format.  It just sends long lines up to the legal limit (990?), and then chops the lines there.  Yuck!

One of these days, I will grow out of Thunderbird.  But, meanwhile, I promise not to send lines longer than the legal limit.

Cheers,
Uday


0
Uday
6/6/2010 8:22:52 PM
On 6/6/2010 11:17 AM, Mark Crispin wrote:
> [...]
> All because of clueless developers who broke emacs in version 23.

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

Refs:

<http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-Lets-Users-Install-Signed-Packages-Sans-Root-Privileges>

<http://linux.slashdot.org/story/09/11/20/1241231/Fedora-12-Package-Installation-Policy-Tightened>

<https://www.redhat.com/archives/fedora-announce-list/2009-November/msg00012.html>

<https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html>

Developer's blog:

<http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/>
0
Thad
6/7/2010 1:07:58 AM
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.
0
Mark
6/7/2010 2:53:26 AM
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
0
Uday
6/7/2010 6:18:55 AM
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
0
Uday
6/7/2010 7:34:44 AM
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
0
Tim
6/7/2010 8:39:18 AM
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
0
Tim
6/7/2010 8:46:42 AM
Tim X <timx@nospam.dev.null> writes:

> If you don't like what they have done, either 
>
>    a) get on the devel list and present a case and maybe build support
>

Wouldn't this contradict the cause, now that line-move-visual is the
*default* ?

Heh.

-ap
0
Andreas
6/7/2010 10:21:07 AM
> 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
0
Stefan
6/7/2010 4:23:52 PM
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)
0
Joost
6/7/2010 9:30:48 PM
On 2010-06-07 09:19 +0100, Uday S Reddy wrote:
> "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.

And that usually is the outcome of long discussions.

The whole new feature is almost useless (by adding its + and -) and I
wished they had been more careful and selective in putting things in
emacs releases.

Leo
0
Leo
6/8/2010 8:52:54 AM
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.
0
Joseph
6/9/2010 7:42:48 PM
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.

0
Joseph
6/9/2010 7:51:20 PM
David Kastrup <dak@gnu.org> writes:

> What makes you think that Emacs developers are responsible for end users
> subjected to restrictive administrations?
>
> To a degree where you think heaping abuse on them is the right answer
> for your problems with authorities?

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.

0
Joseph
6/9/2010 8:00:19 PM
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
0
brendan
6/9/2010 8:22:24 PM

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. 

0
Joseph
6/9/2010 8:23:25 PM
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?)

0
Joseph
6/9/2010 9:38:23 PM
On 6/9/2010 1:22 PM, Brendan Halpin wrote:
> 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. 

Agreed!  I use compare-windows so frequently I have this in my .emacs:

(global-set-key "\C-x!"  'compare-windows)

0
Thad
6/9/2010 10:23:57 PM
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
0
LanX
6/9/2010 10:42:14 PM
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.

-- 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.
0
Mark
6/10/2010 1:17:20 AM
> 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
0
Stefan
6/10/2010 1:23:56 AM
["Followup-To:" header set to gnu.emacs.help.]
On 2010-06-09 at 18:38 ADT, Joseph Brenner <doom@kzsu.stanford.edu> wrote:
>
> 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.

And you can imagine how the usefulness of those discussions would
rapidly drop to zero if everyone who used emacs (or any of your other
examples) joined the (respective) development discussions.

David: the message (about fundamental features changing being a Bad
Thing) was delivered in a less than gentle way, but I think you should
re-consider the idea, as opposed to the way it was delivered.
Further, your comment "Those who choose ... A common democratic
principle." is just plain wrong.  But I assume you know that.

Cheers.
				Jim
0
Jim
6/10/2010 1:34:56 AM
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
0
David
6/10/2010 7:12:28 AM
>> 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
0
Uday
6/10/2010 10:12:19 AM
> 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
0
Stefan
6/10/2010 1:43:46 PM
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


0
Uday
6/10/2010 3:17:18 PM
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.

0
despen
6/10/2010 3:44:02 PM
Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Perhaps an 'auto' setting where the behavior depended on the buffer
mode?  For instance equivalent to 'nil' in programming language modes
and to 't' in text editing modes.

-- 
http://www.greenend.org.uk/rjk/
0
Richard
6/10/2010 4:24:20 PM
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.
0
Mark
6/10/2010 4:57:01 PM
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


0
Uday
6/10/2010 6:38:17 PM
On 6/10/2010 6:43 AM, Stefan Monnier wrote:
> [...]
>   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.
> [...]

Hmmm, I've had the following line

    (global-set-key "\M-#"   'goto-line)

in my .emacs for so many years (think decades) as a quick'n'easy method
to go to a specific line number mentioned in a compiler warning/error
regardless where I'm presently in the buffer.

I.e., "C-u 8 ESC #" goes to line 8; "C-u 1234 ESC #" goes to line 1234.

How is/will that be affected (if C-n and C-p are affected)?
0
Thad
6/10/2010 7:06:46 PM
>> 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
0
Stefan
6/10/2010 7:53:24 PM
>> 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"
0
Stefan
6/10/2010 7:57:34 PM
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
0
Tassilo
6/10/2010 10:02:12 PM
Stefan Monnier <monnier@iro.umontreal.ca> writes:

>         Stefan "who never uses Emacs while root"

I think you forgot to add the subordinate clause "...because he uses
TRAMP's sudo method in an already running emacs server to access files
where he has no permissions for", right?

Bye,
Tassilo
0
Tassilo
6/10/2010 10:10:23 PM
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.

0
Evans
6/10/2010 10:48:08 PM
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
0
Uday
6/10/2010 11:56:27 PM
Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

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

Not invasive from a user's point of view, but from a implementation
point of view.  With visual-line-mode, C-e is not bound to
`move-end-of-line' but to `end-of-visual-line', and the same applies to
other bindings.  It's possible that this redefinition of standard keys
leads to unexpected behavior, for example when using [remap
move-end-of-line].

Not sure if that's really problematic, so that's why I've asked.

Bye,
Tassilo
0
Tassilo
6/11/2010 12:48:54 AM
>> Stefan "who never uses Emacs while root"
> I think you forgot to add the subordinate clause "...because he uses
> TRAMP's sudo method in an already running emacs server to access files
> where he has no permissions for", right?

Actually, no, I almost never use su/sudo via Tramp.
I typically use zile instead.


        Stefan
0
Stefan
6/11/2010 12:58:11 AM
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.
0
Mark
6/11/2010 11:56:06 PM
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
0
Wojciech
6/12/2010 12:17:21 AM
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
0
Uday
6/13/2010 12:46:42 PM
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.
0
Mark
6/13/2010 5:23:45 PM
On Sun, 13 Jun 2010, Uday S Reddy posted:
> 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.

To this, also add predictability.

Mission critical software doesn't deliver different results just because 
the screen width is different.

-- 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.
0
Mark
6/13/2010 5:26:40 PM
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).

0
Alan
6/13/2010 8:56:30 PM
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
0
Jim
6/14/2010 12:42:29 AM
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
0
Uday
6/14/2010 10:49:36 AM
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).

0
Alan
6/14/2010 5:16:14 PM
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
0
Uday
6/14/2010 5:34:23 PM
Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

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

It will be interesting to see where you are heading.  You are aware that
Alan is the maintainer of cc-mode?

-- 
David Kastrup
0
David
6/14/2010 6:16:55 PM
Alan Mackenzie <acm@muc.de> writes:
> 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).

     Keyboard macros are far from obscure.  I use them daily at least.

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

     It is a big deal when it breaks existing code.  Backwards
compatibility is important.

> And it was dashed near impossible to move easily to the middle of
> long, long lines.

     C-u <some number> right-arrow

Sincerely,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)
0
Patrick
6/14/2010 6:23:34 PM
>> 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?
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"
0
Stefan
6/14/2010 8:28:00 PM
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/
0
pjb
6/15/2010 6:54:18 AM
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
0
Uday
6/15/2010 8:42:30 AM
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
0
Tim
6/15/2010 9:26:13 AM
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
0
David
6/15/2010 9:30:29 AM
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
0
Tim
6/15/2010 9:38:18 AM
> 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
0
Stefan
6/15/2010 1:45:25 PM
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
0
David
6/15/2010 1:57:06 PM
Another easier way is to search for a word in the point of the line
you want to go, and search for it with C-s word

>> And it was dashed near impossible to move easily to the middle of
>> long, long lines.
> 
>     C-u <some number> right-arrow
> 
0
J
6/15/2010 4:31:54 PM
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).

0
Alan
6/15/2010 4:51:21 PM
Stefan Monnier wrote:

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

Yes, you did say all of that, and I understood it the first time.  But, is 
Stefan liking something good enough a reason to change the default behaviour? 
You can set your own defaults in your .emacs to get the behaviour you like and 
so can all the other people.  Does it need to cause an incompatible change to 
Emacs defaults and potentially break the code/macros of people that have 
depended on the old behaviour?  Does it need endanger people who might 
unsuspectingly download packages over the net that might depend on the old 
defaults and have their files corrupted as a result?  I hope you will agree 
that these are more serious questions than merely liking or disliking some 
behaviour.

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

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?

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

Cheers,
Uday

0
Uday
6/15/2010 6:32:14 PM
In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote:
> Stefan Monnier wrote:

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

> Yes, you did say all of that, and I understood it the first time.  But,
> is  Stefan liking something good enough a reason to change the default
> behaviour?

Please convince me you're not trolling crudely here.  You can take it as
written that when somebody like Stefan M. says he "liked" something, the
wellbeing of the mass of Emacs users was his prime motivator.

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

> Does it need to cause an incompatible change to  Emacs defaults and
> potentially break the code/macros of people that have  depended on the
> old behaviour?

Yes.  All changes which aren't new features are incompatible to some
extent.

> Does it need endanger people who might unsuspectingly download packages
> over the net that might depend on the old defaults and have their files
> corrupted as a result?

Yes.

> I hope you will agree that these are more serious questions than merely
> liking or disliking some behaviour.

Please stop being so damned patronising.

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

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

Step back a bit, take the broad view, and consider that you may just be
wrong; that these "potentially" unsafe changes will remain potential, and
a tiny number of people will be hurt, not very badly, as Mark Crispin the
OP seems to have been. 

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

Not at all.  Things were weighed up, not disregarded.

> Imagine, for instance, that your favourite mail client happened to use
> `next-line' instead of `forward-line' somewhere in handling the mail
> headers.  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?

Yes.

> Cheers,
> Uday

-- 
Alan Mackenzie (Nuremberg, Germany).

0
Alan
6/15/2010 7:02:40 PM
On Jun 15, 1:42=C2=A0am, 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. =C2=A0I mean, keep C-f pressed until the
> > cursor reaches the column you want, you don't even need to count
> > 76. =C2=A0And keep C-n pressed until the cursor reaches the line you wa=
nt.
>
> Except that pressing control-key for that long with your pinky is a healt=
h risk!
>
> But I feel this discussion is tangential. =C2=A0Most of us accept that vi=
sual line
> movement is a /good/ idea and we find it useful in lots of contexts. =C2=
=A0We 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). =C2=A0I 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 =E2=80=9CFOSS=E2=80=9D or =E2=80=9CFUD=E2=80=9D 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
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/15/2010 7:17:55 PM
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
0
Leo
6/15/2010 7:37:48 PM
* 2010-06-15 20:37 (+0100), Leo wrote:

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

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

Here are links to some Guile-related discussions in emacs-devel mailing
list earlier this year:

    "Guile in Emacs"
    http://thread.gmane.org/gmane.emacs.devel/121291/focus=121734

    "guile and emacs and elisp, oh my!"
    http://thread.gmane.org/gmane.emacs.devel/123666

    "Logistics of Using Guile"
    http://thread.gmane.org/gmane.emacs.devel/124089

But if you seriously want to have a part in this game you need to
subscribe to emacs-devel and express yourself there:

    http://lists.gnu.org/mailman/listinfo/emacs-devel
0
Teemu
6/15/2010 8:13:25 PM
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
0
Uday
6/15/2010 9:04:02 PM
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.

The best solution for Windows systems is:

<http://technet.microsoft.com/en-us/sysinternals/bb897578.aspx>
<http://download.sysinternals.com/Files/Ctrl2Cap.zip>

another is a UNIX/Linux keyboard:

<http://pckeyboards.stores.yahoo.net/linux101.html>
0
Thad
6/15/2010 10:27:02 PM
On Jun 15, 3:27=C2=A0pm, 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. =C2=A0I mean, keep C-f pressed until th=
e
> >> cursor reaches the column you want, you don't even need to count
> >> 76. =C2=A0And keep C-n pressed until the cursor reaches the line you w=
ant.
>
> > 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.

=E2=80=A2 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+=E2=80=B9key=E2=80=BA spots void, since now with=
 only one
pinky many otherwise good Ctrl+=E2=80=B9key=E2=80=BA 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: =C2=AB... do not use two fingers on the same hand at the same
time, except in emergencies. ...=C2=BB.

YSK wrote: =C2=ABSeriously? 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?=C2=BB.

--------------------------------
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
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/15/2010 10:45:58 PM
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.
0
Thad
6/15/2010 11:31:55 PM
,------ 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.
0
Evans
6/16/2010 3:30:54 AM
Teemu Likonen <tlikonen@iki.fi> writes:

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

Agreed.  Unfortunately, RMS has kept some trauma from his first exposure
to Common Lisp.  And the Hyperspec is not under the GDL...

> Here are links to some Guile-related discussions in emacs-devel mailing
> list earlier this year:
>
>     "Guile in Emacs"
>     http://thread.gmane.org/gmane.emacs.devel/121291/focus=121734
>
>     "guile and emacs and elisp, oh my!"
>     http://thread.gmane.org/gmane.emacs.devel/123666
>
>     "Logistics of Using Guile"
>     http://thread.gmane.org/gmane.emacs.devel/124089
>
> But if you seriously want to have a part in this game you need to
> subscribe to emacs-devel and express yourself there:
>
>     http://lists.gnu.org/mailman/listinfo/emacs-devel

Thanks for the links.  I looked at the first one and saw that luckily
there are already a few CLers keeping up our flag there.

Nicolas
0
lastname (93)
6/16/2010 12:24:03 PM
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
0
Leo
6/16/2010 12:37:40 PM
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
0
David
6/16/2010 12:43:56 PM
> 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?


        Stefan
0
Stefan
6/16/2010 2:20:31 PM
On Jun 15, 4:31=C2=A0pm, Thad Floryan <t...@thadlabs.com> wrote:
> 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. =C2=A0I mean, keep C-f pressed until =
the
> >>>> cursor reaches the column you want, you don't even need to count
> >>>> 76. =C2=A0And 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.
>
> > =E2=80=A2 Why You Should Not Swap Caps Lock With Control
> > =C2=A0http://xahlee.org/emacs/swap_CapsLock_Ctrl.html
> > [...]
>
> Your opinion which neither I nor 100,000s of others share -- you stand al=
one.

if we actually do a poll anywhere near scientific, i think majority
will find my opinion the better on, as given in my essay.

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

Right, another anecdote from a old man.

The question is not whether you have RSI problem. As i detailed in my
essay, you can be a programer for 40 years coding daily, and never had
RSI problems, yet you can't even touch type. In fact, many programers
can't touch type. Am curious what's a rough percentage. I think
actually more than 50% of those who makes a living by coding cann't
touch type.

> 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 question is not whether it is that bad or not that bad. As i
pointed out in my essay, the keyboard itself is badly designed, and
much worse is its precursor the typewriter. Yet, people lived with
typerwriter for generations.

> 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 a=
nd
> bash as a shell.

The question, is whether Swapping Ctrl and Caps Lock key is better
with respect to ergonomics, on a average PC keyboard for the general
public. I've given detailed reasons why i believe that it is worse, in
my essay. To argue fruitfully, you might counter my points.

from my years of experience on this and my observation from the
arguments, i think that actually only a minority really propose that
swapping Caps Lock and Control is a good thing, even that we hear them
online often. It is this minority that keeps spreading baseless info.
Also, i think this minority tends to be older people, say, had
computing career at least as early as back in 1980s or early 1990s.

i think mostly the reason these minority have such view is because in
those days, it is not unusual to find keyboards with Control key on
the Caps Lock position. These people =E2=80=9Cgrew up=E2=80=9D with that. T=
he habit
stuck.

As i have said in my essay, there's a very simple test anyone can do
to see which is better. Let me repeat here:

Now, type the following, but on every 3rd letter hold down Caps Lock
key as if it is Control.

a b c d e f g h i j k l m n o p q r s t u v w x y z

Do this 100 times or 20 minutes. Really. Do it.

Now, take a break. When you are ready, do it again, but each 3rd
letter press the Control key at the either corners of your keyboard,
and follow my methods described in my esssay.

You can easily determine, which is less tiring or faster.

This simple test can be varied easily. For example, instead of typing
the alphabets in order, you can just grab any sentence. Instead of
holding the modifier every 3rd letter, you can easily create a test so
that it's every nth letter with n being random from 3 to 5. To prepare
the test, YoU caN cAp The letTER tHAt yOu neEd to pReSs thE ModiFier
liKE In thIs senTenCe.

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

aside from the ergonomic matter, i've noticed in my study of
keyboarding, 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. For example, i am quite absolutely certain, that
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 unconcious.

i've studied keyboarding quite a lot. Wrote some 40 articles in the
past 10 years from my 20 years of using keyboards, 10 or so keyboard
macros softwares across linux mac classic, os x, Windows;
(resedit keymap, QuicKey, QuickSilver, keybinding.dict, AutoHotKey,
IntelliType, xmodmap, ...), studied key systems in oses (mac classic,
x11, mac os x), mastered shortcuts in tens of apps across oses and
their capabilities at user level settings, touch
type at professional speed in qwerty and dvorak layouts, studied
chinese input systems, studied shortcut notations and key
notations and key macro language notations, studied keyboard soft
layouts (qwerty, dvorak, and international ones), studied keyboard
hardware key layouts,... you can see them here:

=E2=80=A2 All About Keyboards, Keyboard Layouts, Shortcuts, Macros
  http://xahlee.org/Periodic_dosage_dir/keyboarding.html

if keyboard freaks of the world would gather, i think i'd be a high
ranking officer. LOL

  Xah
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/16/2010 2:31:25 PM
> 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
0
Stefan
6/16/2010 2:33:34 PM
>>> 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.
>> Yes, you did say all of that, and I understood it the first time.  But,
>> is  Stefan liking something good enough a reason to change the default
>> behaviour?
> Please convince me you're not trolling crudely here.  You can take it as
> written that when somebody like Stefan M. says he "liked" something, the
> wellbeing of the mass of Emacs users was his prime motivator.

Actually in this particular case, it's really that I personally liked
it.  Only as a second step did I then wonder whether that could apply to
more of the users than myself (I'm not deluded enough to think that my
usage pattern is the most common one).
In any case that "liking" was just the trigger to investigate whether or
not to change the default, rather than being the actual basis for
the change.


        Stefan
0
Stefan
6/16/2010 2:37:02 PM
> 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
0
Stefan
6/16/2010 2:49:25 PM
> 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"
0
Stefan
6/16/2010 2:52:15 PM
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).

0
Alan
6/16/2010 3:33:59 PM
On Jun 15, 8:30=A0pm, Evans Winner <tho...@unm.edu> wrote:
> ,------ Thad Floryan wrote ------
> | =A0 Your opinion which neither I nor 100,000s of others
> | =A0 share -- you stand alone.
>
> Not alone. =A0I'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. =A0But if nothing is hit along with SPC then it
> sends a Space character on key-up. =A0Obviously 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. =A0I don't know if it is possible to map
> the keys that way, though. =A0I'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. =A0It 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. =A0For 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.

=95 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:

=95 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
0
Xah
6/16/2010 4:14:49 PM
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
0
David
6/16/2010 6:04:59 PM
,------ Stefan Monnier wrote ------
>> 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.

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?
0
Evans
6/16/2010 7:55:09 PM
Evans Winner <thorne@unm.edu> writes:

> ,------ Stefan Monnier wrote ------
>>> 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.
>
> 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?

Not meaning to speak for Stefan, but I read something a while back that
indicated touch typing was part of the cause. The RSI type of issue
comes up because you are doing rapid repeated movements with your
hands/fingers in a fairly static position with few/no regular breaks.
People who don't touch type don't tend to do this and tend to have
longer breaks.

I'm one of the lucky ones. I've been touch typing since I was 12 years
old. I work on the keyborad every day for at least 5 hours and have
never suffered any problems. It is very easy for me to type almost as
quickly as I think - a sort of flow of consciousness. This can result in
multiple paragraphs or pages of typing with few or no breaks. This is
exactly the sort of typing that can lead to RSI type problems. Most of
the first recorded cases of RSI were from admin assistants/secretaries
who would spend long periods transcribing text from dictaphones etc. 

I have always ensured I use a good quality keyboard (one with good
feedback from the keys, firm keys), a good quality chair and table set
in the right positions. I also had a typing teacher who was rather
strict regarding hand position and how you held your hand and fingers.
All of these things have probably protected me somewhat. On the odd
occasions when I have noticed discomfort, rather than just ignore it and
keep working, I always adjust my chair, table and monitor to ensure my
hands, arms and shoulders are in a comfortable position and don't ache.
It is important to not ignore initial slight discomfort. I also don't
remap keys, but don't see an issue with that. I've just never had an
issue with the default layout. 

Tim


-- 
tcross (at) rapttech dot com dot au
0
Tim
6/16/2010 10:41:30 PM
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)
0
Chris
6/16/2010 11:23:46 PM
Extended my post from this thread.

=E2=80=A2 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 =E2=80=9CMeta=E2=80=9D, and heavy use of Co=
ntrol as
primary modifier, and avoiding any Ctrl+Shift+=E2=80=B9letter=E2=80=BA in i=
ts 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=E2=9D=90.
right side close up=E2=9D=90. 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 =E2=80=9CBackspace=E2=80=9D key, was chosen as =
browser's
back to previous page shortcut. Note that this key is labeled =E2=80=9CDele=
te=E2=80=9D
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.

=E2=80=9Cvi=E2=80=9D's Esc might be better today at PC keyboard's Alt or Ca=
ps Lock.
=E2=80=9Cvi=E2=80=9D's H J K L is still pretty good, but arguably better wi=
th:

   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
=E2=88=91 http://xahlee.org/

=E2=98=84
0
Xah
6/16/2010 11:45:03 PM
"Chris F.A. Johnson" <cfajohnson@gmail.com> writes:

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

Yep same here.

Forget about swapping, just disable CapsLock it's an accident waiting to
happen.
 
0
despen
6/17/2010 1:11:31 AM
> 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
0
Stefan
6/17/2010 2:25:39 AM
On Jun 16, 7:25=A0pm, Stefan Monnier <monn...@iro.umontreal.ca> 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.
>
> =A0 =A0 =A0 =A0 Stefan

yeah. I know a lot sport lovers who plays a lot in school and in
weekend with their friends, but never good enough to join the pro.
Unlike the pros, they never had injuries. Maybe the pros shouldn't be
so efficient with all the modern sport training. They'll have less
injuries!

I LOL.

 Xah
0
Xah
6/17/2010 3:22:59 AM
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)
0
Chris
6/17/2010 3:51:25 AM
* 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.
0
Teemu
6/17/2010 8:00:31 AM
On 6/16/2010 3:33 PM, Stefan Monnier wrote:

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

Ok, that is a neat solution for all the safety issues.  Thanks for that.  (I 
guess I didn't notice it because I am still using the Emacs 22 compiler for 
most of my work.)

So the only problem left is for people that use keyboard macros.  And, the 
cookbook recipe users.

Cheers,
Uday
0
Uday
6/17/2010 8:50:09 AM
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
0
Uday
6/17/2010 8:51:26 AM
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


0
Uday
6/17/2010 9:03:20 AM
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
0
B
6/20/2010 5:08:02 PM
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
> 
> 
0
B
6/20/2010 6:42:56 PM
On 2010-06-10, Evans Winner <thorne@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 ....
0
Ilya
6/29/2010 8:04:54 AM
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=C2=A0am, 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
=E2=88=91 http://xahlee.org/

=E2=98=84

On Jun 29, 1:04=C2=A0am, 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. =C2=A0What new users want is an editor that is 5%
> > better than notepad.exe because that is per-force the limit
> > of their imagination. =C2=A0They generally do no know 1% of what
> > Emacs can do, so are not in a position to intelligently
> > decide what the defaults should be. =C2=A0They /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. =C2=A0If they aren't, then Emacs
> > isn't for them. =C2=A0Let them go.
>
> Do not think you would find many people agreeing with you. =C2=A0Anyway:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>
> I applaud the stand of emacs developers in this thread: facing with
> (extremely rude, unsubstantiated and, IMO, just plain stupid) attacks fro=
m
> a handful of self-righteous ... - Well, there is no need to stack epithet=
s
> 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. =C2=
=A0Myself,
> I never used Emacs23, so cannot comment on the particular feature in ques=
tion;
> however, I cannot skip commenting on the general question of maintainance=
 of
> Emacs defaults. =C2=A0(In 1/2 of what follows, there is going to be nothi=
ng new
> w.r.t. my other runts on this topic; skip to '----' if you cannot stand t=
his
> habit of mine.)
>
> For several decades, Emacs was practically unusable as a text editor AS
> SHIPPED. =C2=A0Mostly, this was due to the old-guard developers having no=
 clue
> in questions of UI design. =C2=A0The 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). =C2=A0I attribute it to inflow of new bl=
ood 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 defa=
ults
> 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 u=
sers.
>
> In my experience (and let me stress that this thread proves me wrong - se=
e
> below), Emacs users come in two large categories: the silent majority (>7=
0%,
> 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.
>
> =C2=A0(In my experience, most users also share another feature: most of t=
hem are
> =C2=A0 not interested in "typing as quick as they think". =C2=A0They are =
more
> =C2=A0 interested in following the "when you say what you think, think wh=
at you
> =C2=A0 say" maxim. =C2=A0Quality [and prudence] over speed... =C2=A0Few o=
f they would be
> =C2=A0 interested in "minimizing leaving home row keys".)
>
> The other category consists of us, old guard old farts, who consider it a=
n
> 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 th=
ings
> are not working as we expect, and for whom it is absolutely not a nuisanc=
e
> to insert a line into .emacs once in several years.
>
> Facing these two categories, the policy is obvious: the default should ca=
ter
> 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 HOW=
TO
> on undoing these changes. =C2=A0(And: this thread contained many suggesti=
ons how
> to make this navigation easier.)
>
> ---- =C2=A0And now the new part =C2=A0----
>
> 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 recolle=
ct
> hearing from it before): "hapless" old farts - those who have a pretty go=
od
> 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 c=
ater
> to their needs as well. =C2=A0And 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. =C2=
=A0Use them
> by replacing the defaults value by
>
> =C2=A0 (choose-by-version
> =C2=A0 =C2=A0 emacs-principal-UI-freeze
> =C2=A0 =C2=A0 nil
> =C2=A0 =C2=A0 "23.2" t
> =C2=A0 =C2=A0 "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 free=
ze
> the "principal parts" of UI, such a trick may have a major role. =C2=A0Ju=
st a
> POSSIBILITY to freeze allows one much more freedom in CHANGING the defaul=
ts.
> 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
>
> [*] =C2=A0BTW: why not have an option "Edit configuration file" in the He=
lp menu?
> =C2=A0 =C2=A0 =C2=A0Or maybe it is already there? =C2=A0Not here, in 21.4=
....
>
> =C2=A0 =C2=A0 =C2=A0One may even insert some meaningful header there if t=
he file is
> =C2=A0 =C2=A0 =C2=A0not present (sp?):
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; This file is loaded by Emacs before=
-this/after-that;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; it should contain Emacs-Lisp code c=
ustomizing Emacs to your taste.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; To debug problems in this file, one=
 may skip loading it
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; by giving option -q to emacs. =C2=
=A0Alternatively, uncomment
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; the following line (or give --debug=
-init option to Emacs):
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; (....)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; For further details, Choose XYZT fr=
om Emacs menu, or type ....
0
Xah
6/29/2010 11:09:45 AM
On 2010-06-29, Xah Lee <xahlee@gmail.com> wrote:
> 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.

No, I'm definitely not.  Especially taken into account that I did not
type it as quick as I think...

Yours,
Ilya

P.S.
> am curious, what are your emacs configs? are they public somewhere?

The currently published version is not v23-compatible.  I will have a
laptop with v23 back in a few days; I hope to update it then.

  ilyaz.org/software/emacs
0
Ilya
6/29/2010 7:08:31 PM
> 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;

Writing the program could be interesting. Would you like to let us try
it?
0
w_a_x_man
7/3/2010 5:08:01 PM
On Jun 16, 7:33=A0am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> 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). =A0In 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. =A0This 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)).

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

as far as i know, currently there are some 200 functions with the word
=93toggle=94 in their name, but i think vast majority of minor modes don't
have such a function.

also related, many minor modes or functions also has a globle version.
(e.g.
global-hi-lock-mode, global-font-lock-mode, global-linum-mode, global-
hl-line-mode, global-visual-line-mode, global-whitespace-newline-mode)
How's the toggle gonna be done wiht global?

are all minor modes going to be associated with a new toggle function?

some question about elisp:  when calling a function interactively
without any arg, how does emacs lisp engine distinguish it from with a
nil argument? or, is there a function that tells me how many argument
a function received? or is this handled due to lisp macro ability that
(interactive) is?

thanks a lot.

 Xah
0
Xah
7/12/2010 12:51:04 AM
Reply: