From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [DISCUSSION] Refactoring fontification system
Date: Thu, 9 Jun 2022 22:31:09 +0700 [thread overview]
Message-ID: <t7t3o3$ink$1@ciao.gmane.io> (raw)
In-Reply-To: <CA+G3_PPYmiiwHYKkgiJDZQ=o7DvaG=0G3aQnPHSBKEMZsOyG-g@mail.gmail.com>
On 08/06/2022 11:23, Tom Gillespie wrote:
>> As for lang parameter support in example blocks, would you mind creating
>> a separate feature request thread? Extending export blocks export will
>> require changing in parser syntax and thus should be discussed carefully
>> in a separate thread.
>
> I would strongly caution against allowing an optional #+begin_example lang
> syntax. It will lead to extreme confusion, even when users know to use org-lint.
> The reason for this is that example blocks do not have (and frankly should not
> have) full org-babel support. Babel is already complex enough as is without
> having to explain to a user that yes they can noweb an example block into
> a src block, but that they cannot noweb a source block into an example block.
My expectation is that treating #+begin_example almost as #+begin_src
will simplify code. E.g. `org-latex-src-block' has a fallback to plain
\begin{verbatim} if language is unknown or is not specified, so it may
handle examples as well. The difference is that for #+begin_example
evaluation and noweb are disabled, either it is hardcoded (my
preference) or default values for :noweb and :eval header argument are
adjusted.
On 09/06/2022 12:37, Pedro Andres Aranda Gutierrez wrote:
> OK, just to add to the discussion. The original intent of my message was
> to give _me_ control over what I want to colour, not delegating that to
> the fontifying engine in Emacs.
>
> I need limited and controlled colouring for text-books and lab manuals
> where colouring elements of a listing goes against the publishing
> standards. I only need custom colouring to "emulate" terminal output,
> not for the code as such. And I could do that with the #+ATTR: if supported.
Fontification and an attribute to specify an option for environment are
independent features. My point is that if example and src blocks reused
the same code than it would be enough to implement :options attribute
(similar to #+begin_quote) once and both types of blocks would be more
flexible.
If #+begin_example becomes more dumb, unsure if it is reasonable to
allow to generate "\begin{verbatim}[commandchars=\\\{\}]" for example
block but not for source blocks.
Side note: I can not say that #+begin_example with language is widely
used, but one case may be found in org-manual.org and a dozen in worg.
next prev parent reply other threads:[~2022-06-09 17:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
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
2022-06-03 9:45 ` Ihor Radchenko
2022-06-03 20:37 ` Ted Reed via General discussions about Org-mode.
2022-06-04 13:45 ` Ihor Radchenko
2022-06-04 23:28 ` Ted Reed via General discussions about Org-mode.
2022-06-03 21:38 ` Tim Cross
2022-06-07 16:48 ` Max Nikulin
2022-06-08 2:02 ` Ihor Radchenko
2022-06-08 4:23 ` Tom Gillespie
2022-06-08 6:35 ` Tim Cross
2022-06-09 15:31 ` Max Nikulin [this message]
2022-06-10 2:06 ` [PATCH] #+begin_example lang used in manual and worg (was: [DISCUSSION] Refactoring fontification system) Ihor Radchenko
2022-06-15 3:40 ` Max Nikulin
2022-06-16 12:31 ` Ihor Radchenko
2022-06-16 12:33 ` [BUG] Unescaped #+ lines in WORG example blocks (was: [PATCH] #+begin_example lang used in manual and worg (was: [DISCUSSION] Refactoring fontification system)) Ihor Radchenko
2022-06-16 16:33 ` Tim Cross
2024-04-15 13:44 ` Ihor Radchenko
2022-06-16 15:08 ` [DISCUSSION] Refactoring fontification system Max Nikulin
2022-06-08 6:52 ` Phil Estival
2023-05-30 11:25 ` [RFC] Refactoring org-element API (was: [DISCUSSION] Refactoring fontification system) Ihor Radchenko
2023-05-30 11:32 ` Ihor Radchenko
2023-05-30 15:00 ` [RFC] Refactoring org-element API Stefan Nobis
2023-05-31 8:57 ` Ihor Radchenko
2023-06-23 12:20 ` Ihor Radchenko
2023-06-30 13:53 ` Ihor Radchenko
2023-07-01 11:44 ` [RFC] Refactoring org-element API (was: [DISCUSSION] Refactoring fontification system) Ihor Radchenko
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='t7t3o3$ink$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).