Re: [FR] Allow flattened imenu index

[Spencer Baugh]

Ihor Radchenko  writes:
> Eli Zaretskii  writes:
>
>>> I am wondering if it makes more sense to add this "flatten" option
>>> globally into imenu instead.
>>
>> I'm not sure I understand what you are asking.  As we don't seem to
>> have an active maintainer of imenu on board, more details are needed
>> to understand the request.  Of course, patches are even more welcome.
>
> Normally, `imenu' supports nested menus, when users select the target
> location in steps, like item3  -> item3.1  -> ...
>
> What is proposed is to list all the sub-menus together, as an option, so
> that the users can choose, for example, item.3.1 directly, without going
> through parent item3.

I would love to have this feature.  I have wanted this for OCaml, where
the default imenu index produced by the "merlin" tool is annoyingly
deeply nested, which makes it awkward to use.

I have an alternative proposal though, which might be better: We could
enhance the imenu completion table to understand completion boundaries.
Then the imenu hierarchy could be completed over in a single
completing-read instead of a sequence of multiple completing-reads.  It
would work the same way as read-file-name.

So, for example, if the completion boundary was /, and we had a hierarchy
containing these elements:
aaa/bbb/ddd
aaa/bbb/eee
aaa/ccc/eee
aaa/ccc/fff

You could choose aaa/bbb/ddd with this sequence of minibuffer contents:
(input in [brackets], point at |)

[a]
a|
[]
aaa/| ; completion now shows bbb and ccc as options
[b]
aaa/b/d|
[TAB]
aaa/bbb/ddd|
[RET]

Alternatively, you could choose aaa/bbb/eee with this sequence:

[*/*/e]
*/*/e|
[TAB]
aaa/|/eee ; completion now shows bbb and ccc as options, point is at |
[b]
aaa/b|/eee
[TAB]
aaa/bbb/eee|
[RET]

To be very clear, these completion features already exist (and are
enabled by default!), all we would need to do is enhance the imenu
completion table to understand completion boundaries, and then imenu
would have access to these features too.

This new completion table could be turned on by default, since it would
be strictly more powerful than the current imenu UI.

Plus, if some alternative completion UI wanted to flatten the hierarchy
anyway, this more advanced imenu completion table would allow that.

Re: [PATCH] org-id: allow using parent's existing id in links to headlines

[Rick Lupton]

Dear Ihor,

Thanks for taking a look at the patch and for your feedback.

Re various docstrings, documenting new optional argument -- I will try to 
address these.

Other comments/questions below.

On Sun, 10 Dec 2023, at 1:35 PM, Ihor Radchenko wrote:
> "This change..." part sounds like a commit message, not a NEWS item.

I think there are lots of other examples that are written like this in ORG-NEWS 
(but I agree my sentence was unnecessary and have removed it).

>> +(defcustom org-id-link-use-context t
>> +  "Non-nil means org-id links from `org-id-store-link' contain context.
>> +\\
>> +A search string is added to the id with \"::\" as separator and
>> +used to find the context when the link is activated by the
>> +command `org-open-at-point'.  When this option is t, the entire
>> +active region is be placed in the search string of the file link.
>> +If set to a positive integer N, only the first N lines of context
>> +are stored.
>
> It does not look like integer value is respected in the patch.

You're right. Do you have a preference between

(a) sticking to this docstring, which creates the possibility of using 
different numbers of lines for id: and file: links' context, and makes the code 
slightly more complicated, but keeps the meaning of 
`org-link-context-for-files' specifically `for files'; or

(b) Always use `org-link-context-for-files' to set the number of lines of 
context used for all links; `org-id-link-use-context' is just a boolean. The 
code is simpler.

?

