bug#8492: 23.3; Time to use a different binding for completion?

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

Emacs binds various completion functions to M-Tab, which is already used
by many window managers, including Compiz and Metacity, i.e. the WMs one
is likely to use on a modern GNU system, for switching between open
windows.

Is it therefore time to admit defeat and find an alternative binding for
completion functions, even if it’s an extra binding rather than simply a
different one?


In GNU Emacs 23.3.2 (i686-pc-linux-gnu, GTK+ Version 2.22.0)
 of 2011-03-02 on canta
Windowing system distributor `The X.Org Foundation', version 11.0.10900000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Javascript/nxhtml

Minor modes in effect:
  nxml-where-marks: t
  nxml-where-tag+id: t
  nxml-where-header: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  iswitchb-mode: t
  icomplete-mode: t
  global-whitespace-mode: t
  global-auto-revert-mode: t
  nxhtml-menu-mode: t
  nxhtml-tag-do-also: t
  popcmp-group-alternatives: t
  popcmp-short-help-beside-alts: t
  mlinks-active-links: t
  rngalt-minimal-validation-header: t
  rngalt-display-validation-header: t
  desktop-save-mode: t
  flyspell-mode: t
  recentf-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
t m l - w e b - <tab> <backspace> <backspace> <backspace> 
<backspace> <tab> v c <tab> s <tab> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> C-g <down-mouse-1> <mouse-1> 
M-x w e b - c v s - <backspace> <backspace> <backspace> 
<backspace> v b <backspace> c s <tab> n x <tab> <return> 
3 y C-c C-c C-c C-c C-c C-c C-c C-c C-c C-c C-c C-c 
C-x 0 <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> 
<down-mouse-1> <mouse-1> C-x b n i n <backspace> <backspace> 
<backspace> i n d e <return> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <help-echo> <down-mouse-1> <mouse-1> 
<left> <left> M-x x m <backspace> <backspace> n x m 
l = - c o m <backspace> <backspace> <backspace> <backspace> 
- <backspace> <backspace> - c o m p l e t e <return> 
C-g <down-mouse-1> <mouse-movement> <mouse-movement> 
<drag-mouse-1> <down-mouse-1> <mouse-1> C-x 1 M-x <up> 
<return> <down-mouse-1> <mouse-1> M-x <up> <return> 
<down-mouse-1> <mouse-1> y <help-echo> <down-mouse-1> 
<mouse-1> M-< <down-mouse-1> <mouse-1> M-x r e p o 
r t = - b <backspace> <backspace> - <backspace> <backspace> 
- e m a c s - b u g <return>

Recent messages:
XHTML validation header that sets the DTD to XHTML.  This will
not be inserted in the buffer but completion and XHTML validation
will assume it is there so both error checking and completion
will work.

Do you want to add a fictive XHTML validation header? (y or n) 
No alternative found
Using vacuous schema [3 times]
Mark set
Using vacuous schema

Load-path shadows:
/home/rrt/local/share/emacs/nxhtml/util/rnc-mode hides /usr/share/emacs-snapshot/site-lisp/rnc-mode/rnc-mode
/home/rrt/local/share/emacs/nxhtml/related/php-mode hides /home/rrt/local/share/emacs/site-lisp/php-mode
/home/rrt/local/share/emacs/nxhtml/related/csharp-mode hides /home/rrt/local/share/emacs/site-lisp/csharp-mode
/home/rrt/local/share/emacs/site-lisp/popup hides /usr/local/share/emacs/23.3/site-lisp/auto-complete/popup
/home/rrt/local/share/emacs/site-lisp/fuzzy hides /usr/local/share/emacs/23.3/site-lisp/auto-complete/fuzzy
/home/rrt/.emacs.d/elpa/css-mode-1.0/css-mode hides /usr/local/share/emacs/23.3/site-lisp/css-mode/css-mode
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/link hides /usr/local/share/emacs/23.3/site-lisp/dictionary-el/link
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/connection hides /usr/local/share/emacs/23.3/site-lisp/dictionary-el/connection
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/dictionary-init hides /usr/local/share/emacs/23.3/site-lisp/dictionary-el/dictionary-init
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/dictionary hides /usr/local/share/emacs/23.3/site-lisp/dictionary-el/dictionary
/home/rrt/local/share/emacs/site-lisp/dict hides /usr/local/share/emacs/23.3/site-lisp/emacs-goodies-el/dict
/home/rrt/.emacs.d/elpa/css-mode-1.0/css-mode hides /usr/local/share/emacs/23.3/lisp/textmodes/css-mode
/usr/share/emacs-snapshot/site-lisp/ruby1.8-elisp/ruby-mode hides /usr/local/share/emacs/23.3/lisp/progmodes/ruby-mode
/home/rrt/.emacs.d/elpa/css-mode-1.0/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info
/usr/local/share/emacs/23.3/site-lisp/auctex/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl
/usr/local/share/emacs/23.3/site-lisp/auctex/context-en hides /usr/share/emacs/site-lisp/auctex/context-en
/usr/local/share/emacs/23.3/site-lisp/auctex/latex hides /usr/share/emacs/site-lisp/auctex/latex
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik
/usr/local/share/emacs/23.3/site-lisp/dictionary-el/lpath hides /usr/share/emacs/site-lisp/auctex/lpath
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar
/usr/local/share/emacs/23.3/site-lisp/auctex/tex hides /usr/share/emacs/site-lisp/auctex/tex
/usr/local/share/emacs/23.3/site-lisp/auctex/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-fptex hides /usr/share/emacs/site-lisp/auctex/tex-fptex
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold
/usr/local/share/emacs/23.3/site-lisp/auctex/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp
/usr/local/share/emacs/23.3/site-lisp/auctex/context hides /usr/share/emacs/site-lisp/auctex/context
/usr/local/share/emacs/23.3/site-lisp/auctex/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex
/usr/local/share/emacs/23.3/site-lisp/auctex/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite
/usr/local/share/emacs/23.3/site-lisp/auctex/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/local/share/emacs/23.3/site-lisp/auctex/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style

Features:
(shadow sort mail-extr emacsbug zencoding-mode whelp wid-browse
viper-tut useful-commands tyda tabkey2 sml-modeline sex-mode search-form
rxi rebind pointback pause org-panel ocr-user new-key-seq-widget n-back
winsize ourcomments-widgets winsav windmove trace mumamo-regions
ps-print ps-def lpr mumamo-aspnet markchars key-cat inlimg idn
html-write hl-needed vline hl-line hfyview gpl ediff-url custsets
cus-new-user css-simple-completion css-palette chartg buffer-bg
as-external wrap-to-fill anchored-transpose wikipedia-mode tutorial
visual-basic-mode tt-mode smarty-mode hippie-exp add-log mozadd
iss-mumamo iss-mode flymu flymakemsg flymake-java-1 flymake-helpers
flymake-css django csharp-mode outline-magic nxml-where nxhtml-js
nxhtml-strval nxhtml-bug html-wtoc html-move html-chklnk autostart22
nxhtmlmaint message sendmail ecomplete rfc822 mml mml-sec mailabbrev
nnheader gmm-utils mailheader canlock sha1 hex-util hashcash org-wl
org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs
org-html org-exp org-exp-blocks org-agenda org-info org-gnus org-bibtex
org-bbdb parse-time timezone mail-utils url-cache nxhtml-web-vcs
jka-compr autoconf autoconf-mode vc-git css-mode js json thingatpt
newcomment nxml-uchnm rng-xsd xsd-regexp rng-cmpct face-remap filladapt
nxhtml-mumamo mumamo-fun nxhtml completing-help ange-ftp tramp-imap
tramp-gw tramp-fish tramp-smb tramp-cache tramp-ftp tramp-cmds tramp
auth-source shell password-cache format-spec tramp-compat trampver paren
savehist minibuf-eldef iswitchb icomplete whitespace autorevert time
server nxhtml-autostart nxhtml-autoload moz majmodpri rnc-mode
nxhtml-menu udev-rinari udev-ecb udev flymake-js flymake css-color
nxhtml-mode html-quote tidy-xhtml ediff-merg ediff-diff ediff-wind
ediff-help ediff-util ediff-mult ediff-init ediff html-imenu imenu
loadhist popcmp xhtml-help mlinks html-toc xml fupd html-pagetoc foldit
appmenu-fold appmenu mumamo sgml-mode rngalt rng-nxml nxml-mode
nxml-outln nxml-rap nxml-glyph rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-util
nxml-enc xmltok desktop help-mode view flyspell fold-dwim hideshow
html-upl html-site ourcomments-util uniquify recentf tree-widget org
byte-opt warnings org-footnote org-src org-list org-faces org-compat
org-macs noutline outline ido bookmark pp apropos grep ffip gimpedit
dired web-vcs bytecomp byte-compile rx url-http tls url url-proxy
url-privacy url-expand url-methods url-history url-auth url-cookie
url-util url-parse url-gw url-vars mm-decode gnus-util netrc mm-bodies
mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums
mm-util time-date mail-prsvr cus-edit cus-start cus-load wid-edit
compile web-autoload nxhtml-base php-mode etags cc-langs cc-mode
cc-fonts cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
speedbar sb-image ezimage dframe lua-mode regexp-opt comint ring
ropemacs pymacs smart-quotes ffap ispell auto-dictionary-autoloads
c-eldoc-autoloads css-mode-autoloads dictionary-autoloads
diff-git-autoloads dired-isearch-autoloads full-ack-autoloads
guess-style-autoloads javascript-autoloads kill-ring-search-autoloads
lambdacalc-autoloads magit-autoloads mv-shell-autoloads tumble-autoloads
http-post-simple-autoloads package reporter advice advice-preload
yasnippet help-fns derived edmacro kmacro easymenu assoc cl cl-19
muse-autoloads emacs-goodies-el emacs-goodies-custom
emacs-goodies-loaddefs easy-mmode bbdb-autoloads preview-latex tex-site
auto-loads tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win
x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind system-font-setting
font-render-setting gtk x-toolkit x multi-tty emacs)

-- 
http://rrt.sc3d.org/

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Monnier]

> Is it therefore time to admit defeat and find an alternative binding for
> completion functions, even if it’s an extra binding rather than simply a
> different one?

TAB can do completion if you (setq tab-always-indent 'complete).


        Stefan

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 15 April 2011 20:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Is it therefore time to admit defeat and find an alternative binding for
>> completion functions, even if it’s an extra binding rather than simply a
>> different one?
>
> TAB can do completion if you (setq tab-always-indent 'complete).

Thanks for the tip, I'll try that.

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Sat, Apr 16, 2011 at 12:53 AM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 15 April 2011 20:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Is it therefore time to admit defeat and find an alternative binding for
>>> completion functions, even if it’s an extra binding rather than simply a
>>> different one?
>>
>> TAB can do completion if you (setq tab-always-indent 'complete).
>
> Thanks for the tip, I'll try that.

The idea is nice, but there is perhaps a problem with the current
implementation: There are many ways to complete in Emacs.

In for example tabkey2.el other choices are made available too. See
http://www.emacswiki.org/emacs/TabCompletion for more info.
(tabkey2.el may be broken at the moment, I am not sure how it works
right now.)

bug#8492: 23.3; Time to use a different binding for completion?

[Andrew W. Nosenko]

On Wed, Apr 13, 2011 at 20:26, Reuben Thomas <rrt@sc3d.org> wrote:
> Emacs binds various completion functions to M-Tab, which is already used
> by many window managers, including Compiz and Metacity, i.e. the WMs one
> is likely to use on a modern GNU system, for switching between open
> windows.

Unable to say anything about Compiz, but Metacity binds nothing to
M-Tab (moreover, it binds nothing to Meta-combinations at all).  For
switching between windows it uses Alt-Tab.

Another problem is that in many Linux distros Meta and Alt bound the
same physical key by default.  But they may be easy splited using
keyboard preferences.  I use Windows key for Meta and Alt key for Alt,
for example.

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

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Tue, Apr 19, 2011 at 12:52 PM, Andrew W. Nosenko
<andrew.w.nosenko@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 20:26, Reuben Thomas <rrt@sc3d.org> wrote:
>> Emacs binds various completion functions to M-Tab, which is already used
>> by many window managers, including Compiz and Metacity, i.e. the WMs one
>> is likely to use on a modern GNU system, for switching between open
>> windows.
>
> Unable to say anything about Compiz, but Metacity binds nothing to
> M-Tab (moreover, it binds nothing to Meta-combinations at all).  For
> switching between windows it uses Alt-Tab.
>
> Another problem is that in many Linux distros Meta and Alt bound the
> same physical key by default.  But they may be easy splited using
> keyboard preferences.  I use Windows key for Meta and Alt key for Alt,
> for example.

On w32 moving Emacs META from Alt to the Windows key is not that
simple. It requires my patch for this to be reliable (avaliable in the
EmacsW32 repository).

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Monnier]

>>>> Is it therefore time to admit defeat and find an alternative binding for
>>>> completion functions, even if it’s an extra binding rather than simply a
>>>> different one?
>>> TAB can do completion if you (setq tab-always-indent 'complete).
>> Thanks for the tip, I'll try that.
> The idea is nice, but there is perhaps a problem with the current
> implementation: There are many ways to complete in Emacs.

It's not the ultimate solution, no.  I'm not sure what "other choices"
you're thinking of, but I know that for some major modes, mixing
completion and indentation via (setq tab-always-indent 'complete) is not
really an option (e.g. Python where TAB cycles through various
indentation levels).


        Stefan

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Tue, Apr 19, 2011 at 2:46 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>>>> Is it therefore time to admit defeat and find an alternative binding for
>>>>> completion functions, even if it’s an extra binding rather than simply a
>>>>> different one?
>>>> TAB can do completion if you (setq tab-always-indent 'complete).
>>> Thanks for the tip, I'll try that.
>> The idea is nice, but there is perhaps a problem with the current
>> implementation: There are many ways to complete in Emacs.
>
> It's not the ultimate solution, no.  I'm not sure what "other choices"
> you're thinking of, but I know that for some major modes, mixing
> completion and indentation via (setq tab-always-indent 'complete) is not
> really an option (e.g. Python where TAB cycles through various
> indentation levels).

This is what I have in tabkey2.el in nXhtml (though it might be broken
at the moment):

(defcustom tabkey2-completion-functions
  '(
    ("Emacs default completion" completion-at-point
completion-at-point-functions)
    ;; Front ends (should take care of the rest, ie temporary things,
    ;; snippets etc...)
    ("Company Mode completion" company-complete company-mode)
    ;; Temporary things
    ("Spell check word" flyspell-correct-word-before-point nil)
    ;; Snippets
    ("Yasnippet" yas/expand (yas/expandable-at-point))
    ;; Main mode related, often used
    ("Semantic Smart Completion" senator-complete-symbol senator-minor-mode)
    ("Programmable completion" pcomplete (and (boundp
'pcomplete-parse-arguments-function)

pcomplete-parse-arguments-function))
    ("nXML completion" nxml-complete (derived-mode-p 'nxml-mode))
    ("Complete Emacs symbol" lisp-complete-symbol (and (derived-mode-p
'emacs-lisp-mode)
                                                       (not (fboundp
'completion-at-point))))
    ("Widget complete" widget-complete nil)
    ("Comint Dynamic Complete" comint-dynamic-complete nil)
    ("PHP completion" php-complete-function php-mode)
    ("Tags completion" complete-tag nil)
    ;; General word completion
    ("Predictive word" complete-word-at-point predictive-mode)
    ("Predictive abbreviations" pabbrev-expand-maybe)
    ("Dynamic word expansion" dabbrev-expand t (setq
dabbrev--last-abbrev-location nil))
    ("Ispell complete word" ispell-complete-word t)
    ;; The catch all
    ("Anything" anything (commandp 'anything))
    )
  "List of completion functions.
The first 'active' entry in this list is normally used during the
'Tab completion state' by `tabkey2-complete'.  An entry in the
list should have either of this forms

  \(TITLE COMPLETION-FUNCTION ACTIVE-FORM RESET-FORM)

