Re: org-ctags-find-tag should not prompt inside org-open-at-point

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> When org-ctags-find-tag is a member of org-open-link-functions, fuzzy
>> links and custom-id links are broken. Instead of following those links,
>> Emacs prompts for a filename with "Visit tags table (default TAGS)".
>
> This is expected. As per org-ctags documentation:
>
> ;; By default, with org-ctags loaded, org will first try and visit the tag
> ;; with the same name as the link; then, if unsuccessful, ask the user if
> ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
> ;; the user wishes to append 'tag' as a new toplevel heading at the end of
> ;; the buffer; and finally, defer to org's default behavior which is to
> ;; search the entire text of the current buffer for 'tag'.
> ;;
> ;; This behavior can be modified by changing the value of
> ;; ORG-CTAGS-OPEN-LINK-FUNCTIONS.
>
>> I'm sure how org-ctags is getting required in my Emacs, but I think
>> (require 'org-ctags) probably shouldn't call org-ctags-enable.
>
> Check out
> https://list.orgmode.org/orgmode/87o7omg4ie@alphaville.usersys.redhat.com/

Thank you!! I'm glad to see such care taken in considering this issue!

> We generally agree that (require 'org-ctags) should ideally not have
> side effects, but do not want to introduce too breaking changes either.

Does this mean that org-ctag's disruptive behavior will be fixed?

Thanks!!

Joseph

Keeping org-id entries updated with buffer position changes

[Sebastian Wålinder]

Hello!

I often use org-id to create persistent links to headings like this:

* Foo
:PROPERTIES:
:ID:   BAR
:END:

[[BAR][Link]]

However, after inserting a line above foo, following the link BAR will take me 
to the wrong line, because the org-id database hasn't been updated with the 
headline's new position.

Running `org-id-update-id-locations` fixes this issue, but takes forever to run 
because it goes through all my org files.

How would I keep these links updated when I make frequent edits? Is there a 
function that updates the IDs in a single file only? If so, I could advice the 
open link function to run it first and update all the positions quickly before 
following the link.

Thoughts?

Thanks!

Named columns in org tables [9.7-pre (release_9.6.9-797-g4d0f89]

[Paul Stansell]

Hello,

On this page https://orgmode.org/manual/Advanced-features.html
it says
- '!' :: The fields in this line define names for the columns, so that
  you may refer to a column as '$Tot' instead of '$6'.

However, when I experimented with this I found that the first of the
following two tables works (i.e. the empty cells are filled in
correctly), but the second doesn't (the only difference is the
replacement of $4 with $c3 in the second table):

|---+++|
| ! | c1 | c2 | c3 |
| # |  1 |  2 ||
| # |  3 |  4 ||
|---+++|
#+TBLFM: $4 = $c1 + $c2

|---+++|
| ! | c1 | c2 | c3 |
| # |  1 |  2 ||
| # |  3 |  4 ||
|---+++|
#+TBLFM: $c3 = $c1 + $c2

Is this a bug?

Thanks,

Paul

===

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.37, cairo version 1.16.0)
 of 2023-03-16, modified by Debian
Package: Org mode version 9.7-pre (release_9.6.9-797-g4d0f89 @
~/.emacs.d/org-mode-git/lisp/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 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-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-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[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-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 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-speed-command-hook '(org-speed-command-activate
 org-babel-speed-command-activate)
 org-persist-directory "/tmp/org-persist-Cls3dG"
 org-fold-core-isearch-open-function 'org-fold--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-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
  ("id" :follow org-id-open)
  ("eww" :follow org-eww-open :store org-eww-store-link)
  ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
  ("mhe" :follow org-mhe-open :store org-mhe-store-link)
  ("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
  ("info" :follow org-info-open :export org-info-export
:store org-info-store-link :insert-description
org-info-description-as-command)
  ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
  ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
  ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
  ("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
  ("w3m" :store org-w3m-store-link)
  ("doi" :follow org-link-doi-open :export
org-link-doi-export)
  ("file+sys") ("file+emacs")
  ("shell" :follow org-link--open-shell)
  ("news" :follow
#[514 "\301\300\302 Q \"\207"
 ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("mailto" :follow
#[514 "\301\300\302 Q \"\207"
 ["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("https" :follow
#[514 "\301\300\302 Q \"\207"
 ["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("http" :follow
#[514 "\301\300\302 Q \"\207"
 ["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("ftp" :follow
#[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"]
 6 "\n\n(fn URL ARG)"]
)
  ("help" :follow org-link--open-help :store
org-link--store-help)
  ("file" :complete org-link-complete-file)
  ("elisp" :follow org-link--open-elisp))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 )

Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword

[Juan Manuel Macías]

Max Nikulin writes:

> I just have checked that a dirty hack with a few lines of code for
> `org-export-filter-final-output-functions' allows to insert arbitrary
> text to the beginning of export result. Perhaps a more elegant solution
> exists, but I admit it is not a straightforward way. At least it is
> possible.

And it is also possible by simply defining a new class (in Org
terminology, not LaTeX). My usual class is an almost empty one, without
documentclass and without packages, because I don't want org to write
the preamble for me. But I think this is not the point.

> I do not mind that generation of preamble should be more flexible, but I
> consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
> a better variant. That is why I asked for details concerning particular
> use cases.

IMHO, LaTeX_pre_header is obvious and transparent to the user: a version
of LaTeX_header that behaves exactly the same, except that it exports
the lines before \documentclass. It is simple and requires little code
to implement, and it is used for all cases of code before the
declaration of the class, since its syntax is consistent with
LaTeX_header. And its use does not require further explanation. You can
even play with constructions like:

#+NAME: pre
#+begin_src latex :exports none
(some stuff)
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_pre_header: <>
#+end_src

> I remember recipes like "put \usepackage{cmap} immediately after
> \documentclass" (nowadays this particular one should not be necessary).
> So I would prefer to avoid keywords per each chunk of preamble code.

I think that this would not be the case. This is not just any part of
the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
would take care of what is after \documenclass (the axis of a LaTeX
document); LaTeX_pre_header would do it of anything that may have come
before. And both provide a less constricted preamble for advanced use of
LaTeX. Frankly, I can't think of a simpler solution.

> \begin{filecontents*} from the original post is not convincing.

Are you not convinced by some instructions that are included in the
official documentation of a LaTeX package (pdfx)?

https://i.imgur.com/NdLWmwc.png

The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

[BUG] Warning (org-element-cache): org-element--cache: Warning(Checkliste-Updates.txt): Org parser error in Checkliste-Updates.txt [9.7-pre (release_9.6.9-790-ge42b7a @ /home/grfz/src/org-mode/lisp/)]

[Gregor Zattler]

Dear org mode maintainers, developers, Ihor, I caught the
following warning/backtrace while calling
'my/org-goto-agenda-heading´ which in turn is just
"(org-refile '(4))".

HTH/Ciao; Gregor 

 ■  Warning (org-element-cache): org-element--cache: 
Warning(Checkliste-Updates.txt): Org parser error in 
Checkliste-Updates.txt::94. Resetting.
 The error was: (wrong-type-argument integer-or-marker-p nil)
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
Backtrace:
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(comment (:standard-properties [1189 1189 nil nil 1251 0 nil 
nil element t nil nil nil nil # nil nil (section 
(:standard-properties [39 39 39 1251 1251 0 nil section element t nil 39 1251 
nil # nil nil ...]))] :value \"Local Variables:
mode: Org
indent-tabs-mode: nil
End:\"))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(paragraph (:standard-properties [1187 1187 1187 1189 1189 0 
nil nil element t nil nil nil nil # nil nil 
(section (:standard-properties [39 39 39 1251 1251 0 nil section element t nil 
39 1251 nil # nil nil ...]))]))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(paragraph (:standard-properties [920 920 920 1186 1187 1 nil 
nil element t nil nil nil nil # nil nil (section 
(:standard-properties [39 39 39 1251 1251 0 nil section element t nil 39 1251 
nil # nil nil ...]))]))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(plain-list (:standard-properties [39 39 39 917 920 3 nil 
planning element t nil nil nil nil # nil ((39 0 
\"1. \" nil nil nil 917) (64 3 \"* \" nil nil nil 917) (154 5 \"- \" nil nil 
nil 180) (180 5 \"- \" nil nil nil 263) (263 5 \"- \" nil nil nil 917) (357 7 
\"+ \" nil nil nil 711) (397 9 \"- \" nil nil nil 567) (567 9 \"- \" nil nil 
nil 607) (607 9 \"- \" nil nil nil 711) (711 7 \"+ \" nil nil nil 917) (751 9 
\"- \" nil nil nil 917) (852 11 \"+ \" nil nil nil 917)) (section 
(:standard-properties [39 39 39 1251 1251 0 nil section element t nil 39 1251 
nil # nil nil ...]))] :type ordered))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(section (:standard-properties [39 39 39 1251 1251 0 nil 
section element t nil 39 1251 nil # nil nil 
(headline (:standard-properties [1 1 39 1251 1251 0 ... nil nil t ... 41 1249 1 
# nil nil ...] :pre-blank 1 :raw-value 
[org-element-deferred org-element--headline-raw-value ... nil] :title 
[org-element-deferred org-element-property-2 ... nil] :level 1 :priority nil 
:tags nil :todo-keyword nil :todo-type nil :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil))]))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(headline (:standard-properties [1 1 39 1251 1251 0 (:title) 
nil nil t (143 . 1) 41 1249 1 # nil nil 
(org-data (:standard-properties [1 1 1 1251 1251 0 nil org-data nil t nil 3 
1251 nil # nil nil nil] :path 
\"/ssh:root@fs2:/data///WWW_DD_E/Dokumentation 
/How-to-restore-from-proxmox-backup.txt\" :CATEGORY 
\"How-to-restore-from-proxmox-backup\"))] :pre-blank 1 :raw-value 
[org-element-deferred org-element--headline-raw-value (2 36) nil] :title 
[org-element-deferred org-element-property-2 (:raw-value) nil] :level 1 
:priority nil :tags nil :todo-keyword nil :todo-type nil :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(org-data (:standard-properties [1 1 1 1251 1251 0 nil 
org-data nil t nil 3 1251 nil # nil nil nil] 
:path 
\"/ssh:root@fs2:/data///WWW_DD_E/Dokumentation/How-to-restore-from-proxmox-backup.txt\"
 :CATEGORY \"How-to-restore-from-proxmox-backup\"))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Loading persistent 
cache for 
/ssh:root@fs2:/data///WWW_DD_E/Dokumentation/Checkliste-Updates.txt





Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2023-09-19
Package: Org mode version 9.7-pre (release_9.6.9-790-ge42b7a @ 
/home//src/org-mode/lisp/)

current state:
==
(setq
 org-list-use-circular-motion t
 org-link-email-description-format "%c: %.80s"
 org-log-note-headings '((done . "CLOSING NOTE %t") (state . "State %-12s from 
%-12S %t")
 (note . "Note taken on %t")
 (reschedule . "Rescheduled from %S on %t")
 (delschedule . "Not scheduled, was %S on %t")
 (redeadline . "New deadline fr

[PATCH] update urls in ob-doc-maxima.org

[Leo Butler]

Hello,

The current project urls in ob-doc-maxima.org are out-of-date (the .net
urls redirect to the new .io ones). The project image file has moved and
no longer loads. This patch corrects those problems.

Best,
Leo

From dceb35854fcda3e467c3b1bd8f7f343434f7fb2f Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 26 Sep 2023 11:04:45 -0500
Subject: [PATCH] * org-contrib/babel/languages/ob-doc-maxima.org: correct urls

The old .net urls have been replaced by .io urls.  These pages are
served over https.

The location of the project banner has moved, so that is updated, too.
---
 org-contrib/babel/languages/ob-doc-maxima.org | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-maxima.org b/org-contrib/babel/languages/ob-doc-maxima.org
index a6b403dc..50438b3a 100644
--- a/org-contrib/babel/languages/ob-doc-maxima.org
+++ b/org-contrib/babel/languages/ob-doc-maxima.org
@@ -14,11 +14,12 @@
 #+begin_export html
   
   
-  Org Mode support for http://maxima.sourceforge.net/";>Maxima
+  Org Mode support for https://maxima.sourceforge.io/";>Maxima
   
   
-  http://maxima.sourceforge.net/";>
-  http://maxima.sourceforge.net/i/logo.png"/>
+  https://maxima.sourceforge.io/";>
+  https://maxima.sourceforge.io/img/maxima.svg"/>
+  https://maxima.sourceforge.io/img/maxima-banner.png"/>
   
   
   
@@ -73,7 +74,6 @@ You must activate Maxima by adding a line to
  '((maxima . t))) ; this line activates maxima
 #+END_SRC
 
-
 * Org Mode Features for Maxima Source Code Blocks
 ** Header Arguments
 There are no Maxima-specific default header argument values.
-- 
2.40.1

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Max Nikulin]

On 25/09/2023 20:14, Visuwesh wrote:

+  (setq-local dnd-protocol-alist
+  (cons '("^file:///" . org--dnd-local-file-handler)
+dnd-protocol-alist))


Does it mean that `org--dnd-local-file-handler' is unconditionally 
called for Org buffers? Current action is to open text files in the 
widow under cursor and it is what users may expect. They may be 
surprised if the file is attached instead.


Some applications may highlight some area and display a hint describing 
effect of drop. Unsure if it is possible in Emacs.


I have tried to drop files from Dolphin KDE file manager onto an 
Emacs-28 frame. ACTION is always 'private. In some application 
Shift/Ctrl pressed during drop means move/copy. Mouse cursor changes 
accordingly. Is it possible to achieve the same effect in Emacs?

Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword

[Max Nikulin]

On 26/09/2023 04:57, Thomas S. Dye wrote:

Aloha all,

Juan Manuel Macías  writes:



If so, Org should have native support of \DocumentMetadata, not
LATEX_PRE_HEADER or something similar.


If it were the only case of code before \documentclass, I would agree.
But, as I have already said above, the diversity of use cases makes the
implementation of /ad hoc/ solutions unviable, in my opinion.


FWIW, I agree with Juan Manuel here and would welcome a straightforward 
way to insert material before the header.


I just have checked that a dirty hack with a few lines of code for 
`org-export-filter-final-output-functions' allows to insert arbitrary 
text to the beginning of export result. Perhaps a more elegant solution 
exists, but I admit it is not a straightforward way. At least it is 
possible.


I do not mind that generation of preamble should be more flexible, but I 
consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find 
a better variant. That is why I asked for details concerning particular 
use cases.


I remember recipes like "put \usepackage{cmap} immediately after 
\documentclass" (nowadays this particular one should not be necessary). 
So I would prefer to avoid keywords per each chunk of preamble code.


\begin{filecontents*} from the original post is not convincing. 
\DocumentMetadata perhaps should be supported out of the box.


I would consider some kind of templates that use predefined fragments

#+LATEX_REPLACE_TEMPLATE: :preamble mypreamble
#+name: mypreamble
#+begin_src latex :exports none :noweb yes
\providecommand{\pdfxopts}{x-1a}
<>
#+end_src

with ability to use fine grain snippets instead

#+LATEX_REPLACE_TEMPLATE: :preamble detailedpreamble
#+name: detailedpreamble
#+begin_src latex :exports none :noweb yes
<>
\PassOptionsToPackage...
<>
\usepackage{cmap}
\usepackage[english,<>]{babel}
<>
#+end_src


I hope, something similar may be made more readable than series of 
LATEX_HEADER & Co lines.

Re: [PATCH] org-list.el: Reduce scope to subtree

[J. G.]

 Good catch, thanks for the feedback.
The original problem I was attempting to correct was when making use of 
org-contrib's org-checklist.el feature to reset checkboxes with the 
RESET_CHECK_BOXES property. The earliest report of this bug I'm aware of is 
here: https://github.com/doomemacs/doomemacs/issues/1503
When the relevant headline has that property set, is recurring, and is marked 
as done, the headline and its subtrees (without my patch as I've now learned) 
have their checkboxes and counter cookies correctly reset. However, top level 
headlines elsewhere have their counter cookies incorrectly reset to [0/0].
I have attached an example org file which contains a subheading "The heading to 
mark done to reproduce the problem" that when set to done will demonstrate this 
problem. I see the top level headings "Test heading 2" and "Test heading 3" 
have their counter cookies set to [0/0] which is not the desired behavior.
On Tuesday, September 26, 2023 at 02:33:52 AM PDT, Ihor Radchenko 
 wrote:  
 
 "J. G."  writes:

> Hi, this patch reduces the scope of the function 
> org-reset-checkbox-state-subtree to just the subtree per its name and 
> documentation.
> ...
> -    (org-update-checkbox-count-maybe 'all)
> +    (org-update-checkbox-count-maybe)

Thanks for the patch, but without 'all argument,
`org-update-checkbox-count-may' will limit the scope to current
_heading_, not subtree.

May you please describe in more details the problem you experience?
Ideally with a reproducer. See https://orgmode.org/manual/Feedback.html#Feedback

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 
  * My top level heading to hold [1/3]
** TODO Another test heading
** DONE Yet another test heading
CLOSED: [2023-09-26 Tue 07:30]
** TODO The heading to mark done to reproduce the problem [3/3]
SCHEDULED: <2023-09-24 Sun ++1w>
:PROPERTIES:
:RESET_CHECK_BOXES: t
:END:
- [X] An extra box
- [X] Another extra box
- [X] Final extra box
*** DONE My first set [5/5]
CLOSED: [2023-09-26 Tue 07:06]
- [X] My stuff
- [X] More stuff
- [X] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
*** DONE My second set [5/5]
CLOSED: [2023-09-26 Tue 07:06]
- [X] My stuff
- [X] More stuff
- [X] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
*** DONE My third set [5/5]
CLOSED: [2023-09-26 Tue 06:49]
- [X] My stuff
- [X] More stuff
- [X] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
* Test heading 2 [1/3]
:PROPERTIES:
:RESET_CHECK_BOXES: t
:END:
** TODO My first set 2 [3/5]
- [ ] My stuff
- [X] More stuff
- [ ] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
** TODO My second set 2 [3/5]
- [X] My stuff
- [X] More stuff
- [ ] Even more stuff
- [X] Lots of stuff
- [ ] Final stuff
** DONE My third set 2 [5/5]
CLOSED: [2023-09-26 Tue 06:49]
- [X] My stuff
- [X] More stuff
- [X] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
* Test heading 3 [2/3]
:PROPERTIES:
:RESET_CHECK_BOXES: t
:END:
** TODO My first set 2 [4/5]
- [X] My stuff
- [X] More stuff
- [ ] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
** DONE My second set 2 [5/5]
CLOSED: [2023-09-26 Tue 07:10]
- [X] My stuff
- [X] More stuff
- [X] Even more stuff
- [X] Lots of stuff
- [X] Final stuff
** DONE My third set 2 [5/5]
CLOSED: [2023-09-26 Tue 06:49]
- [X] My stuff
- [X] More stuff
- [X] Even more stuff
- [X] Lots of stuff
- [X] Final stuff

[PATCH] Fix org-[beginning|end]-of-line with arguments

[倉成智久]

Hello,

I have created a patch to fix an issue concerning the
org-beginning-of-line and org-end-of-line functions with arguments.

In the current implementation, org-special-ctrl-a/e may not operate as expected.
For example, executing (org-beginning-of-line 2) relocates the cursor
to the start of the line, rather than after the heading symbols even
if org-special-ctrl-a/e is t.
(Movements to prior lines, such as (org-beginning-of-line 0), function
correctly.)

This is my first patch submission. If there are any shortcomings or
additional requirements needed, please do not hesitate to inform me. I
am open to feedback and willing to make any necessary adjustments.

Best,

Tomohisa Kuranari


0001-lisp-org.el-Fix-the-issue-with-argumented-function-c.patch
Description: Binary data

Re: [FR] Make notion of "modification time" configurable during publishing

[Ihor Radchenko]

Suhail Singh  writes:

> Ihor Radchenko writes:
>
>> But do you actually use one but not other in practice?
>
> As in, could users have a preference for one vs the other in practice?
> Yes, since the choice isn't without consequence, it's conceivable
> (generally speaking) that some would prefer one over the other. FWIW, in
> my specific case, I use CommitDate, but I am not convinced it's "the
> right thing" in all situations.
>
> Not having conducted a survey, I also cannot comment on the frequency
> with which users have a desired preference for one vs the other. I am
> also not aware of general rules where users would necessarily prefer one
> over the other, but it's possible they may exist. My point was to simply
> point out that there is more than one interpretation of
> "vc-modification-time".

I see your point. Although, from the point of view of Org development,
we do not want to add features nobody practically use. Such features add
burden upon maintainers and do not practically benefit users. So, I am
inclined to reuse the existing approach and only add more granularity if
users ask for it.

>> It will only work for files without includes and force us to use
>> exactly the same hash algorithm.
>
> I don't follow. I was stating that the concept of a "file hash" could be
> obtained in more than way. I.e., in addition to it being calculated "by
> hand" it would also be possible to query an oracle (the VCS in this
> case) for it. This is distinct and orthogonal from the decision of how a
> "file with includes" is handled.

Sure. But the way "file hash" is calculated should be consistent. The
way Emacs calculates hash is different from git. So, supporting Emacs
and git ways means more code (not a good thing unless necessary). We
should thus prefer Emacs API to calculate hash.

> If I understand you correctly, the logic you have in mind, would be
> something like this:
>
> - during publish, compare the file hash of the file being published as
>   well as all included files
> - if the values for all are the same as in the cache, don't publish (if
>   user has signalled such intent via the equivalent of
>   org-publish-use-timestamps-flag)
> - if the value of any one is different, re-publish and update cache with
>   the updated file hashes
>
> It doesn't matter how the specific file hash is obtained, as long as the
> mechanism is being used consistently and the file hash of the included
> files are also being consulted in an appropriate way.

Yup, you are correct.

Now, to practice - let's start from updating ox-publish to use text hash
to decide about re-publishing. I will put it into my todo list, but
patches are more than welcome (my todo list is rather long). The
function to start looking into is `org-publish-cache-file-needs-publishing'.

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

Re: Case insensitivity of simple [[links]]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> [...]
>
> So, if I understand correctly, there is no way to make "[[link]]" find
> "* Link" while editing, after exporting, and on any Emacs, that is
> 'emacs -Q'.  In other words, writing "* link" in lowercase, which is my
> workaround, is "the solution".  Do I have that right?

You might as well use [[Link]].

As for case sensitivity, it is something we might discuss. I just
outlined the current state of the Org code.

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

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin  writes:

> I am afraid, there is no variant that fits for all cases even in a 
> particular document.

Still, it would be nice to have _a_ variant compared to the current
state of affairs.

As for extra customization, it totally depends on the interest in this
functionality. If not many people are interested, I'd put one variant in
Org and left non-standard export to the users to customize via :export
link property.

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

Re: Fallback fonts in LaTeX export for non latin scripts

[Ihor Radchenko]

Juan Manuel Macías  writes:

>>> [...] any suggestion for improvement is very welcome [...]
>>
>> This is a bit too out of context. Improvement of what?
>
> I think it is related to the previous paragraph: "I am very interested
> in all possible improvements in babel so that it integrates as best as
> possible with automatically generated files[...]"

That's good to hear. In practical terms, if Javier gives us some contact
email, we may CC him when we think that what we discuss is related to
Babel.

>> We can also provide multiple language name variants though I don't see a
>> need to bother unless we get user requests to do such thing.
>
> I agree. I even think it would be a good point to also include the
> vernacular name of each language.

Sounds reasonable. Although, let's come back to this when we have actual
code to discuss.

> By the way, Javier has also told me that he is going to consider the
> 'onchar=ids fonts' issue related to the case of several languages that
> use the same script (already discussed here in past messages).

That would be nice, although determining language may not be trivial.
AFAIK, automatic language detection often relies upon word frequencies
(for example, see https://pypi.org/project/langdetect/) and cannot be
reliable for very short text fragments. In the case of texts combining
multiple languages arbitrarily, the problem becomes even more difficult.
In some cases (dialects), multiple languages can be valid for the same
text fragment.

That said, frequency-based approach can mostly work well, except certain
edge cases. But it requires word corpus. I am not sure how feasible it
would be to include into TeX distribution. (Maybe not very hard - it is
already quite large and a few dictionary files will not change much).

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

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Ihor Radchenko]

Visuwesh  writes:

>> Please, use `make-temp-file' to create files in the temporary
>> directory that may be world writable. Predictable file names there are
>> undesired from security point of view.
>
> What harm does it cause?

/tmp directory can be written by any program and the file, while kept
there, might be modified by malicious code.

Not that I know a concrete example what harm can be done in this
particular case, but it is generally a good practice to make file names
in /tmp random.

>> At first, I expected more common with the following project
>> https://github.com/abo-abo/org-download/
>> however even the approach to fetch images from clipboard is different.
>
> I have never used that package, this is what I wrote in a discussion
> with Ihor in the Matrix room which we iteratively improved.  It was
> mostly written with my workflow in mind.  Without knowledge of how
> others work, I cannot improve the implementation.  I also don't
> understand what the linked package from the Commentary section (which is
> why I never used it).

The package does similar things, except that it focuses on downloading
images from URL stored in clipboard or by making a screenshot. Dnd is
also supported there, but just for a single URL/file path.

Max, unless you see something particular that is implemented better in
org-download, let's just ignore that library. I eyeballed the code and I
do not see anything that we need to account for, except some more
specialized features (like attaching screenshots), which we can always
add in future, if necessary.

>> I am in doubts if the following code is more suitable for org.el or
>> for org-attach.el
>
> I have the same doubts.

The patch implements dnd and media handlers, which constitute Org mode
integration with the rest of Emacs. So, they are a part of major mode
definition. If we want to keep things clean, we may create org-dnd.el
and org-yank-media.el and put the relevant functions there, only leaving
the major mode setup in org.el

I do not think that org-attach is the right place for this new
functionality.

>> Could it be extended to any mime type? If so I would avoid "image" in
>> its name. `org-yank-media-save-dir'?
>
> It should be easy enough to do it but do we want to go there?

Isn't the patch handling non-images as well?
AFAIU, the only case when images are considered separately is when image
data is in clipboard.
In theory, we might handle, for example, html markup in clipboard
specially, but I am not sure if that's what people expect.

>>> +  "Method to save images yanked from clipboard and dropped to Emacs.
>>> +It can be the symbol `attach' to add it as an attachment, or a
>>> +directory name to copy/cut the image to that directory."
>>> +  :group 'org
>>> +  :package-version '(Org . "9.7")
>>> +  :type '(choice (const :tag "Add it as attachment" attach)
>>> + (directory :tag "Save it in directory"))
>>> +  :safe (lambda (x) (or (stringp x) (eq x 'attach
>>
>> Unsure if every directory may be considered as safe (e.g. ~/.ssh/)
>
> Is there a reliable way to know which directory is "safe"?  If not, then
> let the users shoot themselves in the foot.

We can just say :safe nil (omit the keyword). Then, users will be
prompted and can decide which directories are truly safe for them.

>>> +(declare-function org-attach-attach "org-attach" (file &optional visit-dir 
>>> method))
>>> +
>>> +(defun org--image-yank-media-handler (mimetype data)
>>> +  "Save image DATA of mime-type MIMETYPE and insert link at point.
>>> +It is saved as per `org-media-image-save-type'.  The name for the
>>> +image is prompted and the extension is automatically added to the
>>> +end."
>>> +  (let* ((ext (symbol-name (mailcap-mime-type-to-extension mimetype)))
>>> + (iname (read-string "Insert filename for image: "))
>>
>> Unless 'attach is used, `read-file-name' would allow saving to
>> arbitrary directory with path completion.
>
> Sorry, I don't understand what you mean here.  I am not really familiar
> with attachment facilities of org-mode.

Imagine that user enters something like
"/tmp/non-existing-directory/image-file" as an answer to
"Insert filename for image: " prompt.

>> Is there a chance to request for link description? Unsure if
>> `org-insert-link' may be easily reused.
>
> This would include too many prompts and make the whole process annoying
> again.

+1. If users want to have a link description, they can easily follow the
prompt with C-c C-l to edit the inserted link.

>> I do not know if it can be easily implemented, but it may be useful to
>> control attachment/generic directory at the moment when a particular
>> image is yanked/dropped instead of purely relying on predefined user
>> option.
>
> Sorry, I don't understand what you mean here.  Note that my usage of
> attachments is sparse.  "Particular image" is hard to determine since
> the only reliable data at hand is its mimetype.

He meant that users might want to alternate between sa

Re: org-ctags-find-tag should not prompt inside org-open-at-point

[Ihor Radchenko]

Joseph Turner  writes:

> When org-ctags-find-tag is a member of org-open-link-functions, fuzzy
> links and custom-id links are broken. Instead of following those links,
> Emacs prompts for a filename with "Visit tags table (default TAGS)".

This is expected. As per org-ctags documentation:

;; By default, with org-ctags loaded, org will first try and visit the tag
;; with the same name as the link; then, if unsuccessful, ask the user if
;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
;; the user wishes to append 'tag' as a new toplevel heading at the end of
;; the buffer; and finally, defer to org's default behavior which is to
;; search the entire text of the current buffer for 'tag'.
;;
;; This behavior can be modified by changing the value of
;; ORG-CTAGS-OPEN-LINK-FUNCTIONS.

> I'm sure how org-ctags is getting required in my Emacs, but I think
> (require 'org-ctags) probably shouldn't call org-ctags-enable.

Check out
https://list.orgmode.org/orgmode/87o7omg4ie@alphaville.usersys.redhat.com/

We generally agree that (require 'org-ctags) should ideally not have
side effects, but do not want to introduce too breaking changes either.

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

Re: [PATCH] org-list.el: Reduce scope to subtree

[Ihor Radchenko]

"J. G."  writes:

> Hi, this patch reduces the scope of the function 
> org-reset-checkbox-state-subtree to just the subtree per its name and 
> documentation.
> ...
> - (org-update-checkbox-count-maybe 'all)
> + (org-update-checkbox-count-maybe)

Thanks for the patch, but without 'all argument,
`org-update-checkbox-count-may' will limit the scope to current
_heading_, not subtree.

May you please describe in more details the problem you experience?
Ideally with a reproducer. See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: [BUG] Previewing equations [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Peter Prevos  writes:

>  ■  Warning (org-element-cache): org-element--cache: Org parser 
>  error in Infonomics II: Business Information Management and 
>  Measurement::6190. Resetting.
>  The error was: (error "Invalid search bound (wrong side of 
>  point)")

Thanks for reporting!
Does the error disappear if you upgrade to Org 9.6.9?

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