Poll about proposed change in DEL (aka Backspace) and Delete

[Richard Stallman]

In Emacs 24, now in pretest, a change is being considered for ASCII
DEL (on most keyboards, the Backspace key) and the Delete function
key. The change affects the case of an active region that was not
dragged with the mouse. The change is that these commands would
delete the region, rather than just one character as now.

In the past, this behavior was enabled in some minor modes: CUA mode,
Delete Selection mode, and PC Selection mode. In the 24.0.90 pretest,
this behavior is enabled by default. Thus, building and using the
pretest is an easy way to try the change.

Here are the questions we hope you will answer:

* Are you in favor of this change?

* Are you opposed to this change?

* How strongly do you feel about the matter?

We don't want to just "count votes" -- we want to understand
how this affects users. So if you care about the issue,
please tell us how the change affects your editing.

* What are the cases where you find it helps?

* What are the cases where you find it hurts?

* What is your level of Emacs experience?

A further change in the same area has been suggested: when there is an
active region, a self-inserting character would delete the region
before the character is inserted by default.

* What would you think of this further change?

Please send your responses to emacs-de...@gnu.org.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/

[Memnon Anon]

Hi,

Richard Stallman <r...@gnu.org> writes:

> Please send your responses to emacs-de...@gnu.org.

Is there some idea when this poll should be closed?
If not, could you say when you are planning to do a (first) evaluation of
the results?

Everything from 3 days to 4 weeks (or longer) could be a reasonable
amount, I guess, and affect my testing of the question at hand.

Memnon

[Jai Dayal]

I approve of all changes. 

On Thu, Sep 29, 2011 at 11:42 PM, Richard Stallman <r...@gnu.org> wrote:

In Emacs 24, now in pretest, a change is being considered for ASCII
DEL (on most keyboards, the Backspace key) and the Delete function
key.  The change affects the case of an active region that was not
dragged with the mouse.  The change is that these commands would
delete the region, rather than just one character as now.

In the past, this behavior was enabled in some minor modes: CUA mode,
Delete Selection mode, and PC Selection mode.  In the 24.0.90 pretest,
this behavior is enabled by default.  Thus, building and using the
pretest is an easy way to try the change.

Here are the questions we hope you will answer:

* Are you in favor of this change?

* Are you opposed to this change?

* How strongly do you feel about the matter?

We don't want to just "count votes" -- we want to understand
how this affects users.  So if you care about the issue,
please tell us how the change affects your editing.

* What are the cases where you find it helps?

* What are the cases where you find it hurts?

* What is your level of Emacs experience?

A further change in the same area has been suggested: when there is an
active region, a self-inserting character would delete the region
before the character is inserted by default.

* What would you think of this further change?

Please send your responses to emacs-de...@gnu.org.

[rusi]

On Sep 30, 8:42 am, Richard Stallman <r...@gnu.org> wrote:
> In Emacs 24, now in pretest, a change is being considered for ASCII
> DEL (on most keyboards, the Backspace key) and the Delete function
> key.  The change affects the case of an active region that was not
> dragged with the mouse.  The change is that these commands would
> delete the region, rather than just one character as now.
>
> In the past, this behavior was enabled in some minor modes: CUA mode,
> Delete Selection mode, and PC Selection mode.  In the 24.0.90 pretest,
> this behavior is enabled by default.  Thus, building and using the
> pretest is an easy way to try the change.
>
> Here are the questions we hope you will answer:
>
> * Are you in favor of this change?
>
> * Are you opposed to this change?
>
> * How strongly do you feel about the matter?

Mildly in favour. I am not sure I understand all the subtle
consequences but by and large this is how almost all modern programs
(aka cua aka windows) behave -- Is that right?
If so then I would like to see gratuitous differences between emacs
and everything else reduce.

>
> We don't want to just "count votes" -- we want to understand
> how this affects users.  So if you care about the issue,
> please tell us how the change affects your editing.
>
> * What are the cases where you find it helps?
>
> * What are the cases where you find it hurts?
>
> * What is your level of Emacs experience?

About 20 years.

I also hope that other aspects of emacs cleaned up (or are at least
open for consideration)
The one that bugs me more than anything else is customize.
In short customize is ok for browsing available options but terrible
for setting them.
But then I grew up on setq and so dont hear the rhythm in the modern
song and dance :-)

>
> A further change in the same area has been suggested: when there is an
> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>
> * What would you think of this further change?
>

> Please send your responses to emacs-delete-p...@gnu.org.

Sorry cant make out that address.
[Anyway: nice to see you make an appearance here Richard:-) ]

[Bug Dout]

Richard Stallman <r...@gnu.org> writes:

> In the past, this behavior was enabled in some minor modes: CUA mode,
> Delete Selection mode, and PC Selection mode. In the 24.0.90 pretest,
> this behavior is enabled by default. Thus, building and using the
> pretest is an easy way to try the change.

FYI, I found a pre-compiled Emacs 24 for Windows at:
http://code.google.com/p/emacs-for-windows/
--
No fathers or mothers think their own children ugly; and this
self-deceit is yet stronger with respect to the offspring of the mind.
- Miguel de Cervantes Saavedra

[Barry Margolin]

In article
<6601d825-96e3-4029...@d17g2000yqa.googlegroups.com>,

That'll teach you to use Google Groups instead of a real news server and
newsreader. It's emacs-delete-poll <at> gnu.org.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Joel James Adamson]

Richard Stallman <r...@gnu.org> writes:

> Here are the questions we hope you will answer:
>
> * Are you in favor of this change?

No

> * Are you opposed to this change?

Yes

> * How strongly do you feel about the matter?

I feel that maintaining the editor-unique nature of the Emacs delete
key, rather than adopting the behavior of word processors is crucial to
maintaining the uniqueness of Emacs. It's one of the reasons I use
Emacs: the Emacs way makes sense in a way that I strongly prefer. I
never liked the behavior of deleting whole selected regions and I prefer
the Emacs way.

> We don't want to just "count votes" -- we want to understand
> how this affects users. So if you care about the issue,
> please tell us how the change affects your editing.
>
> * What are the cases where you find it helps?

I don't really know of any.

> * What are the cases where you find it hurts?

If I want to delete a large block of text, I want to either drag the
mouse and use mouse-3, or use C-w. I don't see how it helps to replace
this behavior with something that emphasizes the region only as
something to be deleted.

> * What is your level of Emacs experience?

I've been using Emacs daily for six years, and Unix editors before that
for over twelve years. I do all my major computer interaction from
within Emacs, with the exception of web browsing.

> A further change in the same area has been suggested: when there is an
> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>
> * What would you think of this further change?

I don't like this idea. My hand could slip and a whole region would
disappear. I might have been planning to do something else with it.

Feel free to contact me for further discussion. Basically my opinion
boils down to feeling that the way of text editors should be kept in
line with its historical roots. If there is some known advantage to
adopting CUA behavior, then I don't know it myself. Another huge
advantage of Emacs for me was that from years of experience with Unix
editors, I already knew many of the Emacs commands, and the behavior
you're proposing to change was one of them.

Thanks,

Joel

--
Joel J. Adamson
Servedio Lab -- University of North Carolina at Chapel Hill
FSF Member #8164 -- http://www.fsf.org/jf?referrer=8164
http://www.unc.edu/~adamsonj

[Le Wang]

On Fri, Sep 30, 2011 at 11:17 PM, Joel James Adamson
<joeljame...@gmail.com> wrote:
> I feel that maintaining the editor-unique nature of the Emacs delete
> key, rather than adopting the behavior of word processors is crucial to
> maintaining the uniqueness of Emacs.  It's one of the reasons I use
> Emacs: the Emacs way makes sense in a way that I strongly prefer.  I
> never liked the behavior of deleting whole selected regions and I prefer
> the Emacs way.

I don't want to turn this into a huge debate, so this will be my last
reply to this that cc's the list.

It's not editor-unique vs word-processor. It's editor-unique vs (web
browser + email editor + word processor + EVERYTHING).

I feel it's far more reasonable to change Emacs to be less surprising
to new users than it is to keep it same-old same-old for the users who
are already used to it. After all, if the traditional Emacs behavior
is preferable to you, you can easily restore it. It's harder for a
brand new user to make Emacs less shocking.

To use myself as an example, I started using Emacs because I REALLY
didn't like vi for some school projects. I was fortunate that I gave
Emacs enough of a chance to find CUA-mode, delete-selection-mode, and
a few other bits at a time when they weren't a part of the Emacs
distribution. These conveniences made Emacs tolerable to me, and gave
me a glimpse of the Emacs' power. Slowly, I grew away from those
packages and now, I pretty much do everything the "Emacs way".

Now, specifically talking about the DEL change proposed, if I want to
copy something into the clipboard and replace a new selection with it,
currently I would

1. select stuff
2. M-w
3. select stuff to delete
4. C-w
5. C-y
6. M-y

This requires the new user to be aware of C-y and M-y and how to use
each to do a very basic task. While pressing DEL to delete a selected
region is much more intuitive.

I'm so happy that Emacs is already evolving to be more newbie
friendly. Transient-mark is on by default. Shift-select is on by
default. All these little things help.

The "Emacs way" to do very basic tasks should not shock newbies so
much that they give up in disgust before they have a chance to
experience the real crown jewel of Emacs, Emacs-lisp.


--
Le

[Bug Dout]

Le Wang <l26...@gmail.com> writes:

> It's not editor-unique vs word-processor. It's editor-unique vs (web
> browser + email editor + word processor + EVERYTHING).

> default. All these little things help.

...

> The "Emacs way" to do very basic tasks should not shock newbies so
> much that they give up in disgust before they have a chance to
> experience the real crown jewel of Emacs, Emacs-lisp.

The proposed changes aren't just for newbies. I've used Emacs 25 years
and the current behavior, which is proposed to change, still annoys me
and surprises me. The reality is every other app, which simultaneously
delete the selected region and paste from the copy buffer, all do it
that way because it's the easiest and most intuitive. Emacs got it
wrong, no big deal, now fix it.
--
I think animal testing is a terrible idea; they get all nervous and
give the wrong answers.
--Peter Kay

[Ian Zimmerman]

Richard> * Are you in favor of this change?

No.

Richard> * Are you opposed to this change?

Yes.

Richard> * How strongly do you feel about the matter?

Very strongly.

Richard> * What are the cases where you find it helps?

None. If I know I have an active region, I can kill it with C-w. The
fact that it goes into the kill ring is not important 99% of the time,
and in the other 1% I can just define a keybinding (perhaps temporary)
for delete-region.

Richard> * What are the cases where you find it hurts?

It would make me scream every time I select a region and then forget
about it (which is _very_ often) and then try to activate
delete-backward-char with DEL (which is _also very often_). By the way,
what would delete-backward-char be bound to if this change is
implemented?

Richard> * What is your level of Emacs experience?

Experienced Emacs Lisp programmer.

Richard> * What would you think of this further change?

Opposed, on similar grounds.

Richard> Please send your responses to emacs-de...@gnu.org.

All in all, if the change is made I'll just override it in my .emacs :-P

--
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD
Rule 420: All persons more than eight miles high to leave the court.

[Suvayu Ali]

On Thu, 29 Sep 2011 23:42:50 -0400
Richard Stallman <r...@gnu.org> wrote:

> * Are you in favor of this change?
>

Yes.

> * Are you opposed to this change?
>

No.

> * How strongly do you feel about the matter?
>

Strongly. So much so, that I had advised delete to behave like this when
I was using Emacs 23. I am not an expert lisp programmer, so it was a
bit buggy. When I discovered this feature in Emacs 24 I was happy to let
go of my customisation.

FWIW, if this is customisable by a variable expert users opposing this
change can easily revert back to the old behaviour but new users find
this very confusing (at least in my experience from ~3 yrs back when I
adopted Emacs).

> We don't want to just "count votes" -- we want to understand
> how this affects users. So if you care about the issue,
> please tell us how the change affects your editing.
>

> * What are the cases where you find it helps?
>

Often I want to delete large chunks of text and don't want it to
"pollute" my kill ring. This option lets me do that very easily. In my
experience I find I use this more often when I am writing plain text
rather than programming. IMO, with the advent of more such modes in
Emacs where you edit large amounts of plain text (and not source code)
makes this a very useful feature for me (e.g. message-mode, org-mode,
..). I found default behaviour (like the old behaviour) can be a hurdle
when introducing other friends to Emacs (I was trying to introduce my
non techie friends to org-mode and LaTeX).

> * What are the cases where you find it hurts?
>

As I mentioned above, I find it less useful while programming but I
wouldn't say that it hurts.

> * What is your level of Emacs experience?
>

I have been using Emacs for over 3 yrs now. I am a PhD student and my
Emacs use involves a lot of programming (C/C++, python, shell scripts
for my studies and lisp as hobby), writing notes, draft articles for
publications (with org-mode and LaTeX). I am a relatively experienced
user of Emacs (of course not compared to the list members, but in
comparison to my colleagues at the University). On a more fun note, I am
aware of rectangle commands. ;)

> A further change in the same area has been suggested: when there is an
> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>

> * What would you think of this further change?
>

I am not sure about this, but this brings default Emacs behaviour close
to other modern text editors. If this is a configurable option, I don't
see any harm.

> Please send your responses to emacs-de...@gnu.org.
>
>

Thank you for asking the user's opinion!

--
Suvayu

Open source is the future. It sets us free.

[Tassilo Horn]

