Emacs pretest 24.0.90

Emacs pretest 24.0.90

[Chong Yidong]

Emacs pretest 24.0.90 is now available for download via FTP, at the
following location:

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz

This is the first pretest for what will become Emacs 24.1.
See etc/NEWS for a list of changes since Emacs 23.3.

Please send me an email reporting success or failure on your build
platform.  Please report any bugs that you come across via
M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
For questions, email emacs-devel@gnu.org.

Thank you for helping to test Emacs.


Note: this email is also sent via BCC to the list of Emacs pretesters.
If you are not subscribed to the emacs-devel mailing list, and would
like to receive these emails about Emacs pretests, send me an email and
I will add you to the list.

Re: Emacs pretest 24.0.90

[Leo]

On 2011-09-26 11:57 +0800, Chong Yidong wrote:
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.

Thank you for all the hard work to bring this about ;)

Leo

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 25 Sep 2011 23:57:41 -0400
> 
> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
> 
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz

This doesn't build on MS-Windows because the file lib/makefile.w32-in
is missing from the tarball.

After adding that file (from the bzr tree) and rerunning
nt/configure.bat, the build proceeds as expected, and the resulting
binary seems to work fine.

Thanks!

Re: Emacs pretest 24.0.90

[Glenn Morris]

Eli Zaretskii wrote:

> This doesn't build on MS-Windows because the file lib/makefile.w32-in
> is missing from the tarball.

Now added to make-dist.

Re: Emacs pretest 24.0.90

[Neal Becker]

Chong Yidong wrote:

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
> 
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
> 
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.
> 

Can we post etc/NEWS somewhere so we can see it without d/l all of emacs24.1?

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Neal Becker <ndbecker2@gmail.com>
> Date: Mon, 26 Sep 2011 07:12:17 -0400
> 
> Can we post etc/NEWS somewhere so we can see it without d/l all of emacs24.1?

You can see it here:

   http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/etc/NEWS

Re: Emacs pretest 24.0.90

[Lars Magne Ingebrigtsen]

By the way, do we have any schedule for when 24.1 is going to be
released?  I mean, we obviously don't have any firm deadline, but what
are we aiming for?  Early 2012 or something?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs pretest 24.0.90

[Bastien]

Chong Yidong <cyd@stupidchicken.com> writes:

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
>
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.

Yes, kudos for the hard work!

-- 
 Bastien

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 26 Sep 2011 18:53:43 +0200
> 
> By the way, do we have any schedule for when 24.1 is going to be
> released?  I mean, we obviously don't have any firm deadline, but what
> are we aiming for?  Early 2012 or something?

See

   http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html

Re: Emacs pretest 24.0.90

[Rasmus]

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:

Thank you. 

> Thank you for helping to test Emacs.

Thanks to everyone contributing to GNU Emacs.

-- 
Sent from my Emacs

Re: Emacs pretest 24.0.90

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> See
>
>    http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html

But that was in May.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs pretest 24.0.90

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> On 2011-09-26 11:57 +0800, Chong Yidong wrote:
>> This is the first pretest for what will become Emacs 24.1.
>> See etc/NEWS for a list of changes since Emacs 23.3.
>
> Thank you for all the hard work to bring this about ;)

It would be more appropriate to thank the Emacs development team as a
whole.  Of course, the work to get to 24.1 is just begun...

Re: Emacs pretest 24.0.90

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> See
>>
>>    http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html
>
> But that was in May.  :-)

FWIW, the pretest for 23.1 took six months, but IIRC that had a longer
development period prior to the pretest.  We'll see.

draft for DEL key poll

[Richard Stallman]

I'm planning the poll about DEL.  Here is a draft for comments.  (I
will also write a poll about completion.)



In Emacs 24, now in pretest, a change is being considered for DEL
(often the Backspace key) and the Delete function key.  When there is
an active region, they would delete the region instead of just one
character.  This is enabled by default in the current pretest, so
building and using the pretest is a way to test it.

Are you in favor of 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 helpful?

What are the cases where you find it inconvenient?

How would you describe your level of Emacs experience?

Please send your responses to emacs-delete-poll@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/

Re: draft for DEL key poll

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>I'm planning the poll about DEL.  Here is a draft for comments.  (I
>will also write a poll about completion.)
>
>In Emacs 24, now in pretest, a change is being considered for DEL
>(often the Backspace key) and the Delete function key.  When there is
>an active region, they would delete the region instead of just one
>character.  This is enabled by default in the current pretest, so
>building and using the pretest is a way to test it.
>
>Are you in favor of 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 helpful?
>
>What are the cases where you find it inconvenient?
>
>How would you describe your level of Emacs experience?
>
>Please send your responses to emacs-delete-poll@gnu.org.

It would be great to have some elisp I could evaluate to test this
change before I vote in a poll about it.

-K

Re: draft for DEL key poll

[Kim F. Storm]

Karl Fogel <kfogel@red-bean.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>>I'm planning the poll about DEL.  Here is a draft for comments.  (I
>>will also write a poll about completion.)
>>
>>In Emacs 24, now in pretest, a change is being considered for DEL
>>(often the Backspace key) and the Delete function key.  When there is
>>an active region, they would delete the region instead of just one
>>character.  This is enabled by default in the current pretest, so
>>building and using the pretest is a way to test it.

>
> It would be great to have some elisp I could evaluate to test this
> change before I vote in a poll about it.

Actually, if you use cua-mode, DEL and BS have always behaved like this!
Maybe this fact should be mentioned in the poll, so users of cua-mode
are not confused when trying to determine what's changed (since nothing
changed).

I guess cua-mode need some testing under 24.1 in this respect
(in particular, cua-mode saves the deleted text in register "0",
which I strongly prefer to messing with the kill-ring).

-- 
Kim F. Storm  http://www.cua.dk

disable delete-selection-mode? (was: Re: draft for DEL key poll)

[chad]

I had a question about the poll wording (should it mention
deactivating the region?), but I wanted to check the behavior without
delete-selection-mode, to verify that my memory of the old default was
correct.  Running emacs -q from this morning's bzr HEAD, I can't find
a way to turn off the new behavior; an active region is deleted
regardless of delete-selection-mode.  This isn't the behavior I see with
my os-default emacs 22.1 install. What am I missing?

Thanks,
*Chad

On Sep 26, 2011, at 2:12 PM, Richard Stallman wrote:

> I'm planning the poll about DEL.  Here is a draft for comments.  (I
> will also write a poll about completion.)

Re: Emacs pretest 24.0.90

[Ota, Takaaki]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

Build fails under mingw environment.  Attached is the log from "make
bootstrap".

-Tak

Sun, 25 Sep 2011 20:57:41 -0700: Chong Yidong <cyd@stupidchicken.com> wrote:

> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
> 
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
> 
> This is the first pretest for what will become Emacs 24.1.
> See etc/NEWS for a list of changes since Emacs 23.3.
> 
> Please send me an email reporting success or failure on your build
> platform.  Please report any bugs that you come across via
> M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
> For questions, email emacs-devel@gnu.org.
> 
> Thank you for helping to test Emacs.
> 
> 
> Note: this email is also sent via BCC to the list of Emacs pretesters.
> If you are not subscribed to the emacs-devel mailing list, and would
> like to receive these emails about Emacs pretests, send me an email and
> I will add you to the list.
> 

[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 4765 bytes --]