TITLE to show in menus etc.

COMPLETION-FUNCTION is the completion function symbol.

The entry is considered active if the symbol COMPLETION-FUNCTION
is bound to a command and

  - This function has a key binding at point and ACTIVE-FORM is
  equal to nil.

or

  - The elisp expression ACTIVE-FORM evaluates to non-nil.  If it
  is a single symbol then its variable value is used, otherwise
  the elisp form is evaled.

RESET-FORM is used to reset the completion function before
calling it.

When choosing with `tabkey2-cycle-completion-functions'
only the currently active entry in this list are shown."
  :type '(repeat (list string (choice (command :tag "Currently known command")
                                      (symbol  :tag "Command not known yet"))
                       (choice (const :tag "Active only if it has a
key binding at point" nil)
                               (sexp :tag "Elisp, if evals to non-nil
then active"))
                       (sexp :tag "Elisp, reset completion function")))
  :group 'tabkey2)

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Monnier]

> This is what I have in tabkey2.el in nXhtml (though it might be broken
> at the moment):

That only tells me of alternatives you've thought of.  I'm only
interested in alternatives that really make sense at the same time at
the same place (the others aren't in conflict).


        Stefan

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Tue, Apr 19, 2011 at 3:34 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> This is what I have in tabkey2.el in nXhtml (though it might be broken
>> at the moment):
>
> That only tells me of alternatives you've thought of.  I'm only
> interested in alternatives that really make sense at the same time at
> the same place (the others aren't in conflict).

That is handled by the third argument in each record.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 19 April 2011 11:52, Andrew W. Nosenko <andrew.w.nosenko@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 20:26, Reuben Thomas <rrt@sc3d.org> wrote:
>> Emacs binds various completion functions to M-Tab, which is already used
>> by many window managers, including Compiz and Metacity, i.e. the WMs one
>> is likely to use on a modern GNU system, for switching between open
>> windows.
>
> Unable to say anything about Compiz, but Metacity binds nothing to
> M-Tab (moreover, it binds nothing to Meta-combinations at all).  For
> switching between windows it uses Alt-Tab.

I'm sorry, I was imprecise.

> Another problem is that in many Linux distros Meta and Alt bound the
> same physical key by default.  But they may be easy splited using
> keyboard preferences.

This is the problem: unusable defaults. I'm asking if we can have a
usable default setting.

One could argue that it should be X's defaults that are fixed, but
that seems rather less likely to happen. So it seems there are three
options:

0. Do nothing, arguing that users can always configure things so they
work. That would be a pity, as for every user who has the knowledge
and patience (remember also advanced users who want to use Emacs on a
new account on a new machine), there will be several who just give up,
so that either they don't use Emacs, or they find it less powerful
than it is.

1. Convince X packagers to bind Meta and Alt to different keys. That's
a hard sell, though the purist in me does agree that window-manager
operations should not use a key that is commonly used for application
shortcuts. (In the past I've made my WM use the Windows key for its
bindings, which seems rather more logical, but that's a change which
is not going to stick as a default.)

2. Add a default binding for completion that works with Meta & Alt on
the same key. (No need to remove the existing binding.) The problems
with simply using Tab have already been expounded, though that's a
nice option to have (especially if you're not a Python programmer!).

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Monnier]

> This is the problem: unusable defaults. I'm asking if we can have a
> usable default setting.

Currently, the "usable default" is ESC TAB.

It's a bit longwinded, so it'd be good to find a better solution.
Since this problem has been around for a long time and no good key has
popped up during this time, I believe that using TAB is the
way forward, which means we need to figure out ways to make it work in
the cases where it currently doesn't.

Currently the way it works is "try to reindent, and if there was no
change, try to complete".  As mentioned this doesn't work for Python and
Haskell, so for those modes maybe completion should take precedence as
in "see if we're somewhere where completion makes sense and if not try
to reindent", so TAB would complete if point is in an identifier
but not if it's a BOL.

Not sure if it would work well in practice, but it might be worth trying
it out.  There are other cases where TAB has trouble, e.g. in text modes
where TAB doesn't reindent but jumps to the next tab position.
I don't know how/if we can combine this TAB semantics with completion.


        Stefan

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 20 April 2011 14:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> This is the problem: unusable defaults. I'm asking if we can have a
>> usable default setting.
>
> Currently, the "usable default" is ESC TAB.

I think "usable" is stretching it a bit :)

> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.

I am inclined to agree that that is the path of least resistance; I
think it remains to be demonstrated that two lots of magic can be
loaded on to the same key, but I'm prepared to give it a go!

> for those modes maybe completion should take precedence as
> in "see if we're somewhere where completion makes sense and if not try
> to reindent", so TAB would complete if point is in an identifier
> but not if it's a BOL.

And there's already code to do this.

At least if there's a concerted effort to make this work and it fails,
there's more incentive to come up with another solution.

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Deniz Dogan]

2011/4/20 Stefan Monnier <monnier@iro.umontreal.ca>:
>> This is the problem: unusable defaults. I'm asking if we can have a
>> usable default setting.
>
> Currently, the "usable default" is ESC TAB.
>
> It's a bit longwinded, so it'd be good to find a better solution.
> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.
>
> Currently the way it works is "try to reindent, and if there was no
> change, try to complete".  As mentioned this doesn't work for Python and
> Haskell, so for those modes maybe completion should take precedence as
> in "see if we're somewhere where completion makes sense and if not try
> to reindent", so TAB would complete if point is in an identifier
> but not if it's a BOL.
>
> Not sure if it would work well in practice, but it might be worth trying
> it out.  There are other cases where TAB has trouble, e.g. in text modes
> where TAB doesn't reindent but jumps to the next tab position.
> I don't know how/if we can combine this TAB semantics with completion.
>

Surely there must be keys left that are not used for any particular
purpose in general.  E.g. C-. comes to mind (c.f. C-M-. for
find-tag-regexp), although I'm not sure how well that key is
recognized by terminals.

-- 
Deniz Dogan

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Monnier]

>> Since this problem has been around for a long time and no good key has
>> popped up during this time, I believe that using TAB is the
>> way forward, which means we need to figure out ways to make it work in
>> the cases where it currently doesn't.
> I am inclined to agree that that is the path of least resistance; I
> think it remains to be demonstrated that two lots of magic can be
> loaded on to the same key, but I'm prepared to give it a go!

Of course, pursuing this route doesn't preclude pursuing other routes at
the same time.  So, people should feel free to suggest other keys to use
for completion.

One that comes to mind is C-M-/ (currently bound to dabbrev-completion,
so somewhat compatible) but I'm not sure if it's convenient enough.

Another one could be M-SPC, based on the idea that SPC performs
completion in many cases in the minibuffer, but that would be an
incompatible change since M-SPC currently calls just-one-space.

>> for those modes maybe completion should take precedence as
>> in "see if we're somewhere where completion makes sense and if not try
>> to reindent", so TAB would complete if point is in an identifier
>> but not if it's a BOL.
> And there's already code to do this.

I didn't know that.  Where is it?

> At least if there's a concerted effort to make this work and it fails,
> there's more incentive to come up with another solution.

And the failure itself might give us a clue as to what a better solution
might look like,


        Stefan

bug#8492: 23.3; Time to use a different binding for completion?

[Sven Joachim]

On 2011-04-20 16:16 +0200, Stefan Monnier wrote:

>>> Since this problem has been around for a long time and no good key has
>>> popped up during this time, I believe that using TAB is the
>>> way forward, which means we need to figure out ways to make it work in
>>> the cases where it currently doesn't.
>> I am inclined to agree that that is the path of least resistance; I
>> think it remains to be demonstrated that two lots of magic can be
>> loaded on to the same key, but I'm prepared to give it a go!
>
> Of course, pursuing this route doesn't preclude pursuing other routes at
> the same time.  So, people should feel free to suggest other keys to use
> for completion.
>
> One that comes to mind is C-M-/ (currently bound to dabbrev-completion,
> so somewhat compatible) but I'm not sure if it's convenient enough.

With a German keyboard layout, C-M-/ is horribly cumbersome to type,
much more inconvenient than either ESC TAB or C-M-i (I usually use the
latter).

Sven

bug#8492: 23.3; Time to use a different binding for completion?

[Drew Adams]

> Currently, the "usable default" is ESC TAB.
> It's a bit longwinded, so it'd be good to find a better solution.

It's not very longwinded.  It was used for a very long time before ALT + TAB was
available for the same thing.  It was used by many perfectly capable and fast
programmers, including the one who wrote Emacs (practically overnight) and gcc.
;-)  Likewise `C-M-i' - not very longwinded, and long available for this.

