Re: line-move-visual
Uday S Reddy
> 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
Mark Crispin
> 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.
Uday S Reddy
>
> 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
Tassilo Horn
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
Uday S Reddy
>
> 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
Uday S Reddy
>
> 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
Tassilo Horn
>> 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
Tassilo Horn
>> 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
sable
> I don't care if M-X fart-noisily-with-spray changes its default scent from
> skunk to lemon.
LOL!!!
Brendan Halpin
> Uday S Reddy <uDOTsD...@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...@ul.ie http://www.ul.ie/sociology/brendan.halpin.html
Uday S Reddy
> 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
Brendan Halpin
> 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.
Stefan Monnier
> 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
Mark Crispin
> 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.
Xah Lee
> Attempted thread-jack: why use visual-line-mode instead of
> longlines-mode?
longlines-mode has serious bugs, i believe still so even i haven't
used it since emacs 23.1 a year or 2 ago.
basically, whenever large chunk of text is inserted or removed in a
buffer (either manually, or sometimes automatically by commands such
as patch and version control etc), then the text will be screwed up...
missing parts or something i forgot.
there are 1 or more bug reports of it in emacs bug track. If i recall
correctly, the situation is that it's hard to fix, because longlines-
mode was a hack for lack of visual line move, and i think it is done
by basically just inserting line-breaks in the background but display
and save it otherwise. (i haven't actually looked at the code though)
the visual line move feature is a critical feature in emacs. Before
emacs 23, there are a few packages or code that tries to introduce the
visual line move feature (see emacswiki), and longlines-mode is one of
them. However, because it is such a fundamental feature, it is hard
for a 3rd-party elisp package to get it correct. They all have major
problems...
i think Emacs 23.2's move by visual line feature is great because:
• it fixed a frequently asked feature. (e.g. i think ALL editors/IDEs
after mid 1990s, move by visual line )
• it fixed a issue that 3rd party elisp packages cannot address well.
Btw, who actually coded the visual line mode? I can't find the info. I
like to document it in my emacs pages.
--------------------------------------------------
Personally, i find moving by visual line is not just a good feature,
but a critical one, with consequences that effect the evolution of
language design and thinking, long term. The hard-coded lines is
fundamentally introduced by unix and C gang, and brain damaged a whole
generation of coders.
I've written about 7 essays addressing this point in the past 10
years. See:
• Xah on Programing Languages
http://xahlee.org/Periodic_dosage_dir/comp_lang.html
See the articles under the Formatting section.
Each of these is written in a different context, but they essentially
discuss the same thing. That is, the importance of separating
appearance/formatting from semantic or logical structure.
Here's a synapses on how each article relates to the line move visual
issue.
------------------------------
• The Harm of Hard-wrapping Lines
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
A introduction. (written as a diatribe )
------------------------------
• Tabs versus Spaces in Source Code
http://xahlee.org/UnixResource_dir/writ/tabs_vs_spaces.html
introduces the idea as semantic based formatting vs hard-coded
formatting.
------------------------------
• Plain-Text Email Fetish
http://xahlee.org/UnixResource_dir/writ/plain_text.html
• Unix, RFC, and Line Truncation
http://xahlee.org/UnixResource_dir/writ/truncate_line.html
Shows some connection of the hard-coded habit from unix.
------------------------------
• A Simple Lisp Code Formatter
http://xahlee.org/emacs/lisp_formatter.html
A example of what actually can happen when hard-coded formatting
hasn't become the conventional thought.
------------------------------
• A Text Editor Feature: Extend Selection By Semantic Unit
http://xahlee.org/emacs/syntax_tree_walk.html
Another example of what could happen if unix didn't made people to
think about hard-coded short lines.
------------------------------
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Half of the essay, discuss the above issues with respect to lisp the
language, and consequences.
Xah
∑ http://xahlee.org/
☄
Mark Crispin
> 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 Crispin
> 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.
David Kastrup
> 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
Xah Lee
hi Mark Crispin,
On Jun 4, 11:18 am, Mark Crispin <m...@panda.com> wrote:
> This is why UNIX and C accomplish things. They were based upon
> accomplishing something useful rather than promoting an ideology.
maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix,
and the whole lisp culture and thinking is contrary to unix and C.
> It sounds like Microsoft Word is more suitable for the sort of work that
> you do. Perhaps you ought to use Word instead of seeking to make emacs
> become more like Word.
speaking of Microsoft Word, i wait for dinosaurs like u to die. The
question is, can we recruit enough new generation of coders to emacs
fast enough before emacs extinguishes.
LOL!
Xah
∑ http://xahlee.org/
☄
Stefan Monnier
>> 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
Tassilo Horn
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
Mark Crispin
> 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 Crispin
>> 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 Crispin
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.
Stefan Monnier
>> 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
Stefan Monnier
>> 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
Mark Crispin
> 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.
Thad Floryan
>>> 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 ?)).
Xah Lee
> 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.
• 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 “coding style”, 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 “coding style” 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 “if PREDICATE do BLOCK”.
(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: «As for your code, I don't know why you are indenting
interactive differently than the further forms;»
just sloppy... never really pay much attention about any so-called
“coding style” (which often means the code fomatting habit) Actualy, i
consider the rampant reference and concern about “coding style”, 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.
David Kastrup
> 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
Xah Lee
On Jun 4, 7:33 pm, 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. 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).
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: «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.) »
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. 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.
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:
• Larry Wall and Cults
http://xahlee.org/UnixResource_dir/writ/larry_wall_n_cults.html
• Laziness, Perl, and Larry Wall
http://xahlee.org/UnixResource_dir/writ/perl_laziness.html
• On the Survival Strategies of Larry Wall vs Richard Stallman
http://xahlee.org/UnixResource_dir/writ/wall_stallman.html
• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
• “Free” Software Morality, Richard Stallman, and Paperwork
Bureaucracy
http://xahlee.org/UnixResource_dir/writ2/FSF_philosophy.html
• Why Software Suck
http://xahlee.org/UnixResource_dir/writ/why_software_suck.html
(Kent Pitman)
• Why You should Not Use The Jargon Lisp1 and Lisp2
http://xahlee.org/emacs/lisp1_vs_lisp2.html
• 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:
• 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:
• 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).
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 “Microsoft
Word” 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
∑ http://xahlee.org/
☄
Mark Crispin
> 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 Crispin
> 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 Crispin
> am curious, if you know Daniel Weinreb, and who used emacs first.
> 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.
David Kastrup
> 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
Uday S Reddy
> 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
David Kastrup
> 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
Uday S Reddy
> 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
Alain Ketterlin
Sorry to break the thread, but...
The message I'm following up to has been sent from Thunderbird with
format=flowed, i.e., it contains very long lines, much longer than the
usual 80-column text. It's painful to read, cite in replies, etc.
Is there any way to make gnus reformat such messages to make them fit
the standard Usenet width? My current gnus config is the absolute
minimum. Any help is welcome, even if it takes the form of a few
keywords to help me search the doc. Thanks,
-- Alain.
P/S: I've removed comp.lang.lisp from the Newsgroups:
Tassilo Horn
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
Reiner Steib
> 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/
Mark Crispin
> 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 Crispin
> 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.
Uday S Reddy
>
> 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
Thad Floryan
> [...]
> 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/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/>
Mark Crispin
> 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.
Uday S Reddy
>
> 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
Uday S Reddy
>> 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
Helmut Eller
> 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?
The byte-compiler already warns about uses of next-line because it
rarely makes sense to use next-line in lisp code anyway (forward-line is
usually more appropriate, especially for parsing). So it's very likely
that the remaining occurrences have been inspected by developers very
carefully.
Helmut
Tim X
> Uday S Reddy <uDOTsD...@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
Tim X
> 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.
Andreas Politz
> 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
Stefan Monnier
> rarely makes sense to use next-line in lisp code anyway (forward-line is
> usually more appropriate, especially for parsing). So it's very likely
> that the remaining occurrences have been inspected by developers very
> carefully.
Not sure about "very" since we've had some bug reports after the
warnings were fixed, but yes. BTW my grep only finds 22 occurrences
(in Emacs trunk rather 23.2, but the difference should be small).
Stefan
Stefan Monnier
> 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
Joost Kremers
> 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 joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Tim X
What cause? I don't think anything about defaults is written in stone.
If enough people feel it is the wrong default /and/ they raise the issue
through the correct channel i.e. the dev list and there is enough
support, I don't see any issue. Of course, those who do must be prepared
to still fail to change anything, but thats a different issue.
Joseph Brenner
Stefan Monnier <mon...@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.
Joseph Brenner
>>> 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.
Joseph Brenner
David Kastrup <d...@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.
Brendan Halpin
> 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...@ul.ie http://www.ul.ie/sociology/brendan.halpin.html
Joseph Brenner
Stefan Monnier <mon...@iro.umontreal.ca> writes:
Actually... if you're planning of having a section like that,
I'd suggest there's already a bigger problem.
Joseph Brenner
David Kastrup <d...@gnu.org> writes:
> Uday S Reddy <uDOTsD...@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?)
Joseph Brenner
Stefan Monnier <mon...@iro.umontreal.ca> writes:
I've got some uses of "next-line" in my own code ("third party", not
part of GNU emacs). As I remember it I do it that way for a reason,
though I can't remember what it is: I have read the hint in the docs,
and there are other places where I use forward-line.
If the reason comes back to me, I'll post about it.
Thad Floryan
> 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)
LanX
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
Mark Crispin
> 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.
Stefan Monnier
> 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
Jim Diamond
On 2010-06-09 at 18:38 ADT, Joseph Brenner <do...@kzsu.stanford.edu> wrote:
>
> David Kastrup <d...@gnu.org> writes:
>> Uday S Reddy <uDOTsD...@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
David Kastrup
> 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
Uday S Reddy
>>
>>> 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.
>
> 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:
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
Stefan Monnier
> 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
Uday S Reddy
> 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?
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
des...@verizon.net
>> 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.
Mark Crispin
> David: the message (about fundamental features changing being a Bad
> Thing) was delivered in a less than gentle way,
I proved that it was necessary. His sort will stonewall - it's their
nature - but now he has egg on his face.
> but I think you should
> re-consider the idea, as opposed to the way it was delivered.
He won't.
But perhaps he will think twice before making future pointless changes
like this.
> Further, your comment "Those who choose ... A common democratic
> principle." is just plain wrong. But I assume you know that.
He doesn't. You have to take him at his word.
Richard Kettlewell
> 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.
Mark Crispin
> 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.
Uday S Reddy
> 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
Thad Floryan
> [...]
> 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)?
Stefan Monnier
>> 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
Stefan Monnier
>> 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"
Tassilo Horn
> - 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
Tassilo Horn
> 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
Evans Winner
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.
Uday S Reddy
>
> 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
Stefan Monnier
> 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
Tassilo Horn
>> 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
Mark Crispin
> 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.
Wojciech Meyer
> 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
Tim X
> On Thu, 10 Jun 2010, Uday S Reddy posted:
>> By community ownership, I only mean that all the people that have a stake in
>> the system have a voice in the matter and we all feel ownership of the
>> system. When the community is divided, as seems to be the case on this
>> issue, the developers have to make a decision and move on.
>
> The problem is that nobody ever asked the existing users whether or not they
> wanted this global change foisted upon them. Rather, it was done
> unilaterally, and the individuals responsible are saying "See! Some people
> like it! It was a good change."
>
This is not really correct. The change was discussed in a forum that is
open to anyone who is interested. More accurately, a criticism could be
that it wasn't discussed in the correct forum. However, that in itself
is extremely difficult to identify. For example, how would most of the
users feel if every discussion regarding emacs development, even if
restricted to discussions that directly impact on basic/core behavior
(however that would be defined). was posted to this list? I suspect that
many would be irritated as this is supposed to be an emacs help forum,
not a discussion forum for developments.
A possible solution would be to ensure a page is maintained on the emacs
wiki that discussed some of the proposed developments, especailly those
that may be contentious. A regular post could go to this list pointing
to the relevant page. This would possibly let those who are interested
know about propsed changes and enable them to participate.
Of course this won't reach everyone and there will still be some who are
surprised by changes and possibly get upset. This is unavoidable. All
that can be done is to make it clear what forums are available and try
harder to get wider discussion, particularly with changes that are
likely to have a big impact.
> This sort of thing happened in the past as well. The difference was that
> there was accountability in the past that is absent today.
>
>> In my humble opinion, it is easy to argue that the current default was
>> ill-chosen. But it is not so easy to argue that it should be changed. If
>> we change it, then we face all the same issues all over again affecting the
>> other users that are depending on the current default. So, it seems best to
>> leave things as they are and make a note of all the lessons learned.
>
> I agree that we are probably screwed, and royally so.
>
> I have a new task on my list: replace emacs in the procedures for my target
> audience since emacs is no longer suitable for that purpose. I simply can not
> tell these users "make sure that you set line-move-visual to nil"; they would
> have no clue what that means. More likely than not, I will end up being
> obliged to write a program for the task; and there will be one less way those
> users will be exposed to emacs.
>
Why not just set it back to its previous default in a site startup file?
Most distributions already have one of these - all that is required is a
single line!
> One of the advantages of the "software tools" mindset of the past was that you
> did not have to write a program for every task. Instead, you could leverage
> the existing tools. That falls apart when those tools are corrupted so that
> they no longer can be relied upon to produce predictable results.
>
>>> But even the laymen become power-corrupted.
>> I think that is a bit of an exaggeration. They have a responsibility to
>> bear and sometimes they get carried away.
>
> Every young programmer wants to put his own mark on things. The problem is
> that these changes are frequently ill-considered and sometimes have bad
> consequences.
>
Even well considered changes can have bad consequences. Hindsight is a
wonderful thing!
This personal attack you continue to make on the developers is very
tiresome. Emacs is developed by a large range of people. They vary in
age, vary in location and native language and vary in experience. Not
many of them are regular posters to this list. You seem to be under the
illusion that the developers are some closed powerful group sitting in a
room somewhere together making random changes. GNU Emacs is open to
anyone who wants to get involved. Patches and improvements come from all
over the place - some are minor, some are major, some accepted and some
rejected. Changes are discussed in an open forum that anyone can
participate in.
Valid points have been raised regarding the change in default behavior
and possibly the developers may consider ways to improve discussion and
communication (though I'm not sure how aware they are since this
discussion has occured largely on the wrong forum). Nothing is gained by
continued attacks. If you still feel the need to whinge, then perhaps
you might show the backbone to actualy make your accusations to the
developers and perhaps both get some real facts and just possibly
contribute to improving how future changes are handled.
>>> Since user interface surprise is a barrier to upgrade, they make sure there
>>> aren't any such surprises.
>> Yes, that point is well-made. But, the same argument now suggests that the
>> default should not be changed yet again.
>
> Yup. We're probably screwed.
>
Your arguments all suggest an environment where interfaces never change.
This just doesn't exist and never has. Frequently improvements and new
functionality require changes to existing interfaces, both programming
and user. This is the reason most programs have a major and minor
revision number. It gives an end user an idea of how the program may
have changed. It is also why any professional setup will put new
software through evaluation and testing before putting it into
production. This can result in considerable maintenance overheads, but
cannot be avoided. It is also why many vendors, such as Red hat and
Ubuntu provide versions that are extremely stable and supported for
extended periods of time where the only changes/updates are for critical
security fixes. As a professional, I'm sure, when deciding to upgrade a
major version of some key software, you checked out the release notes to
familiarise yourself with what has changed and any known problems and
used this information to formulate your test plan that wold ensure no
nasty surprises in your production environments. Luckily, the emacs
developers made sure this was all clearly documented and where the
changes involved modified defaults, clearly explained how to reset tot
he previous default.
Tim
--
tcross (at) rapttech dot com dot au
Evans Winner
| For example, how would most of the users feel if every
| discussion regarding emacs development, even if
| restricted to discussions that directly impact on
| basic/core behavior (however that would be defined). was
| posted to this list? I suspect that many would be
| irritated as this is supposed to be an emacs help forum,
| not a discussion forum for developments.
Actually I think that would be a great idea -- I think
that's exactly what ought to be done. I have read a number
of posts on the devel list discussing the question of how to
communicate with Emacs users about things like proposed
changes to defaults. Most of the messages on the devel list
would not be relevant here -- only a tiny fraction, and
readers can always ignore threads that don't interest them.
They could have subject lines that were the equivalent of
"[RFC] Blah blah."
I agree that there is a limit to what complaining about it
after the fact can accomplish, but it is also true that most
users can't realistically monitor such a high-traffic, and
generally technical list like emacs-devel. Posting the
occasional thread here about proposed changes might get
useful feedback, since a lot of people do monitor
gnu.emacs.help.
David Kastrup
> ,------ Tim X wrote ------
> | For example, how would most of the users feel if every
> | discussion regarding emacs development, even if
> | restricted to discussions that directly impact on
> | basic/core behavior (however that would be defined). was
> | posted to this list? I suspect that many would be
> | irritated as this is supposed to be an emacs help forum,
> | not a discussion forum for developments.
>
> Actually I think that would be a great idea -- I think
> that's exactly what ought to be done.
It would mean mechanically routing the developer list here. That's
nonsensical. Anybody really wanting this sort of mixup can tell his
newsreader to create a virtual group that does it.
--
David Kastrup
Evans Winner
| It would mean mechanically routing the developer list
| here. That's nonsensical. Anybody really wanting this
| sort of mixup can tell his newsreader to create a
| virtual group that does it.
You didn't read what I wrote very carefully.
Uday S Reddy
> It would mean mechanically routing the developer list here. That's
> nonsensical. Anybody really wanting this sort of mixup can tell his
> newsreader to create a virtual group that does it.
No, not really.
The discussion that needs to be routed here is about potential changes to the
user's manual. How those changes are *implemented* can continue to stay on the
developer list. Evans suggested "RFC" which I think is a great term for these
kinds of things.
Ideas that add bits to the user's manual can also be brought here, perhaps
selectively. For instance, there is a discussion going on there right now
about how to deliver "bidirectional text" editing, for buffers that intermix
English and Arabic, say. There are lots of tricky issues there about key
bindings and functionality. The discussion is impoverished by the dearth of
people that actually do bidirectional editing. I don't see why that discussion
could not be brought here, where there is some chance of running into people
that might actually do bidirectional editing and who might provide valuable input.
In any organization, virtual or real, there are decisions that should be taken
by small groups of people and there are decisions that can benefit from broad
participation. The organizations that can't figure out the difference usually
decline over time.
Cheers,
Uday
Uday S Reddy
> Your arguments all suggest an environment where interfaces never change.
> This just doesn't exist and never has. Frequently improvements and new
> functionality require changes to existing interfaces, both programming
> and user.
That is not quite true. In the OS & network protocols world, things can never
change essentially. We still live with the possibility of 7bit mail transport
even though nobody knows for sure whether there are any 7bit mail transport
systems anywhere. New protocols are designed that work around the limitations
of the old protocols. It has taken Unix some 15 years to figure out how to
retrofit Unicode into its byte-oriented view of the world. Things get messy
but that is the price we pay for backward-compatibility.
In the Emacs world, we don't need to go that far. But there is no reason why
we can't expect the stability of the basic editing operations.
Cheers,
Uday
Tim X
> On 6/12/2010 5:18 AM, Tim X wrote:
>
>> Your arguments all suggest an environment where interfaces never change.
>> This just doesn't exist and never has. Frequently improvements and new
>> functionality require changes to existing interfaces, both programming
>> and user.
>
> That is not quite true. In the OS & network protocols world, things can never
> change essentially. We still live with the possibility of 7bit mail transport
> even though nobody knows for sure whether there are any 7bit mail transport
> systems anywhere. New protocols are designed that work around the limitations
> of the old protocols. It has taken Unix some 15 years to figure out how to
> retrofit Unicode into its byte-oriented view of the world. Things get messy
> but that is the price we pay for backward-compatibility.
>
I don't disagree, but the mere fact new protocols are developed to
handle the new as well as theold is in itself a change in the interface.
Citing an example that shows no interface change doesn't really counter
the arguement, but citing one that has changed would seem to.
> In the Emacs world, we don't need to go that far. But there is no reason why
> we can't expect the stability of the basic editing operations.
I agree it is important to keep stability in basic editing operations
and I agree the choice to make visual line mode the default was probably
a mistake. However, I disagree with the arguemment that all the
stability has been lost. If the new feature could not be disabled, then
I would agree. However, the fact you can revert back to the old 'stable'
behavior with only a minimal configuration means you can have exactly
the same behavior and stability as before. What is really at issue isn't
the change as much as making the chang ethe default behavior.
Tim X
My only concern here is with identification of what should and should
not be posted in g.e.h as well as on the developer mail list. While I
think Evans suggestion is worth consideration, I still see it failing
because it relies too much on everyone doing the 'right thing' and as
can be seen from this discussion, knowing what is the right thing is not
that straight-forward. However, discussions on possibilities are
certainly worthwhile and essentila to finding the right balance.
Joseph Brenner
Evans Winner <tho...@unm.edu> writes:
> Tim X wrote:
> | For example, how would most of the users feel if every
> | discussion regarding emacs development, even if
> | restricted to discussions that directly impact on
> | basic/core behavior (however that would be defined). was
> | posted to this list? I suspect that many would be
> | irritated as this is supposed to be an emacs help forum,
> | not a discussion forum for developments.
>
> Actually I think that would be a great idea -- I think
> that's exactly what ought to be done.
Some software projects publish summaries of what's been
happening on the developers list. If you can find a volunteer
to do the job, these weekly newsletters are obviously a good
thing to have.
But this isn't the solution to the problem at hand.
> I have read a number of posts on the devel list discussing the
> question of how to communicate with Emacs users about things like
> proposed changes to defaults.
The right answer is that you should not be changing the defaults.
If we really can't convince the developers that they need to respect
backwards compatibility, an actual solution to the problem might
be something like creating a switch that needs to be flipped on to
get the new whizzy behavior, something like:
(setq modernize-emacs t)
You then recommend that the default ~/.emacs for *new* users should
include that line.
Existing users should never have their existing ~/.emacs over-written
the default, so they should only see the old behavior (unless, of
course, they choose to add that line).
Documentation for "modernize-emacs" should make it clear that it's
under development, and that for the immediate future at least,
the behavior it imposes may change.
Doing something like this would be far better than the current
practices, though it's obviously not perfect. Problems include:
o A third-party developer may be suprised by the need to ask
users not to flip on "modernize-emacs", and may have to
write code to shut it off and live with some user confusion
when the "modernized" behavior goes away temporarily.
o It's effectively a project fork that at the very least
complicates documentation and testing.
> I agree that there is a limit to what complaining about it
> after the fact can accomplish,
If you minimize UI changes, then these complaints are minimized.
If you eliminate UI changes, then these complaints are eliminated.
Joseph Brenner
Tim X <ti...@nospam.dev.null> writes:
> Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:
>> Tim X wrote:
>>> Your arguments all suggest an environment where interfaces never change.
>>> This just doesn't exist and never has. Frequently improvements and new
>>> functionality require changes to existing interfaces, both programming
>>> and user.
>>
>> That is not quite true. In the OS & network protocols world, things can never
>> change essentially. We still live with the possibility of 7bit mail transport
>> even though nobody knows for sure whether there are any 7bit mail transport
>> systems anywhere. New protocols are designed that work around the limitations
>> of the old protocols. It has taken Unix some 15 years to figure out how to
>> retrofit Unicode into its byte-oriented view of the world. Things get messy
>> but that is the price we pay for backward-compatibility.
> I don't disagree, but the mere fact new protocols are developed to
> handle the new as well as theold is in itself a change in the interface.
Now you're playing semantic games. The subject under discussion is a
decision where the developers intentionally messed with experienced
users on the theory that they can deal with the pain.
That's the kind of change we're talking about.
If someone working on "ls" made a change that broke dired, you might see
the situation differently.
> Citing an example that shows no interface change doesn't really counter
> the arguement, but citing one that has changed would seem to.
Yes, the switch to unicode and utf-8 was difficult to accomplish without
any pain to existing users, because of the nature of utf-8. Even if
this case, many developers worked hard at making things Just Work, and
they *almost* succeeded.
Tim X
> Tim X <ti...@nospam.dev.null> writes:
>> Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:
>>> Tim X wrote:
>
>>>> Your arguments all suggest an environment where interfaces never change.
>>>> This just doesn't exist and never has. Frequently improvements and new
>>>> functionality require changes to existing interfaces, both programming
>>>> and user.
>>>
>>> That is not quite true. In the OS & network protocols world, things can never
>>> change essentially. We still live with the possibility of 7bit mail transport
>>> even though nobody knows for sure whether there are any 7bit mail transport
>>> systems anywhere. New protocols are designed that work around the limitations
>>> of the old protocols. It has taken Unix some 15 years to figure out how to
>>> retrofit Unicode into its byte-oriented view of the world. Things get messy
>>> but that is the price we pay for backward-compatibility.
>
>> I don't disagree, but the mere fact new protocols are developed to
>> handle the new as well as theold is in itself a change in the interface.
>
> Now you're playing semantic games. The subject under discussion is a
> decision where the developers intentionally messed with experienced
> users on the theory that they can deal with the pain.
The 'subject at hand' has covered many things. This particular point was
referring to the claim that responsible developers never change the
interface for mature and even mission critical systems. This simply
isn't true. All you need to refute this claim is an example of programs
and utilities that have, which is trivial. It can even be argued that
doing so is sometimes the right decision and that failing to do so is
more irresponsible. Take for example the difficulties that have faced
the MS Windows environment. Many of the security problems they have
experienced are due to the desire to maintain backwards compatibility
and a stable interface. As software ages and new developments and
technologies are introduced, maintaining a stable interface becomes more
and more difficult. Eventually, a point is reached that the cost of
maintainging this stability of interface becomes too expensive and
things have to change or the system dies under an impossible wait of
maintenance or inability to interface in new ways that are important. I
am not suggesting that the current issue is even close to this, only
that claiming interfaces on mature systems never change if the systems
are maintained by responsible developers simply is over simplificaiton
and incorrect..
If there is a criticism, it does regard the way this change was managed
and the very real contention that the change should not have been made
the default. However, that does not tell us anything about the
motivation, experience or even the underlying thinking of those who made
the change. Given the volunteer nature, complexity and time it takes to
contribute to the maintenance of emacs and all the other improvements
and enancements that have occured, maybe it wold be fairer to consider
the change to visual line mode as the default as a lapse in judgement
rather than writing off all the developers as immature, glory hunting
childish and inexperienced programmers.
>
> That's the kind of change we're talking about.
>
> If someone working on "ls" made a change that broke dired, you might see
> the situation differently.
You mean something like when GNU ls introduced ansi colour escape
sequences to the output. I remember seeinig many posts from emacs users
who found this change broke their interface from emacs. Again, it was
resolved easily enough and now emacs has the ansi-color package. This wa
a change in interface and many, especially newer users, don't even give
the colour listing a second thought, except perhaps to wonder what has
gong wrong if they do an ls and there are no colours.
The crucial difference here was that the ls devs didn't make colour
output the default. Unfortunately, many distros did, but that is not
something the devs have control over. AGain, I don't disagree with the
argument that visual line mode should not have been made the default.
>
>> Citing an example that shows no interface change doesn't really counter
>> the arguement, but citing one that has changed would seem to.
>
> Yes, the switch to unicode and utf-8 was difficult to accomplish without
> any pain to existing users, because of the nature of utf-8. Even if
> this case, many developers worked hard at making things Just Work, and
> they *almost* succeeded.
>
Let me be very clear. I don't disagree with the criticisms regarding
making the change to visual line mode the default. That was probably
something that needed more thought. However, the carry on regarding how
the developers have broken emacs is wildly over stating the issue. The
default is easily changed and it is easily done for any experienced
user. What I totally disagree with are the many assumptions and very
derogatory remarks being made about the developers and maintainers based
on speculation regarding their motivation, maturity and even age. I also
disagree witht he claim that interfaces, both user and programming, on
mature systems are never changed by responsible developers. I agree that
changing interfaces is a very serious decision that should never be
taken lightly - any change that has a potentially negative impact on
users needs to be carefully considered. However, absolute claims that
say it should never be done are just as ill conceived and potentially
irresponsible.
Another point to be considered is that this change has been in the
released version of emacs for around a year. While I have seen a couple
of posts asking how to disable it, this is the first long thread
debating the issue at such length. The number of participants is also
relatively small compared to the number of emacs 23 users. If this
change has broken things as fundamentally as some would argue, I would
have expected to see a lot more posts and have seen them a lot sooner.
Maybe this thread has run it course and now has just degenerated into
bitching. Probably time to quit.
Tim X
> Evans Winner <tho...@unm.edu> writes:
>> Tim X wrote:
>> | For example, how would most of the users feel if every
>> | discussion regarding emacs development, even if
>> | restricted to discussions that directly impact on
>> | basic/core behavior (however that would be defined). was
>> | posted to this list? I suspect that many would be
>> | irritated as this is supposed to be an emacs help forum,
>> | not a discussion forum for developments.
>>
>> Actually I think that would be a great idea -- I think
>> that's exactly what ought to be done.
>
> Some software projects publish summaries of what's been
> happening on the developers list. If you can find a volunteer
> to do the job, these weekly newsletters are obviously a good
> thing to have.
>
A good idea if someone is prepared to step up and do it.
> But this isn't the solution to the problem at hand.
>
>> I have read a number of posts on the devel list discussing the
>> question of how to communicate with Emacs users about things like
>> proposed changes to defaults.
>
> The right answer is that you should not be changing the defaults.
I tend to agree that defaults should usually not change. However, you
cannot anticipate all possible situations and should avoid absolutes.
Defaults should only change after serious consideration and discussion
and should be as inclusive of users as possible. However, they should
not be treated as sacred and can never be changed.
Again, we need to be very wary of any absolute such as UI will never
chnage or defaults can never change. We live in an environment that
changes and need to be able to adapt.
It would be a mistake to eliminate UI changes. There have been a number
of improvements in the emacs UI over the last couple of versions. Many
of htem I don't like, such as using dialog boxes for find file and
yes-no questions if you use the menu etc, but many others, think they
are excellent improvements that helps emacs reamin current and of
interest to new developers (who are important as some of them will
likely be future dev/maintainers). You also have things like the current
work on bi-directional editing, which will obviously be a UI change. The
developments in handling various character encodings also had some
impact on the UI. Many of these were positive and some of them were
important and some are necessary.
Change is not the issue. Change can be positive and is necessary. The
issue is managing that change. Any attempt to enforce a static
unchanging environment will fail.