emacs-orgmode
[Top][All Lists]
Advanced

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

Re: Support for tagging (special) blocks


From: Ihor Radchenko
Subject: Re: Support for tagging (special) blocks
Date: Wed, 05 Oct 2022 15:49:50 +0800

Sébastien Miquel <sebastien.miquel@posteo.eu> writes:

> Hi,
>
> Ihor Radchenko writes:
>> Thanks for the clarification!
>> I did not mean to reduce the font size in affiliated keywords.
>> I was referring to replacing the display of affiliated keywords:
>>
>> #+name: A classic
>> #+tag: easy
>>
>> will be displayed by Emacs as
>>
>> #+... A classic :easy:
>>
>> The underlying text will not be changed.
>> The hidden parts will be revealed upon cursor entering the affiliated
>> keywords.
>
> Perhaps something like
> #+... name: A classic tag: easy
> might be used for any kind of keyword. That'd be quite the trick.

> It would certainly improve the situation when an element has several
> keywords, but I'm not sure how common that is.
>
> I'll look into implementing such #+name and #+tag keywords, when I
> have the time.

Escaping might be an issue.
Another approach could be following out headline format
#+name: Title :tag1:tag2:

In any case, I am not too concerned about the semantics at this point.

In order to implement tag support in named blocks, you will need to add
it to many places in Org, like parser, export, babel, user commands,
etc. It is not trivial. And do not forget about backwards compatibility
and, for example, third-party export backends.

> On an unrelated note, how is your work on revamping org's
> fontification going, if I may ask ? I had had a look at your repo, but
> since adapting my configuration would have required some effort I did
> not try it.

The latest progress is a bit of discussion on parser-based font-lock
keywords in emacs-devel. See
https://yhetil.org/emacs-devel/87wn9srn9n.fsf@localhost/

The code status still requires some decisions to be made about code
design of the parser. In particular, the current (albeit working)
implementation will make it difficult to apply arbitrary fontification
order for parent/child elements. Like in
https://orgmode.org/list/m2mtdp2cwo.fsf@ntnu.no

And I need to write tests, add faces to all possible elements/objects,
and re-factor the code into shorter function.

I have not had much time to work in these lately because of the upcoming
Org release.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92



reply via email to

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