And anyway it doesn't really matter all that much how longwinded a _default_
binding is.  (Yes, there is no reason to purposefully use longer bindings when
better, shorter ones can be found.)

> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.

So your logic is that simply because you cannot find an available key you want
to complicate the behavior of the command so that it acts, in effect, as
multiple commands depending on the context.

That's not a good argument.  Occam stands with his razor against it - you are
multiplying things needlessly.

Keep it simple.  Find a key or let users find their own key for a simple,
straightforward command (i.e., that does only what M-TAB does currently).
Forget about combining 36 different behaviors on the same key.

In practice, so-called "DWIM" too often means lousy, half-baked compromises and
"do-what-some-programmer-who-thought-herself-clever-figured-would-be-innovative-
and-loved-by-everyone".  The "I" in DWIM is too seldom the user, and the "WIM"
is too seldom accurate.

Do I really care, for M-TAB or `completion-at-point'?  Not much.  I do care that
we needlessly complicate the behavior of keys with compromised,
not-so-clever-after-all DWIM-wittedness.

Please go back to the problem itself and look for a simple solution _to it_.

M-TAB is not easily available on several systems.  OK, so you want a different
key as the default binding for `completion-at-point' (or whatever).  OK, so pick
another key.  Problem solved.

But please do not redesign the behavior to become hydra-headed so it tries to
adapt to multiple contexts, just because you cannot think of a good default key.
That makes little sense.

