A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00425.html below:

Re: Help sought understanding shorthands wrt modules/packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Gerd Möllmann Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Tue, 8 Nov 2022 11:35:59 +0100 User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 
On 08.11.22 10:54, João Távora wrote:
On Tue, Nov 8, 2022, 06:20 Gerd Möllmann <gerd.moellmann@gmail.com <mailto:gerd.moellmann@gmail.com>> wrote: 
    .

    BTW, in light of what I read now on emacs-devel in various threads,
    I take my questions about the design of shorthands and there use instead
    of modules/packages back, because there is no design.
I find this characterization a bit unfair. There was and is a design, a fairly small one and one aimed primarily at solving a particular problem, which wouldn't be possible with CL packages. 
Sorry for having been a battleaxe :-).

I know that part, and I think it's likely a good tool when meeting
realities like dash and s and so on.

What I meant was using shorthands as the basis for a general mechanism
that somehow solves a "problem" that other languages use modules for.  I
mean, a design, or at least what I understand under a design, should
have at least briefly considered things like Eldoc, xref, completions,
and what else there is.  I didn't see/hear this, and it only slowly
comes up and generates "we could do this or that".  TBH, that reminds me
a bit of Greenspun's tenth.

But anyways, the ship has sailed.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4