[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs
From: |
Eli Zaretskii |
Subject: |
bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs |
Date: |
Sat, 02 Oct 2021 17:20:42 +0300 |
> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 2 Oct 2021 15:02:41 +0100
> Cc: Phil Sainty <psainty@orcon.net.nz>, 50959@debbugs.gnu.org
>
> > > 0. no integration
> > >
> > > 1. This is the current integration. I.e. when C-h o is pressed on the
> > > symbol the global name is discovered and used as the default. This
> > > is how SLIME work with CL's namespacing system. SLIME is a very well
> > > tested and widely appreciated Common Lisp IDE for Emcas.
> > >
> > > 2. The shorthands from the buffer where the minibuffer was entered are
> > > _not_ in the completions list, but typing one of them interns the
> > > symbol with those shorthands present, so you get the desired result.
> > > This would fix Phil's visually-copy-and-type scenario.
> > >
> > > 3. (Eli's suggestion): the completion list would be augmented with the
> > > shorthands from the buffer where the minibuffer was entered from.
> >
> > Are 2 and 3 significantly different (from the implementation POV)?
>
> I think so.
>
> I think 2 can be achieved by setting elisp-shorthands buffer-locally
> in the minibuffer and removing the "require-match" flag requirement to
> whatever completing-read call happens there.
>
> 3 is achieved by calculating the list of completions using
> 'elisp--completion-local-symbols` and then filtering it down as usual.
> "require-match" is kept untouched.
You are saying that 3 is easier than 2? Then I think we should do 3,
as it's better from the user's POV, right?
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Phil Sainty, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs,
Eli Zaretskii <=
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Richard Stallman, 2021/10/03
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Richard Stallman, 2021/10/03