Re: tab-line-tab-modified: cool feature... not yet there

Re: tab-line-tab-modified: cool feature... not yet there

[Adam Porter]

Hi Juri, Pedro,

Not sure why this thread was moved off-list.  I'll add it back.

> > El 28 sept 2021, a las 21:04, Juri Linkov <juri@linkov.net> escribió:

> > Thanks, now everything is clear.  The problem is that it changes the color
> > of the tab only after you switch to another buffer.  I don't know whether
> > the author Adam (Cc'ed) intended this.  It makes sense not to change
> > the color of the current tab immediately to not distract the user.

On Wed, Sep 29, 2021 at 12:00 AM Pedro Andres Aranda Gutierrez
<paaguti@gmail.com> wrote:

> I don’t know if changing the colour in the tab distracts or confuses. At least it seems to confuse me ;-) I would expect the tab to change at the same time as the mode-line in order to have consistent information on the screen. I don’t like to be told different things by the tab line and the mode line ;-)

The patch I submitted doesn't have any effect on how or when the
tab-line is updated.  I've also noticed the effect you describe, that
the tab-line doesn't update until I change to another buffer, but ISTM
that that's an orthogonal issue.  The tab-bar does update with
redisplay, while the tab-line seems to only update on buffer-switch,
or something like that.  If the tab-line should update with redisplay,
I guess that could be done.  I guess it might be relevant to redisplay
performance, but Juri should know about that; maybe that's why it
doesn't already do that.

Re: tab-line-tab-modified: cool feature... not yet there

[Juri Linkov]

>> > Thanks, now everything is clear.  The problem is that it changes the color
>> > of the tab only after you switch to another buffer.  I don't know whether
>> > the author Adam (Cc'ed) intended this.  It makes sense not to change
>> > the color of the current tab immediately to not distract the user.
>>
>> I don’t know if changing the colour in the tab distracts or confuses. At
>> least it seems to confuse me ;-) I would expect the tab to change at the
>> same time as the mode-line in order to have consistent information on the
>> screen. I don’t like to be told different things by the tab line and the
>> mode line ;-)
>
> The patch I submitted doesn't have any effect on how or when the
> tab-line is updated.  I've also noticed the effect you describe, that
> the tab-line doesn't update until I change to another buffer, but ISTM
> that that's an orthogonal issue.  The tab-bar does update with
> redisplay, while the tab-line seems to only update on buffer-switch,
> or something like that.  If the tab-line should update with redisplay,
> I guess that could be done.  I guess it might be relevant to redisplay
> performance, but Juri should know about that; maybe that's why it
> doesn't already do that.

Indeed, it's related to redisplay performance, so it was optimized by caching
to update the tab-line only on buffer switching, not on every key press.

Re: tab-line-tab-modified: cool feature... not yet there

[Pedro Andres Aranda Gutierrez]

Hi, I've seen a couple of ideas in the internet on how to spped his up. You could use the buffer-change hooks and defadvice on undo and would be much less than on every keypress, right? I think this could be a good compromise

Best, /PA

Enviado desde mi iPad

El 2 oct 2021, a las 21:42, Juri Linkov <juri@linkov.net> escribió:

>>>> Thanks, now everything is clear.  The problem is that it changes the color
>>>> of the tab only after you switch to another buffer.  I don't know whether
>>>> the author Adam (Cc'ed) intended this.  It makes sense not to change
>>>> the color of the current tab immediately to not distract the user.
>>> 
>>> I don’t know if changing the colour in the tab distracts or confuses. At
>>> least it seems to confuse me ;-) I would expect the tab to change at the
>>> same time as the mode-line in order to have consistent information on the
>>> screen. I don’t like to be told different things by the tab line and the
>>> mode line ;-)
>> 
>> The patch I submitted doesn't have any effect on how or when the
>> tab-line is updated.  I've also noticed the effect you describe, that
>> the tab-line doesn't update until I change to another buffer, but ISTM
>> that that's an orthogonal issue.  The tab-bar does update with
>> redisplay, while the tab-line seems to only update on buffer-switch,
>> or something like that.  If the tab-line should update with redisplay,
>> I guess that could be done.  I guess it might be relevant to redisplay
>> performance, but Juri should know about that; maybe that's why it
>> doesn't already do that.
> 
> Indeed, it's related to redisplay performance, so it was optimized by caching
> to update the tab-line only on buffer switching, not on every key press.