Ian Zimmerman <i...@buug.org> writes:

Hi Ian,

> Richard> * What are the cases where you find it hurts?
>
> It would make me scream every time I select a region and then forget
> about it (which is _very_ often) and then try to activate
> delete-backward-char with DEL (which is _also very often_).

How can you forget about your active region? I mean, it's highlighted.
If you already turned off transient-mark-mode, then you won't be
affected anyway.

> By the way, what would delete-backward-char be bound to if this change
> is implemented?

,----[ C-h f delete-backward-char RET ]
| delete-backward-char is an interactive compiled Lisp function in `simple.el'.
|
| It is bound to DEL.
|
| (delete-backward-char N &optional KILLFLAG)
|
| Delete the previous N characters (following if N is negative).
| If Transient Mark mode is enabled, the mark is active, and N is 1,
| delete the text in the region and deactivate the mark instead.
| To disable this, set `delete-active-region' to nil.
|
| Optional second arg KILLFLAG, if non-nil, means to kill (save in
| kill ring) instead of delete. Interactively, N is the prefix
| arg, and KILLFLAG is set if N is explicitly specified.
|
| In Overwrite mode, single character backward deletion may replace
| tabs with spaces so as to back over columns, unless point is at
| the end of the line.
`----

Bye,
Tassilo

[ken]

> [Making this change] brings default Emacs behaviour close
> to other modern text editors. ....

This is an invalid argument, more an appeal to fashion than an appeal to
reason. When switching from one application to another, we shouldn't
expect the new one to behave just like the former one. They are
different pieces of software, after all. When you start using different
software, you should expect that it will operate differently. You
should expect that you'll have to learn new things.

Secondly, there are places in the world where people haven't ever used
Windows; instead, their first and only experience with computers is with
Linux. What sense can it make to them that emacs' behavior is changed
simply to mimic some other editor they've never seen or used?

I think that over the long term it will trend upwards that more people's
first and only computer experience will be with FOSS. So thinking ahead
to those times, why should we alter the default behavior of Emacs to
conform to a legacy editor?

Fourth, if we apply your argument to every difference between Emacs and
(e.g.) Word, then we end up with Emacs behaving just like Word, and
there being no difference between Emacs and Word. Then we might as well
just use Word. :/

Fifth, if we change emacs to comport with Word, and if in future Word
changes the way it handles highlighted text to way emacs does now,
should emacs then change back again, just to (again) follow the way Word
works?

Finally, as said at the top, the argument to follow "other modern
editors" is nothing more than an appeal to fashion. And fashion is very
subjective and capricious. We should no more change emacs simply to
comport with some other, even (currently) more popular software than you
and I and all the other guys on this list should start dressing
ourselves like the cool dudes on whatever soap opera is the most popular
these days.

Let's just talk about what makes sense.

[Jai Dayal]

I'm confused as to why they conducted a poll in the first place.  Based on the audience (pedantic pseudo-scientists who are simply programmers and not scientists), it's obvious that the people who are against it will be hostile for the most trivial of reasons (hence, they are simple programmers not scientists).

No original functionality will be removed from emacs.  This is just a simple, logical, edition.  To insert a given character, say 'a', who actually highlights a block of text and types 'a'?  One simply moves the cursor to the location and presses 'a'.  This emacs 'feature' is illogical and useless, hence I strongly support the new editions.

But that's moot - the pedantic pseudo-scientists will simply bicker and create the most anecdotal and trivial use cases to justify their position.

[Torsten Mueller]

ken <geb...@mousecar.com> wrote:

> > [Making this change] brings default Emacs behaviour close to other
> > modern text editors. ....
>
> This is an invalid argument, more an appeal to fashion than an appeal
> to reason. When switching from one application to another, we
> shouldn't expect the new one to behave just like the former one. They
> are different pieces of software, after all. When you start using
> different software, you should expect that it will operate
> differently. You should expect that you'll have to learn new things.

If you start using different cars you will see very soon that turning
the wheel to the left moves also the car to the left, regardless from
the model or the street or the traffic regulations. OK, call it fashion.

> Secondly, there are places in the world where people haven't ever used
> Windows; instead, their first and only experience with computers is
> with Linux.

And with web browsers and web applications (influenced by what?).

T.M.

[Suvayu Ali]

Hi Ken,

On Mon, 03 Oct 2011 09:18:11 -0400
ken <geb...@mousecar.com> wrote:

> Secondly, there are places in the world where people haven't ever
> used Windows; instead, their first and only experience with computers

> is with Linux. What sense can it make to them that emacs' behavior
> is changed simply to mimic some other editor they've never seen or
> used?

You wrongly assumed by modern editors I was talking about Windows
editors[1], you can check out other FOSS editors (in fact they are
pretty good for relatively simple use) like Geany, Kate, Gedit, Nedit
(this is actually pretty old), text input windows of most file/web
browsers, many GUI email clients and so on. And most of the friends I
was trying to introduce to org-mode were *nix users already (yes there
are non-techie people using *nix, and yes they made the decision
without any "friendly help" guiding them in that direction).

No need to start a(n) argument/flame-war here, RMS asked users' opinion
and I expressed myself. Don't get me wrong, I love Emacs and I couldn't
manage to work without it. But the first day experience in Emacs is
definitely one of my worst. My opinion was based on that experience.

Cheers,

Footnotes:

[1] BTW, MS Word is not an editor, its a word processor a parallel in
the FOSS world would be LibreOffice Writer.

[Andreas Röhler]

Am 03.10.2011 15:24, schrieb Jai Dayal:
> I'm confused as to why they conducted a poll in the first place. Based on
> the audience (pedantic pseudo-scientists who are simply programmers and not
> scientists),

Hi Jai,

I'm afraid that's a little bit high-eyebrowed.
Well, being ready to count any other wrong stand over nothing - however,
you can do better.

If people spent their lifetime to present tool like Emacs, it fairly
doesn't matter being estimated a scientist or whatever artist or not.

:)

Beside, usability questions are fairly complicated and are complicated
with Emacs in a specific way.

Stay patient, cheers,

Andreas

[Andreas Röhler]

Am 03.10.2011 11:21, schrieb Tassilo Horn:
> Ian Zimmerman<i...@buug.org> writes:
>
> Hi Ian,
>
>> Richard> * What are the cases where you find it hurts?
>>
>> It would make me scream every time I select a region and then forget
>> about it (which is _very_ often) and then try to activate
>> delete-backward-char with DEL (which is _also very often_).
>
> How can you forget about your active region? I mean, it's highlighted.
> If you already turned off transient-mark-mode, then you won't be
> affected anyway.
>
>> By the way, what would delete-backward-char be bound to if this change
>> is implemented?
>
> ,----[ C-h f delete-backward-char RET ]
> | delete-backward-char is an interactive compiled Lisp function in `simple.el'.
> |
> | It is bound to DEL.
> |

> | (delete-backward-char N&optional KILLFLAG)

> |
> | Delete the previous N characters (following if N is negative).
> | If Transient Mark mode is enabled, the mark is active, and N is 1,
> | delete the text in the region and deactivate the mark instead.
> | To disable this, set `delete-active-region' to nil.
> |
> | Optional second arg KILLFLAG, if non-nil, means to kill (save in
> | kill ring) instead of delete. Interactively, N is the prefix
> | arg, and KILLFLAG is set if N is explicitly specified.
> |
> | In Overwrite mode, single character backward deletion may replace
> | tabs with spaces so as to back over columns, unless point is at
> | the end of the line.
> `----
>
> Bye,
> Tassilo
>
>
>

Hi Tassilo,

I'm in favor of the change now, but was against the feature years ago.
That might be just a personal story.

Habits differ. And not just differ, but differ in a way, some times you
can't explain that by rationality.

Even if in favor of the change now, think Ian's argument is valid.

Preparing decision by such a poll is a very good idea BTW,

thanks all

Andreas

[ken]

On 10/03/2011 09:41 AM Suvayu Ali wrote:
> Hi Ken,
>
> On Mon, 03 Oct 2011 09:18:11 -0400
> ken <geb...@mousecar.com> wrote:
>
>> Secondly, there are places in the world where people haven't ever
>> used Windows; instead, their first and only experience with computers
>> is with Linux. What sense can it make to them that emacs' behavior
>> is changed simply to mimic some other editor they've never seen or
>> used?
>
> You wrongly assumed by modern editors I was talking about Windows
> editors[1],

No, I wasn't assuming you were talking about Word. Since you didn't say
which editor you were talking about, I just picked Word as a foil. If
you re-read my post, you'll see on my first reference to Word I preceded
it by "e.g.", implying the same thereafter.

> you can check out other FOSS editors (in fact they are
> pretty good for relatively simple use) like Geany, Kate, Gedit, Nedit
> (this is actually pretty old), text input windows of most file/web
> browsers, many GUI email clients and so on. And most of the friends I
> was trying to introduce to org-mode were *nix users already (yes there
> are non-techie people using *nix, and yes they made the decision
> without any "friendly help" guiding them in that direction).

My same argument still applies: What's done in other editors isn't
relevant here. Emacs doesn't have to do everything the same as [insert
your favorite editor here]. *Again* we shouldn't try simply to follow
what's fashionable.

Also, I don't understand the reason for making a distinction between
"techie people" and others.

>
> No need to start a(n) argument/flame-war here, RMS asked users' opinion

> and I expressed myself. ....

Agreed. It's just that you were the second person to bring up the
Following Fashion argument. It seemed, then, worthwhile to consider
which criteria are actually relevant to the issue. How is that
'starting a flame war'?



> ....

>
> Footnotes:
>
> [1] BTW, MS Word is not an editor, its a word processor a parallel in
> the FOSS world would be LibreOffice Writer.

And, technically speaking, emacs is a text processor. Relevance?

[Joel James Adamson]

Le Wang <l26...@gmail.com> writes:

> On Fri, Sep 30, 2011 at 11:17 PM, Joel James Adamson
> <joeljame...@gmail.com> wrote:
>> I feel that maintaining the editor-unique nature of the Emacs delete
>> key, rather than adopting the behavior of word processors is crucial to
>> maintaining the uniqueness of Emacs.  It's one of the reasons I use
>> Emacs: the Emacs way makes sense in a way that I strongly prefer.  I
>> never liked the behavior of deleting whole selected regions and I prefer
>> the Emacs way.
>
> I don't want to turn this into a huge debate, so this will be my last
> reply to this that cc's the list.

Sorry, I didn't realize that I'd sent my reply to every address, I only
meant it to go to emacs-de...@gnu.org.

> It's not editor-unique vs word-processor. It's editor-unique vs (web
> browser + email editor + word processor + EVERYTHING).

I see your point, and I know that there's more out there than just Emacs
and Microsoft Word. My point was that I actually didn't like that
behavior where I had encountered it most (Microsoft Word), and I was
glad that Emacs was different. However, I can see how most people would
just be surprised. I just never got why "Unix editors" (I used them
mostly on Unix in those days) like Emacs seemed to make sense, whereas
everything else seemed to enforce irrational behavior. I can't say why
one thing made sense whereas the other didn't, but I'm sure someone's
done a study on it.

I also get your point about not being surprising: surely Emacs will hang
on to more users if they are less surprised. However, we're not trying
to take over the world here, are we? I mean that this is not
necessarily about _how many_ users Emacs ultimately has. There may be
other factors at play: I am not an Emacs Developer, but I would see the
most important things as providing a well-functioning piece of free
software[1].

The bottom-line for me is what you mentioned: as long as I can restore
the default behavior of current versions with one Customize Option, then
I think the change is fine.

Joel

Footnotes:
[1] http://trashbird1240.wordpress.com/2011/09/18/free-software-at-the-farmers-market/

[Stefan Monnier]

> Secondly, there are places in the world where people haven't ever used
> Windows; instead, their first and only experience with computers is with
> Linux.

You probably mean GNU/Linux, but note that this discussion doesn't have
anything to do with the OS you use: all major GUI toolkits in use
nowadays on all major OSes follow the convention that DEL deletes the
currently selected text, if any.


Stefan

[Andreas Röhler]

[ ... ]

Don't get me wrong, I love Emacs and I couldn't
> manage to work without it. But the first day experience in Emacs is
> definitely one of my worst. My opinion was based on that experience.
>

Would wish these kind of experience, which also has been mentioned as a
steep learning curve, would get more attention still.

BTW my view is: Emacs tutorial should not that much teaching keys but
commands - and indeed offer the common copy-and-paste keys for
beginners, even if I prefer Emacs-keys.

Andreas

[Richard Riley]

ken <geb...@mousecar.com> writes:

>> [Making this change] brings default Emacs behaviour close
>> to other modern text editors. ....
>
> This is an invalid argument, more an appeal to fashion than an appeal
> to reason.

A little tongue in check but ...

Having to change common UI motions from app to app is a pain. While I
agree not all things should be embraced more recent changes like how
select, mark and clipboards work make it FAR easier for the newer
adopter : hard core users are more than able to customise back to the
1994 "standard" they prefer as the previous poster mentioned.

Always try to remember the hassles you had when embracing emacs. Only
then can you judge more dispassionately. If you have no interest in
making emacs more palatable for new users then also fine : but that
point needs to be made obvious. But many people do : hence efforts like
the starter kit and el-get and so forth.

> When switching from one application to another, we shouldn't expect the new one
> to behave just like the former one. They are different pieces of software,
> after all. When you start using different software, you should expect that it
> will operate differently. You should expect that you'll have to learn new
> things.
>