[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include  -o oo-spd/i386/addsection.o addsection.c
gcc -o oo-spd/i386/addsection.exe \
		   -gdwarf-2 -g3  -mno-cygwin -Lc:/d/pub/emacs/lib oo-spd/i386/addsection.o   -luser32
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include  -o oo-spd/i386/cmdproxy.o cmdproxy.c
gcc -o oo-spd/i386/cmdproxy.exe \
		   -gdwarf-2 -g3  -mno-cygwin -Lc:/d/pub/emacs/lib oo-spd/i386/cmdproxy.o   -luser32
make   -C ../lisp bootstrap-clean
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
rm /c/d/pub/emacs/emacs-24.0.90/lisp/loaddefs.el
make -w bootstrap-clean-SH
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[2]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
for dir in . calc calendar emacs-lisp emulation erc eshell gnus international language mail mh-e net nxml org play progmodes textmodes url vc cedet cedet/ede cedet/semantic cedet/srecode cedet/semantic/analyze cedet/semantic/bovine cedet/semantic/decorate cedet/semantic/symref cedet/semantic/wisent term obsolete; do rm -f $dir/*.elc $dir/*/*.elc $dir/*/*/*.elc; done
make[2]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lisp'
make   -C ../src clean
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/src'
rm "s/*.h~" "m/*.h~"
rm: cannot lstat `s/*.h~': No such file or directory
rm: cannot lstat `m/*.h~': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm 
rm: missing operand
Try `rm --help' for more information.
make[1]: [clean] Error 1 (ignored)
rm -r oo-spd
rm: cannot lstat `oo-spd': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm stamp_BLD gl-stamp globals.h
rm: cannot lstat `stamp_BLD': No such file or directory
rm: cannot lstat `gl-stamp': No such file or directory
rm: cannot lstat `globals.h': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm buildobj.h
rm: cannot lstat `buildobj.h': No such file or directory
make[1]: [clean] Error 1 (ignored)
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/src'
make   -C ../lib-src clean make-docfile
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib-src'
rm DOC* 
rm: cannot lstat `DOC*': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm ctags.c
rm: cannot lstat `ctags.c': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm -r oo-spd
rm: cannot lstat `oo-spd': No such file or directory
make[1]: [clean] Error 1 (ignored)
rm stamp_BLD
rm: cannot lstat `stamp_BLD': No such file or directory
make[1]: [clean] Error 1 (ignored)
mkdir "oo-spd"
mkdir "oo-spd/i386"
echo oo-spd/i386 > stamp_BLD
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include -DWINDOWSNT -DDOS_NT -DNO_LDAV=1 -DNO_ARCHIVES=1 -DHAVE_CONFIG_H=1 -I../lib -I../nt/inc -I../src -o oo-spd/i386/make-docfile.o make-docfile.c
gcc -I. -c -gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2     -Ic:/d/pub/emacs/include -DWINDOWSNT -DDOS_NT -DNO_LDAV=1 -DNO_ARCHIVES=1 -DHAVE_CONFIG_H=1 -I../lib -I../nt/inc -I../src -o oo-spd/i386/ntlib.o ntlib.c
gcc -o oo-spd/i386/make-docfile.exe  -gdwarf-2 -g3  -mno-cygwin -Lc:/d/pub/emacs/lib oo-spd/i386/make-docfile.o oo-spd/i386/ntlib.o   -ladvapi32
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lib-src'
make   -C ../lib clean all
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib'
make[1]: *** No rule to make target `clean'.  Stop.
make[1]: Leaving directory `/c/d/pub/emacs/emacs-24.0.90/lib'
make: *** [bootstrap-gmake] Error 2

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Mon, Sep 26, 2011 at 09:43, Eli Zaretskii <eliz@gnu.org> wrote:

> After adding that file (from the bzr tree) and rerunning
> nt/configure.bat, the build proceeds as expected, and the resulting
> binary seems to work fine.

Same here. It both builds and bootstraps OK on a Windows 7 Home
Premium, using gcc (GCC) 3.4.5 (mingw-vista special r3).

    Juanma

Re: disable delete-selection-mode?

[Glenn Morris]

chad wrote:

> I had a question about the poll wording (should it mention
> deactivating the region?), but I wanted to check the behavior without
> delete-selection-mode, to verify that my memory of the old default was
> correct.  Running emacs -q from this morning's bzr HEAD, I can't find
> a way to turn off the new behavior; an active region is deleted
> regardless of delete-selection-mode.  This isn't the behavior I see with
> my os-default emacs 22.1 install. What am I missing?

The NEWS file (it's delete-active-region).

Re: Emacs pretest 24.0.90

[Leo]

On 2011-09-27 02:43 +0800, Chong Yidong wrote:
> It would be more appropriate to thank the Emacs development team as a
> whole.  Of course, the work to get to 24.1 is just begun...

That is what I meant.

Leo

Re: Emacs pretest 24.0.90

[Glenn Morris]

"Ota, Takaaki" wrote:

>> Please send me an email reporting success or failure on your build
>> platform.  Please report any bugs that you come across via
>> M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
[...]
> make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib'
> make[1]: *** No rule to make target `clean'.  Stop.

http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00617.html

Re: draft for DEL key poll

[Juri Linkov]

> I'm planning the poll about DEL.  Here is a draft for comments.

Please include also a related important question:

When there is an active region, a self-inserting character
should delete the region before the character is inserted
by default?

Re: Emacs pretest 24.0.90

[Ota, Takaaki]

Thanks for responding to the old news.  It indeed builds now after
adding lib/makefile.w32-in.

-Tak

Mon, 26 Sep 2011 16:58:32 -0700: Glenn Morris <rgm@gnu.org> wrote:

> "Ota, Takaaki" wrote:
> 
> >> Please send me an email reporting success or failure on your build
> >> platform.  Please report any bugs that you come across via
> >> M-x report-emacs-bugs, or email bug-gnu-emacs@gnu.org.
> [...]
> > make[1]: Entering directory `/c/d/pub/emacs/emacs-24.0.90/lib'
> > make[1]: *** No rule to make target `clean'.  Stop.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00617.html
> 

Re: draft for DEL key poll

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> In Emacs 24, now in pretest, a change is being considered for DEL
> (often the Backspace key) and the Delete function key.  When there is
> an active region, they would delete the region instead of just one
> character.  This is enabled by default in the current pretest, so
> building and using the pretest is a way to test it.

This description fails to explain the underlying logic behind the
change.

If an active region is made with the mouse, and with shift-selection,
the DEL key deletes it.  This behavior is non-negotiable as a default,
as it is the standard behavior of graphical applications on modern GUI
platforms and there is no good reason for Emacs to violate it.

Some Emacs commands perform a certain operation on the region when it is
active.  In general, this "act on region" behavior does not draw a
distinction between a region made with the mouse (or shift-selection)
and a region made "normally" (e.g. by C-SPC followed by point motion).
In previous Emacs releases, a special exception was made for the DEL and
delete keys.  This exception has now been dropped.

Anyone who argues that DEL ought not to delete a "normal" active region
should provide a convincing explanation of why DEL should be treated
differently from other Emacs commands that act on active regions.

Re: draft for DEL key poll

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> (I will also write a poll about completion.)

Such a poll will not be useful.  While tweaks that can be made to the
behavior of the partial completion methods, such as making it treat
hidden buffers better (Bug#9598), such tweaks hardly require a poll.

As for the outright removal of partial completion, I disagree with such
a change; since its introduction in Emacs 23, it has proven to be a
useful feature that does the right thing in almost all circumstances.
It's easy for those who disagree with this feature to disable it.

Re: draft for DEL key poll

[Stefan Reichör]

no-spam@cua.dk (Kim F. Storm) writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>>I'm planning the poll about DEL.  Here is a draft for comments.  (I
>>>will also write a poll about completion.)
>>>
>>>In Emacs 24, now in pretest, a change is being considered for DEL
>>>(often the Backspace key) and the Delete function key.  When there is
>>>an active region, they would delete the region instead of just one
>>>character.  This is enabled by default in the current pretest, so
>>>building and using the pretest is a way to test it.
>
>>
>> It would be great to have some elisp I could evaluate to test this
>> change before I vote in a poll about it.
>
> Actually, if you use cua-mode, DEL and BS have always behaved like this!
> Maybe this fact should be mentioned in the poll, so users of cua-mode
> are not confused when trying to determine what's changed (since nothing
> changed).
>
> I guess cua-mode need some testing under 24.1 in this respect
> (in particular, cua-mode saves the deleted text in register "0",
> which I strongly prefer to messing with the kill-ring).

When using cua rectangle mode (start with C-RET), DEL does not delete the selection.
It just deletes one character and disables the selection.
This is often annoying. Is this a bug or a design feature?

I consider it a bug.


Stefan.

Re: draft for DEL key poll

[Richard Stallman]

    It would be great to have some elisp I could evaluate to test this
    change before I vote in a poll about it.

You can test it by building the pretest.  Maybe someone could extract
a patch to test it, but testing it that way would require more
knowledge than building a pretest, so it might not help much.

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

Re: draft for DEL key poll

[Richard Stallman]

    Actually, if you use cua-mode, DEL and BS have always behaved like this!

CUA mode changes a lot more too, right?
We should avoid giving the idea that enabling CUA mode is
a way to try this out.

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

Re: disable delete-selection-mode? (was: Re: draft for DEL key poll)

[Richard Stallman]

    I had a question about the poll wording (should it mention
    deactivating the region?),

Would you please state your question at greater length?
I can't understand it from that.

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

Re: draft for DEL key poll

[Richard Stallman]

    When there is an active region, a self-inserting character
    should delete the region before the character is inserted
    by default?

Ok, I will ask about this other change too.

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

Re: draft for DEL key poll

[Richard Stallman]

    This description fails to explain the underlying logic behind the
    change.

It is not needed.  The purpose of the poll is to ask people like or
dislike, and why.  It isn't supposed to argue in favor of the feature.

    Anyone who argues that DEL ought not to delete a "normal" active region
    should provide a convincing explanation of why DEL should be treated
    differently from other Emacs commands that act on active regions.

DEL is a basic and frequent command, so it should make distinctions as
is convenient for users, including special cases when that's what's
convenient.  Uniformity is not the priority for commands such as this.

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

Re: draft for DEL key poll

[Richard Stallman]

    As for the outright removal of partial completion, I disagree with such
    a change; since its introduction in Emacs 23, it has proven to be a
    useful feature that does the right thing in almost all circumstances.
    It's easy for those who disagree with this feature to disable it.

Let's see what the users think of this change.

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

Re: draft for DEL key poll

[James Cloos]

>>>>> "CY" == Chong Yidong <cyd@stupidchicken.com> writes:

CY> Some Emacs commands perform a certain operation on the region when
CY> it is active.  In general, this "act on region" behavior does not
CY> draw a distinction between a region made with the mouse (or
CY> shift-selection) and a region made "normally" (e.g. by C-SPC
CY> followed by point motion).  In previous Emacs releases, a special
CY> exception was made for the DEL and delete keys.  This exception has
CY> now been dropped.

(It has been long enough since region highlighting arrived that
I've forgotten what setting I used to require a double-tap to create
highlighted regions.  And grep(1)ing my custom file didn't "highlight"
the amswer.  (Sorry for the pun.))

Is is the case that active region == highlighted region?

Ie, if emacs is configured such that C-SPC must be hit twice to
highlight the region, does that imply that when a region is not
highlighted that DEL will not delete it?

Allowing DEL to delete or seft-insert to replace a highlighted region
is one thing.  Allowing them to delete a non-highlighted region, OTOH,
is -- or should be -- a non-starter.

And I still think that regions so deleted should be on the kill-ring.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: draft for DEL key poll

[Alan Mackenzie]

On Mon, Sep 26, 2011 at 08:52:20PM -0400, Chong Yidong wrote:
> Richard Stallman <rms@gnu.org> writes:

> > In Emacs 24, now in pretest, a change is being considered for DEL
> > (often the Backspace key) and the Delete function key.  When there is
> > an active region, they would delete the region instead of just one
> > character.  This is enabled by default in the current pretest, so
> > building and using the pretest is a way to test it.

> This description fails to explain the underlying logic behind the
> change.

> If an active region is made with the mouse, and with shift-selection,
> the DEL key deletes it.  This behavior is non-negotiable as a default,
> as it is the standard behavior of graphical applications on modern GUI
> platforms and there is no good reason for Emacs to violate it.

There are several good reasons, otherwise Richard wouldn't be initiating
a poll about it.

I sincerely hope we won't be introducing too many more behaviours which
are "standard" in modern GUIs.

> Some Emacs commands perform a certain operation on the region when it is
> active.  In general, this "act on region" behavior does not draw a
> distinction between a region made with the mouse (or shift-selection)
> and a region made "normally" (e.g. by C-SPC followed by point motion).
> In previous Emacs releases, a special exception was made for the DEL and
> delete keys.  This exception has now been dropped.

I cannot let you get away with this epistemological conflation.  These
other commands do not act _ON_ the region.  They act _IN_ the region.
I.e., they do their normal thing in a portion of the buffer.  You've
utterly changed the meaning of `delete-character-forward', making it act
ON a region rather than on a character.  The behaviour of DEL and delete
was not previously an exception - they did their normal thing at the
boundary of the region.

> Anyone who argues that DEL ought not to delete a "normal" active region
> should provide a convincing explanation of why DEL should be treated
> differently from other Emacs commands that act on active regions.

See above.  DEL should keep its normal meaning in the presence of a
region, just like most other commands do.

As a matter of interest, in the proposed default configuration, how does
one delete a single character at a boundary of an "active" region?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: draft for DEL key poll

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

> I sincerely hope we won't be introducing too many more behaviours
> which are "standard" in modern GUIs.

Yes, I hope we incorporate (or invent) only behaviors that make sense
and improve editing.  And in this concrete case (or, say, comment-dwim,
M-;), I actually like this special behavior.

> > Some Emacs commands perform a certain operation on the region when
> > it is active.  In general, this "act on region" behavior does not
> > draw a distinction between a region made with the mouse (or
> > shift-selection) and a region made "normally" (e.g. by C-SPC
> > followed by point motion).  In previous Emacs releases, a special
> > exception was made for the DEL and delete keys.  This exception has
> > now been dropped.
>
> I cannot let you get away with this epistemological conflation.  These
> other commands do not act _ON_ the region.  They act _IN_ the region.
> delete was not previously an exception - they did their normal thing
> at the boundary of the region.

Well, there's no way to be *not* at the boundary of the region, right?
So there couldn't be any special behavior if at the region boundaries
any command had to act "normally."

> As a matter of interest, in the proposed default configuration, how
> does one delete a single character at a boundary of an "active"
> region?

I deactivate the region (C-g), delete the character (DEL), and
reactivate the region with `C-x C-x'.  But this situation occurs (for
me) much less frequently than the situation where I want to delete the
complete active region, so I'm happy that I can now simply hit DEL
instead of C-w.

Bye,
Tassilo

Re: draft for DEL key poll

[Lennart Borgman]

On Wed, Sep 28, 2011 at 10:26, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Alan Mackenzie <acm@muc.de> writes:
>
> Hi Alan,
>
>> I sincerely hope we won't be introducing too many more behaviours
>> which are "standard" in modern GUIs.
>
> Yes, I hope we incorporate (or invent) only behaviors that make sense
> and improve editing.  And in this concrete case (or, say, comment-dwim,
> M-;), I actually like this special behavior.

So we are into this discussion again. ;-)

Please remember that for most newcommers the standard behaviour is
what makes sense. Whatever you yourself think about that.

Re: draft for DEL key poll

[chad]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]


On Sep 28, 2011, at 12:54 AM, Alan Mackenzie wrote:
> 
> As a matter of interest, in the proposed default configuration, how does
> one delete a single character at a boundary of an "active" region?

If ou want to act on a single character, why did you activate the region?  
(assuming that the region isn't that single character, of course).

*Chad


[-- Attachment #2: Type: text/html, Size: 683 bytes --]

Re: draft for DEL key poll

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Actually, if you use cua-mode, DEL and BS have always behaved like this!
>
> CUA mode changes a lot more too, right?
Right.

> We should avoid giving the idea that enabling CUA mode is
> a way to try this out.

I didn't suggest that - but since users of cua-mode are already
accustomed to the proposed new behaviour, maybe you could note that
cua-mode users should ignore the poll, as they are not affected by the
change.

-- 
Kim F. Storm  http://www.cua.dk

Re: draft for DEL key poll

[Stefan Monnier]

> I didn't suggest that - but since users of cua-mode are already
> accustomed to the proposed new behaviour, maybe you could note that
> cua-mode users should ignore the poll, as they are not affected by the
> change.

We could mention that this change makes standard a subset of the
behavior provided by delete-selection-mode, pc-selection-mode, and
cua-mode, indeed.


        Stefan

Re: draft for DEL key poll

[Richard Stallman]

    If ou want to act on a single character, why did you activate the region?  

Perhaps because you wanted to go to the other side of it with C-x C-x,
is the usual reason in my case.

Another reason is, you want to do something to the region, so you mark
it, but then you decide to first insert some text at the end of it.


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

Re: draft for DEL key poll

[chad]

On Sep 29, 2011, at 3:49 AM, Richard Stallman wrote:

>    If ou want to act on a single character, why did you activate the region?  
> 
> Perhaps because you wanted to go to the other side of it with C-x C-x,
> is the usual reason in my case.
> 
> Another reason is, you want to do something to the region, so you mark
> it, but then you decide to first insert some text at the end of it.

So, only in situations where you explicitly don't want to activate the region?
Does it often happen that you change your mind about activating the 
region? The C-x C-x case happens to me also, but rarely, and I find that
`C-x C-x C-x C-x' is comfortable enough in those cases.

*Chad

Re: draft for DEL key poll

[Andrew W. Nosenko]

On Thu, Sep 29, 2011 at 20:56, chad <yandros@mit.edu> wrote:
>
> On Sep 29, 2011, at 3:49 AM, Richard Stallman wrote:
>
>>    If ou want to act on a single character, why did you activate the region?
>>
>> Perhaps because you wanted to go to the other side of it with C-x C-x,
>> is the usual reason in my case.
>>
>> Another reason is, you want to do something to the region, so you mark
>> it, but then you decide to first insert some text at the end of it.
>
> So, only in situations where you explicitly don't want to activate the region?
> Does it often happen that you change your mind about activating the
> region? The C-x C-x case happens to me also, but rarely, and I find that
> `C-x C-x C-x C-x' is comfortable enough in those cases.

How repeating C-x C-x helps you to deactivate region (and thus help it
to survive after DEL)?  In my case it still to be activated regardless
on the amount of "C-x C-x" repeatings.

About "rarely": do you understand that now, with current defaults, it
is only one way to safe using DEL in the macro -- explicitly mark the
intended to be deleted character by region and only then delete it?
Otherwise there my occur already activated region and you will delete
not the single character but the whole half of buffer.  Just by
occasion and the Murphy Law.

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: draft for DEL key poll

[chad]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

On Sep 29, 2011, at 4:17 PM, Andrew W. Nosenko wrote:
> On Thu, Sep 29, 2011 at 20:56, chad <yandros@mit.edu> wrote:
>> On Sep 29, 2011, at 3:49 AM, Richard Stallman wrote:
>>> 
>>> Perhaps because you wanted to go to the other side of it with C-x C-x,
>>> is the usual reason in my case. […]
>> 
>> […] The C-x C-x case happens to me also, but rarely, and I find that
>> `C-x C-x C-x C-x' is comfortable enough in those cases.

> How repeating C-x C-x helps you to deactivate region (and thus help it
> to survive after DEL)?  In my case it still to be activated regardless
> on the amount of "C-x C-x" repeatings.

My apologies; I was still using some experimental code that deactivated
the region on any C-x C-x but the first (as a side-effect to allowing a prefix
arg to toggle transient-mark-mode). Mea culpa.

> About "rarely": do you understand that now, with current defaults, it
> is only one way to safe using DEL in the macro -- explicitly mark the
> intended to be deleted character by region and only then delete it?
> Otherwise there my occur already activated region and you will delete
> not the single character but the whole half of buffer.  Just by
> occasion and the Murphy Law.

I assume that you mean keyboard macro here, yes?  This usage had not 
occurred to me, as I use elisp far more often than keyboard macros, and
don't use macros for destructive things like DEL.  Perhaps this is why the 
new code works on delete-char-forward and delete-char-backward but 
explicitly not delete-char?  (I admit that I was puzzled by that choice.)

*Chad





[-- Attachment #2: Type: text/html, Size: 2658 bytes --]

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-delete-poll@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/

Re: draft for DEL key poll

[Richard Stallman]

    We could mention that this change makes standard a subset of the
    behavior provided by delete-selection-mode, pc-selection-mode, and
    cua-mode, indeed.

I mentioned that.

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

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

[Memnon Anon]

Hi,

Richard Stallman <rms@gnu.org> writes:

> Please send your responses to emacs-delete-poll@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

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

[Jai Dayal]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

I approve of all changes.

On Thu, Sep 29, 2011 at 11:42 PM, Richard Stallman <rms@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-delete-poll@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/
>
>

[-- Attachment #2: Type: text/html, Size: 2409 bytes --]

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

[Joel James Adamson]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

Richard Stallman <rms@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

[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: draft for DEL key poll

[Richard Stallman]

    So, only in situations where you explicitly don't want to activate the region?

I don't generally care whether the region is active -- I set
mark-even-if-inactive to t.  I often use C-x C-x to see or adjust the
other side of the region.

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

Re: draft for DEL key poll

[Eli Zaretskii]

> Date: Fri, 30 Sep 2011 17:03:36 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I don't generally care whether the region is active -- I set
> mark-even-if-inactive to t.

t is the default value of that variable nowadays.

RE: Emacs pretest 24.0.90

[Drew Adams]

> Sent: Sunday, September 25, 2011 8:58 PM
> Emacs pretest 24.0.90 is now available for download via FTP, at the
> following location:
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz

Is there a Windows build available via HTTP?

Re: draft for DEL key poll

[Andreas Röhler]

Am 30.09.2011 23:22, schrieb Eli Zaretskii:
>> Date: Fri, 30 Sep 2011 17:03:36 -0400
>> From: Richard Stallman<rms@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> I don't generally care whether the region is active -- I set
>> mark-even-if-inactive to t.
>
> t is the default value of that variable nowadays.
>
>

Hi,

sounds like a redundancy for me:

*Non-nil means you can use the mark even when inactive.
This option makes a difference in Transient Mark mode.
When the option is non-nil, deactivation of the mark
turns off region highlighting, but commands that use the mark
behave as if the mark were still active.


IMHO there are two cases to decide:

- if exists a difference between point and mark, ie the region exists

- the region is highlighted or not

two functions resp. variables are enough for indicating this

region-active-p
transient-mark-mode.

all the other stuff introduces rather confusion than being helpful AFAIU

Cheers,

Andreas

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

[Le Wang]

On Fri, Sep 30, 2011 at 11:17 PM, Joel James Adamson
<joeljamesadamson@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

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

[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-delete-poll@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.

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

[Suvayu Ali]

On Thu, 29 Sep 2011 23:42:50 -0400
Richard Stallman <rms@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-delete-poll@gnu.org.
> 
> 

Thank you for asking the user's opinion!

-- 
Suvayu

Open source is the future. It sets us free.

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

[Tassilo Horn]

Ian Zimmerman <itz@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

"like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Jai Dayal]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

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.

On Mon, Oct 3, 2011 at 9:18 AM, ken <gebser@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.
>
> 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3382 bytes --]

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Suvayu Ali]

Hi Ken,

On Mon, 03 Oct 2011 09:18:11 -0400
ken <gebser@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.

-- 
Suvayu

Open source is the future. It sets us free.

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[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

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

[Andreas Röhler]

Am 03.10.2011 11:21, schrieb Tassilo Horn:
> Ian Zimmerman<itz@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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[ken]

On 10/03/2011 09:41 AM Suvayu Ali wrote:
> Hi Ken,
> 
> On Mon, 03 Oct 2011 09:18:11 -0400
> ken <gebser@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?

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

[Joel James Adamson]

[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]

Le Wang <l26wang@gmail.com> writes:

> On Fri, Sep 30, 2011 at 11:17 PM, Joel James Adamson
> <joeljamesadamson@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-delete-poll@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/

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

[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[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

Re: "like other editors" [

[Richard Riley]

ken <gebser@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?

Re: "like other editors" [

[Richard Riley]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> Hi Ken,
>
> On Mon, 03 Oct 2011 09:18:11 -0400
> ken <gebser@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.

Re: "like other editors" [

[Richard Riley]

ken <gebser@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 <gebser@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?

RE: Emacs pretest 24.0.90

[Drew Adams]

> Sent: Friday, September 30, 2011 5:23 PM
> > Sent: Sunday, September 25, 2011 8:58 PM
> > Emacs pretest 24.0.90 is now available for download via FTP, at the
> > following location:
> >   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.90.tar.gz
> 
> Is there a Windows build available via HTTP?

ping.

The last Windows build published by Sean was from 2011-09-19.  I haven't found a
build for the pretest.  Is there one (available using HTTP)?

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[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 <gebser@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.

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

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

Re: "like other editors" [

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

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

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

[Tassilo Horn]

Ian Zimmerman <itz@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

Re: "like other editors" [

[Rasmus]

Ian Zimmerman <itz@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

Re: "like other editors" [

[ken]

On 10/03/2011 12:02 PM Richard Riley wrote:
> ken <gebser@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 <gebser@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.

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

[Martyn Jago]

Andreas Röhler <andreas.roehler@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

Re: "like other editors" [

[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 <gebser@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
> editors might be a good idea and makes sense?

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/3/2011 10:11 AM, Drew Adams wrote:

> The last Windows build published by Sean was from 2011-09-19.  I haven't found a
> build for the pretest.  Is there one (available using HTTP)?

Sean said he didn't have internet access for a couple of weeks. He will 
provide a build as soon as he is able I assume.

Christoph

RE: Emacs pretest 24.0.90

[Drew Adams]

> > The last Windows build published by Sean was from 
> > 2011-09-19.  I haven't found a build for the pretest.
> > Is there one (available using HTTP)?
> 
> Sean said he didn't have internet access for a couple of 
> weeks. He will provide a build as soon as he is able I assume.

I see.  I guess the pretest will be posted, when available, at
http://alpha.gnu.org/gnu/emacs/pretest/windows/

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/3/2011 5:42 PM, Drew Adams wrote:

> I see.  I guess the pretest will be posted, when available, at
> http://alpha.gnu.org/gnu/emacs/pretest/windows/

That's the plan, I think.

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[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/

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

[MBR]

[-- Attachment #1: Type: text/plain, Size: 4166 bytes --]

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-delete-poll@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
    mbr@arlsoft.com <mailto:mbr@arlsoft.com>



[-- Attachment #2: Type: text/html, Size: 5735 bytes --]

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

[suvayu ali]

Hi Mark,

On Tue, Oct 4, 2011 at 6:28 AM, MBR <mbr@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.

-- 
Suvayu

Open source is the future. It sets us free.

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

[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

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

[Jonathan Groll]

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

[...]

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

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

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

Furthermore, I would like it to work well with completion.el. (as per
http://www.emacswiki.org/emacs/delsel.el )

Cheers,
Jonathan
--
jjg: Jonathan J. Groll : groll co za
has_one { :blog => "http://bloggroll.com" }
Sent from my computer device which runs on free software

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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


On 10/03/2011 12:22 PM Jeremiah Dodds wrote:
> 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 <gebser@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.
> 

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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


On 10/03/2011 12:22 PM Jeremiah Dodds wrote:
> 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 <gebser@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.
> 

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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

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

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

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

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

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

[MBR]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2960 bytes --]

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

[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 <mbr@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
>

:)

-- 
Suvayu

Open source is the future. It sets us free.

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

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

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

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

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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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

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

[S Boucher]

----- Original Message -----
> From: Richard Stallman <rms@gnu.org>
> To: info-gnu-emacs@gnu.org; help-gnu-emacs@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-delete-poll@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/
>

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

[Alan E. Davis]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 461 bytes --]

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Jeremiah Dodds]

On Tue, Oct 4, 2011 at 7:44 AM, ken <gebser@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!".

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

[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 <rms@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-delete-poll@gnu.org.

-- 
Johnny

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

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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[ken]

On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
> On Tue, Oct 4, 2011 at 7:44 AM, ken <gebser@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.

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Jeremiah Dodds]

On Tue, Oct 4, 2011 at 3:02 PM, ken <gebser@mousecar.com> wrote:
> On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
>>
>> On Tue, Oct 4, 2011 at 7:44 AM, ken <gebser@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.

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[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 <gebser@mousecar.com> wrote:
>> On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
>>> On Tue, Oct 4, 2011 at 7:44 AM, ken <gebser@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.

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Jai Dayal]

[-- Attachment #1: Type: text/plain, Size: 4073 bytes --]

I love flame wars between pedantic programmers.

On Tue, Oct 4, 2011 at 5:42 PM, ken <gebser@mousecar.com> wrote:

> 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 <gebser@mousecar.com> wrote:
>>
>>> On 10/04/2011 02:40 PM Jeremiah Dodds wrote:
>>>
>>>> On Tue, Oct 4, 2011 at 7:44 AM, ken <gebser@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.
>
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 6403 bytes --]

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Jeremiah Dodds]

On Tue, Oct 4, 2011 at 4:42 PM, ken <gebser@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!

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

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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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


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

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[Rustom Mody]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

On Wed, Oct 5, 2011 at 8:00 PM, Richard Stallman <rms@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?

[-- Attachment #2: Type: text/html, Size: 1010 bytes --]

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

[MBR]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

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
    mbr@arlsoft.com <mailto:mbr@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 :-)
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2156 bytes --]

Re: "like other editors" [was: Re: Poll about proposed change in DEL (aka Backspace) and Delete]

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

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

[Thien-Thi Nguyen]

() "Ludwig, Mark" <ludwig.mark@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.

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

[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)

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.

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

[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... ;-)

Re: Emacs pretest 24.0.90

[nabil-82]

seewhydee wrote:
> 
> Emacs pretest 24.0.90 is now available for download via FTP, at the
> Thank you for helping to test Emacs.
> 
1.) I couldn't install emacs-24.0.90 properly on my notebook - I use Ubuntu
10.04 LTS.
./configure and then make worked. And I could/can run emacs 24 from the
src-directory.

But after "make install" I got 2 Errors:
cd /home/nab/emacs-24.0.90/doc/misc; makeinfo ert.texi
/bin/sh: makeinfo: not found
make[2]: *** [../../info/ert] Fehler 127 /* Fehler is german and means error
*/
make[2]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90/doc/misc' /* verlasse
= leave, Verzeichnis = directory */
make[1]: *** [info-real] Fehler 2
make[1]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90'
make: *** [info] Fehler 2 

2.) I don't if this is relevant. Because I could not complete the
installtion as I wrote... Maybe it's a bug?
: 
Arabic text ist written correctly R2L and also  the accents
(=diacritcs=tashkeel).
But the arabic characters don't appear connected as they should. I tested
several fonts.

 
 

