bug#40990: Improve message-mode and isearch icons

bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

As discussed previously in the "Why is emacs so square?" thread, here's
a couple of patches that improve the toolbar icons in GTK builds.

Attached are several screenshots from my machine: isearch toolbar with
the x-gtk-stock-map patch and without (the difference is one icon), and
message-mode toolbar without the patch, with the patch, and also with
the extra patch that makes message-tool-bar-retro use the standrd
"mail/send" icon instead of the Gnus-specific one. Fixing Emacs not to
use message-tool-bar-retro is left as a future exercise.

I'd like to present a few arguments for the inclusion of the
x-gtk-stock-map patch in Emacs 27 (on which the current answer is no,
but I'll try to elaborate):

1. With it, the answer to the question "why does everybody tell the new
users to turn off toolbars" becomes less obvious, at least in GTK based
environments.

2. This only affects GTK. And also, if a theme doesn't contain the "new"
replacement image, the previous one will be shown instead.

3. Since "everybody" turns off the toolbars now, the risk of complaints
is pretty low. By the same token, we could de-prioritize said complaints
even if they appear, given that for most people the improvement is most
likely obvious (feedback welcome).

The second patch is a tiny bit more risky, but honestly, since it uses
an icon apparently borrowed from some old GTK-related icon set, using a
new version of the same icon shouldn't bother most people. But this
patch *can* affect users on different toolkits and different platforms
(again, feedback welcome).

[-- Attachment #2: message-tool-bar-retro.diff --]
[-- Type: text/x-patch, Size: 473 bytes --]

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index adefa0efd6..62cbc754bd 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -7983,7 +7983,7 @@ message-tool-bar-gnome
 
 (defcustom message-tool-bar-retro
   '(;; Old Emacs 21 icon for consistency.
-    (message-send-and-exit "gnus/mail-send")
+    (message-send-and-exit "mail/send")
     (message-kill-buffer "close")
     (message-dont-send "cancel")
     (mml-attach-file "attach" mml-mode-map)

[-- Attachment #3: x-gtk-stock-map.diff --]
[-- Type: text/x-patch, Size: 2199 bytes --]

diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 5b8feb14a5..d7bc64fa52 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -1407,13 +1407,13 @@ x-gtk-stock-map
     ("etc/images/right-arrow" . ("go-next" "gtk-go-forward"))
     ("etc/images/home" . ("go-home" "gtk-home"))
     ("etc/images/jump-to" . ("go-jump" "gtk-jump-to"))
-    ("etc/images/index" . "gtk-index")
+    ("etc/images/index" . ("gtk-search" "gtk-index"))
     ("etc/images/exit" . ("application-exit" "gtk-quit"))
     ("etc/images/cancel" . "gtk-cancel")
     ("etc/images/info" . ("dialog-information" "gtk-info"))
     ("etc/images/bookmark_add" . "n:bookmark_add")
     ;; Used in Gnus and/or MH-E:
-    ("etc/images/attach" . "gtk-attach")
+    ("etc/images/attach" . ("mail-attachment" "gtk-attach"))
     ("etc/images/connect" . "gtk-connect")
     ("etc/images/contact" . "gtk-contact")
     ("etc/images/delete" . ("edit-delete" "gtk-delete"))
@@ -1425,12 +1425,14 @@ x-gtk-stock-map
     ("etc/images/lock" . "gtk-lock")
     ("etc/images/next-page" . "gtk-next-page")
     ("etc/images/refresh" . ("view-refresh" "gtk-refresh"))
+    ("etc/images/search-replace" . "edit-find-replace")
     ("etc/images/sort-ascending" . ("view-sort-ascending" "gtk-sort-ascending"))
     ("etc/images/sort-column-ascending" . "gtk-sort-column-ascending")
     ("etc/images/sort-criteria" . "gtk-sort-criteria")
     ("etc/images/sort-descending" . ("view-sort-descending"
 				     "gtk-sort-descending"))
     ("etc/images/sort-row-ascending" . "gtk-sort-row-ascending")
+    ("etc/images/spell" . ("tools-check-spelling" "gtk-spell-check"))
     ("images/gnus/toggle-subscription" . "gtk-task-recurring")
     ("images/mail/compose" . "gtk-mail-compose")
     ("images/mail/copy" . "gtk-mail-copy")
@@ -1442,7 +1444,7 @@ x-gtk-stock-map
     ("images/mail/reply-all" . "gtk-mail-reply-to-all")
     ("images/mail/reply" . "gtk-mail-reply")
     ("images/mail/save-draft" . "gtk-mail-handling")
-    ("images/mail/send" . "gtk-mail-send")
+    ("images/mail/send" . ("mail-send" "gtk-mail-send"))
     ("images/mail/spam" . "gtk-spam")
     ;; Used for GDB Graphical Interface
     ("images/gud/break" . "gtk-no")

[-- Attachment #4: isearch-icons-new.png --]
[-- Type: image/png, Size: 22249 bytes --]

[-- Attachment #5: isearch-icons-old.png --]
[-- Type: image/png, Size: 27019 bytes --]

[-- Attachment #6: message-mode-icons-new.png --]
[-- Type: image/png, Size: 33060 bytes --]

[-- Attachment #7: message-mode-icons-new-with-extra-patch.png --]
[-- Type: image/png, Size: 32123 bytes --]

[-- Attachment #8: message-mode-icons-old.png --]
[-- Type: image/png, Size: 33823 bytes --]

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 May 2020 02:50:04 +0300
> 
> I'd like to present a few arguments for the inclusion of the
> x-gtk-stock-map patch in Emacs 27 (on which the current answer is no,
> but I'll try to elaborate):

Thanks, but I see nothing in these arguments to say that it's urgent
or even very important to have these UI changes in Emacs 27.

Please help me release Emacs 27.1 as soon as possible by trying to
look at this stuff from my POV.

bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov]

On 01.05.2020 09:16, Eli Zaretskii wrote:
> Thanks, but I see nothing in these arguments to say that it's urgent
> or even very important to have these UI changes in Emacs 27.

It's steps like this that address the perceived lack of polish that 
users see when starting to use Emacs. So I'm fairly sure it's important. 
Just not critical, of course.

And my arguments are, as usual, about the added value vs risk. Which I'm 
fairly sure is minimal.

> Please help me release Emacs 27.1 as soon as possible by trying to
> look at this stuff from my POV.

...I do? (*) Just with somewhat different approach, e.g. preponderance 
of evidence rather than presumption of unimportance. :-)

Anyway, such discussions should become rare if we somehow manage to 
speed up the release cycle someday.

(*) For instance, I chose the proposed changes critically, leaving out 
certain others that would add more risk.

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

> Cc: 40990@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 May 2020 18:21:32 +0300
> 
> On 01.05.2020 09:16, Eli Zaretskii wrote:
> > Thanks, but I see nothing in these arguments to say that it's urgent
> > or even very important to have these UI changes in Emacs 27.
> 
> It's steps like this that address the perceived lack of polish that 
> users see when starting to use Emacs. So I'm fairly sure it's important. 
> Just not critical, of course.

We had this UI since v23, I think.  I don't think anything bad will
happen if we have it for another year or 2.  And of course people who
track the master branch will have it immediately.

> > Please help me release Emacs 27.1 as soon as possible by trying to
> > look at this stuff from my POV.
> 
> ...I do?

You do, but I'm asking to help me more.  We should have released 27.1
a year ago.

> Anyway, such discussions should become rare if we somehow manage to 
> speed up the release cycle someday.

Such a someone will be very welcome, indeed.

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

> Date: Fri, 01 May 2020 18:43:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 40990@debbugs.gnu.org
> 
> We had this UI since v23, I think.  I don't think anything bad will
> happen if we have it for another year or 2.  And of course people who
> track the master branch will have it immediately.
                          ^^^^^^^^^^^^
I meant "will have the new UI" here.  Sorry for confusing wording.

bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov]

On 01.05.2020 18:43, Eli Zaretskii wrote:
> We had this UI since v23, I think.  I don't think anything bad will
> happen if we have it for another year or 2.  And of course people who
> track the master branch will have it immediately.

People who track master are not the audience I was thinking of, though. 
But okay, let's target Emacs 28 to be the "new UI polish" release.

It would be nice to backport these patches to 27.2 if/when if comes out, 
though.

> You do, but I'm asking to help me more.  We should have released 27.1
> a year ago.

I really hope that none of my late patches were ever the reason for the 
delay.

Come to think of it, I don't recall any of my proposals like that to 
cause a release-delaying regression later, in the last... many years.

And not just my proposals. We're pretty conservative about it. Which is 
a good thing, of course, but it indicates that we could be moving 
faster, even if just a bit (be it in allowing more last-minute fixes, or 
more feature backports, or doing shorter pretests, or starting pretests 
faster, or all of that together).

>> Anyway, such discussions should become rare if we somehow manage to
>> speed up the release cycle someday.
> Such a someone will be very welcome, indeed.

Someone?

Anyway, for all I know, we could release 27 tomorrow. As soon as we deal 
with the "modify literal objects" documentation discussion.

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

> Cc: 40990@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 2 May 2020 01:12:38 +0300
> 
> > You do, but I'm asking to help me more.  We should have released 27.1
> > a year ago.
> 
> I really hope that none of my late patches were ever the reason for the 
> delay.

Not you alone.  It's a long series of small changes, each one of them
considered "important".  Together they add up.  And then COVID-19
added its toll.

> And not just my proposals. We're pretty conservative about it. Which is 
> a good thing, of course, but it indicates that we could be moving 
> faster, even if just a bit (be it in allowing more last-minute fixes, or 
> more feature backports, or doing shorter pretests, or starting pretests 
> faster, or all of that together).
> 
> >> Anyway, such discussions should become rare if we somehow manage to
> >> speed up the release cycle someday.
> > Such a someone will be very welcome, indeed.
> 
> Someone?

Someone, somehow, you name it.

> Anyway, for all I know, we could release 27 tomorrow. As soon as we deal 
> with the "modify literal objects" documentation discussion.

There's always "that one last" issue to be fixed.

The only way to speed up our releases that I see is to care less about
stability and regressions.  If you are following the bug list closely,
you will see that we just recently started to get reports about
significant regressions in Emacs 27 (and some in Emacs 26).  Should we
disregard them?  We never did that, not since Emacs 25, at least.

bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov]

Now fixed on master. Closing.

On 02.05.2020 09:23, Eli Zaretskii wrote:

>> Anyway, for all I know, we could release 27 tomorrow. As soon as we deal
>> with the "modify literal objects" documentation discussion.
> 
> There's always "that one last" issue to be fixed.
> 
> The only way to speed up our releases that I see is to care less about
> stability and regressions.  If you are following the bug list closely,
> you will see that we just recently started to get reports about
> significant regressions in Emacs 27 (and some in Emacs 26).  Should we
> disregard them?  We never did that, not since Emacs 25, at least.

I don't know what's the best course of action in each case, but if we 
did make a point of releasing more often (e.g. did time-based releases, 
for instance), Emacs 27.1 would probably have been less stable. But it 
would have been released maybe a year ago, and by now we'd already have 
released, say, 27.2 and 27.3, with more regressions fixed and faster 
because of exposure to a wider audience, more testing.

It's a tricky road, but a possible one.

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

> Cc: 40990-done@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 04:42:32 +0300
> 
> > The only way to speed up our releases that I see is to care less about
> > stability and regressions.  If you are following the bug list closely,
> > you will see that we just recently started to get reports about
> > significant regressions in Emacs 27 (and some in Emacs 26).  Should we
> > disregard them?  We never did that, not since Emacs 25, at least.
> 
> I don't know what's the best course of action in each case, but if we 
> did make a point of releasing more often (e.g. did time-based releases, 
> for instance), Emacs 27.1 would probably have been less stable. But it 
> would have been released maybe a year ago, and by now we'd already have 
> released, say, 27.2 and 27.3, with more regressions fixed and faster 
> because of exposure to a wider audience, more testing.
> 
> It's a tricky road, but a possible one.

You are just listing the advantages of releasing frequently.  No one
will argue with that, the problem is how to make that happen without
hurting stability.

bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov]

On 11.05.2020 05:35, Eli Zaretskii wrote:
> You are just listing the advantages of releasing frequently.  No one
> will argue with that, the problem is how to make that happen without
> hurting stability.

I don't think it's possible not to sacrifice stability at all. It will 
most likely go down in XX.1 releases, at least to some extent.

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

On May 11, 2020 5:46:03 AM GMT+03:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 11.05.2020 05:35, Eli Zaretskii wrote:
> > You are just listing the advantages of releasing frequently.  No one
> > will argue with that, the problem is how to make that happen without
> > hurting stability.
> 
> I don't think it's possible not to sacrifice stability at all. It will
> 
> most likely go down in XX.1 releases, at least to some extent.

The stability already goes down in NN.1 versions, that's why we always have a NN.2 version to follow.  We are talking about how much more it will decrease.  If you have practical suggestions for how to keep the instability in check while making more frequent releases, I'm all ears.

bug#40990: Improve message-mode and isearch icons

[Dmitry Gutov]

On 11.05.2020 07:17, Eli Zaretskii wrote:
> On May 11, 2020 5:46:03 AM GMT+03:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
>> On 11.05.2020 05:35, Eli Zaretskii wrote:
>>> You are just listing the advantages of releasing frequently.  No one
>>> will argue with that, the problem is how to make that happen without
>>> hurting stability.
>>
>> I don't think it's possible not to sacrifice stability at all. It will
>>
>> most likely go down in XX.1 releases, at least to some extent.
> 
> The stability already goes down in NN.1 versions, that's why we always have a NN.2 version to follow.  We are talking about how much more it will decrease.  If you have practical suggestions for how to keep the instability in check while making more frequent releases, I'm all ears.

I mean will go down compared to the current situation.

But actually, if the period before branching, before stabilization, is 
also reduced proportionally, then fewer regressions will have a chance 
to sneak in. The odds of *some* regression remaining will likely go up, 
though.

For example, if we target, say, a new Emacs release every 6 months, then 
it will be 2 months development, 2 months stabilization, and 2 months 
prerelease (with new developments doing to the master for the last 4 
months).

With cycles like that, there will also be less temptation to "sneak that 
last feature in", or land an experimental feature later in the cycle. 
Developers will also moderate the risk themselves.

As for regression bugs remaining at each time, maybe the way to look at 
them is: If the period between when the regression happened and when it 
was reported will be longer than the time to the next minor release, 
maybe we can do the release now. And thus nominate fewer bugs to be 
actual blockers.

Right now Emacs releases, and even development branches, are fairly 
stable, so we have some margin for experimentation.

bug#40990: Improve message-mode and isearch icons

[Eli Zaretskii]

> Cc: 40990-done@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 17:18:15 +0300
> 
> For example, if we target, say, a new Emacs release every 6 months, then 
> it will be 2 months development, 2 months stabilization, and 2 months 
> prerelease (with new developments doing to the master for the last 4 
> months).

2 months for development is way too little.

> With cycles like that, there will also be less temptation to "sneak that 
> last feature in", or land an experimental feature later in the cycle. 
> Developers will also moderate the risk themselves.

I will believe that when I see it ;-)

Anyway, serious discussion of this should be on emacs-devel.