> Secondly, there are places in the world where people haven't ever used
> Windows;

Yes, but in the real world... Most people have and do. and emacs runs on
Windows. This isnt a Linux v Windows fanoi bun fight ;)

> instead, their first and only experience with computers is with Linux. What
> sense can it make to them that emacs' behavior is changed simply to mimic some
> other editor they've never seen or used?

emacs is not "Linux". Gnu/Linux has desktop editors which all share
trends virtually identically to how the Windows equivalents do in the
massive majority of cases.

>
> I think that over the long term it will trend upwards that more people's first
> and only computer experience will be with FOSS. So thinking ahead to those
> times, why should we alter the default behavior of Emacs to conform to a legacy
> editor?

Modern FOSS editors invariably conform to common desktop UI paradigms
and key strokes. Not that I advocate changing core keys necessarily.

>
> Fourth, if we apply your argument to every difference between Emacs and (e.g.)
> Word, then we end up with Emacs behaving just like Word, and there being no
> difference between Emacs and Word. Then we might as well just use
> Word. :/

But no one is suggesting Emacs is made into Word. Total Strawman.

>
> Fifth, if we change emacs to comport with Word, and if in future Word changes
> the way it handles highlighted text to way emacs does now, should emacs then
> change back again, just to (again) follow the way Word works?

Strawman now taken to far, far extremes...

Word is not an "editor" in the context of this thread. Its a wysiwig
word processor. And that said, certain wysiwig elements in emacs are VERY
popular. See LaTeX support for a start.

>
> Finally, as said at the top, the argument to follow "other modern editors" is
> nothing more than an appeal to fashion. And fashion is very
> subjective and

No it isnt. Its to follow and conform to other apps many people use and
have developed over many years too and conform to modern desktop standards.

> capricious. We should no more change emacs simply to comport with some other,
> even (currently) more popular software than you and I and all the other guys on
> this list should start dressing ourselves like the cool dudes on whatever soap
> opera is the most popular these days.
>
> Let's just talk about what makes sense.

You dont think emacs sharing certain features with much more popular
editors might be a good idea and makes sense?

[Richard Riley]

ken <geb...@mousecar.com> writes:

> On 10/03/2011 09:41 AM Suvayu Ali wrote:
>> Hi Ken,
>>
>> On Mon, 03 Oct 2011 09:18:11 -0400
>> ken <geb...@mousecar.com> wrote:
>>

>>> Secondly, there are places in the world where people haven't ever

>>> used Windows; instead, their first and only experience with computers

>>> is with Linux. What sense can it make to them that emacs' behavior
>>> is changed simply to mimic some other editor they've never seen or
>>> used?
>>

>> You wrongly assumed by modern editors I was talking about Windows
>> editors[1],
>
> No, I wasn't assuming you were talking about Word. Since you didn't say which
> editor you were talking about, I just picked Word as a foil. If you re-read my
> post, you'll see on my first reference to Word I preceded it by "e.g.", implying
> the same thereafter.

Dont you feel using Word (Windows only non programmers editor) was a
little far fetched considering the plethora of cross platform
programmers editors including and not limited to emacs and vi? Never
mind eclipse etc as well as all the FOSS Gnu/Linux stuff like gedit etc?

[Richard Riley]

Suvayu Ali <fatkasuv...@gmail.com> writes:

> Hi Ken,
>
> On Mon, 03 Oct 2011 09:18:11 -0400
> ken <geb...@mousecar.com> wrote:
>
>> Secondly, there are places in the world where people haven't ever
>> used Windows; instead, their first and only experience with computers
>> is with Linux. What sense can it make to them that emacs' behavior
>> is changed simply to mimic some other editor they've never seen or
>> used?
>
> You wrongly assumed by modern editors I was talking about Windows

> editors[1], you can check out other FOSS editors (in fact they are

> pretty good for relatively simple use) like Geany, Kate, Gedit, Nedit
> (this is actually pretty old), text input windows of most file/web
> browsers, many GUI email clients and so on. And most of the friends I
> was trying to introduce to org-mode were *nix users already (yes there
> are non-techie people using *nix, and yes they made the decision
> without any "friendly help" guiding them in that direction).
>

> No need to start a(n) argument/flame-war here, RMS asked users' opinion

> and I expressed myself. Don't get me wrong, I love Emacs and I couldn't

> manage to work without it. But the first day experience in Emacs is
> definitely one of my worst. My opinion was based on that experience.

I agree with you. How it became a Linux v Windows and Word v Emacs fight
I'm not quite sure.

[Ian Zimmerman]

Ian> It would make me scream every time I select a region and then
Ian> forget about it (which is _very_ often) and then try to activate
Ian> delete-backward-char with DEL (which is _also very often_).

Tassilo> How can you forget about your active region? I mean, it's
Tassilo> highlighted. If you already turned off transient-mark-mode,
Tassilo> then you won't be affected anyway.

Ian> By the way, what would delete-backward-char be bound to if this
Ian> change is implemented?

Tassilo> ,----[ C-h f delete-backward-char RET ] | delete-backward-char
Tassilo> is an interactive compiled Lisp function in `simple.el'.
Tassilo> |
Tassilo> | It is bound to DEL.

One reaction to both hunks: have you read the actual proposal by RMS? I
have, but perhaps I misread it so in that case please point out my
error. As I understand it if the proposal is approved active region
status or transient-mark-mode won't matter - it will be enough to just
have a region at all (ie. to have set a mark and have mark != point).
And, this command will be bound to DEL, replacing the current binding to
delete-backward-char. Since delete-backward-char seems to have no other
key binding, I was interested if another binding for it was planned.

In the end, this doesn't matter very much to me practically, because a
one line addition to my .emacs would revert to the old behavior [1].
But I strongly object philosophically, along the lines expressed in the
other subthread.

[1]
It would be a pain when running with -q, though.

[Ian Zimmerman]

Richard> Having to change common UI motions from app to app is a
Richard> pain. While I agree not all things should be embraced more
Richard> recent changes like how select, mark and clipboards work make
Richard> it FAR easier for the newer adopter : hard core users are more
Richard> than able to customise back to the 1994 "standard" they prefer
Richard> as the previous poster mentioned.

With Emacs, this may be true (I sure hope it is, because I sense the
proposal with go through). But in general, when a package or program
decides to "embrace" we hard core users face a sad choice: retrain our
fingers to the Windows way (and yes, that _is_ what it is, if you trace
it to the source), or "customise back" and give up any new features,
because they are usually not compatible with the old interface. It
happens again and again, and I'm sick of it. Emacs has been sort of
like last bastion, and if it falls I give up computing as a passion and
approach it strictly for the money. Seriously.

Richard> Always try to remember the hassles you had when embracing
Richard> emacs. Only then can you judge more dispassionately.

I do remember that time (around 1995). I came from Windows too, and the
initial difficulties were totally worth it.

Richard> You dont think emacs sharing certain features with much more
Richard> popular editors might be a good idea and makes sense?

Emacs is different because it is first and foremost a programmer's
editor. It is true that it has acquired features for more general text
processing but it always felt those were there so the programmers didn't
have to switch to something different when they composed their emails
:-) Now this proposal would make Emacs itself into something different :-(

People who normally edit general text and only occassionally drop into
highly structured text or code are better served by a simpler editor,
IMO.

[rusi]

The most customizable editor and arguments and fights about an easily
settable default?
Ironic...

I would like to point out that if the suggestions by
the Ilya Zakharevich here (5 from end)
http://groups.google.com/group/comp.emacs/browse_thread/thread/43549e055d64908b/f4fe528ddc02da03

Likewise Alan Macenzie's idea about emacsicality
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/7c08121e215fd383/dcba4f862fc8a7f5?q=emacsicality&lnk=nl&

are taken seriously such arguments are unnecessary.

IOW it is not too much to ask to have the cake and eat it too:

Have: Old users can stay with some version (say emacs 22) and stick
there for as long as they like

Eat: emacs devs can try out genuinely new things unconcerned about
whether some old codgers will get grumpy.

[Lowell Gilbert]

Ian Zimmerman <i...@buug.org> writes:

> One reaction to both hunks: have you read the actual proposal by RMS? I
> have, but perhaps I misread it so in that case please point out my
> error. As I understand it if the proposal is approved active region
> status or transient-mark-mode won't matter - it will be enough to just
> have a region at all (ie. to have set a mark and have mark != point).
> And, this command will be bound to DEL, replacing the current binding to
> delete-backward-char. Since delete-backward-char seems to have no other
> key binding, I was interested if another binding for it was planned.

The proposal specifically mentions active region, so I think you're
wrong. I'm not positive, though.

[Tassilo Horn]

Ian Zimmerman <i...@buug.org> writes:

Hi Ian,

> One reaction to both hunks: have you read the actual proposal by RMS?
> I have, but perhaps I misread it so in that case please point out my
> error. As I understand it if the proposal is approved active region
> status or transient-mark-mode won't matter - it will be enough to just
> have a region at all (ie. to have set a mark and have mark != point).

No, no. You need to have an active region, which depends on having
transient-mark-mode on. The latter got default in emacs 23, but DEL did
not delete the active region. With the proposed behavior, it will be
deleted. The proposed behavior is that you get with the current emacs
24 pretest tarball.

Bye,
Tassilo

[Rasmus]

Ian Zimmerman <i...@buug.org> writes:

> With Emacs, this may be true (I sure hope it is, because I sense the
> proposal with go through). But in general, when a package or program
> decides to "embrace" we hard core users face a sad choice: retrain our
> fingers to the Windows way (and yes, that _is_ what it is, if you trace
> it to the source), or "customise back" and give up any new features,
> because they are usually not compatible with the old interface. It
> happens again and again, and I'm sick of it.

But in general Emacs exhibit a degree of conservatism. The hard part is
choosing the optimal degree of conservatism. With Emacs I don't see
development in branches; but the general concern is valid.

> Emacs has been sort of like last bastion, and if it falls I give up
> computing as a passion and approach it strictly for the money.
> Seriously.

There are also imitators of Emacs. For example I belive one can choose
Emacs bindings in GTK applications. Abiword supports Emacs bindings for
sure. For Firefox the keysnail extension is absolutely wonderful.
Emacs works.

> Richard> Always try to remember the hassles you had when embracing
> Richard> emacs. Only then can you judge more dispassionately.
>
> I do remember that time (around 1995). I came from Windows too, and the
> initial difficulties were totally worth it.

I am sure everyone on this list agrees. Complex software such as Emacs
is hard. Should we `dumb it down' to make it more accessible? I do not
think so, but choosing sane defaults is surely important. (I think
deleting a highlighted region by default is sane).

> Emacs is different because it is first and foremost a programmer's
> editor.

> [...]

> People who normally edit general text and only occassionally drop into
> highly structured text or code are better served by a simpler editor,
> IMO.

I disagree. Generally Emacs is a lisp machine. This enables it to be
used for all kinds of general solutions. For you programming is the
specific solution that you value the most. For me, I value being able
to edit plain text in a coherent environment, whether this plain text is
to be understood as `email', `org', `tex' or whatever. Second, I value
the possibility of integrating other process into my lisp machine,
specifically software such as R and Python. In this sense it also
becomes a programer's tool for me, but the objective is not
programming. Emacs is a specific solution to programming for some
people, but programming is not Emacs.

–Rasmus

--
Sent from my Emacs

[ken]

On 10/03/2011 12:02 PM Richard Riley wrote:
> ken <geb...@mousecar.com> writes:
>
>> On 10/03/2011 09:41 AM Suvayu Ali wrote:

>>> Hi Ken,
>>>
>>> On Mon, 03 Oct 2011 09:18:11 -0400
>>> ken <geb...@mousecar.com> wrote:
>>>
>>>> Secondly, there are places in the world where people haven't ever
>>>> used Windows; instead, their first and only experience with computers
>>>> is with Linux. What sense can it make to them that emacs' behavior
>>>> is changed simply to mimic some other editor they've never seen or
>>>> used?
>>> You wrongly assumed by modern editors I was talking about Windows
>>> editors[1],

>> No, I wasn't assuming you were talking about Word. Since you didn't say which
>> editor you were talking about, I just picked Word as a foil. If you re-read my
>> post, you'll see on my first reference to Word I preceded it by "e.g.", implying
>> the same thereafter.
>
> Dont you feel using Word (Windows only non programmers editor) was a
> little far fetched considering the plethora of cross platform
> programmers editors including and not limited to emacs and vi? Never
> mind eclipse etc as well as all the FOSS Gnu/Linux stuff like gedit etc?

You're missing the point entirely. Re-read my original post in this thread.

[Martyn Jago]

Andreas Röhler <andreas...@easy-emacs.de> writes:

[...]

> Hi Tassilo,
>
> I'm in favor of the change now, but was against the feature years ago.
> That might be just a personal story.
>
> Habits differ. And not just differ, but differ in a way, some times
> you can't explain that by rationality.
>
> Even if in favor of the change now, think Ian's argument is valid.
>
> Preparing decision by such a poll is a very good idea BTW,
>
> thanks all
>
> Andreas

+1

Personally, if it wasn't for org-mode showing me how creative you can
really get with Emacs key-strokes, I may well have moved on/out ~
instead I now have dynamic keystrokes that do all manner of things org
stylee.

The fact is ~ if you don't like it, the setting of a single flag will
make your world right. No? And you know very well how to do it.

There are much better battles to have, and I'm all for encouraging new
blood.

