GNU bug report logs - #53452
29.0.50; C-<arrow> selection broken by translate-upper-case-key-bindings

Previous Next

To reply to this bug, email your comments to 53452 AT debbugs.gnu.org.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Sat, 22 Jan 2022 19:26:35 +0100

Hi:

When translate-upper-case-key-bindings is nil; the shift-arrow selection
does not work

emacs -Q
M-: (setq translate-upper-case-key-bindings nil)
S-<right>  // says it is not bound... somehow expected.

M-: (keymap-global-set "S-<right>" #'right-char)
S-<right>  // Now moves point but with no selection

I don't know where/how emacs recognizes the Shift in this case, but
somehow it is not working

Best,



In GNU Emacs 29.0.50 (build 42, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-01-21 built on Ergus
Repository revision: 1228ec3e1d7657c9eb50184719410f37ed0eb750
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --prefix=/home/ergo/.local/ --with-mailutils --with-json
 --with-x-toolkit=gtk3 --with-xft --with-wide-int --with-modules
 --with-cairo --with-harfbuzz --with-native-compilation --with-pgtk'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  global-auto-revert-mode: t
  xclip-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  electric-pair-mode: t
  flyspell-mode: t
  company-mode: t
  flycheck-mode: t
  counsel-mode: t
  ivy-mode: t
  composable-mark-mode: t
  composable-mode: t
  repeat-mode: t
  xterm-mouse-mode: t
  minibuffer-depth-indicate-mode: t
  winner-mode: t
  save-place-mode: t
  which-key-mode: t
  override-global-mode: t
  delete-selection-mode: t
  savehist-mode: t
  global-display-fill-column-indicator-mode: t
  display-fill-column-indicator-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
~/gits/emacs_clones/composable/composable-mark hides /home/ergo/.config/emacs/elpa/composable-20201024.1458/composable-mark
~/gits/emacs_clones/composable/composable hides /home/ergo/.config/emacs/elpa/composable-20201024.1458/composable
/home/ergo/.config/emacs/elpa/transient-20220117.1122/transient hides /home/ergo/.local/share/emacs/29.0.50/lisp/transient
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-jump hides /usr/share/emacs/site-lisp/notmuch-jump
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-hello hides /usr/share/emacs/site-lisp/notmuch-hello
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-query hides /usr/share/emacs/site-lisp/notmuch-query
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-show hides /usr/share/emacs/site-lisp/notmuch-show
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-parser hides /usr/share/emacs/site-lisp/notmuch-parser
/home/ergo/.config/emacs/elpa/cmake-mode-20210104.1831/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-wash hides /usr/share/emacs/site-lisp/notmuch-wash
/home/ergo/.config/emacs/elpa/protobuf-mode-20211013.1726/protobuf-mode hides /usr/share/emacs/site-lisp/protobuf-mode
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-crypto hides /usr/share/emacs/site-lisp/notmuch-crypto
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-tree hides /usr/share/emacs/site-lisp/notmuch-tree
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/coolj hides /usr/share/emacs/site-lisp/coolj
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-lib hides /usr/share/emacs/site-lisp/notmuch-lib
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-compat hides /usr/share/emacs/site-lisp/notmuch-compat
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-company hides /usr/share/emacs/site-lisp/notmuch-company
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-draft hides /usr/share/emacs/site-lisp/notmuch-draft
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-tag hides /usr/share/emacs/site-lisp/notmuch-tag
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-message hides /usr/share/emacs/site-lisp/notmuch-message
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-mua hides /usr/share/emacs/site-lisp/notmuch-mua
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-address hides /usr/share/emacs/site-lisp/notmuch-address
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-print hides /usr/share/emacs/site-lisp/notmuch-print
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch hides /usr/share/emacs/site-lisp/notmuch
/home/ergo/.config/emacs/elpa/notmuch-20220120.1932/notmuch-maildir-fcc hides /usr/share/emacs/site-lisp/notmuch-maildir-fcc

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils thingatpt amx s autorevert filenotify
xclip yasnippet-snippets yasnippet elec-pair flyspell-correct-ivy
flyspell-correct flyspell ispell company-semantic company-template
company-capf company flycheck json map find-func dash pcase cape counsel
xdg xref project dired dired-loaddefs compile text-property-search
comint ansi-color swiper ivy-avy avy ivy flx ivy-faces ivy-overlay colir
term/tmux term/xterm xterm init composable composable-mark powerline
comp comp-cstr warnings advice powerline-separators color
powerline-themes repeat xt-mouse edmacro kmacro mb-depth simple-16-theme
winner ring saveplace diminish which-key cl-extra help-mode use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core disp-table delsel
savehist easy-mmode display-fill-column-indicator display-line-numbers
info ede/auto eieio-base cl-seq seq eieio subr-x byte-opt bytecomp
byte-compile cconv eieio-core cl-macs gv eieio-loaddefs cl-loaddefs
cl-lib tex-site rx slime-autoloads early-init iso-transl tooltip eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/pgtk-win pgtk-win term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit pgtk lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 269329 16379)
 (symbols 48 18331 0)
 (strings 32 70803 7968)
 (string-bytes 1 2271188)
 (vectors 16 30164)
 (vector-slots 8 636227 5879)
 (floats 8 197 995)
 (intervals 56 1611 0)
 (buffers 992 10))

