unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: emacs-devel@gnu.org
Subject: Re: [PATCH] tab-line: New tab-line-tab-face-modified face
Date: Fri, 24 Sep 2021 17:13:20 -0500	[thread overview]
Message-ID: <87k0j5bp1b.fsf@alphapapa.net> (raw)
In-Reply-To: 87pmsyj9dh.fsf@mail.linkov.net

Juri Linkov <juri@linkov.net> writes:

>>>> Spending some more time using Emacs 28.0.50 with tab-bar and tab-line, I
>>>> found myself missing the ability to look at a tab-line tab and know
>>>> whether its buffer is modified (e.g. after using
>>>> `xref-query-replace-in-results' on some project buffers).
>>>>
>>>> This patch adds a face for modified, file-backed buffers.  I chose to
>>>> inherit from the font-lock-doc-face, as it seems readable and intuitive
>>>> with the default theme.  It seems to make the tab-line much more useful,
>>>> and more in line with what users will probably expect from having used
>>>> other editors' GUIs.
>>>
>>> Thanks, a modified buffer needs to be indicated somehow,
>>> but all other editors' GUIs display ‘*’ at the beginning
>>> of the modified buffer's name.
>>
>> Some do, yes, but I've used some that change the appearance of the text
>> in the tab's name, e.g. making it bold, italic, etc.  We already use
>> italic for non-file-backed buffers, and bold seems, well, too bold, IMHO
>> (and it may change the width of the tab with proportional fonts), so
>> changing the color seems reasonable.
>>
>> I'm not opposed to optionally adding an asterisk to the name, but that
>> would change the width of the tab as soon as a user types into a buffer,
>> which doesn't seem like a good default to me.
>
> I see another problem with an asterisk: many buffers already have an asterisk
> as the first character of their buffer names, so it will be indistinguishable
> from the modified status.

Yes, good point.

> But why font-lock-doc-face?  Have you tried to change tab background color?
> I guess this would be more visually pleasing.  Or maybe not.  This needs
> more experimentation.

Because in the default theme, it results in text that's a dark red,
which is easily distinguished against the default tab background color,
while still being readable (IMHO).  It reminds me of other editors I've
used that use the red color to indicate a modified tab, so I think it
should be somewhat familiar to users.  And by using a "font-lock-" face,
it will be themed automatically by common third-party themes; while that
doesn't guarantee it will look good with any theme by default, it should
help.

A background color could be used as well, but I think that would be too
jarring; we already have an option to alternate the background color to
help distinguish tabs, which results in alternating shades of gray in
the default theme, which are already a bit high-contrast (subtler shades
of gray would be better, IMHO).  Having some of the tabs be, e.g. a red
background color, would be off-putting to users, IMO; I guess they might
prefer to disable the feature entirely in that case.

I also feel like a changed background color ought to be reserved for
something more urgent, like a tab that "requires attention", similar to
how desktop environments or MS-Windows highlight tabs that are trying to
get the user's attention due to an error or notification.

Having said that, it doesn't matter to me what the default face is.  If
there's a better foreground color, or a good background color, or some
other face attribute that would be a better default, let's use that.




  reply	other threads:[~2021-09-24 22:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24  4:57 [PATCH] tab-line: New tab-line-tab-face-modified face Adam Porter
2021-09-24  6:38 ` Juri Linkov
2021-09-24  7:09   ` Adam Porter
2021-09-24 10:29     ` Stefan Kangas
2021-09-24 15:42     ` Juri Linkov
2021-09-24 22:13       ` Adam Porter [this message]
2021-09-25 19:18         ` Juri Linkov
2021-09-26  0:14           ` Adam Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0j5bp1b.fsf@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).