And TAB, in particular, is *not* "the way forward for this".  If ever there was
a key *not* to double-up on for this (triple? quadruple? pentuple?), TAB is it.
It's just about the poorest choice possible here.

(Yes, I am aware that some users have done exactly what you suggest and like the
effect.  Pick any behavior and you will find some users who are happy with it to
the point of proselytizing.  But such a chimera is not a good solution for
vanilla Emacs.)

Just one opinion, and no, I do not really care much.  But this is misguided,
IMHO.

bug#8492: 23.3; Time to use a different binding for completion?

[David De La Harpe Golden]

On 20/04/11 15:16, Stefan Monnier wrote:
>>> Since this problem has been around for a long time and no good key has
>>> popped up during this time, I believe that using TAB is the
>>> way forward, which means we need to figure out ways to make it work in
>>> the cases where it currently doesn't.
>> I am inclined to agree that that is the path of least resistance; I
>> think it remains to be demonstrated that two lots of magic can be
>> loaded on to the same key, but I'm prepared to give it a go!
>
> Of course, pursuing this route doesn't preclude pursuing other routes at
> the same time.  So, people should feel free to suggest other keys to use
> for completion.
>

Well, given that the usual mapping on x.org X11 is, for better or worse,

Alt key => Meta
Windows/other-symbol* key => super

then perhaps additionally binding s-TAB out-of-box might be worth 
considering?  I expect it's mostly people with keyboards with such keys 
who have trouble with M-TAB (and also apparently don't like C-M-i and 
ESC TAB).

(Though you might get people then trying to use such a default binding 
as precedent to put all sorts of stuff on s-blah, sigh...)

Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead 
of "super" when you press the windows keys (testing in wine not real 
windows), w32 emacs may also need to be adjusted to map them to 
left/right super by default and treat them as modifiers. Note that such 
a mapping would be consistent with typical x11 as above, but also 
arguably with macosx, where "command" (⌘) is often taken to send super** 
- and when you plug a pc keyboard into a mac, the windows keys become 
"command" by default.  Yes, macosx, gnustep and x11 all allow fairly 
easy adjustment, I'm just talking about out-of-box defaults.

(Of course, I also don't know if windows itself is now using 
WindowsKey-TAB for anything, I know it used not to.)

I'm one of the people who puts any window manager bindings on super in 
the first place (windows key, innit...), obviously easy to do in common 
X11 window managers, so don't need any of this personally (in fact I put 
what windows has on Alt-Tab on Super-Tab so I wouldn't even see it), 
it's just a suggestion.

* You can get keyboards with a penguin there. :-)

** note how  emacs/lisp/term/ns-win-el has a bunch of super bindings 
out-of-box, saying "Here are some Nextstep-like bindings for command key 
sequences."...

bug#8492: 23.3; Time to use a different binding for completion?

[Deniz Dogan]

2011/4/20 David De La Harpe Golden <david@harpegolden.net>:
> (Of course, I also don't know if windows itself is now using WindowsKey-TAB
> for anything, I know it used not to.)
>

Windows Vista and Windows 7 use Win+TAB to switch between windows in a
more useless and annoying manner.  Sort of like a rolodex:
http://thavarajah.dk/sites/thavarajah.dk/uploads/2007/01/vista_window_switch.png

-- 
Deniz Dogan

bug#8492: 23.3; Time to use a different binding for completion?

[Eli Zaretskii]

> Date: Wed, 20 Apr 2011 17:41:41 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: 8492@debbugs.gnu.org, Reuben Thomas <rrt@sc3d.org>
> 
> Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead 
> of "super" when you press the windows keys (testing in wine not real 
> windows), w32 emacs may also need to be adjusted to map them to 
> left/right super by default and treat them as modifiers.

