[Top][All Lists]

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

Re: A read-based grep-like for symbols (el-search?) (was Do shorthands b

From: Richard Stallman
Subject: Re: A read-based grep-like for symbols (el-search?) (was Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master))
Date: Thu, 07 Oct 2021 18:21:04 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

For reference, these are the two use-cases:

  > > * Creating longer real names to avoid collisions. In this kind of case 
  > > the package that you load creates shorthands for itself, which rename 
  > > its symbols to longer names that won't conflict.  This is what we will 
  > > do with s.el.
  > >
  > > * Creating shorter names for convenience. In this kind of case, one Lisp 
  > > file would create shorthand prefixes for code in other files.  These 
  > > prefixes might really be shorter than the symbols' documented name.

You wrote:

  > (1) the need for a solution to the first use case is essentially a 
  > consequence of the absence of a solution to the second use case (IOW, a 
  > few library authors have chosen to use short prefixes in their libraries 
  > to make them more appealing to use),

It might be true that the existence _in the past_ of a system for
shortening the names of symbols in another package would have avoided
making libraries whose own name prefixes are "s-" and "-".  We can't be

It does not follow that adding such a system now would eliminate the
problem that those short prefixes cause.  I don't think it would.

People have proposed conventions to use particular punctuation characters
to indicate a shortened prefix -- such as `s:', perhaps.  And maybe
that's what we should do.  But programs that do (require 's) don't
start those symbols with `s:'.  They start them with `s-'.

  > (4) a solution to the first use case cannot be a long term solution,

We need a long term solution, and that's what this is intended to be.
It is a good solution because it avoids the need to convince hundreds,
perhaps thousands, of library authors that we are not in communication
with to change the way they write calls to Magnars's libraries.

Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

reply via email to

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