Coloring of Org Babel shorter/longer results

Hello @salutis and thank you for reporting this?

For longer results, Org Babel switches from : to #+{begin,end}_example as follows:

Why would Org change the style of the presentation depending on the lines of output? That seems arbitrary (at least based on your example).

Does this behavior represent a feature or a bug?

It shows a situation that is not controlled by the active theme. In the second case, the begin_example is a block, so it will use whatever modus-themes-org-blocks specifies. Whereas the first case uses the org-code face (the one you get with ~code~ notation---also check the modus-themes-intense-markup toggle).

As such, the "bugs" here are as follows:

Code blocks are not the same as inline ~code~, so they should have their own face (which can inherit from org-code for backward compatibility).
Result blocks should ideally have their own face, so that we can differentiate them from source blocks (e.g. we could colour them differently and/or apply a slant).
There are two types of formats for the results, though it is not clear why.

What do you think?

Re:

Why would Org change the style of the presentation depending on the lines of output? That seems arbitrary (at least based on your example).

and

There are two types of formats for the results, though it is not clear why.

See the org-babel-min-lines-for-block-output variable. By default, org-babel places longer results (over 10 lines) in #+{begin,end}_example.

Okay that explains it. What is the rationale though? What use-case does this differentiation serve?

[ It does not change the substance of your issue and I do not want to run off on a tangent. I am just curious because right now I think I would only ever want every result to look the same regardless of line count. ]

Background:

I decided to write some notes on statistics, and they contain lots of R. Some results get the gray highlight behind them while others do not. Further, on code and/or data changes, some results often become "highlighted" out of sudden. As a result, the current modus-themes defaults do not work that well for more serious literate programming, and that made me open this bug report.

What is the rationale though? What use-case does this differentiation serve? [ It does not change the substance of your issue and I do not want to run off on a tangent. I am just curious because right now I think I would only ever want every result to look the same regardless of line count. ]

To avoid visual noise?

In mathematical and scientific code, one often has lots of blocks that output a single scalar. For those, org-babel-min-lines-for-block-output reduces the number of lines by 100%.

Compare:

2 lines:

#+RESULTS:
: 9.5

4 lines (+100%):

#+RESULTS:
#+begin_example
9.5 
#+end_example

That makes sense. Thank you!

Then the actual problem we have is what I wrote before:

Code blocks are not the same as inline ~~code~~, so they should have their own face (which can inherit from org-code for backward compatibility).

Result blocks should ideally have their own face, so that we can differentiate them from source blocks (e.g. we could colour them differently and/or apply a slant).

Here is my specific constraint: I would like to remove the background from the org-code face (affects lines that start with :) and use a more colourful text colour instead. However, this would break the use-case of inline code, such as what I have in modus-themes.org. Sample:

This manual, written by Protesilaos Stavrou, describes the customization
options for the ~modus-operandi~ and ~modus-vivendi~ themes, and provides
every other piece of information pertinent to them.

You may ask, why not use = instead of ~? Because the .texi output distinguishes between the two. The = produce a @samp construct, which is semantically incorrect when describing a code symbol, whereas ~ returns @code:

This manual, written by Protesilaos Stavrou, describes the customization
options for the @samp{modus-operandi} and @samp{modus-vivendi} themes, and provides
every other piece of information pertinent to them.

This manual, written by Protesilaos Stavrou, describes the customization
options for the @code{modus-operandi} and @code{modus-vivendi} themes, and provides
every other piece of information pertinent to them.

So we are facing a dilemma because a single face applies to two cases that have different requirements.

In the past I had this:

`(org-code ((,class :inherit modus-themes-fixed-pitch :foreground ,magenta-alt)))

Try it with:

(set-face-attribute 'org-code nil :foreground (modus-themes-color 'magenta-alt))

EDIT: Ignore the inherit for now.

Try it with:

(set-face-attribute 'org-code nil :foreground (modus-themes-color 'magenta-alt))

But that leaves the gray background in place. Perhaps my explanation above lacks clarity as to what I expect. In short, I expect all results to either have or not have the gray background by default. That way, when the resulting vector gets longer (returning 12 elements instead of 6), the presentation style will not change.

But that leaves the gray background in place.

I understood your intent but thought the code would have the desired effect.

Please try this instead:

(set-face-attribute 'org-code nil :foreground (modus-themes-color 'magenta-alt) :background 'unspecified)

That is the style we had in the past. I still am no fan of it but it was a compromise between the "code block" and "inline code" cases.

For me the real solution is to patch Org so that #+RESULTS have their own face. Then we can style the face without making any compromises.

Please try this instead: ...

Now this one fixes it. It still looks different than the "example" blocks, but not diametrically different, like before. It also breaks the ~foo~, as expected. Now ~foo~ and =foo= look become diametrically different. Oops! Personally, I would go with conservative theming by default and expand in a clean, systematic way just when the relevant packages, such as Org, add the necessary faces (or fix bugs).

mentioned in issue #214 (closed)

Now ~foo~ and =foo= look become diametrically different.

Which means that to fix this case we must also change org-verbatim, org-macro and every other "inline code" in markdown-mode, markup-faces (adoc-mode), and more. I am fine with that, but I am pointing out that this is not a trivial change as it changes the character of the themes.

What should be the new style of those constructs if not a grey background and a subtle foreground? Maybe a more colourful foreground with no background. But that can make paragraphs looks a bit too colourful in some cases, especially in technical documentation. A subtle coloured text? That might be hard to discern...

So I need to research this thoroughly before making any changes.

Also, I should remind you why Org blocks do not have a background by default and why changing those is not an option:

  commit 2d5ed2ff2965167a4c28b1623565629cf5208fc7
  Author: Protesilaos Stavrou <info@protesilaos.com>
  Date:   Fri Dec 31 06:06:08 2021 +0200
  
      Change default style of Org block (no backgrounds)
      
      As I explained in Emacs bug#52587,[1] Org has code that overrides themes
      which prefer not to extend the block delimiter faces to the edge of the
      window.  This practically means that we cannot have backgrounds for
      those lines and keep them limited to the stretch of area covered by
      their text.
      
      As such, the default for Org block delimiter lines now is a gray
      foreground with no distinct background colour.  The user option
      'modus-themes-org-blocks' provides "blocky" alternatives that use
      background colours---those extend to the edge of the window.
      
      [1] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52587#46>
  
   doc/modus-themes.info | 151 ++++++++++++++++++++++++++------------------------
   doc/modus-themes.org  |  22 +++++---
   modus-themes.el       |  32 +++++++----
   3 files changed, 114 insertions(+), 91 deletions(-)

The upstream bug is what we discussed where the background "leaks" through a folded heading.

EDIT: add clarification.

mentioned in commit d370604b

Hello again @salutis!

Just added modus-themes-markup. Please try it. Also changed the default style for inline code and the like:

  commit d370604bfa09f9f9c4cc5535306919ec1ce29e97
  Author: Protesilaos Stavrou <info@protesilaos.com>
  Date:   Mon Jan 17 14:52:55 2022 +0200
  
      Add modus-themes-markup customisation option
      
      This affects constructs such as =verbatim= and ~code~ in Org, `code` in
      Markdown, `code' in Info, and more.
      
      * Change the default style for code markup in Org and others so that it
        only uses a foreground value instead of a combination of foreground
        and gray background.
      
      * The old style of a gray background with a very subtle foreground has
        been retired.  It did not work well in certain contexts and it no
        longer feels consistent with the rest of the theme due to changes such
        as in commit 2d5ed2f.
      
      * The new default works better for literate programming with Org, as
        #+RESULTS which output lines with the 'org-code' face do not have a
        background (same as the default for source blocks, which makes things
        look consistent).
      
      * The new default also combines naturally with the default style of Org
        mode to show emphasis markers.
      
      Thanks to Rudolf Adamkovič for the feedback in issue 274:
      <https://gitlab.com/protesilaos/modus-themes/-/issues/274>.
  
   README.md             |   6 +-
   doc/modus-themes.info | 268 ++++++++++++++++++++++++++++----------------------
   doc/modus-themes.org  |  62 +++++++++---
   modus-themes.el       | 131 ++++++++++++++++++------
   4 files changed, 308 insertions(+), 159 deletions(-)

added custom-option label

added development label

Oh, this look so much more consistent now:

Thank you, @protesilaos!

closed

You are welcome!

Coloring of Org Babel shorter/longer results

Designs

Child items ...

Activity