See w32-lwindow-modifier and w32-rwindow-modifier.  (And note the
footnote in the Emacs manual's "Windows Keyboard" node about the
caveats.)

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 20 April 2011 16:49, Drew Adams <drew.adams@oracle.com> wrote:
>> Currently, the "usable default" is ESC TAB.
>> It's a bit longwinded, so it'd be good to find a better solution.
>
> It's not very longwinded.

It's two keystrokes rather than a two-key chord for a function which
users these days expect to use frequently.

> It was used by many perfectly capable and fast
> programmers, including the one who wrote Emacs practically
> overnight) and gcc.

I'd be interested to know whether that's actually true, or whether
they simply didn't use it.

> ;-)  Likewise `C-M-i' - not very longwinded, and long available
> for this.

Takes two hands.

> And anyway it doesn't really matter all that much how longwinded a _default_
> binding is.

It does. If the letter 'e' were bound by default to "ESC C-M x 5 a" I
wouldn't use Emacs.

The point is that there are features that are relatively new which
users now expect. Syntax coloring is another which went from optional
(largely for performance reasons, IIRC) to on-by-default, but of
course it doesn't really need keybindings.

> So your logic is that simply because you cannot find an available key you want
> to complicate the behavior of the command so that it acts, in effect, as
> multiple commands depending on the context.

That may work: we already have plenty of context-dependent keystrokes,
which are often called "electric". Tab is, as even you've noted,
already overloaded.

Having said that, no key binding is better than a clever key binding.
Some uses of completion perhaps don't need a key (as for example many
uses of code completion, which in other IDEs pop up a list of
completions by default).

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[David De La Harpe Golden]

On 20/04/11 18:11, Deniz Dogan wrote:
> 2011/4/20 David De La Harpe Golden<david@harpegolden.net>:
>> (Of course, I also don't know if windows itself is now using WindowsKey-TAB
>> for anything, I know it used not to.)
>>
>
> Windows Vista and Windows 7 use Win+TAB to switch between windows in a
> more useless and annoying manner.

D'oh. Oh well.

Though that does mean there is now something of an alternative to 
Alt+TAB on windows, so if you do configure emacs to grab Alt+TAB at a 
low level on windows with w32-register-hot-key as the docs mention, then 
it's no longer the case you're hidden the ability to easily* switch app 
from the keyboard, so the issue is maybe actually a bit less pressing 
than it used to be on w32.

* though in a more useless and annoying, or at least gimmicky, manner...

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Wed, Apr 20, 2011 at 3:18 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> This is the problem: unusable defaults. I'm asking if we can have a
>> usable default setting.
>
> Currently, the "usable default" is ESC TAB.

Which does not work at all if you use Viper.

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Wed, Apr 20, 2011 at 4:16 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> One that comes to mind is C-M-/ (currently bound to dabbrev-completion,
> so somewhat compatible) but I'm not sure if it's convenient enough.

Which is a problematic binding if you do not use US keyboard.

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Wed, Apr 20, 2011 at 8:28 PM, David De La Harpe Golden
<david@harpegolden.net>
>
> Though that does mean there is now something of an alternative to Alt+TAB on
> windows, so if you do configure emacs to grab Alt+TAB at a low level on
> windows with w32-register-hot-key as the docs mention, then it's no longer
> the case you're hidden the ability to easily* switch app from the keyboard,
> so the issue is maybe actually a bit less pressing than it used to be on
> w32.

I mentioned before that I have somewhere MS doc have read that Alt-TAB
is not configurable. It actually still was on xp when I tested, but
has anyone tested this on win7?

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Wed, Apr 20, 2011 at 7:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 20 Apr 2011 17:41:41 +0100
>> From: David De La Harpe Golden <david@harpegolden.net>
>> Cc: 8492@debbugs.gnu.org, Reuben Thomas <rrt@sc3d.org>
>>
>> Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead
>> of "super" when you press the windows keys (testing in wine not real
>> windows), w32 emacs may also need to be adjusted to map them to
>> left/right super by default and treat them as modifiers.
>
> See w32-lwindow-modifier and w32-rwindow-modifier.  (And note the
> footnote in the Emacs manual's "Windows Keyboard" node about the
> caveats.)

Which are not guaranteed to work unless you use a low level keyboard
hook. See EmacsW32 repository for a path with this.

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Monnier]

> Having said that, no key binding is better than a clever key binding.
> Some uses of completion perhaps don't need a key (as for example many
> uses of code completion, which in other IDEs pop up a list of
> completions by default).

I think this one is a fallacy: popping up the menu may not need a key
binding, but you do need a key binding in order to select something from
that menu.  Admittedly, it changes the problem enough that the solution
may be simpler (e.g. M-n and M-p can be used for that whereas they don't
seem nearly as attractive for completion-at-point).


        Stefan

bug#8492: 23.3; Time to use a different binding for completion?

[Drew Adams]

> > Currently, the "usable default" is ESC TAB.
> 
> Which does not work at all if you use Viper.

We should not change Emacs default bindings based on the bindings of Viper - or
of any other emulator - or of any other mode etc.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 20 April 2011 23:48, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Having said that, no key binding is better than a clever key binding.
>> Some uses of completion perhaps don't need a key (as for example many
>> uses of code completion, which in other IDEs pop up a list of
>> completions by default).
>
> I think this one is a fallacy: popping up the menu may not need a key
> binding, but you do need a key binding in order to select something from
> that menu.  Admittedly, it changes the problem enough that the solution
> may be simpler (e.g. M-n and M-p can be used for that whereas they don't
> seem nearly as attractive for completion-at-point).

I should have been more precise, because I agree with you. I should
have said "perhaps doesn't need a global key binding".

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 20 April 2011 23:49, Drew Adams <drew.adams@oracle.com> wrote:
>> > Currently, the "usable default" is ESC TAB.
>>
>> Which does not work at all if you use Viper.
>
> We should not change Emacs default bindings based on the bindings of Viper - or
> of any other emulator - or of any other mode etc.

Well, any other mode whose operation involves changing the default
keymap. But otherwise, I agree with this sentiment: it's hard enough
making bindings fit into Emacs without worrying about other
essentially different bindings sets, other of course than the global
window manager bindings that made me raise this question in the first
place.

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Sean Sieger]

    Windows Vista and Windows 7 use Win+TAB to switch between windows in
    a more useless and annoying manner.  Sort of like a rolodex:
    http://thavarajah.dk/sites/thavarajah.dk/uploads/2007/01/vista_window_switch.png

Yep.

But you know, when I first encountered Windows 7, I got the distinct
impression (with precisely phenomena like the `rolodex' you refer to,
what, with Alt-TAB doing the slide across the app images and the
redundancy) that Microsoft was trying to keep up with the slickitiness
of Ubuntu.  Ubuntu's just as ugly and heavy.

bug#8492: 23.3; Time to use a different binding for completion?

[Deniz Dogan]