Re: tab-line-tab-modified: cool feature... not yet there

[Juri Linkov]

> Hi, I've seen a couple of ideas in the internet on how to spped his up. You
> could use the buffer-change hooks and defadvice on undo and would be much
> less than on every keypress, right? I think this could be a good compromise

Fortunately, it was much easier to implement this by adding
just these 3 lines to tab-line-format:

+                          (and (memq 'tab-line-tab-face-modified
+                                     tab-line-tab-face-functions)
+                               (buffer-file-name) (buffer-modified-p))))

So now this is fixed in the emacs-28 branch.

Re: tab-line-tab-modified: cool feature... not yet there

[Pedro Andres Aranda Gutierrez]

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

will check :-)

/PA

On Sun, 3 Oct 2021 at 19:21, Juri Linkov <juri@linkov.net> wrote:

> > Hi, I've seen a couple of ideas in the internet on how to spped his up.
> You
> > could use the buffer-change hooks and defadvice on undo and would be much
> > less than on every keypress, right? I think this could be a good
> compromise
>
> Fortunately, it was much easier to implement this by adding
> just these 3 lines to tab-line-format:
>
> +                          (and (memq 'tab-line-tab-face-modified
> +                                     tab-line-tab-face-functions)
> +                               (buffer-file-name) (buffer-modified-p))))
>
> So now this is fixed in the emacs-28 branch.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1368 bytes --]

Re: tab-line-tab-modified: cool feature... not yet there

[Pedro Andres Aranda Gutierrez]

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

Cool! Everything is consistent right now:-)

Thanks a ton! /PA

On Sun, 3 Oct 2021 at 19:21, Juri Linkov <juri@linkov.net> wrote:

> > Hi, I've seen a couple of ideas in the internet on how to spped his up.
> You
> > could use the buffer-change hooks and defadvice on undo and would be much
> > less than on every keypress, right? I think this could be a good
> compromise
>
> Fortunately, it was much easier to implement this by adding
> just these 3 lines to tab-line-format:
>
> +                          (and (memq 'tab-line-tab-face-modified
> +                                     tab-line-tab-face-functions)
> +                               (buffer-file-name) (buffer-modified-p))))
>
> So now this is fixed in the emacs-28 branch.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1411 bytes --]

tab-line-tab-modified: cool feature... not yet there

[Pedro Andres Aranda Gutierrez]

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

Hi,

I'm really excited with this tab-line-tab-modified customizable face. In my
case I have two themes, which I use depending on the light conditions (one
dark and one light) and I have a function to switch themes, very much as
explained in

https://stackoverflow.com/questions/23793288/cycle-custom-themes-w-emacs-24

Now, what I see is that the font isn't changed if I call customize-face
from lisp (i.e. in my code) It does, however, when I call it interactively
(M-x customize-face). That looks really weird to me.

Any help appreciated...

Best,/PA

PS:
In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60
Version 10.15.7 (Build 19H1419))
 of 2021-09-26 built on paag-MacBookAir
Repository revision: 27d8726ae29a1441dba776d7d3d0685ef85a3fdf
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Configured using:
 'configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
 LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include CC=clang
 OBJC=clang 'CFLAGS=-g -O3''

Checking on Linux in a couple of minutes....
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1873 bytes --]

Re: tab-line-tab-modified: cool feature... not yet there

[Juri Linkov]

> I'm really excited with this tab-line-tab-modified customizable face. In my
> case I have two themes, which I use depending on the light conditions (one
> dark and one light) and I have a function to switch themes, very much as
> explained in
>
> https://stackoverflow.com/questions/23793288/cycle-custom-themes-w-emacs-24
>
> Now, what I see is that the font isn't changed if I call customize-face
> from lisp (i.e. in my code) It does, however, when I call it interactively
> (M-x customize-face). That looks really weird to me.
>
> Any help appreciated...

It's not clear how do you call customize-face, but this has no problems:

  (set-face-foreground 'tab-line-tab-modified "darkgreen")

This is how I switch faces depending on the light conditions.