bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#33784: 27.0.50; some case c-backward-token-2 takes cpu more and emac


From: Alan Mackenzie
Subject: bug#33784: 27.0.50; some case c-backward-token-2 takes cpu more and emacs hang
Date: Tue, 18 Dec 2018 21:05:07 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Eli.

On Tue, Dec 18, 2018 at 21:23:45 +0200, Eli Zaretskii wrote:
> > Date: Tue, 18 Dec 2018 18:55:05 +0000
> > Cc: address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > The current strategy is silently to ignore (font-lock-mode) when the
> > buffer name begins with a space.  It feels to me like an easy to
> > implement, but suboptimal, workaround to a real problem, whatever that
> > real problem might be.

> The real problem is probably performance.  But that's a guess; someone
> will have to do the forensics to find out which change did that, and
> then try to find related bug reports and/or discussions.

Hah!  The change, not to fontify buffers with names beginning with
spaces, was made by Simon Marshall on 1995-12-09.  The list archives only
go back to 2000.  :-(

I suspect what happened was that back last millenium, there was a strong
convention for what a buffer with a name beginning with a space meant,
and it was perfectly OK then not to fontify such a buffer.  Over time,
that convention became diluted such that even buffers created by users
(e.g. by with-temp-buffer) get names starting with a space.  But that's
only a guess.

Maybe the solution would be not to start with-temp-buffer names with a
space.

Indeed page "Buffer Names" in Elisp states "Buffers that are ephemeral
and generally uninteresting to the user have names starting with a
space", which is ambiguous - does a buffer have to be both ephemeral and
generally uninteresting, or will one of these properties do?  Probably
the latter.

Maybe the documentation for with-temp-buffer should be amended to
recommend Lisp programmers not to use it for buffers holding user text.

Or something like that.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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