emacs-devel
[Top][All Lists]
Advanced

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

Re: 27.0.50: How can I test a buffer-local window-configuration-change-h


From: Stefan Monnier
Subject: Re: 27.0.50: How can I test a buffer-local window-configuration-change-hook in batch mode?
Date: Sat, 26 Oct 2019 11:59:16 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> >> I don't think long lines pose any performance problems in buffers
>> >> which are never displayed
>> > You are wrong: it will cause problems in any function that uses the
>> > display code, even if nothing is displayed.  For example,
>> > vertical-motion, next-line, posn-at-point, etc. all use the display
>> > code internally.
>> In theory you're right.  But I think in practice "buffers that aren't
>> displayed" is a pretty good approximation of "so-long won't help".
> I don't understand how practice makes theory unimportant in this case.
> There's a leap in your logic that I couldn't follow.

The `so-long` package is a trade-off: it has advantages (supposedly
avoids some nasty slowdowns) and disadvantages (it works by disabling
some features).

It's virtually impossible to determine reliably when it's better to use
so-long and when it's better not to.  So theory is not super relevant
compared to actual practical experience.

I don't have an opinion on whether so-long should (by default) only be
enabled in buffers that are displayed, but it intuitively sound like
a potentially good heuristic to minimize the risk of breaking stuff.

>> I missed something: which new hook would be needed?
> This sub-thread was in response to Martin's question here:
>   https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg01013.html

Ah, I see.  I thought (and still think) it was just a misunderstanding
on Martin's part, not an actual need (at least Phil didn't express
a need for it).

[ Or maybe this particular case just reminded Martin of other cases
  where such a hook could have been handy.  ]


        Stefan




reply via email to

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