emacs-devel
[Top][All Lists]
Advanced

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

Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorth


From: Eli Zaretskii
Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)
Date: Thu, 30 Sep 2021 17:12:17 +0300

> Date: Fri, 01 Oct 2021 01:23:48 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Alan Mackenzie <acm@muc.de>, joaotavora@gmail.com, emacs-devel@gnu.org
> 
> On 2021-09-29 08:29, Eli Zaretskii wrote:
> > I'm not aware of any plans to use shorthands in Emacs itself.
> 
> No doubt; but that doesn't prevent people using them in
> libraries which are subsequently proposed for contribution to
> Emacs or ELPA.

If we decide we don't want that except in the few cases which it's
supposed to solve, then we will ask the authors to kindly not use that
in the packages submitted to ELPA, certainly to the core.

> This use-case is an extremely limited one, targeted (AFAIU) at
> an *extremely* small number of libraries; so the impact is quite
> limited.

The problem is not with the number of libraries, the problem is with
the libraries that _use_ those few.  They are a lot.

> Alan's examples will probably be real -- people will put all
> kinds of shorthand declarations into their third-party code,
> including shorthands for core features, just because they can,
> and because it's an officially-supported feature.

If we decide we don't want that, we won't allow that.

> 1. A way of displaying long symbols in the desired short form,
>     such that the buffer contains the actual symbol, but the
>     user sees the short symbol (i.e. some kind of replacing
>     display).

I very much doubt that display-time feature can solve this, because it
will not be supported by Lisp itself.  And then you have worse
problems.

> 2. Something analogous to abbrev which recognises when someone
>     starts typing a symbol with one of the configured short
>     prefixes, and expands it to be the full name (but per (1)
>     visually displayed as the short form that they typed).

Are you thinking about M-/ ?  That already exists, and I'm using it
all the time, not only in Lisp.  Long identifiers are ubiquitous these
days, and long words in human-readable text are as well.

I really don't understand why you and Alan (and others) are so
worried.  Use of this feature is entirely optional, and if we are
afraid this will somehow slip into the parts of Emacs we don't want,
let's augment CONTRIBUTE to prevent that.  Me, I think it's no more
dangerous than someone trying to sneak files without lexical-binding
into Emacs: it will be immediately caught and flagged, because several
people watch the commits closely enough.



reply via email to

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