GNU bug report logs - #51371
28.0.50; [PATCH] Make list-colors-display sorting support general

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51371 in the body.
You can then email your comments to 51371 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: dalanicolai <dalanicolai <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; [PATCH] Make list-colors-display sorting support general
Date: Sun, 24 Oct 2021 11:35:47 +0200

[Message part 1 (text/plain, inline)]

Motivation for this patch is that I would like to use the following code
snippet in https://elpa.gnu.org/packages/sketch-mode.html.

```
(let ((list-colors-sort 'hsv))
  (list-colors-display (mapcar #'car shr-color-html-colors-alist)
                       nil))
```

The snippet passes colors form the shr-color-html-colors-alist variable
to list-colors-display. However, currently, despite the docstring
suggesting to me something different, the list-colors-display function
only applies its sort functionality if no list is passes as argument.
I don't see a good reason for that limitation, because the limitation is
set using a when condition, while the sort function works perfectly fine
with custom color-lists (e.g. try the snippet above).

So this patch simply removes the (when (null list)) condition, and
passes the list, if given, to the sort functionality.
Adapting the docstring is not necessary as it already suggests that the
sort functionality works in general.

With this patch, I can offer a great sorted color selection menu,
providing only colors supported by SVG.


In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.17.4)
 of 2021-09-06 built on daniel-fedora
Repository revision: c4724add006e62b81f847937db56335a81bdcc74
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --with-mailutils --with-cairo --with-modules --with-pgtk
 --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 67179 6847)
 (symbols 48 6625 0)
 (strings 32 19309 1709)
 (string-bytes 1 660631)
 (vectors 16 13095)
 (vector-slots 8 260900 12229)
 (floats 8 22 32)
 (intervals 56 225 0)
 (buffers 992 11))

[Message part 2 (text/html, inline)]

[facemenu.patch (text/x-patch, attachment)]

Message #8 received at 51371 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: dalanicolai <dalanicolai <at> gmail.com>
Cc: 51371 <at> debbugs.gnu.org
Subject: Re: bug#51371: 28.0.50; [PATCH] Make list-colors-display sorting
 support general
Date: Sun, 24 Oct 2021 05:47:07 -0700

dalanicolai <dalanicolai <at> gmail.com> writes:

> The snippet passes colors form the shr-color-html-colors-alist variable
> to list-colors-display. However, currently, despite the docstring
> suggesting to me something different, the list-colors-display function
> only applies its sort functionality if no list is passes as argument.
> I don't see a good reason for that limitation, because the limitation is
> set using a when condition, while the sort function works perfectly fine
> with custom color-lists (e.g. try the snippet above).
>
> So this patch simply removes the (when (null list)) condition, and
> passes the list, if given, to the sort functionality.
> Adapting the docstring is not necessary as it already suggests that the  sort functionality works in general.

Is there any situation in which you wouldn't want the list sorted?

Message #13 received at 51371 <at> debbugs.gnu.org (full text, mbox):

From: dalanicolai <dalanicolai <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51371 <at> debbugs.gnu.org
Subject: Re: bug#51371: 28.0.50; [PATCH] Make list-colors-display sorting
 support general
Date: Sun, 24 Oct 2021 15:16:12 +0200

[Message part 1 (text/plain, inline)]

(@stefan Did not notice it was a group message)

Not really, I think. But if so then I guess we could just call it with
list-colors-sort set to nil:
```
(let ((list-colors-sort 'nil))
  (list-colors-display (mapcar #'car shr-color-html-colors-alist)
                       nil))
```



On Sun, 24 Oct 2021 at 14:47, Stefan Kangas <stefan <at> marxist.se> wrote:

> dalanicolai <dalanicolai <at> gmail.com> writes:
>
> > The snippet passes colors form the shr-color-html-colors-alist variable
> > to list-colors-display. However, currently, despite the docstring
> > suggesting to me something different, the list-colors-display function
> > only applies its sort functionality if no list is passes as argument.
> > I don't see a good reason for that limitation, because the limitation is
> > set using a when condition, while the sort function works perfectly fine
> > with custom color-lists (e.g. try the snippet above).
> >
> > So this patch simply removes the (when (null list)) condition, and
> > passes the list, if given, to the sort functionality.
> > Adapting the docstring is not necessary as it already suggests that the
> sort functionality works in general.
>
> Is there any situation in which you wouldn't want the list sorted?
>

[Message part 2 (text/html, inline)]

Message #16 received at 51371 <at> debbugs.gnu.org (full text, mbox):

From: dalanicolai <dalanicolai <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51371 <at> debbugs.gnu.org
Subject: Re: bug#51371: 28.0.50; [PATCH] Make list-colors-display sorting
 support general
Date: Sun, 24 Oct 2021 15:18:40 +0200

[Message part 1 (text/plain, inline)]

The nil (again) without the quote of course

On Sun, 24 Oct 2021 at 15:16, dalanicolai <dalanicolai <at> gmail.com> wrote:

> (@stefan Did not notice it was a group message)
>
> Not really, I think. But if so then I guess we could just call it with
> list-colors-sort set to nil:
> ```
> (let ((list-colors-sort 'nil))
>   (list-colors-display (mapcar #'car shr-color-html-colors-alist)
>                        nil))
> ```
>
>
>
> On Sun, 24 Oct 2021 at 14:47, Stefan Kangas <stefan <at> marxist.se> wrote:
>
>> dalanicolai <dalanicolai <at> gmail.com> writes:
>>
>> > The snippet passes colors form the shr-color-html-colors-alist variable
>> > to list-colors-display. However, currently, despite the docstring
>> > suggesting to me something different, the list-colors-display function
>> > only applies its sort functionality if no list is passes as argument.
>> > I don't see a good reason for that limitation, because the limitation is
>> > set using a when condition, while the sort function works perfectly fine
>> > with custom color-lists (e.g. try the snippet above).
>> >
>> > So this patch simply removes the (when (null list)) condition, and
>> > passes the list, if given, to the sort functionality.
>> > Adapting the docstring is not necessary as it already suggests that
>> the  sort functionality works in general.
>>
>> Is there any situation in which you wouldn't want the list sorted?
>>
>

[Message part 2 (text/html, inline)]

Message #19 received at 51371 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: dalanicolai <dalanicolai <at> gmail.com>
Cc: 51371 <at> debbugs.gnu.org
Subject: Re: bug#51371: 28.0.50; [PATCH] Make list-colors-display sorting
 support general
Date: Sun, 24 Oct 2021 15:08:47 -0700

dalanicolai <dalanicolai <at> gmail.com> writes:

> (@stefan Did not notice it was a group message)
>
> Not really, I think. But if so then I guess we could just call it with
> list-colors-sort set to nil:
> ```
> (let ((list-colors-sort 'nil))
                          ^ no need to quote nil, BTW.
>   (list-colors-display (mapcar #'car shr-color-html-colors-alist)
>                        nil))
> ```

Do we have any data from e.g. GNU ELPA, MELPA, GitHub or something to
back that up?

I checked, and we have only one call to `list-colors-display' in the
Emacs tree: in `widget-color--choose-action'.  Does that function still
work as it should with your patch?

Message #22 received at 51371 <at> debbugs.gnu.org (full text, mbox):

From: dalanicolai <dalanicolai <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51371 <at> debbugs.gnu.org
Subject: Re: bug#51371: 28.0.50; [PATCH] Make list-colors-display sorting
 support general
Date: Mon, 25 Oct 2021 23:46:20 +0200

[Message part 1 (text/plain, inline)]

I see, it is called when setting the face foreground/background via the
customize menu.
I've tested it, and it works still perfectly fine (as expected...
predicting the expected
effects/implications in this case seems quite straightforward to me).

On Mon, 25 Oct 2021 at 00:08, Stefan Kangas <stefan <at> marxist.se> wrote:

> dalanicolai <dalanicolai <at> gmail.com> writes:
>
> > (@stefan Did not notice it was a group message)
> >
> > Not really, I think. But if so then I guess we could just call it with
> > list-colors-sort set to nil:
> > ```
> > (let ((list-colors-sort 'nil))
>                           ^ no need to quote nil, BTW.
> >   (list-colors-display (mapcar #'car shr-color-html-colors-alist)
> >                        nil))
> > ```
>
> Do we have any data from e.g. GNU ELPA, MELPA, GitHub or something to
> back that up?
>
> I checked, and we have only one call to `list-colors-display' in the
> Emacs tree: in `widget-color--choose-action'.  Does that function still
> work as it should with your patch?
>

[Message part 2 (text/html, inline)]

Message #25 received at 51371 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: dalanicolai <dalanicolai <at> gmail.com>
Cc: 51371 <at> debbugs.gnu.org
Subject: Re: bug#51371: 28.0.50; [PATCH] Make list-colors-display sorting
 support general
Date: Sat, 30 Oct 2021 08:40:34 -0700

close 51371 29.1
thanks

dalanicolai <dalanicolai <at> gmail.com> writes:

> I see, it is called when setting the face foreground/background via the customize menu.
> I've tested it, and it works still perfectly fine (as expected... predicting the expected
> effects/implications in this case seems quite straightforward to me).

OK, I think you are correct, and furthermore a caller can disable
sorting themselves by let-binding `list-colors-sort'.  So I've pushed
your patch to master, after fixing it up to follow our conventions for
ChangeLog, etc.  (See commit eb07b3d9b3.)

However, I skipped this hunk,

    @@ -542,8 +542,7 @@ list-colors-display
     colors that the current display can handle.  Customize
     `list-colors-sort' to change the order in which colors are shown.
     Type \\<help-mode-map>\\[revert-buffer] after customizing \
    -`list-colors-sort' to redisplay colors in
    -the new order.
    +`list-colors-sort' to redisplay colors in the new order.

     If the optional argument BUFFER-NAME is nil, it defaults to \"*Colors*\".

as it would lead to this incorrectly filled docstring,

    Display names of defined colors, and show what they look like.
    If the optional argument LIST is non-nil, it should be a list of
    colors to display.  Otherwise, this command computes a list of
    colors that the current display can handle.  Customize
    ‘list-colors-sort’ to change the order in which colors are shown.
    Type g after customizing ‘list-colors-sort’ to redisplay colors in
the new order.

You had missed that "\" character, which indicates a continued line.

In the future, you could send the patch using "git format-patch -1 HEAD"
to get a full git patch with your author details already filled in.
That makes it easier for us to install.  Thanks for the patch!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.