2011/4/21 Sean Sieger <sean.sieger@gmail.com>:
>    Windows Vista and Windows 7 use Win+TAB to switch between windows in
>    a more useless and annoying manner.  Sort of like a rolodex:
>    http://thavarajah.dk/sites/thavarajah.dk/uploads/2007/01/vista_window_switch.png
>
> Yep.
>
> But you know, when I first encountered Windows 7, I got the distinct
> impression (with precisely phenomena like the `rolodex' you refer to,
> what, with Alt-TAB doing the slide across the app images and the
> redundancy) that Microsoft was trying to keep up with the slickitiness
> of Ubuntu.  Ubuntu's just as ugly and heavy.
>

I wasn't hating on Windows for the rolodex thing, I'm just saying it's
useless.  That said, I'm not sure what window manager you're referring
to when you say Ubuntu.

bug#8492: 23.3; Time to use a different binding for completion?

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 21 Apr 2011 00:03:10 +0200
> Cc: David De La Harpe Golden <david@harpegolden.net>, 8492@debbugs.gnu.org, rrt@sc3d.org
> 
> On Wed, Apr 20, 2011 at 7:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Wed, 20 Apr 2011 17:41:41 +0100
> >> From: David De La Harpe Golden <david@harpegolden.net>
> >> Cc: 8492@debbugs.gnu.org, Reuben Thomas <rrt@sc3d.org>
> >>
> >> Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead
> >> of "super" when you press the windows keys (testing in wine not real
> >> windows), w32 emacs may also need to be adjusted to map them to
> >> left/right super by default and treat them as modifiers.
> >
> > See w32-lwindow-modifier and w32-rwindow-modifier.  (And note the
> > footnote in the Emacs manual's "Windows Keyboard" node about the
> > caveats.)
> 
> Which are not guaranteed to work unless you use a low level keyboard
> hook. See EmacsW32 repository for a path with this.

Yeah, yeah, yeah, and we must destroy Carthage, too.

(The part in parentheses in my message exactly referred to the caveats
of using these two keys.)

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Thu, Apr 21, 2011 at 12:49 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Currently, the "usable default" is ESC TAB.
>>
>> Which does not work at all if you use Viper.
>
> We should not change Emacs default bindings based on the bindings of Viper - or
> of any other emulator - or of any other mode etc.

Thanks for your view, Drew, but I found this statement of you just
unusable and unnecessary here.

bug#8492: 23.3; Time to use a different binding for completion?

[Drew Adams]

> >> > Currently, the "usable default" is ESC TAB.
> >>
> >> Which does not work at all if you use Viper.
> >
> > We should not change Emacs default bindings based on the 
> > bindings of Viper - or of any other emulator - or of any
> > other mode etc.
> 
> Thanks for your view, Drew, but I found this statement of you just
> unusable and unnecessary here.

You claim that a given default key "does not work at all" if you put yourself in
a special emulation mode.  So what?  If I play chess in checkers mode should I
expect the default, chess binding of each piece to still "work" in checkers?

This is a _default_ key binding we're talking about.  It is not _expected_ to
work in every possible mode.  It's especially narrow-sighted to demand that
Emacs default key bindings have their default effects in an _emulator_ mode such
as Viper.

Expecting default Emacs key bindings to all just "work" in a `vi' mode is
ridiculous - and you should know that.

You use Emacs as if it were `vi', and yet you expect all of Emacs, even its
default keys, to keep your personal practice front and center - all attention on
Lennart and what he's doing.  It's not about your own favorite mode or your very
UN-default use of Emacs.  This is about a _default_ key binding.

If Viper mode cannot handle a default key that you think it should be able to
handle, then fix Viper mode to fit your wish.  Don't ask default Emacs to worry
about Viper special needs.

An alternative: break out of the emulator closet once and for all.  Just use
`vi' itself.  Then you don't need to worry at all about Emacs and its krazy
keys.

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Thu, Apr 21, 2011 at 4:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> > Currently, the "usable default" is ESC TAB.
>> >>
>> >> Which does not work at all if you use Viper.
>> >
>> > We should not change Emacs default bindings based on the
>> > bindings of Viper - or of any other emulator - or of any
>> > other mode etc.
>>
>> Thanks for your view, Drew, but I found this statement of you just
>> unusable and unnecessary here.
>
> You claim that a given default key "does not work at all" if you put yourself in
> a special emulation mode.  So what?  If I play chess in checkers mode should I
> expect the default, chess binding of each piece to still "work" in checkers?

This is just plain stupid. Viper is not just any emulation mode. It
happen to be key bindings a lot of potential and current Emacs users
knows.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 21 April 2011 19:49, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 4:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>> >> > Currently, the "usable default" is ESC TAB.
>>> >>
>>> >> Which does not work at all if you use Viper.
>>> >
>>> > We should not change Emacs default bindings based on the
>>> > bindings of Viper - or of any other emulator - or of any
>>> > other mode etc.
>>>
>>> Thanks for your view, Drew, but I found this statement of you just
>>> unusable and unnecessary here.
>>
>> You claim that a given default key "does not work at all" if you put yourself in
>> a special emulation mode.  So what?  If I play chess in checkers mode should I
>> expect the default, chess binding of each piece to still "work" in checkers?
>
> This is just plain stupid. Viper is not just any emulation mode. It
> happen to be key bindings a lot of potential and current Emacs users
> knows.

I don't understand why there's even an argument here. Viper is a mode
with a radically different approach to keybinding, so what does it
have to do with the default keybindings? It's clearly unreasonable to
expect default single-chord keybindings to take it into account.

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Thu, Apr 21, 2011 at 9:34 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 21 April 2011 19:49, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 4:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>>> >> > Currently, the "usable default" is ESC TAB.
>>>> >>
>>>> >> Which does not work at all if you use Viper.
>>>> >
>>>> > We should not change Emacs default bindings based on the
>>>> > bindings of Viper - or of any other emulator - or of any
>>>> > other mode etc.
>>>>
>>>> Thanks for your view, Drew, but I found this statement of you just
>>>> unusable and unnecessary here.
>>>
>>> You claim that a given default key "does not work at all" if you put yourself in
>>> a special emulation mode.  So what?  If I play chess in checkers mode should I
>>> expect the default, chess binding of each piece to still "work" in checkers?
>>
>> This is just plain stupid. Viper is not just any emulation mode. It
>> happen to be key bindings a lot of potential and current Emacs users
>> knows.
>
> I don't understand why there's even an argument here. Viper is a mode
> with a radically different approach to keybinding, so what does it
> have to do with the default keybindings? It's clearly unreasonable to
> expect default single-chord keybindings to take it into account.

The same has been said about CUA-bindings. Both cua-mode and viper are
parts of Emacs and parts that many users depends on. There are other
emulations that are not that important. In fact I do not know of any
people still using the other emulations.

But the fact is that many people using Emacs depends on cua-mode and
viper. Not taking facts into account is not a good real world
reasoning.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> The same has been said about CUA-bindings. Both cua-mode and viper are
> parts of Emacs and parts that many users depends on. There are other
> emulations that are not that important. In fact I do not know of any
> people still using the other emulations.
>
> But the fact is that many people using Emacs depends on cua-mode and
> viper.

Sure, so from time to time those bindings have to be updated when new
incompatibilities arise with the default Emacs bindings. How is that a
big deal?

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Thu, Apr 21, 2011 at 10:14 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>
>> The same has been said about CUA-bindings. Both cua-mode and viper are
>> parts of Emacs and parts that many users depends on. There are other
>> emulations that are not that important. In fact I do not know of any
>> people still using the other emulations.
>>
>> But the fact is that many people using Emacs depends on cua-mode and
>> viper.
>
> Sure, so from time to time those bindings have to be updated when new
> incompatibilities arise with the default Emacs bindings. How is that a
> big deal?


The big deal is that it is Emacs that has to accommodate its default
bindings since the world outside is so much bigger.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 21 April 2011 21:55, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 10:14 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>> On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>
>>>
>>> But the fact is that many people using Emacs depends on cua-mode and
>>> viper.
>>
>> Sure, so from time to time those bindings have to be updated when new
>> incompatibilities arise with the default Emacs bindings. How is that a
>> big deal?
>
>
> The big deal is that it is Emacs that has to accommodate its default
> bindings since the world outside is so much bigger.

How is Viper or CUA the world outside? I filed this bug because of a
clash between Emacs and the "world outside", in this case, standard
window-manager bindings. But Viper and CUA are a) part of Emacs and b)
both have (to a greater extent in Viper's case, a lesser in CUA's) a
different and fundamentally incompatible approach to key binding from
Emacs's default. I still don't see, therefore, why it's necessary, or
even how it's possible for Emacs's default keybindings to take account
of them.