-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32607388.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Fri, 7 Oct 2011 12:25:24 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> But after "make install" I got 2 Errors:
> cd /home/nab/emacs-24.0.90/doc/misc; makeinfo ert.texi
> /bin/sh: makeinfo: not found
> make[2]: *** [../../info/ert] Fehler 127 /* Fehler is german and means error
> */
> make[2]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90/doc/misc' /* verlasse
> = leave, Verzeichnis = directory */
> make[1]: *** [info-real] Fehler 2
> make[1]: Verlasse Verzeichnis '/home/nab/emacs-24.0.90'
> make: *** [info] Fehler 2 

You don't have the Texinfo package installed, but that package should
not be needed for building and installing a pretest.  There's already
a file info/ert in the tarball, and it is newer than
doc/misc/ert.texi.

I think the problem is in doc/misc/Makefile.in in this line:

  $(infodir)/ert: ert.texi $(infodir)

$(infodir) should not be a prerequisite of ert.  If you remove
$(infodir) from this line and re-run "configure", does "make install"
run to completion without problems?

> Arabic text ist written correctly R2L and also  the accents
> (=diacritcs=tashkeel).
> But the arabic characters don't appear connected as they should. I tested
> several fonts.

You are missing several libraries that are needed for Arabic shaping.
Here's an excerpt from the file INSTALL that describes these
libraries; you need to install all of the libraries mentioned below to
have Arabic shaping:

  * Complex Text Layout support libraries

  Emacs needs the optional libraries "m17n-db", "libm17n-flt", "libotf"
  to correctly display such complex scripts as Indic and Khmer.
  On some systems, particularly GNU/Linux, these libraries may be
  already present or available as additional packages.  Note that if
  there is a separate `dev' or `devel' package, for use at compilation
  time rather than run time, you will need that as well as the
  corresponding run time package; typically the dev package will contain
  header files and a library archive.  Otherwise, you can download and
  build libraries from sources.

  The sources of these libraries are available by anonymous CVS from
  cvs.m17n.org.

      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n login
      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co m17n-db
      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co m17n-lib
      % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co libotf

  For m17n-lib, if you have problems with making the whole package
  because you lack some other packages on which m17n-lib depends, try to
  configure it with the option "--without-gui".

Re: Emacs pretest 24.0.90

[nabil-82]

I respect the etiquette - but thanks.

It worked. I've installed the packages (Texinfo and the others) und
reinstalled emacs 24. (So, I didn't change anything in 
doc/misc/Makefile.in)



But there is another thing - not a bug. After choosing the
arabic-input-metho I can't put the "eastern-arabic-digits". I get the arabic
ones (so they are called). But in the (eastern) arabic countries they're not
used so often "eastern-arabic" ones. 
arabic: 0 1 2 3 ...
"eastern-arabic": 
٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
http://en.wikipedia.org/wiki/Eastern_Arabic_numerals

What I did: I've changed leim/quail/arabic.el  (put the 10 rules for the
eastern arabic digits)
It works - now. Could I have complications later? Is there a better
solution?



Eli Zaretskii wrote:
> 
> You don't have the Texinfo package installed, but that package should
> not be needed for building and installing a pretest.  There's already
> a file info/ert in the tarball, and it is newer than
> doc/misc/ert.texi.
> 
> I think the problem is in doc/misc/Makefile.in in this line:
> 
>   $(infodir)/ert: ert.texi $(infodir)
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32615869.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Glenn Morris]

Eli Zaretskii wrote:

> I think the problem is in doc/misc/Makefile.in in this line:
>
>   $(infodir)/ert: ert.texi $(infodir)

I think you're right; fixed in trunk.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Sat, 8 Oct 2011 09:38:23 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> After choosing the
> arabic-input-metho I can't put the "eastern-arabic-digits". I get the arabic
> ones (so they are called). But in the (eastern) arabic countries they're not
> used so often "eastern-arabic" ones. 
> arabic: 0 1 2 3 ...
> "eastern-arabic": 
> ٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
> http://en.wikipedia.org/wiki/Eastern_Arabic_numerals
> 
> What I did: I've changed leim/quail/arabic.el  (put the 10 rules for the
> eastern arabic digits)
> It works - now. Could I have complications later?

No, I wouldn't expect complications.

> Is there a better solution?

You could type the arabic digits after turning off the input method,
i.e.

  C-\
  type something in Arabic
  C-\
  type digits
  C-\
  type more Arabic

Re: Emacs pretest 24.0.90

[nabil-82]

I think my last Email wasn't clea: I need the eastern-arabic digits. But the
arabic-input-method use the arabic digits, not the eastern ones. That's why
I changed arabic.el.
(And C-\ would not help)

Eli Zaretskii wrote:
> 
> 
>> arabic: 0 1 2 3 ...
>> "eastern-arabic": 
>> ٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
>> http://en.wikipedia.org/wiki/Eastern_Arabic_numerals
>> Is there a better solution?
> 
> You could type the arabic digits after turning off the input method,
> i.e.
> 
>   C-\
>   type something in Arabic
>   C-\
>   type digits
>   C-\
>   type more Arabic
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32619171.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Sun, 9 Oct 2011 06:02:50 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> 
> I think my last Email wasn't clea: I need the eastern-arabic digits. But the
> arabic-input-method use the arabic digits, not the eastern ones. That's why
> I changed arabic.el.

Sorry, my misunderstanding.  Feel free to submit your change to
arabic.el for inclusion in Emacs.

Re: Emacs pretest 24.0.90

[Kenichi Handa]

In article <32615869.post@talk.nabble.com>, nabil-82 <sjanjal@web.de> writes:

> But there is another thing - not a bug. After choosing the
> arabic-input-metho I can't put the "eastern-arabic-digits". I get the arabic
> ones (so they are called). But in the (eastern) arabic countries they're not
> used so often "eastern-arabic" ones. 
> arabic: 0 1 2 3 ...
> "eastern-arabic": 
> ٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩
> http://en.wikipedia.org/wiki/Eastern_Arabic_numerals

> What I did: I've changed leim/quail/arabic.el  (put the 10 rules for the
> eastern arabic digits)
> It works - now. Could I have complications later? Is there a better
> solution?

With that, when you install a new version of Emacs, that
file will be overwritten.  If you want to avoid that, one
way is to define only additional rules in your .emacs as
below:

(quail-use-package "arabic" "quail/arabic")
(quail-define-rules
 ("1" ?١)
 ...)

By the way, if your request is a common one, it is better
that we add the rules for eastern-arabic digits to "arabic"
input method and provide a customizable variable to select
which kind of digits to input.

How the other arabic input methods work?

---
Kenichi Handa
handa@m17n.org

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> Is there a Windows build available via HTTP?
>
> ping.
>
> The last Windows build published by Sean was from 2011-09-19.  I haven't found a
> build for the pretest.  Is there one (available using HTTP)?

FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).

Here's my simple recipe:

0. Prerequisites:
0.1. Install bzr (if you are going to pull the sources from a bzr branch).
0.2. Install mingw (with the msys package).
0.3. Create a file "mingw-start.cmd" with the content described in [a].

1. Get the sources you want to build from ("bzr pull" or your favorite way).
2. Open a Windows console (cmd.exe).
3. run "cd C:\emacs\trunk\nt". [b].
4. run "configure --without-xpm --without-png --without-jpeg
--without-tiff --without-gif".
5. run "make bootstrap". [c].
6. run "make info". [c]
7. run "make install". [c]

That's all.  I hope it helps.


--- Footnotes: ---

[a] File "mingw-console.cmd":
------ begin of file -----------------------------
@set PATHMINGW=C:\MinGW\bin;C:\MinGW\msys\1.0\bin
@set PATHBAZAAR=C:\Program Files (x86)\Bazaar
@set PATH=%PATHMINGW%;%PATHBAZAAR%;%PATH%
@cmd
------ end of file -------------------------------
Substitute:
* "C:\MinGW" with the directory where you've installed mingw(+msys).
* "C:\Program Files (x86)\Bazaar" with the directory where you've
installed bazaar.

[b] Substitute "C:\emacs\trunk" with the directory where you've got
the emacs source tree.

[c] This starts a make process.  Unfortunately, sometimes the process
stops because it spawns a child "cmd.exe" session (I don't know why).
In these cases, I've seen that the solution is simply to exit from
that session (run "exit").  As many of you know, this problem can be
solved if you substitute msys with various utilities from the GnuWin
project.  IMO this is a pity, because msys is well integrated into the
mingw-get package manager, and thus seems to be a better alternative.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 12:18:19 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> [c] This starts a make process.  Unfortunately, sometimes the process
> stops because it spawns a child "cmd.exe" session (I don't know why).

It's a problem with the MSYS Make and MSYS Bash.  They convert
command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
fails miserably when the original command-line argument is not a file
name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
nt/INSTALL, which doesn't recommend MSYS for this very reason.

> IMO this is a pity, because msys is well integrated into the
> mingw-get package manager, and thus seems to be a better alternative.

Did you try the MinGW installer, here:

   http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe/download

I never tried it, but perhaps it also does a good job, and will give
you a working MinGW environment without MSYS.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>>> Is there a Windows build available via HTTP?
>>
>> ping.
>>
>> The last Windows build published by Sean was from 2011-09-19.  I haven't found a
>> build for the pretest.  Is there one (available using HTTP)?
>

Here's my recipe again, with a couple of fixes (in steps #0.3 and #2):

0. Prerequisites:
0.1. Install bzr (if you are going to pull the sources from a bzr branch).
0.2. Install mingw (with the msys package).
0.3. Create a file "mingw-console.cmd" with the content described in [a].

1. Get the sources you want to build from ("bzr pull" or your favorite way).
2. Invoke the "mingw-console.cmd" script (to open a console where
we'll run the following commands).
3. run "cd C:\emacs\trunk\nt". [b].
4. run "configure --without-xpm --without-png --without-jpeg
--without-tiff --without-gif".
5. run "make bootstrap". [c].
6. run "make info". [c]
7. run "make install". [c]

That's all.  I hope it helps.


--- Footnotes: ---

[a] File "mingw-console.cmd":
------ begin of file -----------------------------
@set PATHMINGW=C:\MinGW\bin;C:\MinGW\msys\1.0\bin
@set PATHBAZAAR=C:\Program Files (x86)\Bazaar
@set PATH=%PATHMINGW%;%PATHBAZAAR%;%PATH%
@cmd
------ end of file -------------------------------
Substitute:
* "C:\MinGW" with the directory where you've installed mingw(+msys).
* "C:\Program Files (x86)\Bazaar" with the directory where you've
installed bazaar.

[b] Substitute "C:\emacs\trunk" with the directory where you've got
the emacs source tree.

[c] This starts a make process.  Unfortunately, sometimes the process
stops because it spawns a child "cmd.exe" session (I don't know why).
In these cases, I've seen that the solution is simply to exit from
that session (run "exit").  As many of you know, this problem can be
solved if you substitute msys with various utilities from the GnuWin
project.  IMO this is a pity, because msys is well integrated into the
mingw-get package manager, and thus seems to be a better alternative.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Dani Moncayo]

On Wed, Oct 12, 2011 at 12:25, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Did you try the MinGW installer, here:
>
>   http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe/download
>

Yes, that is the installer (and the version) I used to install my
current MinGW environment.

> I never tried it, but perhaps it also does a good job, and will give
> you a working MinGW environment without MSYS.

But the Emacs build process needs some utilities like "rm", "cp" or
"make" that aren't part of MinGW but MSYS (the are in the
"MinGW\msys\1.0\bin" directory).  So, I would have to borrow them from
another place (e.g. GnuWin).

Therefore, what I say is that it would be great if the version of
"make" that comes with MSYS didn't have the problem I (and you) said,
because then, we'd have a easy to use and monolithic environment to
build Emacs on Windows.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 13:28, Dani Moncayo <dmoncayo@gmail.com> wrote:

> Therefore, what I say is that it would be great if the version of
> "make" that comes with MSYS didn't have the problem I (and you) said,

But MSYS' make does not have any "problem". It works well for its
purpose: to build MinGW packages. MSYS is not, and has never been,
intended as a generic "Unix tools package for Windows". That's what
GnuWin32 is for.

    Juanma

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> Therefore, what I say is that it would be great if the version of
>> "make" that comes with MSYS didn't have the problem I (and you) said,
>
> But MSYS' make does not have any "problem". It works well for its
> purpose: to build MinGW packages. MSYS is not, and has never been,
> intended as a generic "Unix tools package for Windows". That's what
> GnuWin32 is for.

From "http://www.mingw.org/wiki/MSYS":

  MSYS is a collection of GNU utilities such as bash, make, gawk and
grep to allow
  building of applications and programs which depend on traditionally UNIX tools
  to be present. It is intended to supplement MinGW and the
deficiencies of the cmd shell.

This description doesn't seems to be the same as yours:  "to allow
building of applications and programs" not "to build MinGW packages".

As I said, I'm able to successfully build the latest Emacs trunk on
Windows using exclusively MinGW and MSYS, which are both conveniently
integrated into a package manager (mingw-get).  The only obstacle is
the one already explained, which apparently has a very simple
workaround (already explained too).

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 13:28:48 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: cyd@stupidchicken.com, drew.adams@oracle.com, emacs-devel@gnu.org
> 
> On Wed, Oct 12, 2011 at 12:25, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Did you try the MinGW installer, here:
> >
> >   http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe/download
> >
> 
> Yes, that is the installer (and the version) I used to install my
> current MinGW environment.
> 
> > I never tried it, but perhaps it also does a good job, and will give
> > you a working MinGW environment without MSYS.
> 
> But the Emacs build process needs some utilities like "rm", "cp" or
> "make" that aren't part of MinGW but MSYS (the are in the
> "MinGW\msys\1.0\bin" directory).

Are you sure?  This page

  http://sourceforge.net/projects/mingw/files/MinGW/make/

claims that "make" _is_ included.

"rm" and "cp" are part of Coreutils, a single package that you need to
download from GnuWin32 (it may require a few DLLs that are used by
Coreutils).

> Therefore, what I say is that it would be great if the version of
> "make" that comes with MSYS didn't have the problem I (and you) said,
> because then, we'd have a easy to use and monolithic environment to
> build Emacs on Windows.

The MSYS Make cannot not have this problem, because file-name
translation is at the core of MSYS operation.  Without it, most of
MSYS's raison d'etre is gone.

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 14:07, Dani Moncayo <dmoncayo@gmail.com> wrote:

> From "http://www.mingw.org/wiki/MSYS":
>
>  MSYS is a collection of GNU utilities such as bash, make, gawk and
> grep to allow
>  building of applications and programs which depend on traditionally UNIX tools
>  to be present. It is intended to supplement MinGW and the
> deficiencies of the cmd shell.

In other words, it would be perhaps useful to build a POSIX Emacs on
Windows, less so to build the Emacs port, which doesn't really depend
on "traditional UNIX tools" apart of make and a few simple file tools
like mv and cp. The description you quote is talking about autoconf,
etc.

That said, MSYS was created to build MinGW tools. If they now
advertise it as a general tool to build "programs which depend on
traditionally UNIX tools", they are competing with Cygwin...

> As I said, I'm able to successfully build the latest Emacs trunk on
> Windows using exclusively MinGW and MSYS

Which means that you are using MinGW, and a few tools from MSYS. If
that works for you, I'm glat to hear it. But I wouldn't recommend it
to anyone.

Just out of curiosity, are you able to build the Emacs info files with
MSYS' makeinfo?

    Juanma

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 14:07:46 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, drew.adams@oracle.com, 
> 	emacs-devel@gnu.org
> 
> >From "http://www.mingw.org/wiki/MSYS":
> 
>   MSYS is a collection of GNU utilities such as bash, make, gawk and
> grep to allow
>   building of applications and programs which depend on traditionally UNIX tools
>   to be present. It is intended to supplement MinGW and the
> deficiencies of the cmd shell.
> 
> This description doesn't seems to be the same as yours:  "to allow
> building of applications and programs" not "to build MinGW packages".

Nevertheless, Juanma is right.  To be more precise, MSYS is a package
to build MinGW ports of software whose build needs to run the Posix
`configure' shell script and whose Makefiles require a Posix shell.

Emacs is not in that category, because it has a Windows configure.bat
script to configure it and Windows makefile.w32-in Makefiles that do
not require a Posix shell.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

> Just out of curiosity, are you able to build the Emacs info files with
> MSYS' makeinfo?

Yes.  "make info" apparently runs successfully, and I can browse from
my Emacs the manuals shipped with it.  Perfectly well.


-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

> Yes.  "make info" apparently runs successfully, and I can browse from
> my Emacs the manuals shipped with it.  Perfectly well.

I'm assuming this will be with a recent release of MinGW/MSYS, and so
makeinfo 4.13. Curious.

    Juanma

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> Yes.  "make info" apparently runs successfully, and I can browse from
>> my Emacs the manuals shipped with it.  Perfectly well.
>
> I'm assuming this will be with a recent release of MinGW/MSYS, and so
> makeinfo 4.13. Curious.

Yes:
  C:\Users\Dani>makeinfo --version
  makeinfo (GNU texinfo) 4.13


-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Stefan Monnier]

> Emacs is not in that category, because it has a Windows configure.bat
> script to configure it and Windows makefile.w32-in Makefiles that do
> not require a Posix shell.

Would MinGW+MSYS work to build Emacs if Emacs adapted its autoconf
script to handle Windows as well?


        Stefan

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/12/2011 4:25 AM, Eli Zaretskii wrote:

>> [c] This starts a make process.  Unfortunately, sometimes the process
>> stops because it spawns a child "cmd.exe" session (I don't know why).
>
> It's a problem with the MSYS Make and MSYS Bash.  They convert
> command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> fails miserably when the original command-line argument is not a file
> name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> nt/INSTALL, which doesn't recommend MSYS for this very reason.

I see this problem even without using MSYS. I am using TDM-GCC with gcc 
4.5.2 and make 3.82 and GnuWin tools. Every so often my nightly build 
stalls and fails with an `Access denied' error. It looks like it spawns 
a child cmd.exe right before. I googled and someone said make might trip 
up during parallel compilation so I force it with `-j 1' for testing. It 
still fails now and then. I will capture the exact error message and the 
context next time it happens.

Christoph

Re: Emacs pretest 24.0.90

[nabil-82]

"Kenichi Handa" writes:

> (quail-use-package "arabic" "quail/arabic")
> (quail-define-rules
> ("1" ?١)
> ...)
Thanks for the tip.

> By the way, if your request is a common one, it is better
> that we add the rules for eastern-arabic digits to "arabic"
> input method and provide a customizable variable to select
> which kind of digits to input.
I think it's a common one! So if it could be possible to add an
arabic-eastern-input-method it would be great.

----
After testing the arabic input method I found another problem.  It's not
emacs-specific. I have it with EVERY bidi-editor in Dos or Unix!  And maybe
a lot of people will not see any problem and say: "That's what I want!"

If I type '1' then '2'  in a "L2R paragraph" I get "12" - as expected of
course.

But if do this with in a "R2L paragraph" (I've tried it in arabic and
hebrew) I get on the scren "12". But this is not "normal". Because the
logical order is 1 then 2. And I'm writing from right to left. So the 1
should be on the right and 2 the should be on the left. So I think "21"
should be correct (for me).

It's disturbing. Because the typing direction for characters is r2l and for
digits is l2r!

And if you have a number at the begin of a line (in a R2L paragraph) let's
say "12" (twelve!) . 2 seems to be the first character! But the first
character (by Ctrl-a) is "1".

As I said you have this problem with every editor. And I see that it is
easier to make it as I think it should be: ALWAYS from right to left,  also
for digits and not only for characters - in the R2L-mode. So they must be a
reason...?

(vim can't bidi. Maybe that's why you don't have this effect there if you
type arabic or hebrew..)
-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32638171.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  lekktu@gmail.com,  cyd@stupidchicken.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Wed, 12 Oct 2011 08:46:50 -0400
> 
> > Emacs is not in that category, because it has a Windows configure.bat
> > script to configure it and Windows makefile.w32-in Makefiles that do
> > not require a Posix shell.
> 
> Would MinGW+MSYS work to build Emacs if Emacs adapted its autoconf
> script to handle Windows as well?

Yes, it will.

However, installing MSYS means installing a large number of programs
and DLLs, and people who already have a working MinGW development
environment that doesn't include MSYS will need to be extra careful
when doing such an installation, to avoid breaking their main
development environment.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 12 Oct 2011 14:29:10 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, drew.adams@oracle.com, 
> 	emacs-devel@gnu.org
> 
> > Yes.  "make info" apparently runs successfully, and I can browse from
> > my Emacs the manuals shipped with it.  Perfectly well.
> 
> I'm assuming this will be with a recent release of MinGW/MSYS, and so
> makeinfo 4.13. Curious.

There's nothing wrong with makeinfo 4.13 on Windows.  It's just that
the binary provided by GnuWin32 is broken.

If you have MSYS, you can build Texinfo 4.13 yourself.  I did that,
and the resulting makeinfo.exe "just works".  I don't remember if I
needed any Windows specific changes to build it.  (My primary interest
was to have a working info.exe, which does need changes.  I'm almost
there, btw.)

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 06:52:09 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: emacs-devel@gnu.org, dmoncayo@gmail.com
> 
> On 10/12/2011 4:25 AM, Eli Zaretskii wrote:
> 
> >> [c] This starts a make process.  Unfortunately, sometimes the process
> >> stops because it spawns a child "cmd.exe" session (I don't know why).
> >
> > It's a problem with the MSYS Make and MSYS Bash.  They convert
> > command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> > fails miserably when the original command-line argument is not a file
> > name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> > nt/INSTALL, which doesn't recommend MSYS for this very reason.
> 
> I see this problem even without using MSYS. I am using TDM-GCC with gcc 
> 4.5.2 and make 3.82 and GnuWin tools. Every so often my nightly build 
> stalls and fails with an `Access denied' error.

I think this is an entirely different problem.  The problem with MSYS
manifests itself in a cmd.exe window that opens and sits there waiting
for input.

> It looks like it spawns 
> a child cmd.exe right before. I googled and someone said make might trip 
> up during parallel compilation so I force it with `-j 1' for testing. It 
> still fails now and then. I will capture the exact error message and the 
> context next time it happens.

Yes, more details are needed to analyze this.

RE: Emacs pretest 24.0.90

[Drew Adams]

> > The last Windows build published by Sean was from 
> > 2011-09-19.  I haven't found a build for the pretest.
> > Is there one (available using HTTP)?
> 
> FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).

So please publish it at 
http://alpha.gnu.org/gnu/emacs/pretest/windows/

In the past, GNU Emacs has always posted a Windows binary for the pretest,
typically a few days after the pretest announcement.  It's now been almost a
month since the last binary was made available, and a couple weeks since the
pretest was announced (9/25).

Re: Emacs pretest 24.0.90

[Dani Moncayo]

>> > The last Windows build published by Sean was from
>> > 2011-09-19.  I haven't found a build for the pretest.
>> > Is there one (available using HTTP)?
>>
>> FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).
>
> So please publish it at
> http://alpha.gnu.org/gnu/emacs/pretest/windows/

I have a zip file with my current build (emacs-trunk-r106057; without
image support).

I would not mind to upload it (if people wants and someone gives me
ftp access), but I think that the lack of image support makes it a bad
candidate for publishing.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Dave Abrahams]

on Wed Oct 12 2011, Eli Zaretskii <eliz-AT-gnu.org> wrote:

>> Date: Wed, 12 Oct 2011 12:18:19 +0200
>
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
>> 
>> [c] This starts a make process.  Unfortunately, sometimes the process
>> stops because it spawns a child "cmd.exe" session (I don't know why).
>
> It's a problem with the MSYS Make and MSYS Bash.  They convert
> command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> fails miserably when the original command-line argument is not a file
> name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> nt/INSTALL, which doesn't recommend MSYS for this very reason.

Most options in Windows work if you use "-" instead of "/".  If you use
"-" in your Makefile you can avoid triggering this issue.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Dave Abrahams <dave@boostpro.com>
> Date: Wed, 12 Oct 2011 10:21:18 -0400
> 
> > It's a problem with the MSYS Make and MSYS Bash.  They convert
> > command-line arguments of the form /x/foo/bar to x:/foo/bar.  This
> > fails miserably when the original command-line argument is not a file
> > name, e.g., when the Makefile invokes "cmd /c SOMETHING".  See
> > nt/INSTALL, which doesn't recommend MSYS for this very reason.
> 
> Most options in Windows work if you use "-" instead of "/".  If you use
> "-" in your Makefile you can avoid triggering this issue.

Not in this case: cmd.exe does not accept -c, only /c.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 06:04:31 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> After testing the arabic input method I found another problem.  It's not
> emacs-specific. I have it with EVERY bidi-editor in Dos or Unix!  And maybe
> a lot of people will not see any problem and say: "That's what I want!"
> 
> If I type '1' then '2'  in a "L2R paragraph" I get "12" - as expected of
> course.
> 
> But if do this with in a "R2L paragraph" (I've tried it in arabic and
> hebrew) I get on the scren "12". But this is not "normal". Because the
> logical order is 1 then 2. And I'm writing from right to left. So the 1
> should be on the right and 2 the should be on the left. So I think "21"
> should be correct (for me).

What you see is correct behavior according to UBA, the Unicode
Bidirectional Algorithm that Emacs implements (as do other bidi-aware
applications).  1, 2, 3, etc. are the so-called "European Numbers",
and they are always displayed left to right, even in a right-to-left
paragraph.  If you want to have it otherwise, you will have to enclose
the numbers in a "right-to-left override", by typing the RIGHT-TO-LEFT
OVERRIDE character before the group of digits and the POP DIRECTIONAL
FORMATTING character after them.

> As I said you have this problem with every editor. And I see that it is
> easier to make it as I think it should be: ALWAYS from right to left,  also
> for digits and not only for characters - in the R2L-mode. So they must be a
> reason...?

The reason is the UBA, it mandates this behavior.  I don't read Arabic
(unfortunately), so I cannot comment on how this behavior fits or
doesn't fit the accepted practice.

Re: Emacs pretest 24.0.90

[nabil-82]

"Eli Zaretskii">
> 1, 2, 3, etc. are the so-called "European Numbers", and they are always
> displayed left to right, even in > a right-to-left paragraph. 
I have the same "problem" if I use the eastern-arab-digits.


> The reason is the UBA, it mandates this behavior.  I don't read Arabic
> (unfortunately), so I cannot comment on how this behavior fits or
> doesn't fit the accepted practice.

You have the same behavior by hebrew. 
 If you have "12" at the begin of a line in a hebrew paragraph. So you SEE
the '2' is first symbol on the right and you're writing from right 2 left:
so it should be the first symbol - but it isn't, it's the second. And moving
the cursor is confusing. It makes the jumps by the begin and end of every
number. 
-- 
View this message in context: http://old.nabble.com/Emacs-pretest-24.0.90-tp32537865p32639893.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 15:19, Eli Zaretskii <eliz@gnu.org> wrote:

> There's nothing wrong with makeinfo 4.13 on Windows.  It's just that
> the binary provided by GnuWin32 is broken.

I remember having trouble running the MSYS one, too. But it was a
while ago, and as my current setup works, I don't really want to go
trying new releases or compiling my own unless forced to.

    Juanma

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/12/2011 7:48 AM, Drew Adams wrote:

>> FWIW: lately, I'm able to build Emacs easily on my system (Windows 7).
>
> So please publish it at
> http://alpha.gnu.org/gnu/emacs/pretest/windows/
>
> In the past, GNU Emacs has always posted a Windows binary for the pretest,
> typically a few days after the pretest announcement.  It's now been almost a
> month since the last binary was made available, and a couple weeks since the
> pretest was announced (9/25).

Sean, who has been providing the weekly builds and would have provided 
the pretest build right away I am sure, does not have access to internet 
right now.

Also, any Windows builds to be published, should be build with the 
`mingw32-make dist' target and all features that are usually provided by 
the weekly builds (image support, gnutls etc.).

If Chong or Stephan want to send me instructions on how to upload the 
builds I will upload the pretest build and weekly builds until Sean is back.

Christoph

Re: Emacs pretest 24.0.90

[Stefan Monnier]

> If Chong or Stephan want to send me instructions on how to upload the builds
> I will upload the pretest build and weekly builds until Sean is back.

That would be great.  But I don't know how the upload process
works.  Chong?


        Stefan

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/12/2011 9:33 PM, Stefan Monnier wrote:
>> If Chong or Stephan want to send me instructions on how to upload the builds
>> I will upload the pretest build and weekly builds until Sean is back.
>
> That would be great.  But I don't know how the upload process
> works.  Chong?

I think Jason used to do this, no? CC'ed.

Christoph

Re: Emacs pretest 24.0.90

[Kevin Rodgers]

On 9/26/11 5:36 AM, Eli Zaretskii wrote:
>> From: Neal Becker<ndbecker2@gmail.com>
>> Date: Mon, 26 Sep 2011 07:12:17 -0400
>>
>> Can we post etc/NEWS somewhere so we can see it without d/l all of emacs24.1?
>
> You can see it here:
>
>     http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/etc/NEWS

Is this a typo:

Buffers RTL text should look exactly the same as before.
        ^
        with no

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 09:58:54 -0700 (PDT)
> From: nabil-82 <sjanjal@web.de>
> 
> 
> "Eli Zaretskii">
> > 1, 2, 3, etc. are the so-called "European Numbers", and they are always
> > displayed left to right, even in > a right-to-left paragraph. 
> I have the same "problem" if I use the eastern-arab-digits.

Yes.  Again, the UBA mandates that.  European numbers and Arabic
numbers (what you call eastern-arab-digits) behave almost the same as
far as the UBA is concerned.  There are differences between them, but
they are very minor.

> You have the same behavior by hebrew. 

But in Hebrew this is expected: numbers are always displayed
left-to-right, no matter if the paragraph is L2R or R2L.

> And moving the cursor is confusing. It makes the jumps by the begin
> and end of every number.

Cursor motion in Emacs is in logical order.  I know that some people
find this confusing, but at least some bidi-aware applications out
there do the same.  It should be possible (although not trivial) to
add visual-order cursor motion to Emacs, but logical-order movement is
a must, and so it was implemented first.

Re: Emacs pretest 24.0.90

[Eli Zaretskii]

> From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> Date: Wed, 12 Oct 2011 22:50:06 -0600
> 
> On 9/26/11 5:36 AM, Eli Zaretskii wrote:
> >> From: Neal Becker<ndbecker2@gmail.com>
> >> Date: Mon, 26 Sep 2011 07:12:17 -0400
> >>
> Is this a typo:
> 
> Buffers RTL text should look exactly the same as before.
>         ^
>         with no

Yes, of course.  Thanks for catching it.  I fixed it.

RE: Emacs pretest 24.0.90

[Drew Adams]

> If Chong or Stephan want to send me instructions on how to upload the 
> builds I will upload the pretest build and weekly builds 
> until Sean is back.

That would be great.  Thanks.

Re: Emacs pretest 24.0.90

[Dani Moncayo]

> Also, any Windows builds to be published, should be build with the
> `mingw32-make dist' target and all features that are usually provided by the
> weekly builds (image support, gnutls etc.).

If it is possible, I'd like to know the exact steps involved in such
weekly builds (in order to learn and try to reproduce them in my
system).

TIA.

-- 
Dani Moncayo

Re: Emacs pretest 24.0.90

[Juanma Barranquero]

On Thu, Oct 13, 2011 at 16:28, Dani Moncayo <dmoncayo@gmail.com> wrote:

> If it is possible, I'd like to know the exact steps involved in such
> weekly builds (in order to learn and try to reproduce them in my
> system).

nt/INSTALL should have all required information. If not, please file a
bug detailing what is missing.

    Juanma

Re: Emacs pretest 24.0.90

[Chong Yidong]

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

>> If Chong or Stephan want to send me instructions on how to upload the builds
>> I will upload the pretest build and weekly builds until Sean is back.
>
> That would be great.  But I don't know how the upload process
> works.  Chong?

See step 11 in admin/make-tarball.  Except the files needs to go in the
windows/ subdirectory.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/13/2011 10:15 AM, Chong Yidong wrote:
> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>
>>> If Chong or Stephan want to send me instructions on how to upload the builds
>>> I will upload the pretest build and weekly builds until Sean is back.
>>
>> That would be great.  But I don't know how the upload process
>> works.  Chong?
>
> See step 11 in admin/make-tarball.  Except the files needs to go in the
> windows/ subdirectory.

Thanks. I will have a look there.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/13/2011 4:54 PM, Christoph Scholtes wrote:
> On 10/13/2011 10:15 AM, Chong Yidong wrote:
>> See step 11 in admin/make-tarball. Except the files needs to go in the
>> windows/ subdirectory.
>
> Thanks. I will have a look there.

As soon as my GPG key is acknowledged by the GNU ftp folks, I will 
upload the Windows pretest build.

Christoph

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

[Steinar Bang]

>>>>> Richard Stallman <rms@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.

RE: Emacs pretest 24.0.90

[Drew Adams]

> c> If Chong or Stephan want to send me instructions on how to 
> c> upload the builds I will upload the pretest build and weekly
> c> builds until Sean is back.
d> 
d> That would be great.  Thanks.

That was a while ago.  Any progress?

d>> In the past, GNU Emacs has always posted a Windows binary for 
d>> the pretest, typically a few days after the pretest announcement.
d>> It's now been almost a month since the last binary was made
d>> available, and a couple weeks since the pretest was announced
d>> (9/25).

It's now been a month since the last Windows binary (9/19), and several weeks
since the pretest was announced (9/25).

Still no Windows binary.

Re: Emacs pretest 24.0.90

[Christoph Scholtes]

On 10/18/2011 11:15 AM, Drew Adams wrote:

> It's now been a month since the last Windows binary (9/19), and several weeks
> since the pretest was announced (9/25).
>
> Still no Windows binary.

My GPG key was acknowledged by the GNU ftp people today. I am working on 
the pretest build right now. I will post an announcement to the usual 
places when it is up on the ftp site.

Thank you for the patience.

Christoph

RE: Emacs pretest 24.0.90

[Drew Adams]

> > It's now been a month since the last Windows binary (9/19), 
> > and several weeks since the pretest was announced (9/25).
> >
> > Still no Windows binary.
> 
> My GPG key was acknowledged by the GNU ftp people today.
> I am working on the pretest build right now. I will post
> an announcement to the usual places when it is up on the
> ftp site.  Thank you for the patience.

Good to hear.  Thanks.

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

[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