[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Font lock in org+elisp confused with ?\[
From: |
Arthur Miller |
Subject: |
Re: Font lock in org+elisp confused with ?\[ |
Date: |
Thu, 01 Apr 2021 17:44:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt) |
<tomas@tuxteam.de> writes:
> On Thu, Apr 01, 2021 at 09:18:30AM +0200, Arthur Miller wrote:
>> Tom Gillespie <tgbugs@gmail.com> writes:
>>
>> > This is a known issue with org babel blocks. It is due to the fact
>> > that org babel translates the font locking for the language but not
>> > the syntax propertization. Another frequent cause is the bash case
>> > statement. The end result is that unmatched parens leak out from the
>> > babel blocks and wreak havoc elsewhere in the org file unless you
>> > balance out the parens e.g. in a comment. I have a hacked fix for
>> > this, but it has horrible performance, especially with line numbers
>> > enabled. I think that a proper solution would run arbitrary syntax
>> > propertization on subsets of a buffer without having to continually
>> > check where those subsets start or end. Best,
>> > Tom
>>
>> Thanks for the explanation!
>>
>> I don't know how org-babel works, I guess it opens another buffer,
>> font-locks syntax there and copy it over? What was the reason why they
>> don't copy other properties? Performance or something else?
>
> Hm. I've just poked around a bit. If you are talking about babel
> blocks, I think the entry point is `org-src-font-lock-fontify-block',
> defined in `org-src.el'.
>
> And indeed, this function basically does this (with a lot of
> corner-case chasing around, as is usual in our trade):
>
> (let ((lang-mode (org-src-get-lang-mode lang)))
> ...
> (with-current-buffer
> (get-buffer-create
> (format " *org-src-fontification:%s*" lang-mode))
> ...))
>
> The rest is left to the reader's fantasy, as they say :)
:-) Left as an exercise to reader's fantasy?
I tried to copy 'syntax-table property, but it didn't solve anything.
I think the problem is some bad regexp somewhere when it come to
indentation, it misses what it looks at somewhere (obviously),
but I have no idea where. I am not sure it is org fault.
I see gnus is confused too, so it is probably deeper, maybe in elisp
mode?
I took a profiler snapshot to get a nice stack-trace while moving the
cursor just from one place after parenthesis to the closing parenhesis
on this line:
(if (= (char-before (point)) ?\[)
I have attached profiler-repport.
I also noticed that the function got called ~1000 times, while there are
only ~140 src blocks.
profile-repport
Description: Text document
> Cheers
Happy Eastern!