To give just one example each, Viper is, following vi, modal: keys
that in Emacs are always bound to self-insert-command are bound to
editing commands in viper's command mode; in CUA, C-x is used for cut,
whereas in Emacs's default bindings it's a prefix. So it's not even
hypothetical: there are already fundamental incompatibilities. Why,
therefore, the fuss about another (potential) incompatibility?

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Thu, Apr 21, 2011 at 11:08 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 21 April 2011 21:55, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 10:14 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>>> On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>
>>>>
>>>> But the fact is that many people using Emacs depends on cua-mode and
>>>> viper.
>>>
>>> Sure, so from time to time those bindings have to be updated when new
>>> incompatibilities arise with the default Emacs bindings. How is that a
>>> big deal?
>>
>>
>> The big deal is that it is Emacs that has to accommodate its default
>> bindings since the world outside is so much bigger.
>
> How is Viper or CUA the world outside?

They are mirrors of the outside world. And users of them want this
mirror to be exact in certain cases.

> To give just one example each, Viper is, following vi, modal: keys
> that in Emacs are always bound to self-insert-command are bound to
> editing commands in viper's command mode; in CUA, C-x is used for cut,
> whereas in Emacs's default bindings it's a prefix. So it's not even
> hypothetical: there are already fundamental incompatibilities. Why,
> therefore, the fuss about another (potential) incompatibility?

If you do not think this is a problem then I guess you also could
accept an argument for moving for example C-x in Emacs to another key?

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 22 April 2011 14:47, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 11:08 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>> How is Viper or CUA the world outside?
>
> They are mirrors of the outside world. And users of them want this
> mirror to be exact in certain cases.

We're talking at cross-purposes then.

> If you do not think this is a problem then I guess you also could
> accept an argument for moving for example C-x in Emacs to
> another key?

No, because that would change the default Emacs bindings in a major
way. No-one is suggesting changing them in a major way, and no-one is
suggesting changing Viper or CUA at all!

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Fri, Apr 22, 2011 at 7:33 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>
>> If you do not think this is a problem then I guess you also could
>> accept an argument for moving for example C-x in Emacs to
>> another key?
>
> No, because that would change the default Emacs bindings in a major
> way. No-one is suggesting changing them in a major way, and no-one is
> suggesting changing Viper or CUA at all!

Not in short time. But in the longer time we have been discussing
adjustment. I think the most probable way is to have a way to adjust
all key bindings so that they fit better with CUA. Though I doubt it
will be the default in our life time ;-)

bug#8492: 23.3; Time to use a different binding for completion?

[Sean Sieger]

Lennart Borgman <lennart.borgman@gmail.com> writes:

    This is just plain stupid. Viper is not just any emulation mode. It
    happen to be key bindings a lot of potential and current Emacs users
    knows.

Your valorization of Viper is no more valid than another's
devalorization of it.  I think Vi's great, what's so great about Emacs
that you cause it to behave like Vi?

bug#8492: 23.3; Time to use a different binding for completion?

[Sean Sieger]

Lennart Borgman <lennart.borgman@gmail.com> writes:

    The same has been said about CUA-bindings. Both cua-mode and viper are
    parts of Emacs and parts that many users depends on. There are other
    emulations that are not that important. In fact I do not know of any
    people still using the other emulations.

Oh, no, Lennart, you still don't know what I'm doing with Emacs in
private, let alone how `important' doing it is to me.

    But the fact is that many people using Emacs depends on cua-mode and
    viper. Not taking facts into account is not a good real world
    reasoning.

I'm trying to use my imagination to get my head around how you've come
to know this.

bug#8492: 23.3; Time to use a different binding for completion?

[Lennart Borgman]

On Fri, Apr 22, 2011 at 11:01 PM, Sean Sieger <sean.sieger@gmail.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>    The same has been said about CUA-bindings. Both cua-mode and viper are
>    parts of Emacs and parts that many users depends on. There are other
>    emulations that are not that important. In fact I do not know of any
>    people still using the other emulations.
>
> Oh, no, Lennart, you still don't know what I'm doing with Emacs in
> private, let alone how `important' doing it is to me.
>
>    But the fact is that many people using Emacs depends on cua-mode and
>    viper. Not taking facts into account is not a good real world
>    reasoning.
>
> I'm trying to use my imagination to get my head around how you've come
> to know this.

If you try harder you may succeed.

bug#8492: 23.3; Time to use a different binding for completion?

[Chong Yidong]

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

>> Is it therefore time to admit defeat and find an alternative binding for
>> completion functions, even if it’s an extra binding rather than simply a
>> different one?
>
> TAB can do completion if you (setq tab-always-indent 'complete).

I tried this out some time ago, but found it unsatisfactory.  The
problem was that I sometimes spuriously triggered completion when I only
intended to indent, because the current line happened to be correctly
indented.  It is often difficult to tell by eye whether a line is
already indented.

(Another related topic is that of binding TAB to lisp-complete-symbol in
read-expression-map; this was brought up on emacs-devel some time ago,
but the discussion petered out IIRC.)

bug#8492: 23.3; Time to use a different binding for completion?

[Drew Adams]

> > TAB can do completion if you (setq tab-always-indent 'complete).
> 
> I tried this out some time ago, but found it unsatisfactory.  The
> problem was that I sometimes spuriously triggered completion 
> when I only intended to indent, because the current line happened
> to be correctly indented.  It is often difficult to tell by eye
> whether a line is already indented.

Amen.  Another case of DWIM making the user work harder, forcing her to try to
second-guess it and figure out whether it will in fact DTRT in the current
context.  As I said:

>> Keep it simple.  Find a key or let users find their own key 
>> for a simple, straightforward command (i.e., that does only
>> what M-TAB does currently).  Forget about combining 36
>> different behaviors on the same key.
...
>> But please do not redesign the behavior to become hydra-headed
>> so it tries to adapt to multiple contexts, just because you
>> cannot think of a good default key.  That makes little sense.
>> 
>> And TAB, in particular, is *not* "the way forward for this".  
>> If ever there was a key *not* to double-up on for this (triple?
>> quadruple? pentuple?), TAB is it.  It's just about the poorest
>> choice possible here.

Simple, straightforward commands/keys give the user control (not the clever
programmer).

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas]

On 24 April 2011 19:08, Chong Yidong <cyd@stupidchicken.com> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Is it therefore time to admit defeat and find an alternative binding for
>>> completion functions, even if it’s an extra binding rather than simply a
>>> different one?
>>
>> TAB can do completion if you (setq tab-always-indent 'complete).
>
> I tried this out some time ago, but found it unsatisfactory.  The
> problem was that I sometimes spuriously triggered completion when I only
> intended to indent, because the current line happened to be correctly
> indented.  It is often difficult to tell by eye whether a line is
> already indented.

I feared as much. Thanks for the input, I'll avoid wasting my time on
the experiment.

-- 
http://rrt.sc3d.org

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Kangas]

Reuben Thomas <rrt@sc3d.org> writes:

> Emacs binds various completion functions to M-Tab, which is already used
> by many window managers, including Compiz and Metacity, i.e. the WMs one
> is likely to use on a modern GNU system, for switching between open
> windows.
>
> Is it therefore time to admit defeat and find an alternative binding for
> completion functions, even if it’s an extra binding rather than simply a
> different one?

(This is a long and sprawling discussion.)

In my opinion, the least intrusive change is to allow C-i and TAB to be
bound separately on graphical displays.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On Thu, 21 Oct 2021 at 20:44, Stefan Kangas <stefan@marxist.se> wrote:

>
> In my opinion, the least intrusive change is to allow C-i and TAB to be
> bound separately on graphical displays.
>

Ingenious!

In the mean time, I have solved the problem personally by using Super
rather than Alt/Meta for all my window manager bindings; but I'm conscious
that this won't help many users who never rebind system keys.

-- 
https://rrt.sc3d.org

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

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Kangas]

