From: "Sébastien Miquel" <sebastien.miquel@posteo.eu>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Support for tagging (special) blocks
Date: Fri, 2 Sep 2022 15:32:26 +0000 [thread overview]
Message-ID: <8f79980b-e903-c68a-cf07-6c5265215ee4@posteo.eu> (raw)
In-Reply-To: <87a67hncp7.fsf@localhost>
Ihor Radchenko writes:
> Sébastien Miquel <sebastien.miquel@posteo.eu> writes:
>
>> Ihor Radchenko writes:
>> > They do not. Tags are only considered inside headlines. Trying
to allow
>> > tags outside headlines will require major changes across the
whole Org
>> > codebase and will still make things incompatible with third party
>> > packages, like org-ql. Not to mention the whole new concept for
block
>> > syntax.
>>
>> Tags on block do not need to have the same support as headlines tags.
>> I'm not suggesting they should interact with the agenda or whatnot.
>> Support could be behind a user option, and consist only of say easy
>> tag edition, and `#+exclude_tags:` support. With that scope, the
>> implementation should be fairly simple. As for third party packages,
>> it is up to them whether to extend their features to tagged blocks ;
>> in some case it might not make sense.
>
> We already have ":exports none" header argument.
For src block yes, but not for special blocks.
To explain where I'm coming from : I write mathematical content
categorized using special blocks, such as theorems, exercices, proofs,
personnal notes, etc. Then from a single org file, I export several
pdf files, filtering the content according to the types and tags of
special blocks : for example, to exclude some proofs, or exercices
that are too hard.
>
>> > If one wants to add "tags" or other keywords associated with
blocks or
>> > other Org elements, the right tool to use is affiliated
keywords. But
>> > note that Org search infrastructure is tailored towards searching
>> > headlines.
>>
>> Two inconvenients with using affiliated keywords.
>> 1. There would be no uniform treatment with headline tags. In my use,
>> I have the same tags on headline and blocks, and I filter the
>> export according to them with #+exclude_tags.
>
> Affiliated keywords are indeed not uniform with headlines. But they are
> uniform with everything else. Paragraphs can have affiliated keywords.
> Or other blocks. Or lists. Or tables...
That's indeed a good point. In fact, I had been wondering recently how
I could tag a single list item, but I guess affiliated keywords still
can't do that.
>
>> 2. They waste too much space. Say I have some 20 short exercices
>> (represented by special blocks). Since I dot not display the
>> #+end_ line, each of them takes 2 or 3 lines in my screen. If I
>> want to tag those using affiliated keywords that makes for a 50%
>> or 33% size increase, with very poor readability.
>
>> On a slightly related note, I find it quite unfortunate that one
>> presently cannot make use of the #+begin_ line of special blocks to
>> set some kind of optional title instead of using #+name or
>> #+attr_latex. That's a lot of wasted real estate.
>
> Yes, but we do not want to overcomplicate Org syntax. Affiliated
> keywords are universal across multiple element types. Adding a
> specialized syntax for src blocks will make things complex technically
> and create duplicate code.
>
> We can alter the fontification to compact the screen space though. Will
> it suffice?
>
I don't see any possible compactification that doesn't hinder
readability. From my perspective, it is important that the type of the
special block, its title, and its tags are readable.
One thing that org can do in that regard is hide the #+end_ line. For
special blocks, a requirement is that the org-block face should apply
to them too, to see where the block ends.
--
Sébastien Miquel
next prev parent reply other threads:[~2022-09-02 15:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 4:13 Support for tagging (special) blocks Payas Relekar
2022-09-01 6:13 ` Ihor Radchenko
2022-09-01 16:40 ` Sébastien Miquel
2022-09-02 13:11 ` Ihor Radchenko
2022-09-02 15:32 ` Sébastien Miquel [this message]
2022-09-03 8:41 ` Ihor Radchenko
2022-09-03 10:00 ` Sébastien Miquel
2022-09-04 4:54 ` Ihor Radchenko
2022-10-04 16:58 ` Sébastien Miquel
2022-10-05 7:49 ` Ihor Radchenko
-- strict thread matches above, loose matches on Subject: below --
2022-08-31 20:10 Sébastien Miquel
2022-08-31 20:38 ` Kaushal Modi
2022-09-01 6:59 ` Fraga, Eric
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.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f79980b-e903-c68a-cf07-6c5265215ee4@posteo.eu \
--to=sebastien.miquel@posteo.eu \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/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/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).