>> -  (let ((id (org-entry-get epom "ID")))
>> +  (let ((id (org-entry-get epom "ID" inherit)))
>
> This makes your description of INHERIT argument slightly inaccurate - for
> `org-entry-get', INHERIT can also be a special symbol 'selective.

Good point; I think the answer is to force INHERIT to t or nil, rather than 
documenting and continuing to accept 'selective (when INHERIT is used, it 
should definitely take effect).

>> -(defun org-id-store-link ()
>> +(defun org-id-store-link (interactive?)
>
> Please make this new argument optional and document the argument in the
> docstring and NEWS. Non-optional new argument is a breaking change that
> may break third-party code.

Oops, yes -- but in fact this argument is only needed on 
`org-id-store-link-maybe' (as below), so I can remove it again here.

>>"Store a link to the current entry, using its ID.
>>  
>> +See also `org-id-link-to-org-use-id`,
>> +`org-id-link-use-context`,
>> +`org-id-link-consider-parent-id`.
>> +
>>  If before first heading store first title-keyword as description
>>  or filename if no title."
>> -  (interactive)
>> -  (when (and (buffer-file-name (buffer-base-buffer)) (derived-mode-p 
>> 'org-mode))
>> -(let* ((link (concat "id:" (org-id-get-create)))
>> +  (interactive "p")
>> +  (when (and (buffer-file-name (buffer-base-buffer))
>> + (derived-mode-p 'org-mode)
>> + (or (eq org-id-link-to-org-use-id t)
>
> I do not like this change - `org-id-store-link' is not only used by
> `org-store-link'. Suddenly honoring `org-id-link-to-org-use-id' will be
> a breaking change. Instead, I suggest you to write a wrapper function,
> like `org-id-store-link-maybe' and use it as :store id link property.
> That function will call `org-id-store-link' as necessary according to
> user customization.

Ok, yes that makes sense.

>> +  ;; Prefix to `org-store-link` negates preference from 
>> `org-id-link-use-context`.
>> +  (when (org-xor current-prefix-arg org-id-link-use-context)
>
> This is not reliable. `org-id-store-link' may be called from a completely
> different command, not `org-store-link'. Then, the effect of prefix
> argument will be unexpected. You should instead process prefix argument
> right in `org-store-link' by let-binding `org-id-link-use-context'
> around the call to `org-id-store-link'.

Now that `org-id-store-link' is called via :store link property, 
`org-store-link` does not have special logic for org-id, which I thought was an 
improvement, so it would be a step backwards to add in special logic for 
`org-id-link-use-context'?

Instead, I think this logic could be in `org-id-store-link-maybe' as above. 
That is, it is safe to take account of `current-prefix-arg' within a link 
:store function, and assume it represents prefix args as used with 
`org-store-link'? 

>
>> +(pcase (org-link-precise-link-target id-location)
>
> Why not passing the RELATIVE-TO argument?

The `id-location' is the RELATIVE-TO argument. Or do I misunderstand you?

>>  (defun org-id-open (id _)
>>"Go to the entry with id ID."
>> -  (org-mark-ring-push)
>> -  (let ((m (org-id-find id 'marker))
>> -cmd)
>> +  (let* ((option (and (string-match "::\\(.*\\)\\'" id)
>> +  (match-string 1 id)))
>> + (id (if (not option) id
>> +   (substring id 0 (match-beginning 0
>> + m cmd)
>> +(org-mark-ring-push)
>> +(setq m (org-id-find id 'marker))
>
> This means that the existing IDs that 

Re: [BUG] ox-texinfo no longer inserts menus if there is no content

[Ihor Radchenko]

Jonas Bernoulli  writes:

> (This came up in 878r9p1ntd@bernoul.li, on emacs-devel, but it
> seems it fell through the cracks.)

I thought I fixed this in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dbf415b84

... as I said in https://yhetil.org/emacs-devel/87il8sv6r2.fsf@localhost/

Are you saying that the problem is still present on the latest main?

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

[BUG] ox-texinfo no longer inserts menus if there is no content

[Jonas Bernoulli]

Hello,

(This came up in 878r9p1ntd@bernoul.li, on emacs-devel, but it
seems it fell through the cracks.)

If a section only has subsections but no content of its own, then
ox-texinfo no longer generates the section's menu (listing the
subsections).  And if the section additionally is part of an appendix,
then the subsections now use @subsection instead of @appendixsubsec.

I looked at the history of org and ox-texinfo.el in particular, but
could not find any code change that would explain that change in
behavior.  Org 9.6.8 still works as expected.

 demo.org ---

* only subsections, no direct content
** sub 1
body
** sub 2
body
* A
:PROPERTIES:
:APPENDIX: t
:END:
** AA only subsections, no direct content
*** AAA
body

 demo.texi with org release_9.6.8 ---

\input texinfo@c -*- texinfo -*-

[...]

@node only subsections no direct content
@chapter only subsections, no direct content

@menu
* sub 1::
* sub 2::
@end menu

@node sub 1
@section sub 1

body

@node sub 2
@section sub 2

body

@node A
@appendix A

@menu
* AA only subsections, no direct content: AA only subsections no direct 
content. 
@end menu

@node AA only subsections no direct content
@appendixsec AA only subsections, no direct content

@menu
* AAA::
@end menu

@node AAA
@appendixsubsec AAA

body

@bye

 demo.texi with org release_9.6.13-975-gb8d27bb4e ---

\input texinfo@c -*- texinfo -*-

[...]

@node only subsections no direct content
@chapter only subsections, no direct content

@node sub 1
@section sub 1

body

@node sub 2
@section sub 2

body

@node A
@appendix A

@menu
* AA only subsections, no direct content: AA only subsections no direct 
content. 
@end menu

@node AA only subsections no direct content
@appendixsec AA only subsections, no direct content

@node AAA
@subsection AAA

body

@bye

-

bye;)
Jonas

Re: TODO item: is there a way to alert me about it?

[Ihor Radchenko]

Renato Pontefice  writes:

> Appointment reminders
>
>  <> <> <> <> <>Org can interact with Emacs appointments notification 
> facility. To add the appointments of your agenda files, use the command 
> org-agenda-to-appt. This command lets you filter through the list of your 
> appointments and add only those belonging to a specific category or matching 
> a regular expression. It also reads a ‘APPT_WARNTIME’ property which 
> overrides the value of appt-message-warning-time for this appointment. See 
> the docstring for details.
>
>
> This?

This as well. You may add it to your config, for example. Or run on
timer to add reminders to recently added headings.

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

Re: TODO item: is there a way to alert me about it?

[Ihor Radchenko]

Renato Pontefice  writes:

> Can you show me some package that do it?

https://elpa.gnu.org/packages/org-notify.html for example.

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

Re: Links & images with different attributes in the same paragraph

[Ihor Radchenko]

Max Nikulin  writes:

>> Nested objects of the same type are not really a limitation of top-down
>> parser. It is the syntax of objects that might but does not have to be.
>> We might come up with a syntax that allow nesting.
>
> I would be glad to learn that I am wrong. The current parser picks first 
> terminating token ignoring other opening tokens in between. The only way 
> I see is unique identifiers for opening and closing tokens to allow 
> match them in pairs. It would be tedious to type and to copy fragments 
> from similar text.

Not necessarily. The current parser also allows balanced brackets inside
an object. Search for "balanced" in
https://orgmode.org/worg/org-syntax.html and you will see many examples.

In addition, we can allow multiple forms of tokens. For example,
@wrap{simple wrap}; @wrap{{we can have } inside}};
@wrap{outer wrap; @wrap{inner wrap}; back}.
@wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.

> A similar problem is importing and exporting fragments of mail messages 
> having multilevel quotes. #+begin_quote is not enough, it is necessary 
> to use something else for inner citations, e.g. #+begin_quote1.

As you see, my solution is conceptually similar to #+begin_quote1 idea.

> Moreover I would prefer to have links as links even when they need some 
> special treatment.

What about @wrap[#+attr_html: :alt "Text"]{[[/path/to/image]]}?

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

Re: [PATCH] ol-man.el: Enable completion

[Ihor Radchenko]

Max Nikulin  writes:

>> Max, may you convert this into a patch?
>
> See attachments

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7c9a5216b
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b8d27bb4e

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

Re: Provide org-insert-subitem

[Ihor Radchenko]

Bastien Guerry  writes:

>>> Of course I could bind it myself, and in one of my configs I have, but I 
>>> still think it deserves a default binding, even if it were to be a 
>>> "smart" command that worked like org-table-copy-down when in a table and 
>>> does org-insert-subheading otherwise (because I still think that "S-RET" 
>>> is an obviously appropriate binding for this command).
>>>
>>> What do you think?  =)
>>
>> I think that it still makes sense, even after all these years ;)
>
> +1!  Thanks for reviving this thread.
>
> I would suggest a larger set of enhancements here:
>
> - S-RET on a heading copies down the heading.
>
>   For that we would need a new command `org-clone-subtree' bound to
>   S-RET that would immediately copy the heading at point. This command
>   would accept a universal argument to allow for a number a clones and
>   two universal arguments for adding a time shift.
>
>   `org-clone-subtree-with-time-shift' would continue to be bound to
>   `C-c C-x c' but would be really a call to `org-clone-subtree'
> ...
> S-RET already "copy down" a table cells, so I'm really suggesting a
> generalization of the current keybinding.

This makes sense.

> - S-RET on a list item calls `org-insert-subitem`, a new command.

Did you mean `org-clone-item'?

> - C-M-RET on a heading calls `org-insert-subheading', the existing
>   command.
>
> - C-M-RET on a list item calls `org-insert-subitem', a new command.
>
> I like C-M-RET better than S-RET because inserting a subheading is
> like a "subkey" or inserting a heading.

I tried to play around a bit with various flavours of X- commands
and I am not sure if I like C-M-RET:

1. For org-insert-heading, we have multiple variants that allow
   inserting heading at point, after current subtree, and the same
   variants for TODO heading. We don't have enough key combinations left
   to allow all the equivalents for subheadings.

2. With `org-cycle-level-after-item/entry-creation' set to t (default),
   it is actually very easy to create a subheading/subitem using the
   available C/M-[S]- commands. Just do M- . And the same
   will work for inserting todo headings.

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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> From 66baf6e1d435974fb4c51cc47eb5b3ace3feb22c Mon Sep 17 00:00:00 2001
> From: Nathaniel Nicandro 
> Date: Tue, 9 May 2023 19:58:11 -0500
> Subject: [PATCH] Highlight ANSI escape sequences

Matthew, this thread might be of interest for you as the new feature is
largely aiming at the shell block output.
Feel free to jump in if you have comments on the design of the
ASCII fontification for complex shell block output.

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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> Attached is the updated version of the patch.  I've also attached an
> updated file that I've been using for testing the feature.

Sorry for the late reply, and thanks for the patch!
It runs fine on my side, although I am not sure if things are working as
expected for all the cases. For example, headlines never got fontified
on my side when I tried your patch on top of the latest main branch.

Also, it looks like you simply made the ASCII sequences invisible, which
causes funky behaviour when trying to edit the text around. What we may
need instead is something similar to hidden parts of the links that get
revealed when we try to edit the invisible text. See
`org-catch-invisible-edits' variable and the functions that examine it.

> What I have is essentially a function, org-fontify-ansi-sequences, that
> scans the buffer for an ANSI sequence and depending on the
> element-context processes the region that should be affected according
> to the rules you stated (see above).  The org-fontify-ansi-sequences-1
> function scans the buffer element-wise and processes the appropriate
> regions of the elements, even if no sequences appear in those regions,
> according to an ansi-context.  This is to support the fourth rule you
> mentioned.
>
> Note that modifications to highlighted regions hasn't really been
> considered so if you have a scenario like
>
> #+RESULTS:
> - Paragraph one
> - Paragraph two
>   Line 3
>
> where the sequence affects everything down to "Line 3" and you make a
> modification to line three, the fontification due to the sequence
> disappears on that line.

You may use `org-fontify-extend-region' to handle such scenarios if you
mark the ANSI highlights with a special text property.

> Also note that lesser elements contained in greater elements that
> don't have a RESULTS keyword are handled at the lesser element level
> so if you have something like
>
> #+begin_center
> Paragraph one.
>
> Paragraph two.
> #+end_center
>
> It would be the same as if you just had the paragraphs without the
> greater element.

Sounds reasonable.

P.S. I am not yet commenting on the details in the code.

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

Re: How to use mpirun with C or C++ Org-babel?

[Ihor Radchenko]

Leo Butler  writes:

> From 7d8e406bc4a92e2e2eab772b2671dcd72ca8c202 Mon Sep 17 00:00:00 2001
> From: Leo Butler 
> Date: Tue, 12 Dec 2023 12:32:41 -0600
> Subject: [PATCH] lisp/ob-C.el: add :compile-only header to compile to a named
>  target

Thanks for the patch!

> * lisp/ob-C.el (org-babel-C-execute): The new header argument,
> `:compile-only', causes source and compiled binary files to be named
> using the `:file' header argument.  When `:compile-only' is set,
> execution of source block ends at compilation.  The naming of source
> and binary filenames is factored out to `org-babel-C-src/bin-file'.

What will happen if we have something like :results value or :results
output instead of :results file link?

> * lisp/ob-C.el (org-babel-C-src/bin-file): A new function that factors
> out the setting of source and binary filenames.  It also signals an
> error if `:compile-only' is set, but `:file' is not.
> * testing/examples/ob-C-test.org: Add three example that exercise the
> `:compile-only' header argument, including one that causes an error.
> * testing/lisp/test-ob-C.el: Add three tests of the `:compile-only'
> header argument.  New tests: ob-C/set-src+bin-file-name-{1,2,3}.

You should also announce the new feature in ORG-NEWS and document it in
WORG.

> +(compile-only . (nil no t yes)))

Why nil/t? No other header argument allow "nil" or "t". Just yes/no.

> +(defun org-babel-C-src/bin-file (params src? compile-only?)
> +  "Return the src or bin filename to `org-babel-C-execute'.
> +
> +If `SRC?' is T, a file extension is added to the filename.  By

Just SRC?. You should only quote Elisp symbols and upcase the function
arguments. See
https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html

Also, why upcase "T"?

> +default, the filename is created by `org-babel-temp-file'. If
> +`COMPILE-ONLY?' is T, the filename is taken from the `:file'

I think quoting :file is not necessary.

> +field in `PARAMS'; if that is NIL, an error occurs."

No need to upcase NIL.
Also, "if that is nil, throw an error" - this is more common style
(saying what function does).

> +  (let ((f (cdr (assq :file params

Please avoid short variable names - they are harder to understand and
search in code.

> +(when (and compile-only? (null f))
> +  (error "Error: When COMPILE-ONLY is T or YES, output FILE needs to be 
> set"))

t or "yes". Also, what does "output FILE" refer to? Upcasing implies
function argument, but you are referring to :file header argument in PARAMS.

> +(let* ((file (cond (compile-only? f) (src? "C-src-") (t "C-bin-")))
> +   (ext (if src? (pcase org-babel-c-variant
> +(`c ".c") (`cpp ".cpp") (`d ".d"))

We usually split `cond' and `case' into multiple lines for readability.
Otherwise, it is confusing, especially in `let' forms where one can
confuse `cond' forms with `let' bindings.

> +(unless compile-only?
> +  (let ((results
> +  (org-babel-eval
> ...

No return value at all? I'd expect file link to be returned, as we
discussed in another thread. Also, see the above considerations about
:results value/output. We might want return the compiler output for
:results output. Or maybe even arrange `org-babel-eval-error-notify' to
display compile-mode window when there are compilation warnings.

> --- a/testing/examples/ob-C-test.org
> +++ b/testing/examples/ob-C-test.org
> @@ -174,3 +174,29 @@ std::cout << "\"line 1\"\n";
>  std::cout << "\"line 2\"\n";
>  std::cout << "\"line 3\"\n";
>  #+end_src

If you can, please avoid adding tests as Org files where possible.
Instead, we prefer using `org-test-with-temp-text' or
`org-test-with-temp-text-in-file' when the Org fragment for the test is
not too long.

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

Re: oeg-add-note and double backslash ?

[Ihor Radchenko]

David Masterson  writes:

> The form for copyright assignment asks what files have you changed so
> far. I assumed the form would be universal for any past and future
> changes you make to the program (Emacs).  Do people really need to fill
> that part out? Do I need the info from the 2 commits?

I think it would not hurt.
This form is just a plain text - you will receive a proper pdf form with
all the legal details later for actual signing.

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