bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs


From: João Távora
Subject: bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs
Date: Sat, 2 Oct 2021 15:02:41 +0100

On Sat, Oct 2, 2021 at 1:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Cc: psainty@orcon.net.nz,  50959@debbugs.gnu.org
> > Date: Sat, 02 Oct 2021 12:54:13 +0100
> >
> > 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.

João





reply via email to

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