Best, Martyn

[ken]

Though it makes more sense to bottom-post and/or respond interlinearly,
most people using email top-post. So we should all start doing what
most people do. :P

So...

No, not if it's the sole criterion for changing how emacs (or any
software) works.

On 10/03/2011 12:00 PM Richard Riley wrote:
> ken <geb...@mousecar.com> writes:
>

>>> ....

>
>> Finally, as said at the top, the argument to follow "other modern editors" is
>> nothing more than an appeal to fashion. And fashion is very
>> subjective and
>
> No it isnt. Its to follow and conform to other apps many people use and
> have developed over many years too and conform to modern desktop standards.
>
>> capricious. We should no more change emacs simply to comport with some other,
>> even (currently) more popular software than you and I and all the other guys on
>> this list should start dressing ourselves like the cool dudes on whatever soap
>> opera is the most popular these days.
>>
>> Let's just talk about what makes sense.
>

> You dont think emacs sharing certain features with much more popular

[Richard Stallman]

The abstract arguments about this change have already been brought up
in discussions among the Emacs developers. That is not the help we
need.

What I hope the poll will provide is additional factual information on
how the change affects Emacs users. Thus, the poll asks you how the
change affects you in your own editing. Without the poll, we have to
try to guess that. With the poll, we will know.

Secondly, there are places in the world where people haven't ever used
Windows; instead, their first and only experience with computers is with
Linux.

You can't have an experience with Linux as an end user, because Linux
is a kernel. It has no user interface, and users don't talk to it
directly.

Since you are thinking of an operating system that might replace
Windows, I am sure the system you have in mind is the GNU system,
which is typically used with Linux.

When you talk about the system, please don't call it "Linux". If you
do that, you give the credit for our work to someone else who got
involved much later and did a smaller part of the system. Would you
please call the system "GNU/Linux" and give us equal mention?

For more explanation, see http://www.gnu.org/gnu/gnu-linux-faq.html
and http://www.gnu.org/gnu/the-gnu-project.html for historical
background.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/

[MBR]

Hi Richard.

On 9/29/2011 11:42 PM, Richard Stallman wrote:

In Emacs 24, now in pretest, a change is being considered for ASCII
DEL (on most keyboards, the Backspace key) and the Delete function
key.  The change affects the case of an active region that was not
dragged with the mouse.  The change is that these commands would
delete the region, rather than just one character as now.

In the past, this behavior was enabled in some minor modes: CUA mode,
Delete Selection mode, and PC Selection mode.  In the 24.0.90 pretest,
this behavior is enabled by default.  Thus, building and using the
pretest is an easy way to try the change.

Here are the questions we hope you will answer:

* Are you in favor of this change?

No. I would not favor this change.

* Are you opposed to this change?

Yes.  I would oppose the change.

* How strongly do you feel about the matter?

Rather strongly.

We don't want to just "count votes" -- we want to understand
how this affects users.  So if you care about the issue,
please tell us how the change affects your editing.

* What are the cases where you find it helps?

There are no cases.

* What are the cases where you find it hurts?

If I understand the proposal correctly, the idea is to bind the function normally bound to C-w to the BACKSPACE key and the Delete key.  Have I got that right?

As things currently stand, there are three different kinds of delete functionality I use: delete 1 character backward, delete 1 character forward, and delete the marked region.  For over 25 years I've been used to those functions being invoked by BACKSPACE, C-d, and C-w respectively.  Yes, I could retrain myself, just as I had to do years ago when IBM put the CTRL key in the wrong place.  But it will inevitably be a big pain.

If it weren't core functionality you were proposing changing the assignments of, I probably wouldn't care.  But delete functionality is some of the most basic functionality of any editor, just as stop functionality is some of the most basic functionality of a car.  What do you think would happen if some car manufacturer decided to violate the established standard that the brake pedal is to the left of the gas pedal?  If that were to happen, I'm pretty sure there would suddenly be a whole lot more car crashes because people would be confused about which pedal does what.  Changing keystroke assignments isn't going to cause life-threatening crashes, but it will inevitably cause millions of pico-crashes -- not anything that's going to cause serious harm, but enough to cause real annoyance.

I remember back during the Apple look-and-feel wars you were distributing a flyer arguing that if look-and-feel had been the law of the land when the typewriter keyboard was first designed, every typewriter company would have had to invent its own incompatible layout, and instead of typists we'd have Remington keyboard typists, Smith-Corona typists, Olivetti typists, etc.  Keystroke letter assignments on a typewriter and keystroke function assignments for critical functionality in an editor should change seldom or never.

* What is your level of Emacs experience?

After about 10 years of using vi, I switched to Emacs around 1990, and it's been my preferred editor ever since.  However I'm embarrassed to admit that I've never gotten around to teaching myself Emacs Lisp.  It's truly amazing how much you can get done with Emacs even without programming it!

A further change in the same area has been suggested: when there is an
active region, a self-inserting character would delete the region
before the character is inserted by default.

* What would you think of this further change?

It sounds like the goal here is to make Emacs behave like MS Word.  Why?  If I wanted to use Word, I'd run Word or Libre Office.

Please send your responses to emacs-de...@gnu.org.

I do appreciate that you're asking your users' opinions.  I hope you decide the right way, i.e. my way :-). (That's a joke, I say, that's a joke, son! -- Foghorn Leghorn)

Mark Rosenthal
m...@arlsoft.com

[rusi]

On Oct 4, 9:28 am, MBR <m...@arlsoft.com> wrote:
> Hi Richard.
>
> On 9/29/2011 11:42 PM, Richard Stallman wrote:> In Emacs 24, now in pretest, a change is being considered for ASCII
> > DEL (on most keyboards, the Backspace key) and the Delete function
> > key.  The change affects the case of an active region that was not
> > dragged with the mouse.  The change is that these commands would
> > delete the region, rather than just one character as now.
>
> > In the past, this behavior was enabled in some minor modes: CUA mode,
> > Delete Selection mode, and PC Selection mode.  In the 24.0.90 pretest,
> > this behavior is enabled by default.  Thus, building and using the
> > pretest is an easy way to try the change.
>
> > Here are the questions we hope you will answer:
>
> > * Are you in favor of this change?
>
> No. I would not favor this change.
> * Are you opposed to this change?
>
> Yes.  I would oppose the change.
> * How strongly do you feel about the matter?
> Rather strongly.

Even if a one-line such as

(setq delete-selection-defaults 23)

in your .emacs were to keep your preferred functionality?

Thanks for this example -- it actually works the other way: How many
of today's computer users were born when you (and I if it means
anything) started using emacs?

This analogy is more apposite than you probably realize. For various
reasons (not relevant here) I happen to end up driving two cars, one
with 'American' controls, one with 'European' controls.
Invariably when I switch I end up turning on the wiper when I want to
turn on the turning indicator and vice versa.

As it happens I am still alive to tell this and one could say that the
non-standardization is less lethal than switching brake and gas. But
it is probably more dangerous than delete-selection functionality.

>
> I remember back during the Apple look-and-feel wars you were
> distributing a flyer arguing that if look-and-feel had been the law of
> the land when the typewriter keyboard was first designed, every
> typewriter company would have had to invent its own incompatible layout,
> and instead of typists we'd have Remington keyboard typists,
> Smith-Corona typists, Olivetti typists, etc.  Keystroke letter
> assignments on a typewriter and keystroke function assignments for
> critical functionality in an editor should change seldom or never.

Once again your example works for you if you compare emacs 24 with
earlier emacses.
It works against you if you compare emacs with all the other tools
that almost everyone else uses.
[How many hard-core emacs users can claim that they use no other tools
that are inconsistent with emacs?]

>
> > * What is your level of Emacs experience?
>
> After about 10 years of using vi, I switched to Emacs around 1990, and
> it's been my preferred editor ever since.  However I'm embarrassed to
> admit that I've never gotten around to teaching myself Emacs Lisp.  It's
> truly amazing how much you can get done with Emacs even without
> programming it!> A further change in the same area has been suggested: when there is an
> > active region, a self-inserting character would delete the region
> > before the character is inserted by default.
>
> > * What would you think of this further change?
>
> It sounds like the goal here is to make Emacs behave like MS Word.  

> Why?  If I wanted to use Word, I'd run Word or Libre Office.> Please send your responses to emacs-delete-p...@gnu.org.

Red herring argument.
As discussed by others above the proposed change is in line with the
behavior of most apps on all modern OSes -- and not just text editors
but music, image etc editors as well.

>
> I do appreciate that you're asking your users' opinions.  I hope you
> decide the right way, i.e. my way :-). (That's a joke, I say, that's a
> joke, son! -- Foghorn Leghorn)
>
>     Mark Rosenthal

>     m...@arlsoft.com <mailto:m...@arlsoft.com>

[Jeremiah Dodds]

Let me preface by saying that I don't really care very much about the
behavior of [DEL]
here, but I do care about people trying to call out arguments as
invalid with hogwash.

On Mon, Oct 3, 2011 at 8:18 AM, ken <geb...@mousecar.com> wrote:
>> [Making this change] brings default Emacs behaviour close
>> to other modern text editors. ....
>
> This is an invalid argument, more an appeal to fashion than an appeal to

> reason.  When switching from one application to another, we shouldn't expect

> the new one to behave just like the former one.  They are different pieces
> of software, after all.  When you start using different software, you should
> expect that it will operate differently.  You should expect that you'll have
> to learn new things.
>

Assumptions:

Other "modern text editors" behavior was not decided upon via reason.
All pieces of software are an island.

I don't disagree that people should expect to learn new things, but I'm also not
ignorant of patterns of behavior in categories of software, and how that can
influence a user's ability to learn things quickly as well as how that
can affect adoption.

Perhaps if you had some evidence that the behavior of [DEL] in other
modern editors
was pretty much a big unfortunate trend, this argument would hold. If
I had to guess though,
I would guess that at least one of the editors out there with the
behavior have some
closer to empirical data as to why they chose that behavior.

> Secondly, there are places in the world where people haven't ever used
> Windows; instead, their first and only experience with computers is with

> Linux.  What sense can it make to them that emacs' behavior is changed
> simply to mimic some other editor they've never seen or used?
>

Assumptions:

The Emacs community gives a crap about emacs making sense ;)
In these places in the world, the only editor available is emacs.

>From the discussion, it seems more likely that they'd say something like
"Oh, well it looks like emacs does the same thing as these other editors now".
Then again, I wouldn't know. Maybe some of them are on the list, and would
like to say whether or not they'd be totally befuddled if the behavior of [DEL]
changed?

> I think that over the long term it will trend upwards that more people's
> first and only computer experience will be with FOSS.  So thinking ahead to
> those times, why should we alter the default behavior of Emacs to conform to
> a legacy editor?
>

This is just kinda sidestepping the argument.

A whoooole lot of Emacs behavior is the way it is because it was written before
there were a whole lot of text editors around. Emacs has a lot of
"legacy" behavior and
terminology.

If, in the future, the majority of text editors decided that a
different behavior for [DEL] was
better, presumably through some sort of study, then at that time we
might want to consider
modifying the behavior of [DEL] again. Oh no!

"Correct behavior" and "usability" and all that are not things that
are set in stone, they're
more like really slow rivers mixed with a clusterfuck of culture. Now,
whether or not the
emacs community cares too much about that is another matter .... but
then again, users
who like and use emacs enough *to* care about keeping the current
behavior are probably
knowledgeable enough to know how to configure emacs to keep it...

> Fourth, if we apply your argument to every difference between Emacs and
> (e.g.) Word, then we end up with Emacs behaving just like Word, and there
> being no difference between Emacs and Word.  Then we might as well just use
> Word. :/
>

This is ridiculous. If all differences could be considered equal,
maybe it wouldn't be.

> Fifth, if we change emacs to comport with Word, and if in future Word
> changes the way it handles highlighted text to way emacs does now, should
> emacs then change back again, just to (again) follow the way Word works?
>

Well, is the emacs community making the change to follow *one* editor,
or to follow a trend in
behavior across multiple editors? If the latter has occured, it might
be worth the
consideration of the community.

> Finally, as said at the top, the argument to follow "other modern editors"
> is nothing more than an appeal to fashion.  And fashion is very subjective

> and capricious.  We should no more change emacs simply to comport with some

> other, even (currently) more popular software than you and I and all the
> other guys on this list should start dressing ourselves like the cool dudes
> on whatever soap opera is the most popular these days.
>

This is sort of pointless. AFAICT, keeping the behavior isn't any less
an "appeal to fashion",
it's just an appeal to the current emacs fashion, other than in the
parts of the thread that were
actually bringing up *reasons* for keeping it around or changing it
that weren't just
emotional claptrap.

If the change is *entirely* superficial, then what's going on is a
bunch of bikeshedding, and this
whole discussion should be tossed into the firey inferno.

> Let's just talk about what makes sense.

Seriously.

[suvayu ali]

Hi Mark,

On Tue, Oct 4, 2011 at 6:28 AM, MBR <m...@arlsoft.com> wrote:
> If I understand the proposal correctly, the idea is to bind the function
> normally bound to C-w to the BACKSPACE key and the Delete key.  Have I got
> that right?
>
> As things currently stand, there are three different kinds of delete
> functionality I use: delete 1 character backward, delete 1 character
> forward, and delete the marked region.  For over 25 years I've been used to
> those functions being invoked by BACKSPACE, C-d, and C-w respectively.  Yes,
> I could retrain myself, just as I had to do years ago when IBM put the CTRL
> key in the wrong place.  But it will inevitably be a big pain.
>