Message #8 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50;
 C-<arrow> selection broken by translate-upper-case-key-bindings
Date: Sat, 22 Jan 2022 21:18:11 +0200

> Date: Sat, 22 Jan 2022 19:26:35 +0100
> From:  Ergus via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> When translate-upper-case-key-bindings is nil; the shift-arrow selection
> does not work
> 
> emacs -Q
> M-: (setq translate-upper-case-key-bindings nil)
> S-<right>  // says it is not bound... somehow expected.
> 
> M-: (keymap-global-set "S-<right>" #'right-char)
> S-<right>  // Now moves point but with no selection
> 
> I don't know where/how emacs recognizes the Shift in this case, but
> somehow it is not working

It sounds like it cannot work in that case, because shift-select
_requires_ that a key was shift-translated, and setting
translate-upper-case-key-bindings to nil disables that translation.

Message #11 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ergus <spacibba <at> aol.com>, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Mon, 24 Jan 2022 11:54:19 +0100

>>>>> On Sat, 22 Jan 2022 21:18:11 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> Date: Sat, 22 Jan 2022 19:26:35 +0100
    >> From:  Ergus via "Bug reports for GNU Emacs,
    >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
    >> 
    >> When translate-upper-case-key-bindings is nil; the shift-arrow selection
    >> does not work
    >> 
    >> emacs -Q
    >> M-: (setq translate-upper-case-key-bindings nil)
    >> S-<right>  // says it is not bound... somehow expected.
    >> 
    >> M-: (keymap-global-set "S-<right>" #'right-char)
    >> S-<right>  // Now moves point but with no selection
    >> 
    >> I don't know where/how emacs recognizes the Shift in this case, but
    >> somehow it is not working

    Eli> It sounds like it cannot work in that case, because shift-select
    Eli> _requires_ that a key was shift-translated, and setting
    Eli> translate-upper-case-key-bindings to nil disables that translation.

The docstring says:
"If non-nil, interpret upper case keys as lower case (when applicable)."

which strongly implies that this only applies to letters, not keys
like <right>

Robert
-- 

Message #14 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Mon, 24 Jan 2022 14:38:39 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Ergus <spacibba <at> aol.com>,  53452 <at> debbugs.gnu.org
> Date: Mon, 24 Jan 2022 11:54:19 +0100
> 
>     Eli> It sounds like it cannot work in that case, because shift-select
>     Eli> _requires_ that a key was shift-translated, and setting
>     Eli> translate-upper-case-key-bindings to nil disables that translation.
> 
> The docstring says:
> "If non-nil, interpret upper case keys as lower case (when applicable)."
> 
> which strongly implies that this only applies to letters, not keys
> like <right>

That's a wrong impression, the translation applies to all the keys.

Message #17 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Mon, 24 Jan 2022 14:40:29 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Ergus <spacibba <at> aol.com>,  53452 <at> debbugs.gnu.org
> Date: Mon, 24 Jan 2022 11:54:19 +0100
> 
>     Eli> It sounds like it cannot work in that case, because shift-select
>     Eli> _requires_ that a key was shift-translated, and setting
>     Eli> translate-upper-case-key-bindings to nil disables that translation.
> 
> The docstring says:
> "If non-nil, interpret upper case keys as lower case (when applicable)."
> 
> which strongly implies that this only applies to letters, not keys
> like <right>

That's not the implementation, though.  And I'm not sure applying it
only to letters would make sense.

Message #20 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Mon, 24 Jan 2022 14:19:59 +0100

>>>>> On Mon, 24 Jan 2022 14:38:39 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: Ergus <spacibba <at> aol.com>,  53452 <at> debbugs.gnu.org
    >> Date: Mon, 24 Jan 2022 11:54:19 +0100
    >> 
    Eli> It sounds like it cannot work in that case, because shift-select
    Eli> _requires_ that a key was shift-translated, and setting
    Eli> translate-upper-case-key-bindings to nil disables that translation.
    >> 
    >> The docstring says:
    >> "If non-nil, interpret upper case keys as lower case (when applicable)."
    >> 
    >> which strongly implies that this only applies to letters, not keys
    >> like <right>

    Eli> That's a wrong impression, the translation applies to all the keys.

Yes, it does, but itʼs unexpected (to me at least), that setting
`translate-upper-case-key-bindings' to nil has the effect of disabling
that translation. Iʼd expect to see that side effect described in the
docstring, but that only talks about upper<->lower case mapping.

Robert
-- 

Message #23 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Mon, 24 Jan 2022 14:21:23 +0100

>>>>> On Mon, 24 Jan 2022 14:40:29 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: Ergus <spacibba <at> aol.com>,  53452 <at> debbugs.gnu.org
    >> Date: Mon, 24 Jan 2022 11:54:19 +0100
    >> 
    Eli> It sounds like it cannot work in that case, because shift-select
    Eli> _requires_ that a key was shift-translated, and setting
    Eli> translate-upper-case-key-bindings to nil disables that translation.
    >> 
    >> The docstring says:
    >> "If non-nil, interpret upper case keys as lower case (when applicable)."
    >> 
    >> which strongly implies that this only applies to letters, not keys
    >> like <right>

    Eli> That's not the implementation, though.  And I'm not sure applying it
    Eli> only to letters would make sense.

Why not? non-letters donʼt have a case, they only have a potential
Shift modifier.

Robert
-- 

Message #26 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Mon, 24 Jan 2022 15:39:28 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: spacibba <at> aol.com,  53452 <at> debbugs.gnu.org
> Date: Mon, 24 Jan 2022 14:21:23 +0100
> 
> >>>>> On Mon, 24 Jan 2022 14:40:29 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Cc: Ergus <spacibba <at> aol.com>,  53452 <at> debbugs.gnu.org
>     >> Date: Mon, 24 Jan 2022 11:54:19 +0100
>     >> 
>     Eli> It sounds like it cannot work in that case, because shift-select
>     Eli> _requires_ that a key was shift-translated, and setting
>     Eli> translate-upper-case-key-bindings to nil disables that translation.
>     >> 
>     >> The docstring says:
>     >> "If non-nil, interpret upper case keys as lower case (when applicable)."
>     >> 
>     >> which strongly implies that this only applies to letters, not keys
>     >> like <right>
> 
>     Eli> That's not the implementation, though.  And I'm not sure applying it
>     Eli> only to letters would make sense.
> 
> Why not?

Because people will probably  want it applied to any key.  There's
nothing special about letters, except that "upper-case" implicitly
refers to letters.

Message #29 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Tue, 25 Jan 2022 11:19:33 +0100

>>>>> On Mon, 24 Jan 2022 15:39:28 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
    >> Why not?

    Eli> Because people will probably  want it applied to any key.  There's
    Eli> nothing special about letters, except that "upper-case" implicitly
    Eli> refers to letters.

Let's start again:

Currently, S-<right> produces S-<right>, but is translated to <right>,
and C-S-a is translated to C-a

If you set translate-upper-case-key-bindings to nil, then S-<right>
produces S-<right>, and C-S-a produces C-S-a

So the effect is as if the option were called
'translate-shift-bindings', but that effect is not called out
anywhere.

So either we fix the behaviour, or the documentation. Would it be that
hard to restrict this to something like [a-z] or !function key? Or we
could always add yet-another-user-option.

Robert
-- 

Message #32 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Tue, 25 Jan 2022 14:29:56 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: spacibba <at> aol.com,  53452 <at> debbugs.gnu.org
> Date: Tue, 25 Jan 2022 11:19:33 +0100
> 
> >>>>> On Mon, 24 Jan 2022 15:39:28 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>     >> Why not?
> 
>     Eli> Because people will probably  want it applied to any key.  There's
>     Eli> nothing special about letters, except that "upper-case" implicitly
>     Eli> refers to letters.
> 
> Let's start again:
> 
> Currently, S-<right> produces S-<right>, but is translated to <right>,
> and C-S-a is translated to C-a
> 
> If you set translate-upper-case-key-bindings to nil, then S-<right>
> produces S-<right>, and C-S-a produces C-S-a
> 
> So the effect is as if the option were called
> 'translate-shift-bindings', but that effect is not called out
> anywhere.
> 
> So either we fix the behaviour, or the documentation. Would it be that
> hard to restrict this to something like [a-z] or !function key? Or we
> could always add yet-another-user-option.

My point was that the behavior is probably okay, and the documentation
should be amended if it could confuse.

Message #35 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Tue, 25 Jan 2022 13:37:13 +0100

>>>>> On Tue, 25 Jan 2022 14:29:56 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> So either we fix the behaviour, or the documentation. Would it be that
    >> hard to restrict this to something like [a-z] or !function key? Or we
    >> could always add yet-another-user-option.

    Eli> My point was that the behavior is probably okay, and the documentation
    Eli> should be amended if it could confuse.

Itʼs only ok if weʼre ok with shift-selection being broken by it. Are
we?

Robert
-- 

Message #38 received at 53452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: spacibba <at> aol.com, 53452 <at> debbugs.gnu.org
Subject: Re: bug#53452: 29.0.50; C-<arrow> selection broken by
 translate-upper-case-key-bindings
Date: Tue, 25 Jan 2022 14:45:09 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: spacibba <at> aol.com,  53452 <at> debbugs.gnu.org
> Date: Tue, 25 Jan 2022 13:37:13 +0100
> 
> >>>>> On Tue, 25 Jan 2022 14:29:56 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> So either we fix the behaviour, or the documentation. Would it be that
>     >> hard to restrict this to something like [a-z] or !function key? Or we
>     >> could always add yet-another-user-option.
> 
>     Eli> My point was that the behavior is probably okay, and the documentation
>     Eli> should be amended if it could confuse.
> 
> Itʼs only ok if weʼre ok with shift-selection being broken by it. Are
> we?

Like I said: I don't see how shift-selection could NOT be broken by
disabling shift-translation, because it DEPENDS on it.

Previous Next

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