Reuben Thomas <rrt@sc3d.org> writes:

> On Thu, 21 Oct 2021 at 20:44, Stefan Kangas <stefan@marxist.se> wrote:
>
>>
>> In my opinion, the least intrusive change is to allow C-i and TAB to be
>> bound separately on graphical displays.
>>
>
> Ingenious!

And potentially controversial, but we will see.  ;-)

> In the mean time, I have solved the problem personally by using Super
> rather than Alt/Meta for all my window manager bindings; but I'm conscious
> that this won't help many users who never rebind system keys.

Indeed.  I'm not the biggest fan of the method of "fixing" issues by
telling users to rebind keys locally.  The problem here is universal.

bug#8492: 23.3; Time to use a different binding for completion?

[Phil Sainty]

On 2021-10-22 08:44, Stefan Kangas wrote:
> In my opinion, the least intrusive change is to allow C-i and TAB
> to be bound separately on graphical displays.

You can already bind <tab> independently of TAB / C-i on graphical
displays.

(I don't see how you could separate C-i and TAB because they're
literally the same thing.)


> I'm not the biggest fan of the method of "fixing" issues by telling
> users to rebind keys locally.  The problem here is universal.

IMHO there's very little point in trying to account for window
managers using Ctrl or Meta.  That's inevitably going to be disruptive
to Emacs users, and will most likely affect a lot more than just TAB.

I've used a bunch of window managers, and I can't remember a single
one where I didn't configure it to disable most of its bindings, and
move the things I was keeping to non-conflicting sequences.

I see it as a normal part of configuring a system, if you use Emacs.


-Phil

bug#8492: 23.3; Time to use a different binding for completion?

[Stefan Kangas]

Phil Sainty <psainty@orcon.net.nz> writes:

> You can already bind <tab> independently of TAB / C-i on graphical
> displays.

I didn't know that, thanks.

> IMHO there's very little point in trying to account for window
> managers using Ctrl or Meta.  That's inevitably going to be disruptive
> to Emacs users, and will most likely affect a lot more than just TAB.

I see your point.  Some bindings are indeed specific to this or that
window manager, and trying to accommodate for that sounds like a losing
battle.

But Alt+Tab specifically is pretty ubiquitous these days.

bug#8492: 23.3; Time to use a different binding for completion?

[Lars Ingebrigtsen]

Reuben Thomas <rrt@sc3d.org> writes:

> Emacs binds various completion functions to M-Tab, which is already used
> by many window managers, including Compiz and Metacity, i.e. the WMs one
> is likely to use on a modern GNU system, for switching between open
> windows.
>
> Is it therefore time to admit defeat and find an alternative binding for
> completion functions, even if it’s an extra binding rather than simply a
> different one?

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I have somehow never considered that `completion-at-point' was supposed
to be on `M-TAB', because the Emacs help system only mentions it as
`C-M-i'...  but `C-i' is, of course, `TAB', and with an added Meta,
that's `M-TAB' alright.  🙃

Anyway, I agree that `M-TAB' is a bad choice for a key binding this
days, since many of the window systems out there steal the key, and
therefore an important thing like completion doesn't work logically out
of the box for many people.

`C-TAB' is free, of course, but doesn't work on terminals, and I guess
the same is the case with all other modifier+TAB combinations.  So I
don't know what we could do -- we could bind `C-TAB' for the GUI people,
for instance?

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

bug#8492: 23.3; Time to use a different binding for completion?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I have somehow never considered that `completion-at-point' was supposed
> to be on `M-TAB', because the Emacs help system only mentions it as
> `C-M-i'...  but `C-i' is, of course, `TAB', and with an added Meta,
> that's `M-TAB' alright.  🙃
>
> Anyway, I agree that `M-TAB' is a bad choice for a key binding this
> days, since many of the window systems out there steal the key, and
> therefore an important thing like completion doesn't work logically out
> of the box for many people.
>
> `C-TAB' is free, of course, but doesn't work on terminals, and I guess
> the same is the case with all other modifier+TAB combinations.  So I
> don't know what we could do -- we could bind `C-TAB' for the GUI people,
> for instance?

FWIW, I'm happy with typing C-M-i.  I have no opinion about also binding
C-<tab>, as long as M-<tab> doesn't go away.

bug#8492: 23.3; Time to use a different binding for completion?

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On Fri, 29 Apr 2022 at 13:38, Lars Ingebrigtsen <larsi@gnus.org> wrote:

>
> Anyway, I agree that `M-TAB' is a bad choice for a key binding this
> days, since many of the window systems out there steal the key, and
> therefore an important thing like completion doesn't work logically out
> of the box for many people.
>

Indeed, it won't work for most potential new users.


> `C-TAB' is free, of course, but doesn't work on terminals, and I guess
> the same is the case with all other modifier+TAB combinations.  So I
> don't know what we could do -- we could bind `C-TAB' for the GUI people,
> for instance?
>

C-TAB is a good choice for a binding that won't conflict with the
environment, as it's widely used by other programs for "switch tab", so
it's unlikely that any window manager would steal it by default.

-- 
https://rrt.sc3d.org

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

bug#8492: 23.3; Time to use a different binding for completion?

[Lars Ingebrigtsen]

Reuben Thomas <rrt@sc3d.org> writes:

> C-TAB is a good choice for a binding that won't conflict with the
> environment, as it's widely used by other programs for "switch tab",
> so it's unlikely that any window manager would steal it by default.

I'd forgotten that we do that, too.  :-)  When you have tab-bar-mode
switched on, then `C-TAB' switches between tabs.

So that's a no go for completion...

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

bug#8492: 23.3; Time to use a different binding for completion?

[Drew Adams]

> `M-TAB' is a bad choice for a key binding this
> days, since many of the window systems out there steal the key, and
> therefore an important thing like completion doesn't work logically out
> of the box for many people.

`M-TAB' is a fine key for this, IMO.
(And I'm on MS Windows, so I need to use
`w32-register-hot-key'.)

ESC TAB works out of the box for everyone, no?
If not then nearly everyone.

Just make clear(er) in the doc that you can use
ESC TAB.  If you feel it's necessary because of
this window-systems problem, then make that the
advertised binding
(`set-advertised-calling-convention').