I think you are misunderstanding the change. The proposal says if
there is an active region, pressing the DEL key would delete either
the active region (if present) or one character forward. You can still
use C-w instead, the difference being using DEL won't append the text
to the kill ring but C-w will.

To try out this behaviour, you can use Emacs 24 pretest or the BZR
head. I hope this clears up the proposal.

[Marko Vojinovic]

On Tuesday 04 October 2011 05:28:20 MBR wrote:
> As things currently stand, there are three different kinds of delete
> functionality I use: delete 1 character backward, delete 1 character
> forward, and delete the marked region. For over 25 years I've been used
> to those functions being invoked by BACKSPACE, C-d, and C-w
> respectively. Yes, I could retrain myself, just as I had to do years
> ago when IBM put the CTRL key in the wrong place. But it will
> inevitably be a big pain.

How often do you mark a region and then decide to delete a few characters here
and there while it is marked?

When you mark a region, is it not reasonable to expect that the next action
will be applied to that region?

> If it weren't core functionality you were proposing changing the
> assignments of, I probably wouldn't care. But delete functionality is
> some of the most basic functionality of any editor, just as stop
> functionality is some of the most basic functionality of a car. What do
> you think would happen if some car manufacturer decided to violate the
> established standard that the brake pedal is to the left of the gas
> pedal? If that were to happen, I'm pretty sure there would suddenly be
> a whole lot more car crashes because people would be confused about
> which pedal does what. Changing keystroke assignments isn't going to
> cause life-threatening crashes, but it will inevitably cause millions of
> pico-crashes -- not anything that's going to cause serious harm, but
> enough to cause real annoyance.

If you like analogies, I'd say that there is a certain standard among everyone
about the position of the brake pedal, except in Emacs cars which have a
different (ancient-style) position. I think it is quite reasonable, in the
interest of minimizing confusion and car crashes, that Emacs cars adjust the
pedal positions to what every driver expects (with the possible exception of
old-style Emacs drivers who can keep the old pedals if they wish). ;-)

> I remember back during the Apple look-and-feel wars you were
> distributing a flyer arguing that if look-and-feel had been the law of
> the land when the typewriter keyboard was first designed, every
> typewriter company would have had to invent its own incompatible layout,
> and instead of typists we'd have Remington keyboard typists,
> Smith-Corona typists, Olivetti typists, etc. Keystroke letter
> assignments on a typewriter and keystroke function assignments for
> critical functionality in an editor should change seldom or never.

Well, today you have Emacs typists, and everyone else. Why shouldn't Emacs
change, for the greater benefit of having a uniform keystroke assignments (at
least those most basic and fundamental ones) across all text editors?

> It sounds like the goal here is to make Emacs behave like MS Word.
> Why? If I wanted to use Word, I'd run Word or Libre Office.

No, the goal here is to make Emacs behave like every other editor does (bar a
couple of them maybe).

I really don't see a point in comparing Emacs to Word, nor I understand why
people consider this kind of change as "behave like Word". If some feature or
behavior is good and useful in an editor, it is quite likely that most editors
and word processors will have it (yes, including even Word). So why deny
yourself a useful feature only because Word also has it? Furthermore, most of
the text editors and word processors out there have the same feature, why do
folks tend to single out MS Word to compare against?

Best, :-)
Marko

[ken]

(Again) Though some believe it makes more sense to bottom-post and/or

respond interlinearly, most people using email top-post. So we should
all start doing what most people do. :P

Moreover, in modern email apps the default behavior in replying to an
email places the cursor at the top of your reply. So they must have
done a study on this and found top posting to be better. :P

In keeping with the principle that the sole criterion for changing how
emacs (or any software) works will be what's fashionable, emacs should
make, among others, the following reassignments to its UI:

C-p - Print the file

C-n - New file

C-a - select All

C-q - Quit

These changes will make it easier for those new to emacs. In that they
are culturally biased towards those who speak English, there are good
reasons for them. And because so many other modern editors have these
same key bindings, they must have done a series of studies on them and
found them the most intuitive and therefore best for all (denen von eine
einsiger engen Denk- und Mundart).


Enjoy.

[ken]

Jeremiah,

To be considered a *hidden* assumption (which is what you really meant
to say) to a proposition, it must logically necessary for that
proposition. What you're calling "assumptions" below are not.

[rusi]

On Oct 3, 9:22 pm, Jeremiah Dodds <jeremiah.do...@gmail.com> wrote:
>
> This is sort of pointless. AFAICT, keeping the behavior isn't any less
> an "appeal to fashion",
> it's just an appeal to the current emacs fashion, other than in the
> parts of the thread that were
> actually bringing up *reasons* for keeping it around or changing it
> that weren't just
> emotional claptrap.

Ive been feeling a bit warm of late jogging in my powdered wig. And
my cravat and sword keep getting stuck in elevator doors. Thanks for
drawing my attention to the fact that I may be dressing funny. [Should
have known from the looks I keep getting...]

[Drew Adams]

> If you like analogies, I'd say that there is a certain
> standard among everyone about the position of the brake
> pedal, except in Emacs cars which have a different
> (ancient-style) position. I think it is quite reasonable,
> in the interest of minimizing confusion and car crashes,
> that Emacs cars adjust the pedal positions to what every
> driver expects (with the possible exception of
> old-style Emacs drivers who can keep the old pedals if they wish). ;-)

Yes, it was only a matter of time before we got to
`which-side-of-the-road-to-drive-on' and
`which-side-is-the-steering-wheel-on'.

Country `States Comprising Antartic Meta Earth' is thinking of changing the side
it uses and would like to poll its residents. Which side are you on? Before
responding, please consider the SCAME Tourist and Immigration Bureau's policy of
not wanting to inconvenience newcomers, who might be used to a different side.

[Drew Adams]

> In general this is a welcome change and I will no longer need the
> following in .emacs: (delete-selection-mode 1)

Not really. Not if you expect all that `delete-selection-mode' offers.

The first change proposed in the poll is like one piece of
`delete-selection-mode', but with a twist in one of its default settings: the
DEL key (aka Backspace) deletes without killing.

The second change is like another piece of `delete-selection-mode': it lets you
type to replace the region.

`delete-selection-mode' is more general, and it lets you customize how & which
individual commands (hence keys) interact with it. E.g., you can tell it that
you want DEL to delete (as in the proposal) instead of kill. You can make it do
various things related to the region for any keys you want - very flexible,
simple to modify.

Personally, I use `delete-selection-mode' - always have. I think it should be
the default Emacs behavior. Previously I argued in favor of
`transient-mark-mode' being turned on by default. That took a long time, but it
is now the default behavior.

However, I'm not in favor of either of the current proposals, as is. It is
better for such behavior changes to be contained in one or more well-defined
modes that users can easily recognize and customize. (Delete-selection is one
such mode.)

[And by default, mouse selection should be treated the same as the ordinary
active region. This was changed recently, with no poll, unfortunately.
Likewise, interactions between Emacs selection/region and standard paste
buffers/clipboards/selections were changed, with no poll - and it is not obvious
to a user how to customize Emacs to get back the old behavior.]

> However, I'm not certain from a functional point of view how
> delete-selection-mode differs from the proposed change (will it also
> include transient mark mode?).

Transient mark mode is already turned on now in Emacs, by default. The proposed
change does not implement or replace delete-selection mode. What it does is
make DEL delete the active region. The second proposed change lets characters
you type replace the active region.

FWIW, I am very happy to see that Richard has opened a poll for this. It would
be helpful if the Emacs maintainers did the same for other (and more radical)
changes of behavior that they implement.

[MBR]

Suvayu,

I don't think so.  What Richard wrote was:

"a change is being considered for ASCII DEL (on most keyboards, the Backspace key) and the Delete function key."

ASCII DEL is 0x7F (decimal 127).  As Richard says, on most keyboards that's the key whose keycap says "Backspace".  It's usually on the far right of the keyboard in the row that contains the digits 1-9 and 0.  He also refers to "the Delete function key".  That's the key whose keycap says "Delete".  That's usually somewhere near Insert, Home, End, Page Up, and Page Dn.

I hardly ever use the Delete function key.  But I use Backspace to delete 1 character backward all the time.  I'd guess several times a minute.  This change would mess up my typing bigtime!  I'd guess that it would be a year or two before I stopped accidentally typing Backspace and expecting it to delete 1 character backward.

Mark

On 10/4/2011 3:33 AM, suvayu ali wrote:

Hi Mark,

On Tue, Oct 4, 2011 at 6:28 AM, MBR <m...@arlsoft.com> wrote:

If I understand the proposal correctly, the idea is to bind the function

normally bound to C-w to the BACKSPACE key and the Delete key.  Have I got
that right?

As things currently stand, there are three different kinds of delete
functionality I use: delete 1 character backward, delete 1 character
forward, and delete the marked region.  For over 25 years I've been used to
those functions being invoked by BACKSPACE, C-d, and C-w respectively.  Yes,
I could retrain myself, just as I had to do years ago when IBM put the CTRL
key in the wrong place.  But it will inevitably be a big pain.

I think you are misunderstanding the change. The proposal says if
there is an active region, pressing the DEL key would delete either
the active region (if present) or one character forward. You can still
use C-w instead, the difference being using DEL won't append the text
to the kill ring but C-w will.

To try out this behaviour, you can use Emacs 24 pretest or the BZR
head. I hope this clears up the proposal.

[John Bokma]

ken <geb...@mousecar.com> writes:

> (Again) Though some believe it makes more sense to bottom-post and/or
> respond interlinearly, most people using email top-post. So we should
> all start doing what most people do. :P

So (again) you try to make a point by being a pain in the ass?

--
John Bokma j3b

Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html

[suvayu ali]

Hi Mark,

Sorry in my response I forgot to distinguish between the Delete key and
the backspace key. You are correct in saying both will have this
behaviour.

On Tue, Oct 4, 2011 at 4:08 PM, MBR <m...@arlsoft.com> wrote:
> I hardly ever use the Delete function key.  But I use Backspace to delete 1
> character backward all the time.  I'd guess several times a minute.  This
> change would mess up my typing bigtime!  I'd guess that it would be a year
> or two before I stopped accidentally typing Backspace and expecting it to
> delete 1 character backward.
>

That said, I believe what you say above is incomplete. This is what I
observe in the Emacs 24 head at the moment: if there is some text as
follows,

some !_text!

where the text surrounded by exclamation marks indicate the active
region and the underscore indicates the cursor position then pressing
DEL or <deletechar> (backspace or Delete) will result in the following,

some _

If on the other hand there is no active region as below,

some tex_t

pressing DEL will result in,

some te_t

and pressing <deletechar> will result in,

some tex


I like that this feature gives me convenient keybindings irrespective of
whether I choose to delete (delete-region) the text (or active region)
or kill (kill-region) the text, the difference being greater control
over what goes into the kill ring. I hope I have explained myself
clearly this time around.

> Mark
>

:)

[Ian Zimmerman]

Drew> interactions between Emacs selection/region and standard paste
Drew> buffers/clipboards/selections were changed, with no poll - and it
Drew> is not obvious to a user how to customize Emacs to get back the
Drew> old behavior.]

This is one of my few longtime gripes with Emacs, so I would be _very_
interested in the details of the change. Are they written up anywhere?
If not, could you summarize them here?

Drew> Transient mark mode is already turned on now in Emacs, by default.
Drew> The proposed change does not implement or replace delete-selection
Drew> mode. What it does is make DEL delete the active region. The
Drew> second proposed change lets characters you type replace the active
Drew> region.

Let us settle this once and for ever: would the proposal currently
under consideration change _anything_ for users who set
transient-mark-mode to nil ?

[des...@verizon.net]

> [Making this change] brings default Emacs behaviour close
> to other modern text editors. ....

Sorry, I lost the original post on "like other editors" so no attribution.

Just want to point out that the behavior being discussed is way
more basic than editor behavior.

Firefox, and almost every other GUI or GUI toolkit uses the
key replaces selection behavior. Be it Windows or some other
operating system.

This behavior has become basic to keyboarding.

You don't have to be a Windows user to expect this new
proposed default behavior.

As for the few people complaining, I don't get it.
A few seconds changing an option back to the way you like it?
Give me a break. It's not really about experienced users
preferences.

--
Dan Espen

[Drew Adams]

> Drew> interactions between Emacs selection/region and standard paste
> Drew> buffers/clipboards/selections were changed, with no

> Drew> poll - and it is not obvious to a user how to customize Emacs
> Drew> to get back the old behavior.]

>
> This is one of my few longtime gripes with Emacs, so I would be _very_
> interested in the details of the change. Are they written up
> anywhere? If not, could you summarize them here?

No, I'm afraid I cannot summarize them. I tried to follow the descriptions and
explanations as they came in (largely in response to my questions like yours),
but at the end of the day I can't tell you succinctly just what went down. For
one thing, I'm no expert about X-Window selection etc.

You can do `M-x view-emacs-news' in an Emacs 24 build, and then search for
"selection". This is what you will find. I think it does help, but it might
not leave things crystal clear for at least some users. ;-)

