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

[Jonas Bernoulli]

Ihor Radchenko  writes:

> 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/

This was an unrelated bug that I found while desperately (but
unsuccessfully) trying to find a possible cause of the original issue.
I don't remember what the effect of this secondary (and fixed) issue was
in practice; just that I noticed that this (now reverted) change, was
not correct.

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

Yes, I can still reproduce the "menus are missing" and "type of
subsections in appendix changed" issues with the provided test file.

 Cheers,
 Jonas

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

[Rick Lupton]

On Fri, 15 Dec 2023, at 12:55 PM, Ihor Radchenko wrote:
> No, it is generally not safe. For a different reason.
>
> Let me illustrate with an example:
>
> ...
>
> Conclusion: It is unsafe to use `current-prefix-arg' value. We need to
> pass this information some other way.
>
> The way I proposed is actually not any special for ID links. What I
> meant it to let-bind `org-link-context-for-files' around the whole call
> to `org-store-link-functions', so that the custom :store functions will
> get access to the adjusted value of `org-link-context-for-files'.
> Does this explanation make more sense?

Thanks for the example and explanation. Yes that does make sense, mostly. I 
assume this would look like this in org-store-link:

(let ((org-link-context-for-files (org-xor org-link-context-for-files (equal 
arg '(4
(...call store link functions...))

The meaning of `org-link-context-for-files' is then shifting from being "should 
file: links include search strings (and how much should be included when the 
region is active)" from "should any link that supports search strings include 
them (and how much should be included when the region is active)". Is it 
necessary to rename it to reflect this? (e.g. to `org-link-use-context' or 
similar).

It's also then less clear what the role of `org-id-link-use-context' is and how 
it interacts with `org-link-context-for-files'. I had included 
`org-id-link-use-context' to give a way to opt out of the new behaviour (i.e. 
using the update discussed above, a search string is added if (and 
org-link-context-for-files org-id-link-use-context) ). But perhaps this is also 
unnecessarily complicated, and `org-id-link-use-context' could be removed again 
completely?

> I will update the docstring of
> `org-link-search' to explicitly specify that it is searching within the
> accessible portion of the buffer and update the callers to account for
> this.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=89164e605
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5c543cd9d
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb71bde7c
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=63ef7b924
>
> But does your code do narrowing? I did not notice it.

Not in the patch I sent, I added it later after you pointed this out.

I'll send an updated patch next.

Thanks,
Rick

Re: Citations bug with basic processor, plain bibliographies, LaTeX

[Ihor Radchenko]

William Denton  writes:

> I've found a bug on main that I think is related to the recent patches about 
> raw 
> string objects.
> ...
> mapconcat: Wrong type argument: stringp, (raw nil #("van Dongen, M.R.C." 0 18 
> (:parent #0)))

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=31caf84bb

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

Citations bug with basic processor, plain bibliographies, LaTeX

[William Denton]

I've found a bug on main that I think is related to the recent patches about raw 
string objects.


Try this as Basic.bib:

@book{friends,
  title = {{{LaTeX}} and Friends},
  author = {van Dongen, M.R.C.},
  date = {2012},
  location = {Berlin},
  publisher = {Springer},
  doi = {10.1007/978-3-642-23816-1},
  isbn = {9783642238161}
}

And then this as basic.org:

# --

#+bibliography: Basic.bib
#+cite_export: basic plain numeric
[cite:@friends]
#+print_bibliography:

# --

Exporting to text, HTML or ODT works, but trying with LaTeX gives this error:

mapconcat: Wrong type argument: stringp, (raw nil #("van Dongen, M.R.C." 0 18 
(:parent #0)))



Thanks,


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
CO₂: 421.80 ppm (Mauna Loa Observatory, 2023-12-14)

Re: [BUG] Org Markdown exporter (ox-md) does not respect Footnotes heading level [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Pablo Padilla  writes:

> I have describe the bug here: https://emacs.stackexchange.com/q/79770/11978

Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6e72a4c7f

Original post:

Given that I have an Org document with footnotes
And I have defined:
#+BIND: org-md-toplevel-hlevel 2
And in my Emacs init script I have set:
(setq org-export-allow-bind-keywords t)
When I export using ox-md: C-c C-e m m
Expected: Then I should see that the footnotes heading is a level 2 heading

Actual: The footnotes heading is always exported as a level 1 heading

Do I need to change another setting for this to work?

The entire Org document:

#+BIND: org-md-toplevel-hlevel 2

Post summary or tagline.

** level 1

   Post starts here. [fn:1]

   
*** level2

lorem ipsum


** Footnotes

[fn:1] a footnote 

The resulting Markdown file:


## Table of Contents

1.  [level 1](#orgfadcdb8)
1.  [level2](#org61fade8)

Post summary or tagline.




## level 1

Post starts here. 1




### level2

lorem ipsum


# Footnotes

1 a footnote


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

Re: [BUG] Warnings pop-ups in the org buffer [9.6.13 ( @ /home/soumya/.emacs.d/elpa/org-9.6.13/)]

[Ihor Radchenko]

Soumya Tripathy via "General discussions about Org-mode."
 writes:

> When I am working in a org-buffer, warnings pop-up like this:
>
>  "Warning (org-element-cache): org-element--cache: Org parser error in 
> init.org::75168. Resetting.
>  The error was: (error "Invalid search bound (wrong side of point)")
>  Backtrace:
> nil
>  Please report this to Org mode mailing list (M-x org-submit-bug-report)."

Thanks for reporting!
May you add
(setq org-element--cache-self-verify 'backtrace)
to you config and report the debug log that will appear in the
*Warnings* buffer next time you see the warning?

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

[BUG] Org Markdown exporter (ox-md) does not respect Footnotes heading level [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Pablo Padilla]

Emacs  : GNU Emacs 29.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 
Version 10.14.6 (Build 18G9323))
 of 2023-08-17
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/Applications/Emacs.app/Contents/Resources/lisp/org/)


I have describe the bug here: https://emacs.stackexchange.com/q/79770/11978

[BUG] Warnings pop-ups in the org buffer [9.6.13 ( @ /home/soumya/.emacs.d/elpa/org-9.6.13/)]

[General discussions about Org-mode.]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


When I am working in a org-buffer, warnings pop-up like this:

 "Warning (org-element-cache): org-element--cache: Org parser error in 
init.org::75168. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report)."

Emacs  : GNU Emacs 29.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0)
 of 2023-05-11
Package: Org mode version 9.6.13 ( @ /home/soumya/.emacs.d/elpa/org-9.6.13/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-log-done 'time
 org-agenda-custom-commands '(("c" "Simple agenda view"
   ((alltodo ""
 ((org-agenda-skip-function
   '(org-agenda-skip-entry-if 'notregexp 
"\\[#A\\]" 'todo 'done))
  (org-agenda-overriding-header "High-priority 
unfinished tasks:"))
 )
(agenda "")
(alltodo ""
 ((org-agenda-skip-function
   '(or (air-org-skip-subtree-if-priority 65)
 (org-agenda-skip-if nil '(scheduled 
deadline)))
   )
  )
 )
)
   )
  )
 org-startup-folded t
 org-agenda-files '("~/org_files/elfeed/" "~/org_files/")
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-refile-targets '((+org/opened-buffer-files :maxlevel . 9))
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-refile-use-outline-path 'file
 org-finalize-agenda-hook '(org-agenda-to-appt)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)
 org-wild-notifier-mode t
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-link-from-user-regexp 
"|\\"
 org-image-actual-width nil
 org-mode-hook '(pulsar-mode #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 jinx-mode
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append 
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes 
org-modern-indent-mode)
 org-babel-load-languages '((shell . t))
 org-modern-label-border nil
 org-modern-timestamp nil
 org-agenda-tags-column -120
 org-confirm-shell-link-function 'yes-or-no-p
 org-adapt-indentation 'headline-data
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-startup-indented t
 org-modern-todo nil
 org-babel-python-command "python3"
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-tangle-lang-exts '(("python" . "py") ("latex" . "tex") ("emacs-lisp" 
. "el")
  ("elisp" . "el"))
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-todo-keywords '((sequence "TODO(t)" "ONGOING(o)" "WAIT(w@/!)" "|" 
"DONE(d!/!)" "|"
  "CANCELED(c@/!)")
 )
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-modern-priority nil
 org-modern-mode-hook '(org-modern-mode-set-explicitly)
 org-export-backends '(ascii beamer html icalendar latex md odt)
 org-confirm-babel-evaluate nil
 org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-agenda-finalize-hook '(org-modern-agenda)
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-todo-keyword-faces '(("TODO" . "red") ("ONGOING" . "orange") ("WAIT" . 
"grey") ("DONE" . "blue")
  ("CANCELED" . "yellow"))
 

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

