unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Glenn Morris <rgm@gnu.org>
Cc: 33784@debbugs.gnu.org, linux.xhyang@gmail.com
Subject: bug#33784: 27.0.50; some case c-backward-token-2 takes cpu more and emacs hang
Date: Wed, 19 Dec 2018 19:20:08 +0000	[thread overview]
Message-ID: <20181219192008.GA5683__32535.2552849383$1545248410$gmane$org@ACM> (raw)
In-Reply-To: <hj5zvq1of1.fsf@fencepost.gnu.org>

Hello, Glenn.

On Tue, Dec 18, 2018 at 17:05:22 -0500, Glenn Morris wrote:

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

> This sounds totally wrong to me.

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

> This also sounds wrong to me.

> I confess I have no idea what problem you are trying to solve here.

I have lost the clear overview I had of the problem yesterday, I'm
afraid.

There is an assemblage of confusing features around this bug which seem
to be contributing to the reported bug:

(i) A temporary buffer is created and made a C++ Mode buffer.
(ii) Font Lock Mode isn't enabled.
(iii) Although font lock isn't enabled, font-lock-ensure is called.
This hangs.
(iv) An attempt to enable Font Lock Mode on this buffer fails silently,
because the buffer name begins with a space.
(v) It is unclear whether font-lock-ensure is intended to work when Font
Lock Mode is disabled.
(vi) The spiking of Font Lock Mode to fail on "space buffers" is not
documented, and 23 years later, the reason for it is obscure.

Hope that helps, if only a little.

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2018-12-19 19:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  4:09 bug#33784: 27.0.50; some case c-backward-token-2 takes cpu more and emacs hang xh yang
     [not found] ` <mailman.5878.1545108246.1284.bug-gnu-emacs@gnu.org>
2018-12-18 17:47   ` Alan Mackenzie
     [not found] ` <20181218174716.96822.qmail@mail.muc.de>
2018-12-18 18:51   ` Eli Zaretskii
2018-12-18 18:55     ` Alan Mackenzie
     [not found]     ` <20181218185505.GC8949@ACM>
2018-12-18 19:23       ` Eli Zaretskii
2018-12-18 21:05         ` Alan Mackenzie
2018-12-18 22:05           ` Glenn Morris
2018-12-19 19:20             ` Alan Mackenzie [this message]
2018-12-19 15:22           ` Eli Zaretskii
2018-12-20  7:18 ` bug#33784: xh yang
2018-12-20 12:53   ` bug#33784: Alan Mackenzie

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='20181219192008.GA5683__32535.2552849383$1545248410$gmane$org@ACM' \
    --to=acm@muc.de \
    --cc=33784@debbugs.gnu.org \
    --cc=linux.xhyang@gmail.com \
    --cc=rgm@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).