emacs-orgmode
[Top][All Lists]
Advanced

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

Re: org-mode: example blocks are no longer syntax highlighted in emacs


From: Bruno Barbier
Subject: Re: org-mode: example blocks are no longer syntax highlighted in emacs
Date: Fri, 23 Feb 2024 11:35:05 +0100

Hi Rudy,

Note that I am not an org maintainer; just trying to help :-)

Rudi C <rudiwillalwaysloveyou@gmail.com> writes:

>> Why is `:eval never` not as good ?  You don't have to write it on each
>> code block; you may set it globally, per file, per headline, etc.
>
> The main reason is that I also use source blocks for babel blocks that are
> runnable. So I cannot use per headline etc. solutions. I can use snippets
> to automatically insert `:eval never`, but it's not as good a UX.

You could customize `org-insert-structure-template' like this:

    (add-to-list 'org-structure-template-alist
                  (cons "p"  "src python :eval never"))

Then:

    C-c C-, p
    
should insert your code example:

   #+begin_src python :eval never
   #+end_src


> I also already have lots of org-mode notes written using `example lang`
> blocks. Rewriting all of these will be a PITA.

You could teach Emacs to fix/rewrite those for you.  Ask here if you
need help.  You're probably not the only one that will need to fix
them.


> NickD has identified the commit that introduced this breaking change:
>
> ...
> https://github.com/bzg/org-mode/commit/616e80a9f10c4bd085d7b5ac96fd6ea23e9c9191
> I wrote this patch which can be put in one's config to make this behavior
> configurable.

Thanks for the link.

(your code layout was broken, it's more reliable to attach these kinds
of documents)


> Can you merge this upstream? emacs is all about user customizability, and
> in general, breaking backward compatibility without giving a way out is bad.

According to the email thread, the change was made only to match the
documentation (see
https://list.orgmode.org/87zg7lghzz.fsf@gmail.com/).

So, maybe a new option, like you suggested will be accepted, something like:

   (defvar org-fontify-block-types '("src")
      "Which block types to fontify.
      Prior versions of Org may fontify other blocks than src.  That
      invalid behavior is now fixed.  If you have documents relying on
      this invalid behavior, and, you cannot fix them, add the block
      types to this list.")
      
But:
   -  Fontification must be fast. The more options, the harder to
      optimize.

   -  It might just be opening a can of worms: Why is editing not
      working too then ? Why is the indentation incorrect? Why are
      they not exported correctly ? Why is pandoc not able to handle
      them correctly ?  etc.

Let see what other people think.

Bruno




reply via email to

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