* Re: bug#20352: Factor 2 slow down of font-locking in c-mode [not found] ` <jwvoamlv8qy.fsf-monnier+emacsbugs@gnu.org> @ 2015-05-03 21:33 ` Alan Mackenzie 2015-05-04 2:13 ` Stefan Monnier 0 siblings, 1 reply; 3+ messages in thread From: Alan Mackenzie @ 2015-05-03 21:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Hello, Stefan. On Sat, Apr 18, 2015 at 10:02:17AM -0400, Stefan Monnier wrote: > Hmm... I hope comparing the profiler reports will give us a clue. Indeed. Some while ago, you were musing on putting syntax-ppss, or equivalent, into syntax.c, thus rendering open-paren-in-column-0-is-defun-start unnecessary and obsolete. This would speed up or improve the accuracy of, in particular, back_comment and the stacks of things which depend upon it. Is this enhancement still intended? > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bug#20352: Factor 2 slow down of font-locking in c-mode 2015-05-03 21:33 ` bug#20352: Factor 2 slow down of font-locking in c-mode Alan Mackenzie @ 2015-05-04 2:13 ` Stefan Monnier 2015-05-04 10:33 ` Alan Mackenzie 0 siblings, 1 reply; 3+ messages in thread From: Stefan Monnier @ 2015-05-04 2:13 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel > Indeed. Some while ago, you were musing on putting syntax-ppss, or > equivalent, into syntax.c, thus rendering > open-paren-in-column-0-is-defun-start unnecessary and obsolete. This > would speed up or improve the accuracy of, in particular, back_comment > and the stacks of things which depend upon it. > Is this enhancement still intended? Not in the short term, no. I've toyed with it, but there's a problem: syntax-ppss's caching relies on the syntax-table being constant. This usually works fine because the callers "know" to call syntax-ppss outside of with-syntax-table (I guess in reality they don't really know, but they happen to do that because they call syntax-ppss fairly early on), but it's not uncommon for Elisp code (definitely including CC-mode) to use with-syntax-table around calls to forward-sexp/comment, so calling syntax-ppss implicitly from within those functions exposes this underlying syntax-ppss limitation. IOW, it can't be done until we figure out how to make syntax-ppss handle syntax-table changes. Stefan ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bug#20352: Factor 2 slow down of font-locking in c-mode 2015-05-04 2:13 ` Stefan Monnier @ 2015-05-04 10:33 ` Alan Mackenzie 0 siblings, 0 replies; 3+ messages in thread From: Alan Mackenzie @ 2015-05-04 10:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Hello, Stefan. On Sun, May 03, 2015 at 10:13:48PM -0400, Stefan Monnier wrote: > > Indeed. Some while ago, you were musing on putting syntax-ppss, or > > equivalent, into syntax.c, thus rendering > > open-paren-in-column-0-is-defun-start unnecessary and obsolete. This > > would speed up or improve the accuracy of, in particular, back_comment > > and the stacks of things which depend upon it. > > Is this enhancement still intended? > Not in the short term, no. I've toyed with it, but there's a problem: > syntax-ppss's caching relies on the syntax-table being constant. > This usually works fine because the callers "know" to call syntax-ppss > outside of with-syntax-table (I guess in reality they don't really know, > but they happen to do that because they call syntax-ppss fairly early > on), but it's not uncommon for Elisp code (definitely including CC-mode) > to use with-syntax-table around calls to forward-sexp/comment, so > calling syntax-ppss implicitly from within those functions exposes this > underlying syntax-ppss limitation. Ah. That sounds like a shame. > IOW, it can't be done until we figure out how to make syntax-ppss handle > syntax-table changes. How about having an association list of ((syntax-table . cache) ...), or something like that? Each cache would need its own value of the equivalent of `syntax-propertize--done'. `modify-syntax-entry' would need to wipe the cache. Then there are `category' text properties/overlays which might affect the syntax. And so on. And so on. OK. It's difficult. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-05-04 10:33 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20150417191005.4119.qmail@mail.muc.de> [not found] ` <jwv618uukei.fsf-monnier+emacsbugs@gnu.org> [not found] ` <20150418094552.GA4182@acm.fritz.box> [not found] ` <jwvoamlv8qy.fsf-monnier+emacsbugs@gnu.org> 2015-05-03 21:33 ` bug#20352: Factor 2 slow down of font-locking in c-mode Alan Mackenzie 2015-05-04 2:13 ` Stefan Monnier 2015-05-04 10:33 ` Alan Mackenzie
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).