[Ihor Radchenko]

"Rick Lupton"  writes:

>>> +(defcustom org-id-link-use-context t
>> ...
>> 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.
>
> ?

I think that (b) makes sense. There is no reason to make the
customization yet more granular and complex when there is no clear need.
We can always do it later, if necessary, anyway.

>>> -  (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).

Agree.

>>> +  ;; 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'? 

No, it is generally not safe. For a different reason.

Let me illustrate with an example:

(defun yant/test2 ()
  (message "current-prefix-arg: %S" current-prefix-arg))

(defun yant/test (arg)
  (interactive "P")
  (yant/test2))

When you call M-x yant/test, you will see "current-prefix-arg: nil".
However, when you call C-u M-x yant/test, you will see
"current-prefix-arg: (4)".

Similar logic applies to the non-interactive calls to `org-store-link'.
If some Elisp code implements a command like

(defun yant/my-command (arg)
  (interactive "P")
  
  (org-store-link nil))

then, `org-store-link' may call `org-id-store-link-maybe' and
`org-id-store-link-maybe' will still "see" the top-level prefix argument
passed to `yant/my-command' - the prefix argument that has nothing at
all to do with prefix arguments of `org-store-link'.

Conclusion: It is unsafe to use `current-prefix-arg' value. We need to
pass this information some other way.

The way I proposed is actually not any special for ID links. What I
meant it to let-bind `org-link-context-for-files' around the whole call
to `org-store-link-functions', so that the custom :store functions will
get access to the adjusted value of `org-link-context-for-files'.
Does this explanation make more sense?

>>> +(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?

I just did not notice ID-LOCATION :facepalm:

>>> +(when option
>>> +  (org-link-search option))
>>>  (org-fold-show-context)))
>>
>> `org-link-search' does not always search from point. So, you may end up
>> matching, for example, a duplicate CUSTOM_ID above.
>> Moreover, regular expression match option will be broken -
>> `org-link-search' creates sparse tree in the whole buffer and will
>> disregard the ID part of the link. I suspect that you will need to make
>> dedicated modifications to `org-link-search' as well in order to
>> implement opening ID links with search option cleanly.
>
> Thanks, yes. It looks to me (from the code and some testing) that narrowing 
> to the target heading first before calling `org-link-search' does the right 
> thing. Was there a particular reason you thought `org-link-search' would need 
> to be changed?

Because a lot of the code (except some part `org-link-open') assumes
that `org-link-search' searches the whole buffer, not just the narrowed
part. But that's not your problem - I will update the docstring of
`org-link-search' to explicitly specify that it is searching within the
accessible portion of the buffer and update the callers to account for
this.

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

[Matt]

  On Thu, 14 Dec 2023 15:35:13 +0100  Ihor Radchenko  wrote --- 
 
 > 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.

Thank you for bringing this to my attention and thank you Nathaniel for your 
work on this.

I have no comments on the design presently (my knowledge of Emacs fontification 
is currently limited) and my current priorities prevent me from dedicating the 
time this topic deserves.

I think the topic is interesting and important.  I've had issues with ANSI 
escape codes (in particular progress bars) in source block results.  I made a 
note to return to this thread in case the escape codes don't bring me back :)

Nathaniel, if you and I happen to cross paths in one of Ihor's "office hours," 
I would enjoy learning more about what you're doing.

Re: [BUG] org-clock-auto-clockout does not actually use x11idle on X11 [9.6.8 (release_9.6.8-3-g21171d @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Vladimir Nikishkin  writes:
>>
>>> For some time I have been wondering why auto-clockout does not use
>>> x11idle on my machine.
>>> ...
>
> Attaching a tentative fix.
> It would help if someone can test it on other machine.

Applied, onto main.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=23291840b

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

Re: [BUG] Tangle with symbolic links don't work

[Ihor Radchenko]

Ihor Radchenko  writes:

> Subject: [PATCH] org-babel-tangle: Do note erase the existing tangle target
>  before overwriting

Applied.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fbcd71e85

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