,----
| ** Selection changes.
|
| The default handling of clipboard and primary selections was changed
| to conform with modern X applications. In short, most commands for
| killing and yanking text now use the clipboard, while mouse commands
| use the primary selection.
|
| In the following, we provide a list of these changes, followed by a
| list of steps to get the old behavior back if you prefer that.
|
| +++
| *** `select-active-regions' now defaults to t.
| Merely selecting text (e.g. with drag-mouse-1) no longer puts it in
| the kill ring. The selected text is put in the primary selection, if
| the system possesses a separate primary selection facility (e.g. X).
|
| +++
| **** `select-active-regions' also accepts a new value, `only'.
| This means to only set the primary selection for temporarily active
| regions (usually made by mouse-dragging or shift-selection);
| "ordinary" active regions, such as those made with C-SPC followed by
| point motion, do not alter the primary selection.
|
| ---
| **** `mouse-drag-copy-region' now defaults to nil.
|
| +++
| *** mouse-2 is now bound to `mouse-yank-primary'.
| This pastes from the primary selection, ignoring the kill-ring.
| Previously, mouse-2 was bound to `mouse-yank-at-click'.
|
| +++
| *** `x-select-enable-clipboard' now defaults to t on all platforms.
| +++
| *** `x-select-enable-primary' now defaults to nil.
| Thus, commands that kill text or copy it to the kill-ring (such as
| M-w, C-w, and C-k) also use the clipboard---not the primary selection.
|
| ---
| **** The "Copy", "Cut", and "Paste" items in the "Edit" menu are now
| exactly equivalent to, respectively M-w, C-w, and C-y.
|
| ---
| **** Note that on MS-Windows, `x-select-enable-clipboard' was already
| non-nil by default, as Windows does not support the primary selection
| between applications.
|
| ---
| *** To return to the previous behavior, do the following:
| **** Change `select-active-regions' to nil.
| **** Change `mouse-drag-copy-region' to t.
| **** Change `x-select-enable-primary' to t (on X only).
| **** Change `x-select-enable-clipboard' to nil.
| **** Bind `mouse-yank-at-click' to mouse-2.
|
| +++
| *** Support for X cut buffers has been removed.
|
| *** X clipboard managers are now supported.
| To inhibit this, change `x-select-enable-clipboard-manager' to nil.
|
`----

> Drew> Transient mark mode is already turned on now in Emacs,

> Drew> by default. The proposed change does not implement or
> Drew> replace delete-selection mode. What it does is make DEL
> Drew> delete the active region. The second proposed change
> Drew> lets characters you type replace the active region.

>
> Let us settle this once and for ever: would the proposal currently
> under consideration change _anything_ for users who set
> transient-mark-mode to nil ?

I don't know. My guess is no. Perhaps Richard can explain just what is meant
in this regard, for the two proposals that the poll is about.

[FWIW, I think things would have been clearer if the second proposal (about
type-to-replace) had *not* been included in the (same) poll. For one thing, the
first poll proposal is already part of Emacs 24, and the second one is not - and
it will not be part of Emacs 24.1.]

[S Boucher]

----- Original Message -----

> This is an invalid argument, --snip--

This reminds me of the time rms asked whether menus should be enabled by default.

One objection from a hacker - I won't say who he is - complained that it would require him to change his .emacs to disable the menubar.  Understanding the stupidy of this argument is left as an exercise.

Thankfully, rms did the right thing and the menus are on by defaults... and I disable them in my .emacs :-)

[S Boucher]

----- Original Message -----
> From: Richard Stallman <r...@gnu.org>
> To: info-gn...@gnu.org; help-gn...@gnu.org
> Cc:
> Sent: Thursday, September 29, 2011 11:42:50 PM
> Subject: Poll about proposed change in DEL (aka Backspace) and Delete
>
> In Emacs 24, now in pretest, a change is being considered for ASCII

> DEL (on most keyboards, the Backspace key) and the Delete function

> key.  The change affects the case of an active region that was not

> dragged with the mouse.  The change is that these commands would
> delete the region, rather than just one character as now.
>
> In the past, this behavior was enabled in some minor modes: CUA mode,
> Delete Selection mode, and PC Selection mode.  In the 24.0.90 pretest,
> this behavior is enabled by default.  Thus, building and using the
> pretest is an easy way to try the change.
>
> Here are the questions we hope you will answer:
>
> * Are you in favor of this change?

Yes

> * Are you opposed to this change?
>

> * How strongly do you feel about the matter?

It's a good idea to align with common practices whenever possible.

In this case, hackers will get used to this rapidly.  They'll complain just 'cause that's what hackers do, but in the end will move on to more important things than complain about a mostly harmless change in Emacs' UI.

>
> We don't want to just "count votes" -- we want to understand
> how this affects users.  So if you care about the issue,
> please tell us how the change affects your editing.
>
> * What are the cases where you find it helps?
>

> * What are the cases where you find it hurts?
>

> * What is your level of Emacs experience?

Since emacs 18.59

>
> A further change in the same area has been suggested: when there is an

> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>
> * What would you think of this further change?

Align with the widely accepted behavior.  Do it. It's really a minor behavior change.

If Emacs had done it this way from the get go, people would not lobby to go to what is standard right now in Emacs.  So, we shouldn't catter to those who want the current behavior to remain.

> Please send your responses to emacs-de...@gnu.org.

[Alan E. Davis]

Above all, do no harm.  

I am opposed because I fear my ingrained habits would thrown me under a train.   The del key is not the backspace key, by the way.   The differences between the ways these keys work, or not, seems like a theological argument.  

Forgive me for not answering each point.   I am pretty strongly opposed.

I am a mostly non-programmer, for whom Emacs is an underpinning of my work style.  

Alan Davis

[Jeremiah Dodds]

On Tue, Oct 4, 2011 at 7:44 AM, ken <geb...@mousecar.com> wrote:
> Jeremiah,
>
> To be considered a *hidden* assumption (which is what you really meant to
> say) to a proposition, it must logically necessary for that proposition.
>  What you're calling "assumptions" below are not.
>
>

Luckily we are not using a language where words only have one meaning,
nor are we in a discussion where all the definitions of words are
meant to have the definition used in logic.

Since you seem to be either trying to dismiss arguments by finding
flaws unrelated to the main points of the arguments, or actually
missing the main points of the arguments by being distracted or
something, here are my main issues with the post you made earlier in a
condensed form:

1. You are making it sound like the sole reason for people wanting
the change is so that emacs will act like other editors. Even if this
is the case, analysis of the change should not stop there, what should
be looked at (if possible) is whether or not there's a good reason why
many other editors have the proposed behavior. If there is, then the
argument about changing "just" to emulate other editors doesn't hold
well.

2. The argument about wanting to avoid changes because they are
"appeals to fashion" can be applied to wanting to make the change with
just as much weight. Keeping the behavior just because "that's the way
it is" is just as much of an "appeal to fashion", it's just appealing
to the fashion current in Emacs.

The same flaw that is present in the whole of your argument is present
in that second point -- the arguments *for* keeping the behavior are
*not* as simple as "well that's just the way it is". The arguments
*against* keeping the behavior are also not just "but Mom, everyone is
wearing them!".

[S Boucher]

>
>I am opposed because I fear my ingrained habits would thrown me under a train. 

If a change in UI behavior causes you to be suicidal, I suspect the UI changes are the least of your concerns :-)

[Alan Mackenzie]

As a matter of interest, can anybody (who didn't write it) understand all
this? It seems to be beyond ready comprehension. Is it that it is
intrinsically complicated, or does it just need better explaining?

By the way, when did we start calling marking "selecting"?

>> Let us settle this once and for ever: would the proposal currently
>> under consideration change _anything_ for users who set
>> transient-mark-mode to nil ?

I think it does. It is possible even with t-m-m disabled to create an
active region temporarily, a sort of transient transient mark mode. Such
a region will be vulnerable to the new definitions of DEL and <delete>, I
think.

> I don't know. My guess is no. Perhaps Richard can explain just what is meant
> in this regard, for the two proposals that the poll is about.

--
Alan Mackenzie (Nuremberg, Germany).

[ken]

On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
> On Tue, Oct 4, 2011 at 7:44 AM, ken <geb...@mousecar.com> wrote:
>> Jeremiah,
>>
>> To be considered a *hidden* assumption (which is what you really meant to
>> say) to a proposition, it must logically necessary for that proposition.
>> What you're calling "assumptions" below are not.
>>
>>
>
> Luckily we are not using a language where words only have one meaning,
> nor are we in a discussion where all the definitions of words are
> meant to have the definition used in logic.

Dismissing logic, are we? I suspect this is the reason for the S/N here
approaching zero.

>
> Since you seem to be either trying to dismiss arguments by finding
> flaws unrelated to the main points of the arguments, or actually
> missing the main points of the arguments by being distracted or
> something, here are my main issues with the post you made earlier in a
> condensed form:

Very ironic that you should say that. Please read on.

>
> 1. You are making it sound like the sole reason for people wanting
> the change is so that emacs will act like other editors.

I not only was making it sound like that, that's exactly what I was
saying. And it was *all* that I was saying. I said this because, in
fact, two people posted in favor of the changes and for no other reason
than the proposed changes complied with how 'modern editors' worked.
Please re-read my original post and you'll see I already said this.

> Even if this
> is the case, analysis of the change should not stop there, what should
> be looked at (if possible) is whether or not there's a good reason why
> many other editors have the proposed behavior. If there is, then the
> argument about changing "just" to emulate other editors doesn't hold
> well.

Again, if you reread my original post, you'll find you're now arguing
against something which you're imagining that I said.

>
> 2. The argument about wanting to avoid changes because they are
> "appeals to fashion" can be applied to wanting to make the change with
> just as much weight. Keeping the behavior just because "that's the way
> it is" is just as much of an "appeal to fashion", it's just appealing
> to the fashion current in Emacs.

Not at all. You're obviously not aware of the quite important principle
of UI development which counsels against throwing surprises at users.

>
> The same flaw that is present in the whole of your argument is present
> in that second point -- the arguments *for* keeping the behavior are
> *not* as simple as "well that's just the way it is". The arguments
> *against* keeping the behavior are also not just "but Mom, everyone is
> wearing them!".

Again, re-read my original post. Don't try to put words or arguments in
it that aren't there. I didn't write what you quote above, nor did I
even imply that. So the "flaw" you're talking about is only in
statements coming out of your imagination.

[Johnny]

I thought I'd let this one slip, as I considered myself too
inexperienced to argue a point, but after following some of the sandbox
arguments, I am now compelled to give a view.

Richard Stallman <r...@gnu.org> writes:

> In Emacs 24, now in pretest, a change is being considered for ASCII
> DEL (on most keyboards, the Backspace key) and the Delete function
> key. The change affects the case of an active region that was not
> dragged with the mouse. The change is that these commands would
> delete the region, rather than just one character as now.
>
> In the past, this behavior was enabled in some minor modes: CUA mode,
> Delete Selection mode, and PC Selection mode. In the 24.0.90 pretest,
> this behavior is enabled by default. Thus, building and using the
> pretest is an easy way to try the change.
>
> Here are the questions we hope you will answer:
>
> * Are you in favor of this change?

Yes.

>
> * Are you opposed to this change?

No.

>
> * How strongly do you feel about the matter?

5 out of 10.

>
> We don't want to just "count votes" -- we want to understand
> how this affects users. So if you care about the issue,
> please tell us how the change affects your editing.
>
> * What are the cases where you find it helps?

1) Expanded functionality.
It wouldn't change my editing habits by much, if at all. When I have an
active region, I expect to operate on it, and in my current habits would
/never/ use DEL or Delete, because they do not operate on the active
region. Normally to "delete" text, I'd use 'kill-region' through C-w. It
is quite possible I'd use the delete functionality if implemented, with
the pros and cons of not having the section in the kill ring.

2) Improved harmonisation.
For newcomers and oldtimers alike. While a minor argument, it is
nonetheless valid. Not that emacs needs any selling points as free
software, but sometimes even experienced users have to switch editors,
and in those cases it doesn't harm in harmonising editor behaviours when
it is not degrading the functionality (see point 1).

>
> * What are the cases where you find it hurts?

1) Extra keystrokes.
Rarely (basically never) after selecting an active region, I may change
my mind and want to delete a single character without first using C-g to
deactivate the region. This could be mitigated by customising init.el if
pressing, so not really an issue.

2) Human error.
Getting used to the new behaviour and deleting a region instead of
killing it will make it unyankable (but undoable), and may not be the
desired outcome. This is behavioural training, and I can adapt (I hope I
am not yet too old to learn).

>
> * What is your level of Emacs experience?

2 years, having merged all my (org)anisational, mail, messenging,
browsing and coding needs into one editor.

>
> A further change in the same area has been suggested: when there is an
> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>
> * What would you think of this further change?

The same arguments as above holds. I am for the change, without a heavy bias.

>
> Please send your responses to emacs-de...@gnu.org.

--

Johnny

[Jeremiah Dodds]

On Tue, Oct 4, 2011 at 3:02 PM, ken <geb...@mousecar.com> wrote:
> On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
>>
>> On Tue, Oct 4, 2011 at 7:44 AM, ken <geb...@mousecar.com> wrote:
>
>
> Dismissing logic, are we?  I suspect this is the reason for the S/N here
> approaching zero.
>

No, I was not dismissing logic. I was clarifying that the intended
meaning of the work "assumption" in my post was not the same meaning
as the word has when discussing formal logic.

> I not only was making it sound like that, that's exactly what I was saying.
>  And it was *all* that I was saying.  I said this because, in fact, two
> people posted in favor of the changes and for no other reason than the
> proposed changes complied with how 'modern editors' worked. Please re-read
> my original post and you'll see I already said this.

What other people seem to understand is that when those other people
proposed that the changes be made because other editors have that
behavior, there was most likely an unstated assumption that the other
editors did so for a reason and that the suggestion was not merely one
of wanting to be part of the cool kids club.

Even if those particular people *were* just wanting to feel like they
were using an editor that "belonged", it would still be worth
considering the change *because* of the likelihood of there being a
reason other than being fashionable.

>>  2.  The argument about wanting to avoid changes because they are
>> "appeals to fashion" can be applied to wanting to make the change with
>> just as much weight. Keeping the behavior just because "that's the way
>> it is" is just as much of an "appeal to fashion", it's just appealing
>> to the fashion current in Emacs.
>
> Not at all.  You're obviously not aware of the quite important principle of
> UI development which counsels against throwing surprises at users.
>

That's a hefty assumption. If that was the only "quite important" UI
principle, this discussion would never happen. Furthermore, I wouldn't
suggest just surprising current users with the behavior. There's a
reason we have changelogs and help documents and announcement lists
and so on -- if it's decided that it's worth making a change despite
the possibility of it being surprising to current users, steps can be
taken to minimize the number of users that *are* surprised. Also, that
principle also applies to trying not to surprise *new* users, which
the behavior does for some.

>> The same flaw that is present in the whole of your argument is present
>> in that second point -- the arguments *for* keeping the behavior are
>> *not* as simple as "well that's just the way it is". The arguments
>> *against* keeping the behavior are also not just "but Mom, everyone is
>> wearing them!".
>
> Again, re-read my original post.  Don't try to put words or arguments in it
> that aren't there.  I didn't write what you quote above, nor did I even
> imply that.  So the "flaw" you're talking about is only in statements coming
> out of your imagination.

But you did state that the arguments for changing the behavior were
stated as being only because other editors had the behavior. You're
correct that they were *stated* that way, however that doesn't mean
that that's as far as the motivation for the change being something
worth considering goes, and it's not the spot to argue against making
the change from.

[ken]

Jeremiah, there's no need to CC emacs-delete-poll.

On 10/04/2011 04:19 PM Jeremiah Dodds wrote:
> On Tue, Oct 4, 2011 at 3:02 PM, ken <geb...@mousecar.com> wrote:
>> On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
>>> On Tue, Oct 4, 2011 at 7:44 AM, ken <geb...@mousecar.com> wrote:
>>
>> Dismissing logic, are we? I suspect this is the reason for the S/N here
>> approaching zero.
>>
>
> No, I was not dismissing logic. I was clarifying that the intended
> meaning of the work "assumption" in my post was not the same meaning
> as the word has when discussing formal logic.

Yet you believe those assumptions (which you've conveniently redacted
out) were based on logic.

"Formal logic", as you call it, is just regular logic made more rigorous.

>
>> I not only was making it sound like that, that's exactly what I was saying.
>> And it was *all* that I was saying. I said this because, in fact, two
>> people posted in favor of the changes and for no other reason than the
>> proposed changes complied with how 'modern editors' worked. Please re-read
>> my original post and you'll see I already said this.
>
> What other people seem to understand is that when those other people
> proposed that the changes be made because other editors have that
> behavior, there was most likely an unstated assumption that the other
> editors did so for a reason and that the suggestion was not merely one
> of wanting to be part of the cool kids club.

"there was most likely an unstated assumption..."?! So you're saying
that even though people didn't give another reason, you can imagine that
they had one.

>
> Even if those particular people *were* just wanting to feel like they
> were using an editor that "belonged", it would still be worth
> considering the change *because* of the likelihood of there being a
> reason other than being fashionable.

Again, you're imagining people had another reason, even though they
didn't give another reason.



>>> ....

>
>> Not at all. You're obviously not aware of the quite important principle of
>> UI development which counsels against throwing surprises at users.
>>
>

> .... that

> principle also applies to trying not to surprise *new* users, which
> the behavior does for some.

No it doesn't apply. When you start to use new software, you should
expect to have to learn it. It's not a surprise if you don't yet know
how to use it. Or do you think it's a surprise that you might have to
learn something?

>
>>> The same flaw that is present in the whole of your argument is present
>>> in that second point -- the arguments *for* keeping the behavior are
>>> *not* as simple as "well that's just the way it is". The arguments
>>> *against* keeping the behavior are also not just "but Mom, everyone is
>>> wearing them!".
>> Again, re-read my original post. Don't try to put words or arguments in it
>> that aren't there. I didn't write what you quote above, nor did I even
>> imply that. So the "flaw" you're talking about is only in statements coming
>> out of your imagination.
>
> But you did state that the arguments for changing the behavior were
> stated as being only because other editors had the behavior. You're
> correct that they were *stated* that way, however that doesn't mean
> that that's as far as the motivation for the change being something
> worth considering goes, and it's not the spot to argue against making
> the change from.

I've already said what I said, explained what I said, corrected you when
you imagined I said things I didn't actually say, and several times
referred you back to what I did say. You and I aren't married. I've
got a life outside this thread. And I'm sure there are other people
around you can argue with. Wish them good luck and blessings from me.

[Jai Dayal]

I love flame wars between pedantic programmers. 

[S Boucher]

----- Original Message -----

>( Again) Though some believe it makes more sense to bottom-post and/or respond

> interlinearly, most people using email top-post.  So we should all start doing
> what most people do.  :P

Is it just me that has the impression that you are being argumentative just for the sake of being argumentative?

Let me ask you: Leaving aside the technical merrits for a moment, if rms goes ahead with the change for the sake of being coherent with other applications and make it easier for the newbies, are you going to survive or are you going to give up Emacs?  How painful will the survival be?

> C-p - Print the file
>
> C-n - New file
>
> C-a - select All
>
> C-q - Quit
>
> These changes will make it easier for those new to emacs.  In that they are
> culturally biased towards those who speak English, there are good reasons for
> them.

Sigh! You like to be argumentative...

And we all know that Emacs is not the least bit biased towards English.

C-p - previous-line
C-n - next-line
C-y - yank
C-k - kill-line

Furthermore, if - and that's a big IF - the various letter choices (C-a, C-w, C-x, etc) had  anything to do with ergonomics, those without a qwerty keyboards might be getting a raw deal.

I'm a long time emacs user and love it, but it's not like every decision ever made in emacs is always right.  I recall having to use C-x@ to set mark (that's having to type C-x S-2) to set mark in some instances when I couldn't get C-<space> to work.  Non-working C-<space> was probably one of the most frequent issue brought up in gnu.emacs.help back then.

We should really put this to rest, but that's just my opinion...

[Jeremiah Dodds]

On Tue, Oct 4, 2011 at 4:42 PM, ken <geb...@mousecar.com> wrote:
>
> Yet you believe those assumptions (which you've conveniently redacted out)
> were based on logic.

They were based on inference, yes. I didn't quote them, as they
weren't relevant to what I was replying to. I can't go edit the post I
made, nor would I, anyone is free to look at the threads history to
see them if they'd like.

>>> I not only was making it sound like that, that's exactly what I was
>>> saying.
>>>  And it was *all* that I was saying.  I said this because, in fact, two
>>> people posted in favor of the changes and for no other reason than the
>>> proposed changes complied with how 'modern editors' worked. Please
>>> re-read
>>> my original post and you'll see I already said this.
>>
>> What other people seem to understand is that when those other people
>> proposed that the changes be made because other editors have that
>> behavior, there was most likely an unstated assumption that the other
>> editors did so for a reason and that the suggestion was not merely one
>> of wanting to be part of the cool kids club.
>
> "there was most likely an unstated assumption..."?!  So you're saying that
> even though people didn't give another reason, you can imagine that they had
> one.

Yes, this is very common, especially in non-rigorous discussions like
the one they're having.
I don't feel that it's an improbable discussion, and I would hope that
if it was blatantly incorrect that there would be a slew of people
saying that that's not what they intended. Humans can be bad at
expressing all the necessary assumptive building blocks to a
conclusion, but hopefully do care about clarity.

>> Even if those particular people *were* just wanting to feel like they
>> were using an editor that "belonged", it would still be worth
>> considering the change *because* of the likelihood of there being a
>> reason other than being fashionable.
>
> Again, you're imagining people had another reason, even though they didn't
> give another reason.

I am in fact assuming people have additional reasons, although
unstated. I do this for a few reasons:

1. It's very common.
2. As you pointed out, making changes *just* to be like other
software is a bit silly.
3. People often notice when many things do things similarly and feel
like there may be some merit to their methods.

>> .... that
>> principle also applies to trying not to surprise *new* users, which
>> the behavior does  for some.
>
> No it doesn't apply.  When you start to use new software, you should expect
> to have to learn it.  It's not a surprise if you don't yet know how to use
> it.  Or do you think it's a surprise that you might have to learn something?

I do not, and I agree that it doesn't apply when you start to use
*entirely new* software. I should clarify here -- if you're using your
first image editor, you should expect to have to learn many new
things. If you're using your tenth image editor, you will probably
have quite a bit of transferable knowledge from the first through
ninth that you learned. You should, of course, be fine with learning
new things, but it's not a one-sided argument. Software writers should
also be willing to make changes that are in line with behavior from
other software *in their category*, if there is merit to the behavior.

> You and I aren't married.

Could we be though? I think we'd make a great couple!

[Ludwig, Mark]

> From: Richard Stallman

> Subject: Poll about proposed change in DEL (aka Backspace) and Delete
>

> In Emacs 24, now in pretest, a change is being considered for ASCII
> DEL (on most keyboards, the Backspace key) and the Delete function
> key. The change affects the case of an active region that was not
> dragged with the mouse. The change is that these commands would
> delete the region, rather than just one character as now.
>
> In the past, this behavior was enabled in some minor modes: CUA mode,
> Delete Selection mode, and PC Selection mode. In the 24.0.90 pretest,
> this behavior is enabled by default. Thus, building and using the
> pretest is an easy way to try the change.
>
> Here are the questions we hope you will answer:
>
> * Are you in favor of this change?

Yes

> * Are you opposed to this change?

No

> * How strongly do you feel about the matter?
>

> We don't want to just "count votes" -- we want to understand
> how this affects users. So if you care about the issue,
> please tell us how the change affects your editing.

Moderately strongly. After working long enough in a "standard" Windows GUI, I know my fingers have made that gesture in Emacs and been disappointed that Emacs doesn't do it....

> * What are the cases where you find it helps?

Assuming "case" means use case, most of mine would be helped.

> * What are the cases where you find it hurts?

When I have been using Emacs exclusively for a long enough time, I start remembering the "Emacs way." (There's always Undo....)

> * What is your level of Emacs experience?

I started with EMACS at Cornell in 1980 on a DEC-20 (loved TECO).$$ I was without Emacs 1985-1990 (dark years). I picked up the current lineage at GNU Emacs 19.x ca. 1990 on a Sun-3 or -4? It used to be fun to build it from C and .el files....

I use it regularly for C programming, maintaining a software product. I have a file of Emacs Lisp functions I have written for processing text -- special cases for the software product source or output.

In the dark years, I went so far as to implement a very simple Emacs on top of LSU(?), a programmable editor on VAX/VMS (successor to EDT).

> A further change in the same area has been suggested: when there is an
> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>
> * What would you think of this further change?

I would like this too.

Thanks!

[Richard Stallman]

One objection from a hacker - I won't say who he is - complained
that it would require him to change his .emacs to disable the
menubar.  Understanding the stupidy of this argument is left as an
exercise.

If only one person objects to this change, then it would be comparable
to the change of enabling menus. If many object, that will be the
crucial difference.

The poll will tell us which one it is.

[notbob]

On 2011-09-30, Richard Stallman <r...@gnu.org> wrote:

> * Are you in favor of this change?

Absolutely not!

> * Are you opposed to this change?

Yes.

> * How strongly do you feel about the matter?

Very strongly. I grew up learning to touch type on a manual
typerwriter. The backspace key is as ingrained as the space bar.
Being no code squint, I've had a tough time learning emacs and don't
want to have to "relearn" it. What is this? Windows!?

> * What are the cases where you find it helps?

None whatsoever! I hate reaching for the mouse.

> * What are the cases where you find it hurts?

I may touchtype, but I make a lotta mistakes and the backspace key is
as important as the spacebar, for me.

> * What is your level of Emacs experience?

My primary file mgr and editor. I use it daily and am always
delighted to learn something new. My O'Reilly 1st ed emacs book is
never out of reach.

> * What would you think of this further change?

Hell, emacs is like my brain. I probably use less than 10% of it.
But, that doesn't mean I approve of change for the sake of change. If
ppl want some sorta area delete change, let 'em learn to code it in
themselves. Leave my emacs alone!

> Please send your responses to emacs-de...@gnu.org.

Done.

nb

--
vi ....the heart of evil!

[Rustom Mody]

On Wed, Oct 5, 2011 at 8:00 PM, Richard Stallman <r...@gnu.org> wrote:

   One objection from a hacker - I won't say who he is - complained
   that it would require him to change his .emacs to disable the
   menubar.  Understanding the stupidy of this argument is left as an
   exercise.

If only one person objects to this change, then it would be comparable
to the change of enabling menus.  If many object, that will be the
crucial difference.

The poll will tell us which one it is.

There is one clarification that will make the poll more helpful I feel:
If the change(s) are accepted and a user wants old behavior what is the customizations he would need to make?

[MBR]

Superficially, it sounds like he's just lazy.  But I often find myself in situations where I'm debugging a problem for a client and I'm on someone else's machine.  I can't take the time to edit in all my customizations into the client's account, and even if I could, he might not want me to.  So I have no choice but to just live with the default emacs configuration.  If the issue is whether or not menus are enabled, I can live with or without them.  But if the keystroke assignments have changed, my fingers are constantly tripping over each other, which is distracting enough that it makes it hard to concentrate on debugging the problem I'm there to fix in the first place.  So maybe the objection isn't quite as stupid as you're implying.

Mark Rosenthal
m...@arlsoft.com

On 10/4/2011 1:27 PM, S Boucher wrote:

----- Original Message -----

This is an invalid argument, --snip--

This reminds me of the time rms asked whether menus should be enabled by default.

One objection from a hacker - I won't say who he is - complained that it would require him to change his .emacs to disable the menubar.  Understanding the stupidy of this argument is left as an exercise.

Thankfully, rms did the right thing and the menus are on by defaults... and I disable them in my .emacs :-)

[S Boucher]

>
>  But if the keystroke assignments have changed, my fingers are constantly tripping over each other, which is distracting enough that it makes it hard to concentrate on debugging the problem I'm there to fix in the first place.

My configs are so big that no matter what, it's going to be a bit clumsy when I'm using emacs without all my own cruft.  Heck, there's the reverse scenario: someone I go help has his own cruft that makes emacs non-standard.

The key point is whether making it easier for non-hacker should take precedence over making it easier for hackers.  I think we should make it easier for non-hackers.  In the case of the menus, it therefore made more sense to leave them enabled.

When it comes down to a line or 2 in .emacs, I think the burden should rest on hackers.

In the case of the present proposed change, I wouldn't even offer the choice to have the old behavior to keep the code easier to maintain. Anyone will get over this after at most a day or 2 of !@#$!@$.  And then, you won't have a problem when you go help a friend.

Reminds me of years ago when someone changed all the keybindings of Emacs to match what he was used too on some other Emacs.  Just get used to what the is defined.  It's not the end of the world (at least in the case of the present proposal).  The odd times when a binding changes in Emacs, I just get used to it.

I don't mean to insult anyone, but there's a ridiculous amount of obtuseness displayed in this thread over changes which any reasonably intelligent person will get used to quickly, without adverse effect.  The amount of time spent arguing in this thread is more than it would take anyone to get used to the change.

It's not like we're talking about moving C-x to C-^.

[Thien-Thi Nguyen]

() "Ludwig, Mark" <ludwi...@siemens.com>
() Wed, 5 Oct 2011 01:04:29 +0000

In the dark years, I went so far as to implement a very simple Emacs on top of
LSU(?), a programmable editor on VAX/VMS (successor to EDT).

Probably you mean LSE ("Language-Sensitive Editor", high)
or TPU ("Text Processing Utility(ies)", low).

RIP DEC.

[Ken Goldman]

When I want to delete a large region, I typically use a mouse drag.
When I don't, I'm used to kill-region, which I bind to mouse-3 a la
Unix practice.

So:

- I'm slightly opposed to the change.

- I don't feel strongly about it.

- Experience? I've been using emacs since before you were born (i.e., a
long time)

[Marko Vojinovic]

On Thursday 06 October 2011 20:15:05 Ken Goldman wrote:
> On 9/29/2011 11:42 PM, Richard Stallman wrote:
> > In Emacs 24, now in pretest, a change is being considered for

[snip]

> - Experience? I've been using emacs since before you were born (i.e., a
> long time)

Now *this* is what I call a hyperbola! LOL :-D

Best, :-)
Marko

P.S. Sorry for the noise folks, just couldn't resist... ;-)

[David Kastrup]

Marko Vojinovic <vvm...@gmail.com> writes:

> On Thursday 06 October 2011 20:15:05 Ken Goldman wrote:
>> On 9/29/2011 11:42 PM, Richard Stallman wrote:
>> > In Emacs 24, now in pretest, a change is being considered for
> [snip]
>> - Experience? I've been using emacs since before you were born (i.e., a
>> long time)
>
> Now *this* is what I call a hyperbola! LOL :-D

When uttered in reply to Richard Stallman, it would appear leaning a bit
strongly towards assertiveness.

--
David Kastrup

[stan]

Richard Riley wrote:
> ken <geb...@mousecar.com> writes:

<snip>

>> Secondly, there are places in the world where people haven't ever used
>> Windows;
>
> Yes, but in the real world... Most people have and do. and emacs runs on
> Windows. This isnt a Linux v Windows fanoi bun fight ;)

I seem to be hearing words from my past: "If everyone else jumped off
a cliff would you?"

Windows fashion and popularity aren't interesting or compelling
reasons to change.

>> instead, their first and only experience with computers is with Linux. What
>> sense can it make to them that emacs' behavior is changed simply to mimic some
>> other editor they've never seen or used?
>
> emacs is not "Linux". Gnu/Linux has desktop editors which all share
> trends virtually identically to how the Windows equivalents do in the
> massive majority of cases.

If alternatives already exist, why complain about emacs?

>> I think that over the long term it will trend upwards that more people's first
>> and only computer experience will be with FOSS. So thinking ahead to those
>> times, why should we alter the default behavior of Emacs to conform to a legacy
>> editor?
>
> Modern FOSS editors invariably conform to common desktop UI paradigms
> and key strokes. Not that I advocate changing core keys necessarily.

Seems like you are referring to the competing desktops (KDE vs Gnome)
here and these are clearly targeted at people who want a MS Windows
like experience. Different audience with different needs and wants.

>> Fourth, if we apply your argument to every difference between Emacs and (e.g.)
>> Word, then we end up with Emacs behaving just like Word, and there being no
>> difference between Emacs and Word. Then we might as well just use
>> Word. :/
>
> But no one is suggesting Emacs is made into Word. Total Strawman.

And the paragraph never says anyone suggested that. This is reducto ad
absurdum reasoning. The application is correct and valid.

>> Fifth, if we change emacs to comport with Word, and if in future Word changes
>> the way it handles highlighted text to way emacs does now, should emacs then
>> change back again, just to (again) follow the way Word works?
>
> Strawman now taken to far, far extremes...

How would you handle changes? What it windows changes the core
interface, as the move towards touch screens marches on, to put the
current keystrokes into some software ghetto. Would a changed emacs
follow the new fashion or stick with the current fashion?

In other words, is the suggestion to make emacs a slave to fashion or
simply to make it match the current fashion and people will be happy
(and quiet) forevermore?

> Word is not an "editor" in the context of this thread. Its a wysiwig
> word processor. And that said, certain wysiwig elements in emacs are VERY
> popular. See LaTeX support for a start.

OK, forget Word and substitute wordpad or notepad; a difference
without a distinction as far as editing keystrokes are concerned.

>> Finally, as said at the top, the argument to follow "other modern editors" is
>> nothing more than an appeal to fashion. And fashion is very
>> subjective and
>
> No it isnt. Its to follow and conform to other apps many people use and
> have developed over many years too and conform to modern desktop standards.

By now one would think that even a casual observer would know that the
developers have no interest in this change. The possibilities seem to
be for the "modern editor" proponents to take up the task or at least
find "modern arguments" that haven't been beaten to death.

> You dont think emacs sharing certain features with much more popular
> editors might be a good idea and makes sense?

No. I also don't think it would really help much. Emacs is a different
tool in fundamental ways and putting a facade would simply postpone
the learning curve.

[stan]

Jeremiah Dodds wrote:
> On Tue, Oct 4, 2011 at 4:42 PM, ken <geb...@mousecar.com> wrote:

<snip>

>>> proposed that the changes be made because other editors have that
>>> behavior, there was most likely an unstated assumption that the other
>>> editors did so for a reason and that the suggestion was not merely one
>>> of wanting to be part of the cool kids club.
>>
>> "there was most likely an unstated assumption..."?! �So you're saying that
>> even though people didn't give another reason, you can imagine that they had
>> one.
>
> Yes, this is very common, especially in non-rigorous discussions like
> the one they're having.
> I don't feel that it's an improbable discussion, and I would hope that
> if it was blatantly incorrect that there would be a slew of people
> saying that that's not what they intended. Humans can be bad at
> expressing all the necessary assumptive building blocks to a
> conclusion, but hopefully do care about clarity.

In a rational discussion, it's generally hard to respond to what
people might or might not be thinking. If I understand you correctly,
you're saying people have valid reasons to change but they won't
reveal them? That's not really a discussion "rigorous" or "non-rigorous".

>>> Even if those particular people *were* just wanting to feel like they
>>> were using an editor that "belonged", it would still be worth
>>> considering the change *because* of the likelihood of there being a
>>> reason other than being fashionable.
>>
>> Again, you're imagining people had another reason, even though they didn't
>> give another reason.
>
> I am in fact assuming people have additional reasons, although
> unstated. I do this for a few reasons:
>
> 1. It's very common.
> 2. As you pointed out, making changes *just* to be like other
> software is a bit silly.
> 3. People often notice when many things do things similarly and feel
> like there may be some merit to their methods.

Why not cut to the chase? What are those other reasons?

[John Bokma]

stan <smo...@exis.net> writes:

> Seems like you are referring to the competing desktops (KDE vs Gnome)
> here and these are clearly targeted at people who want a MS Windows
> like experience.

Nope. Why do you think so?

--
John Bokma j3b

Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html

[rusi]

On Oct 12, 2:56 am, stan <smo...@exis.net> wrote:
> Windows fashion and popularity aren't interesting or compelling
> reasons to change.
>

> Seems like you are referring to the competing desktops (KDE vs Gnome)
> here and these are clearly targeted at people who want a MS Windows
> like experience. Different audience with different needs and wants.

The editors mentioned were Geany, Kate, Gedit, Nedit. Which copies
Microsoft?

>
> How would you handle changes? What it windows changes the core
> interface, as the move towards touch screens marches on, to put the
> current keystrokes into some software ghetto. Would a changed emacs
> follow the new fashion or stick with the current fashion?

>

> OK, forget Word and substitute wordpad or notepad; a difference
> without a distinction as far as editing keystrokes are concerned.

> By now one would think that even a casual observer would know that the
> developers have no interest in this change. The possibilities seem to
> be for the "modern editor" proponents to take up the task or at least
> find "modern arguments" that haven't been beaten to death.

See for example: http://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg01145.html
Are orgmode fans also MS fans?

[Steinar Bang]

>>>>> Richard Stallman <r...@gnu.org>:

> * Are you in favor of this change?

No.

> * Are you opposed to this change?

Yes.

> * How strongly do you feel about the matter?

Not very strongly. I'll learn to live with it, whatever it ends up as.

[semperos]

Richard Stallman <rms <at> gnu.org> writes:

>
> In Emacs 24, now in pretest, a change is being considered for ASCII
> DEL (on most keyboards, the Backspace key) and the Delete function
> key. The change affects the case of an active region that was not
> dragged with the mouse. The change is that these commands would
> delete the region, rather than just one character as now.
>

> In the past, this behavior was enabled in some minor modes: CUA mode,
> Delete Selection mode, and PC Selection mode. In the 24.0.90 pretest,
> this behavior is enabled by default. Thus, building and using the
> pretest is an easy way to try the change.
>
> Here are the questions we hope you will answer:
>

> * Are you in favor of this change?
>

> * Are you opposed to this change?
>

> * How strongly do you feel about the matter?
>

> We don't want to just "count votes" -- we want to understand
> how this affects users. So if you care about the issue,
> please tell us how the change affects your editing.
>

> * What are the cases where you find it helps?
>

> * What are the cases where you find it hurts?
>

> * What is your level of Emacs experience?
>

> A further change in the same area has been suggested: when there is an
> active region, a self-inserting character would delete the region
> before the character is inserted by default.
>

> * What would you think of this further change?
>

> Please send your responses to emacs-delete-poll <at> gnu.org.
>

I've been using Emacs seriously for about a year and a half. I am in favor of
both proposed changes, that (1) a selected region can be deleted by pressing
the del/backspace key and (2) if a region is selected, typing a new character
first deletes the selected region and then inserts a character.

In my opinion, this is the only intuitive behavior under these circumstances;
I struggle to think of an alternative behavior that makes more sense. I still
occasionally highlight a region, re-think, then press delete or type new
characters, forgetting that Emacs does not behave like this currently in 23.

-Daniel

[Jorgen Grahn]

On Sun, 2011-11-13, semperos wrote:
> Richard Stallman <rms <at> gnu.org> writes:

...

>> Please send your responses to emacs-delete-poll <at> gnu.org.
>>
>
> I've been using Emacs seriously for about a year and a half. I am in favor of
> both proposed changes, that (1) a selected region can be deleted by pressing
> the del/backspace key and (2) if a region is selected, typing a new character
> first deletes the selected region and then inserts a character.
>
> In my opinion, this is the only intuitive behavior under these circumstances;
> I struggle to think of an alternative behavior that makes more sense.

The alternative is to treat the selection as irrelevant to the
insertion or deletion, like we do today. Not un-intuitive, but not
like the Apple Macintosh either.

> I still
> occasionally highlight a region, re-think, then press delete or type new
> characters, forgetting that Emacs does not behave like this currently in 23.

I don't mind the change so much, because I expect there'll be a way to
turn it off. I might even use it, but that depends on how often I
create a selection without any intention of using it -- e.g. doing
exchange-point-and-mark (C-x C-x) just as a way to jump around.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .