GNU bug report logs - #2760
CUA-like stuff spuriously enables transient-mark-mode.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2760 in the body.
You can then email your comments to 2760 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: CUA-like stuff spuriously enables transient-mark-mode.
Date: Mon, 23 Mar 2009 22:37:03 +0000

Hi, Richard, Eli and Emacs!

Start the CVS head "emacs -Q", and evaluate this:

    (global-set-key [ &\C-\M-\S-m ] 'forward-char)
    (transient-mark-mode -1)

In some buffer, invoke 'forward-char by the above binding.  This enables
transient-mark-mode as a side effect.  This shouldn't happen.  It happens
both in a Linux Virtual terminal (with the requisite enhancements to the
keyboard handling) and in X-Windows.

ANALYSIS:
---------
The "^" in the interactive string causes `handle-shift-selection' to be
invoked by the command loop.  The function and friends abuse the user
option variable `transient-mark-mode' by additionally storing some sort
of state in it.  h-s-s writes the value '(only) into the variable
transient-mark-mode, thus enabling the mode.  A sensible fix would surely
involve leaving `transient-mark-mode' severely alone (only the user
should set this) and creating another variable (or several) to hold the
state currently mashed into t-m-m.

COMMENT:
--------
It is now no longer true that "But Emacs does not assign meanings to keys
directly" (Emacs manual, page "Commands") - Emacs directly assigns a
meaning to the shift key.  This is surely a Bad Thing.

Why, why, why is this thing implemented by hard-coding in the command
loop, where it interferes with users' ability to chose key bindings?
Surely this feature with the shift key should have been implemented by
defining defuns such as `forward-char-with-marking', and putting these
commands in some suitable keymap?  OK, it's more work, but not _that_
much more.

It's practically 100% certain that somebody, somewhere, will want to use
the hyper- or alt- keys instead of <shift> to get this visible region
feature, or possibly might want to use separate bindings entirely.

It's near 100% certain that somebody, somewhere, perhaps with a name like
Xah Lee, will want to use C-f as "find" (i.e. bind it to
`isearch-forward') and use C-S-f for `forward-char'.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 2760 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2760: CUA-like stuff spuriously enables transient-mark-mode.
Date: Mon, 23 Mar 2009 20:46:22 -0400

> Start the CVS head "emacs -Q", and evaluate this:

>     (global-set-key [ &\C-\M-\S-m ] 'forward-char)
>     (transient-mark-mode -1)

> In some buffer, invoke 'forward-char by the above binding.  This enables
> transient-mark-mode as a side effect.  This shouldn't happen.

Can't reproduce it here (I tried the above, after replacing & with ?
and I don't see any indication that transient-mark-mode is being set).

> Why, why, why is this thing implemented by hard-coding in the command
> loop, where it interferes with users' ability to chose key bindings?

Where do you see it hardcoded in the command loop?

> It's practically 100% certain that somebody, somewhere, will want to use
> the hyper- or alt- keys instead of <shift> to get this visible region

We'll cross this bridge when we get there.

> It's near 100% certain that somebody, somewhere, perhaps with a name like
> Xah Lee, will want to use C-f as "find" (i.e. bind it to
> `isearch-forward') and use C-S-f for `forward-char'.

And that works just fine, AFAICT.


        Stefan

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2760 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2760: CUA-like stuff spuriously enables transient-mark-mode.
Date: Tue, 24 Mar 2009 13:52:10 +0000

Hi, Stefan!

On Mon, Mar 23, 2009 at 08:46:22PM -0400, Stefan Monnier wrote:
> > Start the CVS head "emacs -Q", and evaluate this:

> >     (global-set-key [ &\C-\M-\S-m ] 'forward-char)
> >     (transient-mark-mode -1)

> > In some buffer, invoke 'forward-char by the above binding.  This enables
> > transient-mark-mode as a side effect.  This shouldn't happen.

> Can't reproduce it here (I tried the above, after replacing & with ?
> and I don't see any indication that transient-mark-mode is being set).

Sorry, my mistake.  Yes I did mean "?" in the binding, but as depicted
above, the bug doesn't happen.

Instead,

    (global-set-key [ ?\C-\M-m ] 'forward-char)

Now invoke forward-char with this binding + the shift key.  This enables
transient-mark-mode as a side effect.  This shouldn't happen.^H^H^H^H....

Correction: this can be disabled by nullifying the option
shift-select-mode - which isn't yet documented in the Emacs manual.  So I
withdraw my complaint, with apologies.

> > Why, why, why is this thing implemented by hard-coding in the command
> > loop, where it interferes with users' ability to chose key bindings?

> Where do you see it hardcoded in the command loop?

In Fcall_interactively, Lines 207 and 231, where it is interpreting the
interactive string:

      else if (*string == '^')
        {
          if (! NILP (Vshift_select_mode))
             call1 (Qhandle_shift_selection, Qnil);    <================
          /* Even if shift-select-mode is off, temporarily active
             regions could be set using the mouse, and should be
             deactivated.  */
          else if (CONSP (Vtransient_mark_mode)
                   && EQ (XCAR (Vtransient_mark_mode), Qonly))
            call1 (Qhandle_shift_selection, Qt);       <================
          string++;
        }
.

> > It's practically 100% certain that somebody, somewhere, will want to use
> > the hyper- or alt- keys instead of <shift> to get this visible region

> We'll cross this bridge when we get there.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #30 received at 2760-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: 2760-done <at> debbugs.gnu.org
Subject: Re: bug#2760: Acknowledgement (CUA-like stuff spuriously enables
	transient-mark-mode.)
Date: Tue, 24 Mar 2009 15:49:37 +0000

This wasn't a bug.

On Mon, Mar 23, 2009 at 10:45:04PM +0000, Emacs bug Tracking System wrote:
 
> Thank you for filing a new bug report with Emacs.


> -- 
> 2760: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2760
> Emacs Bug Tracking System
> Contact help-debbugs <at> gnu.org with problems

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #35 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 2760 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2760: CUA-like stuff spuriously enables transient-mark-mode.
Date: Tue, 24 Mar 2009 21:38:29 -0400

>> Where do you see it hardcoded in the command loop?

> In Fcall_interactively, Lines 207 and 231, where it is interpreting the
> interactive string:

>       else if (*string == '^')
>         {
>           if (! NILP (Vshift_select_mode))
>              call1 (Qhandle_shift_selection, Qnil);    <================
>           /* Even if shift-select-mode is off, temporarily active
>              regions could be set using the mouse, and should be
>              deactivated.  */
>           else if (CONSP (Vtransient_mark_mode)
>                    && EQ (XCAR (Vtransient_mark_mode), Qonly))
>             call1 (Qhandle_shift_selection, Qt);       <================
>           string++;
>         }
> .

I see.  I guess we just disagree on what is meant by "hardcoded in the
command loop": this code is explicitly requested by the "^" code in the
`interactive' string of a command, so it seems (to me) pretty far from
"hardcoded in the command loop".


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.