emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI


From: João Távora
Subject: Re: Emacs completion matches selection UI
Date: Mon, 30 Dec 2013 16:32:17 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>  Does it not then follow that part of creating a more uniform completion
>> experience ought to include direct Emacs support for that pattern?  The
>> alternative is today's hodgepodge of per-package idiosyncratic redefinition
>> mechanisms.
>
> Yes.  We should make it easier to extend indent-for-tab-command.

Do you think it's possible/desirable to generalize this mechanism (to
support the "fallback-maybe" pattern) so that we can make it easier to
extend any command, not just indent-for-tab-command?

In other words, I believe this could be useful for any binding. I've yet
to think of a nice interface, here's just a thought

(define-fallbackish-command maybe-foo (kbd "[somekey]") ()
  (interactive)
  (if (foop)
      (foo)
      (fallback)))

(define-fallbackish-command maybe-bar (kbd "[somekey]") (args...)
  (interactive ...)
  (if (barp)
      (bar)
      (fallback)))

Now, in a buffer where the active binding (set in whatever manner and
following the normal priority rules) for [somekey] is maybe-bar:

* if (barp) returns true, (bar) is run

* if (barp) fails and (foop) return true, (foo) is run

* if both (barp) and (foop) fail, we get the original keybinding
  [somekey], or nothing if it wasn't bound.

In a buffer where the active binding for [somekey] is maybe-foo, only
(foo) can ever be run, maybe-bar doesn't enter into play, because it was
defined later.

Also note that the fallback doesn't have to be mutually exclusive with
the actual (bar) and (foo) calls, I just thought of this example.

João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]