emacs-devel
[Top][All Lists]
Advanced

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

Re: A proposal for a friendlier Emacs


From: Alexander Adolf
Subject: Re: A proposal for a friendlier Emacs
Date: Thu, 01 Oct 2020 18:13:50 +0200

Hello Eli,

Eli Zaretskii <eliz@gnu.org> writes:

> [...] 
>> > For example, one can assign CC Mode to the category "programming
>> > languages", then it will be in the same category as perl.el, python.el
>> > and fortran.el.
>> > [...]
>> 
>> Where does this assignment happen, on the user's local machine or on the
>> package repository website (or yet another place?), what semantics are
>> associated with that assignment, and how are these semantics exposed to
>> the user?
>
> I don't know.  It's the semantics you proposed, so you know what you
> had in mind.  However, I don't see how that could matter, because the
> problem is a fundamental one, and doesn't depend on the semantics of
> the category.

It seems I'm trying to be too abstract to get things across. Let me try
to approach it from the solution space:

1. On the ELPA package repository, a new attribute would be added to the
   package database. The attribute type would be based on string, with
   restrictions suited to make the value usable as a filename. For each
   new package uploaded to ELPA, the author would be encouraged to fill
   in a value for the new attribute.

2. When a new package is installed locally, the Emacs user would be
   prompted under which headline or keyword he wants the package's
   config to be added to the init files. The value of the new ELPA
   attribute would offered as the default choice at the prompt.

3. With the value chosen by the user in the previous step, Custom would
   look for a file named ~/.emacs.d/setup-<user-chosen-value>.el, and
   create it if it doesn't already exist. Custom would then search that
   file for a section for the new package (using some magic-comment
   convention as I for instance described in my earlier post). If a
   section already exists, job done. If no section for the new package
   exists, Custom would create one, and fill in the default init code
   for the package (as defined by the package author in the package's
   documentation). If there is no init code to insert, Custom would just
   insert an empty magic-comment section for the new package.


>From what I understood of your comments, you seem to claim that local
users choosing different names in step #2 would cause a problem?

Looking forward to your thoughts,

  --alexander



reply via email to

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