emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [DISCUSSION] Refactoring fontification system
@ 2021-11-19 14:12 Ihor Radchenko
  2021-11-19 14:18 ` Bruce D'Arcus
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Ihor Radchenko @ 2021-11-19 14:12 UTC (permalink / raw)
  To: emacs-orgmode

Dear all,

Recently, there have been multiple issues related to incorrect
fontification:
- https://list.orgmode.org/orgmode/23707.20428.546749.44853@frac.u-strasbg.fr/
- https://list.orgmode.org/orgmode/87fsujp7mc.fsf@web.de/
- https://list.orgmode.org/orgmode/87czvqxdn9.fsf@gmail.com/
- https://list.orgmode.org/8735nsv9qo.fsf@nicolasgoaziou.fr/T/#me1c44b6e493dd280cca4f042b833c24749ae4fe0

These issues keep appearing because our current fontification code is
based on regexps and only approximates the actual Org grammar elements.
It is largely a legacy from the times when org-element parser was not a
thing.

Maybe it is a time to upgrade the fontification according to our
state-of-art parser?

Instead of fontifying elements individually via regexps, we can leverage
org-element-map, org-element-parse-buffer, org-element-cache, and
jit-lock-mode. Each type of Org element/object can be assigned with a
fontification function accepting a single argument - the element datum.

Also, the fontification code can be move to a separate library.

WDYT?

Best,
Ihor



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [DISCUSSION] Refactoring fontification system
  2021-11-19 14:12 [DISCUSSION] Refactoring fontification system Ihor Radchenko
@ 2021-11-19 14:18 ` Bruce D'Arcus
  2021-11-19 16:09 ` Tim Cross
  2021-11-24 22:03 ` Nicolas Goaziou
  2 siblings, 0 replies; 4+ messages in thread
From: Bruce D'Arcus @ 2021-11-19 14:18 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: org-mode-email

On Fri, Nov 19, 2021 at 9:11 AM Ihor Radchenko <yantar92@gmail.com> wrote:

> WDYT?

I don't understand all the technical details, but it sounds like a
GREAT idea to me in general!

Bruce


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [DISCUSSION] Refactoring fontification system
  2021-11-19 14:12 [DISCUSSION] Refactoring fontification system Ihor Radchenko
  2021-11-19 14:18 ` Bruce D'Arcus
@ 2021-11-19 16:09 ` Tim Cross
  2021-11-24 22:03 ` Nicolas Goaziou
  2 siblings, 0 replies; 4+ messages in thread
From: Tim Cross @ 2021-11-19 16:09 UTC (permalink / raw)
  To: emacs-orgmode


Ihor Radchenko <yantar92@gmail.com> writes:

> Dear all,
>
> Recently, there have been multiple issues related to incorrect
> fontification:
> - https://list.orgmode.org/orgmode/23707.20428.546749.44853@frac.u-strasbg.fr/
> - https://list.orgmode.org/orgmode/87fsujp7mc.fsf@web.de/
> - https://list.orgmode.org/orgmode/87czvqxdn9.fsf@gmail.com/
> - https://list.orgmode.org/8735nsv9qo.fsf@nicolasgoaziou.fr/T/#me1c44b6e493dd280cca4f042b833c24749ae4fe0
>
> These issues keep appearing because our current fontification code is
> based on regexps and only approximates the actual Org grammar elements.
> It is largely a legacy from the times when org-element parser was not a
> thing.
>
> Maybe it is a time to upgrade the fontification according to our
> state-of-art parser?
>
> Instead of fontifying elements individually via regexps, we can leverage
> org-element-map, org-element-parse-buffer, org-element-cache, and
> jit-lock-mode. Each type of Org element/object can be assigned with a
> fontification function accepting a single argument - the element datum.
>
> Also, the fontification code can be move to a separate library.
>
> WDYT?
>

Sounds like a better approach to me. In addition to being
more accurate, this would mean we don't need to keep 2 separate
definitions in sync or have confusing font locking where the regexp and element
definitions are different. Should gives us increased consistency and
less maintenance. 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [DISCUSSION] Refactoring fontification system
  2021-11-19 14:12 [DISCUSSION] Refactoring fontification system Ihor Radchenko
  2021-11-19 14:18 ` Bruce D'Arcus
  2021-11-19 16:09 ` Tim Cross
@ 2021-11-24 22:03 ` Nicolas Goaziou
  2 siblings, 0 replies; 4+ messages in thread
From: Nicolas Goaziou @ 2021-11-24 22:03 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

> Recently, there have been multiple issues related to incorrect
> fontification:
> - https://list.orgmode.org/orgmode/23707.20428.546749.44853@frac.u-strasbg.fr/
> - https://list.orgmode.org/orgmode/87fsujp7mc.fsf@web.de/
> - https://list.orgmode.org/orgmode/87czvqxdn9.fsf@gmail.com/
> - https://list.orgmode.org/8735nsv9qo.fsf@nicolasgoaziou.fr/T/#me1c44b6e493dd280cca4f042b833c24749ae4fe0
>
> These issues keep appearing because our current fontification code is
> based on regexps and only approximates the actual Org grammar elements.
> It is largely a legacy from the times when org-element parser was not a
> thing.
>
> Maybe it is a time to upgrade the fontification according to our
> state-of-art parser?
>
> Instead of fontifying elements individually via regexps, we can leverage
> org-element-map, org-element-parse-buffer, org-element-cache, and
> jit-lock-mode. Each type of Org element/object can be assigned with a
> fontification function accepting a single argument - the element datum.
>
> Also, the fontification code can be move to a separate library.
>
> WDYT?

I wholeheartedly agree with all these points.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-11-24 22:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-19 14:12 [DISCUSSION] Refactoring fontification system Ihor Radchenko
2021-11-19 14:18 ` Bruce D'Arcus
2021-11-19 16:09 ` Tim Cross
2021-11-24 22:03 ` Nicolas Goaziou

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.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).