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

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

bug#78794: [PATCH] Pretiffy package-menu


From: Elijah Gabe Pérez
Subject: bug#78794: [PATCH] Pretiffy package-menu
Date: Mon, 16 Jun 2025 13:52:32 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50

Philip Kaludercic <philipk@posteo.net> writes:

>>> +(defcustom package-menu-marks-indicators
>>> +  '((install . "I")
>>> +    (delete . "D"))
>>> +  "Alist indicators to indicate a package is marked to install or delete.
>>> +The value of each list must be in the formt: '(KIND . MARK) where KIND
>>> +is the kind mark performed (`install' or `delete') in package-menu and
>>> +MARK a string to use for mark the packages.  This currently support
>>> +marks for install and delete."
>
> What is the reason we would want to customise this in the first place?

IMO, the I and D characters looks somewhat ugly to me, making them
customizable allows to change them to an Unicode/Emoji icon (or any
other character), making them more recognizable according to the user's
preferences (e.g. 🗑️/♻️ and ✅).

>> This doc string has several grammatical issues, and also lacks some
>> important information.  I suggest to rephrase as follows:
>>
>>    "Indicators for packages to be installed or deleted.
>>  The value is an alist whose elements have the form (KIND . MARK),
>>  where KIND is the operation to perform, either `install' or `delete',
>>  and MARK is a string to indicate that the operation is pending for
>>  the package.  The MARK string should satisfy the requirements of the
>>  TAG argument of `tabulated-list-put-tag', which see.  It is displayed
>>  in the padding area of the package's line.
>>
>>  Currently, only indicators for installing or deleting a package are
>>  supported."
>>
>>> +  :type '(list (cons symbol string)
>>> +               (cons symbol string))
>>
>> Can we come up with a meaningful :tag for the value?
>
> (I haven't check it, but...) is this the type of
> `package-menu-marks-indicators'?  If so, we shouldn't document the user
> option as an Alist.

But what other name would be better?

Honestly I decided to make this option a list instead of making a
separated option for each mark, this is in case there are plans to add
more options/marks in the future.

-- 
                                          - E.G via GNU Emacs and Org.





reply via email to

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