Suggestion: User-contributed use-cases on orgmode.org ?

[David Masterson]

Just a suggestion (or maybe this is already handled?).

Was thinking I'd like to see an archive of tagged use-cases for Org that
could be searched via tags or regexp.  The use-cases should include a
description of the problem, a general description of the answer, blocks
of elisp (general code) to setup the answer, and how to use the code to
do the work of the use-case.  In fact, it could be recommended that the
use-cases be written in literate programming style (the first use-case
would have to provide the recommended example).  As such, if written
properly in Org, it could (after a once over by maintainers) be exported
to HTML for inclusion on orgmode.org.

My reason for this is to have a ready reference for how other people
have setup functions/variables that I could then copy/modify for my
particular need.  Many times, hacking other people's code is easier than
digging into the Elisp of the various parts of Org. Forty years of using
Emacs (off fand on) and hacking pieces of Elisp, I never really learned
programming in Elisp.

-- 
David Masterson

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Sat, Nov 11 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> And even if we do want to add certain features in future (like
>>> supporting ditaa executable herein), it does not mean that we have to
>>> rush them by any cost.
>>
>> Ihor, I don't understand that sentence.
>>
>> The *documentation* patch was intended to show that ob-ditaa did not
>> need to be changed. A user can already run ditaa from a script file by
>> setting the customization variables appropriately (or, inappropriately,
>> as Max said ;-) ).
>
> Let me elaborate.
> The below explanation in your patch relies upon the implementation
> detail in `org-babel-execute:ditaa' - how the ditaa command is called.
> however, it can easily happen that we change that detail in future.

Thanks for your clarifications here and in a related email. 

> In fact, your explanation is already not correct for
> :file foo.eps - org-ditaa-jar-path value is ignored in such scenario:

You say `not correct', I say `mutatus mutandis'.

>
> (cmd (concat org-babel-ditaa-java-cmd
> " " java " " org-ditaa-jar-option " "
> (shell-quote-argument
>  (expand-file-name
>   (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
> " " cmdline
> " " (org-babel-process-file-name in-file)
> " " (if pdf-cmd
> eps-file
>   (org-babel-process-file-name out-file
>
> Further, it won't help with the discussed problem -
> trying
> (setq org-ditaa-jar-path "flatpak-spawn --host toolbox run ditaa") will
> simply fail when passed through `shell-quote-argument'.

The patch says "Users may need to use a script to run ditaa." It does
not mention passing arbitrary command strings.

>
> And now imagine that we change how CMD is produced in future. (For
> example, there is a WIP branch that unifies escaping command arguments
> to avoid vulnerabilities). Your documentation patch may cease working
> any moment, causing damage to users who tried to follow it. Or we may
> have to constrain the ways we change the internal implementation details
> in order to not break the existing documentation. Either way is not good
> and that's why I am saying no to your proposed documentation change.

Ok, I have a clearer idea of how to proceed.

Leo

Re: org-src-font-lock-fontify-block is unaware of org-edit-src-content-indentation, leading to fontification issues

[Ihor Radchenko]

JD Smith  writes:

>> Duplicate of
>> https://list.orgmode.org/orgmode/CAOn=hbevUMGS0-qMTy8kB4-db65s1Tmn0cQJcw8b++PZZ=v...@mail.gmail.com/
>> Handled.
>
> Great.  In Org 9.7?

No. It is not fixed yet.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-src-font-lock-fontify-block is unaware of org-edit-src-content-indentation, leading to fontification issues

[JD Smith]

> On Nov 13, 2023, at 3:37 AM, Ihor Radchenko  wrote:
> 
> JD Smith  writes:
> 
>> When `org-edit-src-content-indentation’ is non-nil (default: 2), editing SRC 
>> blocks preserves this amount of extra indentation space at the beginning of 
>> each line of the block, removing and then re-adding it on round trips 
>> through `org-edit-src-code’.
>> 
>> But `org-src-font-lock-fontify-block' does not consider this extra space. 
>> Instead it simply copies the full block verbatim into e.g.  
>> *org-src-fontification:python-mode*, as if the extra indent space were a 
>> legitimate part of the source.  Normally this wouldn’t be a problem, as 
>> faces are attached to keywords.  But for any fontification that depends 
>> explicitly on indentation, this leads to incorrect results.  For example, my 
>> indent-bars package adds indentation bars via text properties based on 
>> absolute column position.  These bars are then offset in the displayed org 
>> src block by 2 columns from their correct locations, due to the extra space 
>> org has put there.
> 
> Duplicate of
> https://list.orgmode.org/orgmode/CAOn=hbevUMGS0-qMTy8kB4-db65s1Tmn0cQJcw8b++PZZ=v...@mail.gmail.com/
> Handled.

Great.  In Org 9.7?

Re: org-src-font-lock-fontify-block is unaware of org-edit-src-content-indentation, leading to fontification issues

[Ihor Radchenko]

JD Smith  writes:

> When `org-edit-src-content-indentation’ is non-nil (default: 2), editing SRC 
> blocks preserves this amount of extra indentation space at the beginning of 
> each line of the block, removing and then re-adding it on round trips through 
> `org-edit-src-code’.
>
> But `org-src-font-lock-fontify-block' does not consider this extra space. 
> Instead it simply copies the full block verbatim into e.g.  
> *org-src-fontification:python-mode*, as if the extra indent space were a 
> legitimate part of the source.  Normally this wouldn’t be a problem, as faces 
> are attached to keywords.  But for any fontification that depends explicitly 
> on indentation, this leads to incorrect results.  For example, my indent-bars 
> package adds indentation bars via text properties based on absolute column 
> position.  These bars are then offset in the displayed org src block by 2 
> columns from their correct locations, due to the extra space org has put 
> there.

Duplicate of
https://list.orgmode.org/orgmode/CAOn=hbevUMGS0-qMTy8kB4-db65s1Tmn0cQJcw8b++PZZ=v...@mail.gmail.com/
Handled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at