[BUG] org-insert-link should use DEFAULT in read-string when asking for description

[Visuwesh]

Currently, when asking the user for the description of link,
`org-insert-link' calls `read-string' with a non-nil INITIAL-INPUT but
this argument is discouraged and deprecated; moreover, it is unfriendly.

`org-insert-link' should, ideally, use the DEFAULT argument.  If the
user decides that the suggested description is okay, they can type M-n.

Regards

Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.16.0, Xaw scroll bars)
Package: Org mode version 9.5.2 (release_9.5.2-9-g7ba24c @ 
/nix/store/0m0yw7b3zly74ljs3qmkblb780xg03id-emacs-git-20220130.0/share/emacs/29.0.50/lisp/org/)

Re: [BUG] org-insert-link should use DEFAULT in read-string when asking for description

[Visuwesh]

[சனி, பிப்ரவரி 26 2022] Max Nikulin wrote:

> On 25/02/2022 21:19, Visuwesh wrote:
>> Currently, when asking the user for the description of link,
>> `org-insert-link' calls `read-string' with a non-nil INITIAL-INPUT but
>> this argument is discouraged and deprecated; moreover, it is unfriendly.
>> `org-insert-link' should, ideally, use the DEFAULT argument.  If the
>> user decides that the suggested description is okay, they can type M-n.
>
> Due to lack of experience with emacs I can miss something. If so,
> please, correct me.
>
> Are you suggesting replacing
> (read-string "rs-initial: " "Some initial")
> by
> (read-string "rs-default: " nil nil "Some default")
> ?

Yes, exactly.

> Is it possible to override provided default description by empty
> string in the latter variant? Currently it is possible to erase
> description using just backspace or C-S-backspace.
>

I admit that I forgot about this but Emacs can be made to not translate
empty string to the default argument if you DTRT when calling
`read-from-minibuffer' (and `read-shell-command' does this).  If writing
a new function just to get this functionality is too much, then I guess
I can live with the current behaviour, but this inconsistency is an
annoyance since I end up with garbled link names, which I only notice
_afterwards_.

> P.S. Many GUI applications pre-select whole value when some input
> field is focused, so it is possible to overwrite current value by
> typing anything. It may be convenient but is not consistent with emacs
> behavior. Moreover it makes uncertain if visually selected text
> overwrites X PRIMARY selection.

I would rather not go there.  You seem to describe
`delete-selection-mode' which, IMO, is also a nuisance given how
mark+point is not the same as "regular selections" (even with
`transient-mark-mode' turned on).

Re: [BUG] org-insert-link should use DEFAULT in read-string when asking for description

[Visuwesh]

[ Please keep me in the CCs since I don't follow the list.  ]

[ஞாயிறு, பிப்ரவரி 27 2022] Max Nikulin wrote:

> On 26/02/2022 21:16, Visuwesh wrote:
>> [சனி, பிப்ரவரி 26 2022] Max Nikulin wrote:
>> 
>>> Are you suggesting replacing
>>>  (read-string "rs-initial: " "Some initial")
>>> by
>>>  (read-string "rs-default: " nil nil "Some default")
>>> ?
>> Yes, exactly.
>
> However you agreed that it would be regression since empty description
> use case would be impossible.
>

No.  It is impossible to do it using read-string, but it is possible to
do it by writing a function that calls read-from-minibuffer (and I gave
an example of a function that does this).

>> I admit that I forgot about this but Emacs can be made to not translate
>> empty string to the default argument if you DTRT when calling
>> `read-from-minibuffer' (and `read-shell-command' does this).  If writing
>> a new function just to get this functionality is too much, then I guess
>
> `read-shell-command' still has INITIAL argument and it is used by
> various callers (vc, grep). In addition, unlike for link description,
> I do not see any point in empty shell command (e.g. in vim :! allows
> to see output of previous shell command). So `read-shell-command' may
> behave quite differently.
>

Two things:

1. I dislike grep's behaviour.  However, I understand why grep
   behaves the way it does.  It makes far more sense to use the
   INITIAL argument in grep, but I don't see the same for
   org-insert-link.

   [ In grep, you rarely ever need to change the initial input.  ]

2. The reason why I cited read-shell-command does not have anything
   to do with the usefulness of empty string (or shell command).  I
   merely wanted to point out that you can have BOTH the DEFAULT
   argument (and no INITIAL), and can make the empty string a valid
   output from the function (i.e., without getting substituted by
   the DEFAULT argument).

I hope (2) makes sense.  I'm struggling to word it.

> Current way to ask for link description has the following properties:
> - Almost no action (just RET) if the user happy with suggested
>   description. Default description is provided with hope that it is
>   the most convenient option.
> - It is possible to erase everything and to get a link with no description.
> - The user is free to replace default description with arbitrary
>   alternative text.
>
> It is unclear for me how to tame `read-from-minibuffer' to get equally
> convenient behavior using DEFAULT argument instead of formally
> deprecated INITIAL one.
>

Please read the docstring of read-from-minibuffer.  You would be better
served by reading it than me replicating it here.  And I gave
read-shell-command as an example so others could study the function.

In essence, you can get the old behaviour (1) but you need to type M-n
beforehand.  Its one more key but it is far better than the current
behaviour since it is consistent with rest of the Emacs ecosystem (see
below also).

>> I can live with the current behaviour, but this inconsistency is an
>> annoyance since I end up with garbled link names, which I only notice
>> _afterwards_.
>
> Sorry, but I have not figured out what particular problem you met.

Inconsistency is the problem.  org-insert-link breaks my muscle memory.
I am not sure if you use the default completion system, but if you do,
org-insert-link sticks out by being intrusive.

With every command I use, when I know that the DEFAULT argument will be
of no use, I simply start typing.  However, with org-insert-link I have
to clear the input _first_ then start typing.  This never happens
elsewhere, even in grep (which you cite as an example)!

[BUG] org-agenda-remove-restriction-lock does not remove file lock [9.5.2 (release_9.5.2-17-gea6b74 @ /nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0/share/emacs/29.0.50/lisp/org/)]

[Visuwesh]

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.


C-u C-c C-x < followed by C-c C-x > does not remove the file restriction
lock.  

`org-agenda-remove-restriction-lock' checks for non-nil value of
`org-agenda-restriction' but `org-agenda-set-restriction-lock' explicitly
sets it to nil when TYPE is 'file.  Setting `org-agenda-restriction' to
a dummy value like 'dummy gets the job done.

Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.16.0, Xaw scroll bars)
Package: Org mode version 9.5.2 (release_9.5.2-17-gea6b74 @ 
/nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0/share/emacs/29.0.50/lisp/org/)

FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

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.


Hard-newlines [1] are an excellent way to inform Emacs to stop refilling
lines.  In a way, this serves a similar purpose to org's \\ but with a
major difference being that hard-newlines are not saved to file.  There
are several cases where this is the desired behaviour:
1. When you want to end a line with a link and continue text in the
   next line.  You don't care about the export since it will be
   taken care of properly.
2. When reflowing text with inline latex in them.  You adjust the
   line width so that it looks like 80 columns are present in a
   single line.  With hard-newlines, this becomes a very easy job
   without with you have to isolate the line of interest into a
   separate paragraph, then do the manual reflow, rinse and repeat.
3. When writing a list, you give a short description at the top.
   Then continue writing down below like this without the need to
   insert a empty line after the first line.

My point is that there are several instances where you need a solution
that is less aggressive than \\ and hard-newlines hit that sweet spot
perfectly.
I currently don't have a git checkout of org-mode handy so cannot
produce a patch wrt master branch but changing
`fill-region-as-paragraph' to `fill-region' does the job, as in

diff --git a/lisp/org/org.el b/lisp/org/org.el
index 6f92cdeab5..d53c8c0243 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -19580,7 +19580,7 @@ org-fill-element
  (org-element-context
 (push (point) cuts)))
 (dolist (c (delq end cuts))
-  (fill-region-as-paragraph c end justify)
+  (fill-region c end justify)
   (setq end c
 t)))
;; Contents of `comment-block' type elements should be

   
1. See C-h f use-hard-newlines RET

Emacs  : GNU Emacs 29.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.16.0, Xaw scroll bars)
 of 2022-09-17
Package: Org mode version 9.5.5 (release_9.5.5 @ 
/home/viz/lib/ports/emacs/lisp/org/)

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 20, 2022] Ihor Radchenko wrote:

>> 1. When you want to end a line with a link and continue text in the
>>next line.  You don't care about the export since it will be
>>taken care of properly.
>> 2. When reflowing text with inline latex in them.  You adjust the
>>line width so that it looks like 80 columns are present in a
>>single line.  With hard-newlines, this becomes a very easy job
>>without with you have to isolate the line of interest into a
>>separate paragraph, then do the manual reflow, rinse and repeat.
>
> This sounds as a reasonable use case. However, the Emacs definition of
> hard newlines also involves re-defining paragraph breaks. I do not think
> that it is a good idea for Org to alter Org paragraph syntax depending
> on `use-hard-newlines' - it will create too much confusion when Org
> documents are opened outside Emacs.

I do not think it is necessary for org to recognise hard-newlines as a
paragraph break either since, after all, the presence of hard-newlines
is ephemeral.

>> 3. When writing a list, you give a short description at the top.
>>Then continue writing down below like this without the need to
>>insert a empty line after the first line.
>
> Note that _not_ having an empty line after the first line can be
> misleading. In Org syntax, absence of line will merge description and
> the text below into a single paragraph. It will, for example, affect
> export.

I do get your point, but sometimes there are situations where merging
does not cause confusion and I would like to have the ability to write
lists like no. 3.  This is more true when you, like me, treat org-mode
as a major-mode which enhances plain text files.  If i was exporting,
then I wouldn't rely on org-mode handling hard-newlines (kind of like
how HTML behaves wrt requiring ).

>> My point is that there are several instances where you need a solution
>> that is less aggressive than \\ and hard-newlines hit that sweet spot
>> perfectly.
>
> All in all, I feel that fully respecting `use-hard-newlines' in Org is
> not a good idea. We can do it partially (for filling), but I am afraid
> that it may create some confusion.

I am not sure what you mean by confusion here: those who have
`use-hard-newlines' turned on are explicitly asking for it.  If
anything, I was confused when I found org-mode did not recognise
hard-newlines.

>> -   (fill-region-as-paragraph c end justify)
>> +   (fill-region c end justify)
>
> There are 3 calls to `fill-region-as-paragraph' inside
> `org-fill-element'. If we decide to support `use-hard-newlines'
> partially, all 3 calls should probably be replaced.

AFAICT, the rest two are comments (though I cannot tell the difference
between "comment" and "comment-block").  I replaced the one in paragraph
since that was where lack of hard-newlines support bit me.

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 20, 2022] Ihor Radchenko wrote:

>>> All in all, I feel that fully respecting `use-hard-newlines' in Org is
>>> not a good idea. We can do it partially (for filling), but I am afraid
>>> that it may create some confusion.
>>
>> I am not sure what you mean by confusion here: those who have
>> `use-hard-newlines' turned on are explicitly asking for it.  If
>> anything, I was confused when I found org-mode did not recognise
>> hard-newlines.
>
> Let me clarify.
>
> Current state of affairs is: Org ignores `use-hard-newlines'
> Proposed: Org sometimes ignores `use-hard-newline' and sometimes not.
>
> I do believe that what you suggest is a good idea (respecting
> `use-hard-newlines' when filling). However, I notice that some people
> may be more confused if we implement this FR compared to the existing
> situation. So, I am asking for feedback from other users instead of
> accepting the FR.

My point is that I don't see how this is confusing when the user who
turns on use-hard-newlines knows all its caveats, but like you say, lets
see what others say.

>> AFAICT, the rest two are comments (though I cannot tell the difference
>> between "comment" and "comment-block").  I replaced the one in paragraph
>> since that was where lack of hard-newlines support bit me.
>
> [...]
>
> I do not see why `use-hard-newline' should affect normal paragraphs but
> not comments.

I phrased my poorly.  I did not look at the calls of
fill-paragraph-as-region simply because the I hadn't tried to use
hard-newlines in comments.  I agree that we should support it comments
too.

[BUG] org-fold-core--fix-folded-region slows down typing [9.6.6 (release_9.6.6 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

In a largeish buffer, org-fold-core--fix-folded-region significantly
slows down typing to a point where I have to wait a few milliseconds to
see the characters typed.  With emacs -Q, the slow down isn't as bad as
with my full configuration but it is still noticeable.  Setting
`org-fold-core--ignore-modifications' to t makes the lag go away.

The large buffer that I type in has a PROPERTIES drawer for every
heading there is and I have 481 such headings.  There is one heading
with a couple of drawers that are hundred of lines long and might even
have long lines.  I can send this heading if you would like privately.
The buffer has the following STARTUP options set:

#+STARTUP: fold num

I have attached three files:

· org-fold-core-slow-profile: profiler report in the said large
  buffer with my Emacs configuration.
· org-fold-core-fast-profile: profiler report in a fresh new org
  buffer with only two lines, also recorded with my Emacs
  configuration.
· org-fold-core-emacs-Q-still-kinda-slow: profiler report in the
  said large buffer recorded in `emacs -Q'.

If this is not enough info, please tell me how to help.  Thank you.



org-fold-core-slow-profile
Description: Binary data


org-fold-core-fast-profile
Description: Binary data


org-fold-core-emacs-Q-still-kinda-slow
Description: Binary data


Emacs  : GNU Emacs 29.0.91 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw scroll 
bars)
 of 2023-06-01
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/home/viz/lib/ports/emacs/lisp/org/)

current state:
==
(setq
 org-agenda-prefix-format '((agenda . " %12:c %12t %s") (todo . " %i %-12:c") 
(tags . " %i %-12:c")
(search . " %i %-12:c"))
 org-attach-preferred-new-method 'dir
 org-link-elisp-confirm-function 'yes-or-no-p
 org-directory "/home/viz/doc/org"
 org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]
 org-pdftools-get-desc-function 'vz/org-pdftools-link-description
 org-agenda-todo-keyword-format "%s"
 org-agenda-scheduled-leaders '("Scheduled " "Sched. %2d ")
 org-startup-folded t
 org-agenda-skip-scheduled-if-done t
 org-agenda-files '("/home/viz/doc/org/calendar.org" 
"/home/viz/doc/org/habits.org"
"/home/viz/doc/uni/schedule.org" 
"/home/viz/doc/uni/epac.org")
 org-capture-templates '(("u" "University Schedule")
 ("ua" "Assignment" entry
  (file+headline "/home/viz/doc/uni/schedule.org" 
"Changes/Quizzes/Assignments")
  #'doct--fill-template :empty-lines-after 1 :prepend t 
:doct
  (:doct-name "Assignment" :keys "a" :headline 
"Changes/Quizzes/Assignments" :tag
   ":assignment:" :stat "DEADLINE: " :inherited-keys 
"ua" :after-finalize
   vz/update-calendar-markers-after-capture :file 
"/home/viz/doc/uni/schedule.org"
   :prepend t :empty-lines-after 1 :template
   "* TODO %?  %{tag}\n%{stat}%(call-interactively 
#'org-time-stamp)" :doct-custom
   (:tag ":assignment:" :stat "DEADLINE: "))
  )
 ("uq" "Quiz" entry
  (file+headline "/home/viz/doc/uni/schedule.org" 
"Changes/Quizzes/Assignments")
  #'doct--fill-template :empty-lines-after 1 :prepend t 
:doct
  (:doct-name "Quiz" :keys "q" :tag ":quiz:" :headline 
"Changes/Quizzes/Assignments" :stat
   "SCHEDULED: " :inherited-keys "uq" :after-finalize
   vz/update-calendar-markers-after-capture :file 
"/home/viz/doc/uni/schedule.org"
   :prepend t :empty-lines-after 1 :template
   "* TODO %?  %{tag}\n%{stat}%(call-interactively 
#'org-time-stamp)" :doct-custom
   (:tag ":quiz:" :stat "SCHEDULED: "))
  )
 ("uo" "Other" entry
  (file+headline "/home/viz/doc/uni/schedule.org" 
"Changes/Quizzes/Assignments")
  #'doct--fill-template :empty-lines-after 1 :prepend t 
:doct
  (:doct-name "Other" :keys "o" :headline 
"Changes/Quizzes/Assignments" :tag "" :stat
   "SCHEDULED: " :inherited-keys "uo" :after-finalize
   vz/update-calendar-markers-after-capture :file 
"/home/viz/doc/uni/schedule.org"
   :prepend t :empty-lines-after 1 :template
   "* TODO %?  %{tag}\n%{stat}%(call-interactively 
#'org-time-stamp)" :doct-custom
   (:tag "" :stat "SCHEDULED: "))
  )
 ("uh" "Homework" entry
  (file+headline "/home/viz/doc/uni/schedule.org" 
"Changes/Quizzes/Assignments")
  

Re: [BUG] org-fold-core--fix-folded-region slows down typing [9.6.6 (release_9.6.6 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[வெள்ளி ஜூன் 09, 2023] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> In a largeish buffer, org-fold-core--fix-folded-region significantly
>> slows down typing to a point where I have to wait a few milliseconds to
>> see the characters typed.  With emacs -Q, the slow down isn't as bad as
>> with my full configuration but it is still noticeable.  Setting
>> `org-fold-core--ignore-modifications' to t makes the lag go away.
>
> Well. This can happen when you have a huge number of text properties in
> your buffer. It is caused by details of how Emacs stores and searches
> text properties.
>
> You can try to set `org-fold-core-style' to overlays. Or you can try to
> disable flyspell. Or you can try to disable org-num that adds up to text
> properties.

What kind of disasters will I invite if I permanently set
`org-fold-core--ignore-modifications' to t?

> Canceled.
> Not much can be done on Org side.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[ஞாயிறு மார்ச் 12, 2023] Timothy wrote:

> Hi All,
>
> After months of work, Karthink and I have prepared a rather large patch-set
> completely overhauling the LaTeX preview system. I hope to have a patch set
> shortly, but in the mean time it would be good to get some more people testing
> this.
>
> To test this feature, please check out the `dev' branch of
>  (it’s the default branch). There 
> are
> also some other changes there currently, but I don’t think anything is broken.

I tested commit '6eb77305361a1f6a3f67c3229f837f1c4e95f546' of the dev
branch.

It worked well all around except for three things:

1. I had to set org-latex-preview-precompile to nil to produce the
   preview for ~2000 snippets.  I got errors in process filters such
   as arg-out-of-range, and Emacs completely blocked itself.  I can
   confirm that mylatexformat is installed

   % dpkg-query -S mylatexformat
   texlive-latex-extra: 
/usr/share/texlive/texmf-dist/tex/latex/mylatexformat
   texlive-latex-extra: 
/usr/share/texlive/texmf-dist/tex/latex/mylatexformat/mylatexformat.ltx

2. Apparently, org-latex-default-packages-alist no longer contain
   asmsymb and asmmath?  This change pulled the rug under me since
   it took me quite a while to figure out why some of my formulas
   were coloured red...

3. The image sizes of the same latex environment (e.g., \[ \]) is
   different for different formulas.  I can send a screenshot of
   this if required.

Except for these hiccups, it works without a hitch.  Thank you very much
for your work!

> If you do come across any issues, please let me know either in a reply here or
> the org-mode matrix room. If you could also run
>  and share 
> the
> diagnostic info, that would be quite helpful.

If needed, I can do this after reproducing (1).

BTW, would it possible to arrange other latex environments (\ch{} in my
case) to be previewed as well?  Currently, I do \(\ch{}\) but omitting
\( \) would be nice.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[திங்கள் ஆகஸ்ட் 21, 2023] Karthik Chikmagalur wrote:

>> It worked well all around except for three things:
>>
>> 1. I had to set org-latex-preview-precompile to nil to produce the
>>preview for ~2000 snippets.  I got errors in process filters such
>>as arg-out-of-range, and Emacs completely blocked itself.  I can
>>confirm that mylatexformat is installed
>
> 1. Are you using xelatex/lualatex?  

I have lualatex installed as part of another texlive package but I am
not sure if org uses it however.

> 2. If yes, precompilation should have turned itself off with a warning.
> 3. If no, do you mind sharing this file (or a stripped down version
> you're okay sharing that still has these issues) along with the LaTeX
> preamble?  That would be `org-latex-preview-preamble' and
> `org-latex-packages-alist'.  I would like to reproduce this bug.
>
> Previewing 2000 snippets is exactly where the new async/speedy system is
> expected to shine compared to the old one.
>
>> 2. Apparently, org-latex-default-packages-alist no longer contain
>>asmsymb and asmmath?  This change pulled the rug under me since
>>it took me quite a while to figure out why some of my formulas
>>were coloured red...
>
> `org-latex-default-packages-alist' was modified to omit amsmath and
> amssymb (among others) in preparation for a conditional export system
> where required packages will be determined automatically from the buffer
> text -- i.e. to avoid exactly the kind of headache you encountered.
> Unfortunately this export system is not part of the patch set yet.

Ah, OK.  I will add them in my config and call it a day.  ;-)

>> 3. The image sizes of the same latex environment (e.g., \[ \]) is
>>different for different formulas.  I can send a screenshot of
>>this if required.
>
> This is a recent regression.  Could you generate png previews by:
>
> 1. (setq org-latex-preview-default-process 'dvipng)
> 2. regenerating previews
>
> and checking if this still happens?  If these look fine, this is a
> dvisvgm issue and we will fix it soon.

No, AFAICT I don't see the issue with png previews.  However, all latex
previews, \( \) and \[ \], seem to be of the same size now.

>>> If you do come across any issues, please let me know either in a reply here 
>>> or
>>> the org-mode matrix room. If you could also run
>>>  and 
>>> share the
>>> diagnostic info, that would be quite helpful.
>>
>> If needed, I can do this after reproducing (1).
>>
>> BTW, would it possible to arrange other latex environments (\ch{} in my
>> case) to be previewed as well?  Currently, I do \(\ch{}\) but omitting
>> \( \) would be nice.
>
> Previewing unadorned LaTeX macros is officially unsupported but
> partially supported in practice.  If you move the cursor over the \ch{}
> and call `org-latex-preview' it should be previewed.  From that point it
> should behave like a regular LaTeX fragment.  Editing it should cause
> the preview to be auto-updated (If you are using
> org-latex-preview-auto-mode).

Is there no automagic way to do this?  Like changing a regexp variable
and hoping it would work till the end of time™.  (:

> Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[திங்கள் ஆகஸ்ட் 21, 2023] Karthik Chikmagalur wrote:

>> I have lualatex installed as part of another texlive package but I am
>> not sure if org uses it however.
>
> If you haven't changed `org-latex-compiler' (globally or in the Org
> buffer using a keyword), it's using pdflatex.

I am indeed using pdflatex.

>>> 3. If no, do you mind sharing this file (or a stripped down version
>>> you're okay sharing that still has these issues) along with the LaTeX
>>> preamble?  That would be `org-latex-preview-preamble' and
>>> `org-latex-packages-alist'.  I would like to reproduce this bug.
>
> Please let us know if you can reproduce the precompilation failure.
> This shouldn't be happening.

Hmm, I tried to reproduce it again but failed to do it.  Perhaps, being
a bit more patient is the key.  Sorry for the false alarm.  I will turn
on precompilation and report if/when I can reproduce the failure.

>> No, AFAICT I don't see the issue with png previews.  
>
> Sizing issues with pdflatex+svg previews should be fixed soon.
>
>> However, all latex previews, \( \) and \[ \], seem to be of the same
>> size now.
>
> Should they not be the same size?

After using the svg previews, I was under the impression that inline
maths environments would be at the same size as the rest of the text
whereas the other environments would be at a slightly higher size.

>>> Previewing unadorned LaTeX macros is officially unsupported but
>>> partially supported in practice.  If you move the cursor over the \ch{}
>>> and call `org-latex-preview' it should be previewed.  From that point it
>>> should behave like a regular LaTeX fragment.  Editing it should cause
>>> the preview to be auto-updated (If you are using
>>> org-latex-preview-auto-mode).
>>
>> Is there no automagic way to do this?  Like changing a regexp variable
>> and hoping it would work till the end of time™.  (:
>
> You can change `org-latex-preview--tentative-math-re' to suit your
> needs.  This variable is used to identify LaTeX fragments when calling
> `org-latex-preview'.  All subsequent checks involve the org-element api,
> but for reasons I can't recall at the moment the initial search is via a
> regexp.

Thanks, that seems to work!

> Karthik

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

[Visuwesh]

Attached patch adds yank-media and DND handler to attach files in the
clipboard and dropped onto an Emacs frame respectively.

The yank-media handler for images is well tested, I use it frequently
however, rest of the stuff aren't really tested since I don't use a GUI
file manager.  I tested enough to make sure the logic is right so I
don't know if they are ergonomic enough.  As noted in the comments,
files copied/cut to clipboard doesn't seem to have a solid spec and most
of the code was written with pcmanfm as the file manager, testing with
other file managers are highly welcome.

Better names for the newly added defcustoms are highly welcome since I
don't find them to be clear enough from their name.

The patch compiles cleanly without warnings but I haven't tested _this_
patch yet, I have these functions in my init.el and have tested those.

>From b6f1315cbdc331f2f54e1801b03272915d344cfd Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-media-image-save-type, org-dnd-default-attach-method): New
defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-local-file-handler): Add yank-media and DND handlers.

* etc/ORG-NEWS: Advertise the new features.
---
 etc/ORG-NEWS |  16 ++
 lisp/org.el  | 153 +--
 2 files changed, 164 insertions(+), 5 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9..f193c54 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,22 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluation, and then plotted afterwards.
 
+*** Images and files in clipboard can be attached
+
+Org can now attach images in clipboard and files copied/cut to the
+clipboard from file managers using the ~yank-media~ command which also
+inserts a link to the attached file.
+
+Images can be saved to a separate directory instead of being attached,
+customize ~org-media-image-save-type~.
+
+*** Files and images can be attached by dropping onto Emacs
+
+Attachment method other than ~org-attach-method~ for dropped files can
+be specified using ~org-dnd-default-attach-method~.
+
+Images dropped also respect the value of ~org-media-image-save-type~.
+
 ** New functions and changes in function arguments
 *** =TYPES= argument in ~org-element-lineage~ can now be a symbol
 
diff --git a/lisp/org.el b/lisp/org.el
index d0b2355..5c66f04 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4999,7 +4999,10 @@ The following commands are available:
   (org--set-faces-extend '(org-block-begin-line org-block-end-line)
  org-fontify-whole-block-delimiter-line)
   (org--set-faces-extend org-level-faces org-fontify-whole-heading-line)
-  (setq-local org-mode-loading nil))
+  (setq-local org-mode-loading nil)
+
+  ;; `yank-media' handler and DND support.
+  (org-setup-yank-dnd-handlers))
 
 ;; Update `customize-package-emacs-version-alist'
 (add-to-list 'customize-package-emacs-version-alist
@@ -15125,20 +15128,20 @@ INCREMENT-STEP divisor."
 	(setq hour (mod hour 24))
 	(setq pos-match-group 1
   new (format "-%02d:%02d" hour minute)))
-   
+
((org-pos-in-match-range pos 6) ;; POS on "dmwy" repeater char.
 	(setq pos-match-group 6
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 6 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 5) ;; POS on X in "Xd" repeater.
 	(setq pos-match-group 5
   ;; Never drop below X=1.
   new (format "%d" (max 1 (+ nincrements (string-to-number (match-string 5 ts-string)))
-   
+
((org-pos-in-match-range pos 9) ;; POS on "dmwy" repeater in warning interval.
 	(setq pos-match-group 9
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 9 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 8) ;; POS on X in "Xd" in warning interval.
 	(setq pos-match-group 8
   ;; Never drop below X=0.
@@ -20254,6 +20257,146 @@ it has a `diary' type."
 		(org-format-timestamp timestamp fmt t))
 	  (org-format-timestamp timestamp fmt (eq boundary 'end)))
 
+;;; Yank media handler and DND
+(defun org-setup-yank-dnd-handlers ()
+  "Setup the `yank-media' and DND handlers for buffer."
+  (setq-local dnd-protocol-alist
+  (cons '("^file:///" . org--dnd-local-file-handler)
+dnd-protocol-alist))
+  (yank-media-handler "image/.*" #'org--image-yank-media-handler)
+  ;; Looks like different DEs go f

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

[Visuwesh]

[வெள்ளி செப்டம்பர் 22, 2023] Max Nikulin wrote:

> On 22/09/2023 21:52, Visuwesh wrote:
>> Attached patch adds yank-media and DND handler to attach files in the
>> clipboard and dropped onto an Emacs frame respectively.
>
> Thank you for your work in this area.
>
> I am not an active DND user, I am just curious what cases are supported:
>
> - X11

Yes.

> - Wayland

I don't know nor am I willing to setup a test environment for it.

> - Sandboxed applications communicating with desktop environment
>   through XDG desktop portal (flatpack/snap/AppImage or just running
>  in bubblewrap)

Same as above.

> - Emacs running on a remote host (ssh + X11 forwarding)

If the DND links are of the form file://HOST/ then the current DND
handler won't run.  I don't have a way to test it myself so I can't
write a handler for remote files.  I am not sure if we can even reuse
the existing the org-attach code for remote files.

> - Windows

I don't have access to a Windows machine so can't test it unfortunately.

> When a file is dropped into an Org buffer I would consider inserting a
> link or storing it in addition to attachment options.

The current code already inserts a link to the dropped files.

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

[Visuwesh]

[சனி செப்டம்பர் 23, 2023] Ihor Radchenko wrote:

>> +*** Images and files in clipboard can be attached
>> +
>> +Org can now attach images in clipboard and files copied/cut to the
>> +clipboard from file managers using the ~yank-media~ command which also
>> +inserts a link to the attached file.
>> +
>> +Images can be saved to a separate directory instead of being attached,
>> +customize ~org-media-image-save-type~.
>
> This requires Emacs 29, which should be documented.

Yes, will do.

>>  ;; Update `customize-package-emacs-version-alist'
>>  (add-to-list 'customize-package-emacs-version-alist
>> @@ -15125,20 +15128,20 @@ INCREMENT-STEP divisor."
>>  (setq hour (mod hour 24))
>>  (setq pos-match-group 1
>>new (format "-%02d:%02d" hour minute)))
>> -   
>> +
>
> These whitespace changes are not relevant.

Sorry, I missed these sneaky changes when I made the commit.

>> +;;; Yank media handler and DND
>> +(defun org-setup-yank-dnd-handlers ()
>> +  "Setup the `yank-media' and DND handlers for buffer."
>> +  (setq-local dnd-protocol-alist
>> +  (cons '("^file:///" . org--dnd-local-file-handler)
>> +dnd-protocol-alist))
>> +  (yank-media-handler "image/.*" #'org--image-yank-media-handler)
>
> This function is not yet available in Emacs <29. Need to protect with 
> `fboundp'.

Of course.

>> +(defcustom org-media-image-save-type 'attach
>
> Maybe org-yank-image-save-type?

That is a better name but still doesn't inform the user that it is
respected by DND too.

>> +(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: "))
>
> It would be nice if we auto-generate the file name here by default. It
> is what I would expect from yanking an image at least.

Hmm, I think I prefer having a descriptive name for the file.  It would
aid in searching for the attachment later (in the org document, and
using find & friends).  We can add a user option but how should the name
be auto-generated? Timestamp?  I have no ideas in this regard.

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

[Visuwesh]

[சனி செப்டம்பர் 23, 2023] Visuwesh wrote:

>>> +(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: "))
>>
>> It would be nice if we auto-generate the file name here by default. It
>> is what I would expect from yanking an image at least.
>
> Hmm, I think I prefer having a descriptive name for the file.  It would
> aid in searching for the attachment later (in the org document, and
> using find & friends).  We can add a user option but how should the name
> be auto-generated? Timestamp?  I have no ideas in this regard.

Attached patch considers your review and also another defcustom to tell
how to generate the filename which by default autogenerates a filename
based on current time.

>From c9f149cde047a60b6c2a256d96616864f5f66352 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-type, org-dnd-default-attach-method)
(org-yank-image-file-name-function): New defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-local-file-handler): Add yank-media and DND handlers.

* etc/ORG-NEWS: Advertise the new features.
---
 etc/ORG-NEWS |  20 ++
 lisp/org.el  | 169 ++-
 2 files changed, 188 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..c4a58dd4d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,26 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluation, and then plotted afterwards.
 
+*** Images and files in clipboard can be attached
+
+Org can now attach images in clipboard and files copied/cut to the
+clipboard from file managers using the ~yank-media~ command which also
+inserts a link to the attached file.  This command was added in Emacs 29.
+
+Images can be saved to a separate directory instead of being attached,
+customize ~org-yank-image-save-type~.
+
+Image filename chosen can be customized by setting
+~org-yank-image-file-name-function~ which by default autogenerates a
+filename based on the current time.
+
+*** Files and images can be attached by dropping onto Emacs
+
+Attachment method other than ~org-attach-method~ for dropped files can
+be specified using ~org-dnd-default-attach-method~.
+
+Images dropped also respect the value of ~org-yank-image-save-type~.
+
 ** New functions and changes in function arguments
 *** =TYPES= argument in ~org-element-lineage~ can now be a symbol
 
diff --git a/lisp/org.el b/lisp/org.el
index d0b2355ea..d69f9ec70 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4999,7 +4999,10 @@ The following commands are available:
   (org--set-faces-extend '(org-block-begin-line org-block-end-line)
  org-fontify-whole-block-delimiter-line)
   (org--set-faces-extend org-level-faces org-fontify-whole-heading-line)
-  (setq-local org-mode-loading nil))
+  (setq-local org-mode-loading nil)
+
+  ;; `yank-media' handler and DND support.
+  (org-setup-yank-dnd-handlers))
 
 ;; Update `customize-package-emacs-version-alist'
 (add-to-list 'customize-package-emacs-version-alist
@@ -20254,6 +20257,170 @@ it has a `diary' type."
 		(org-format-timestamp timestamp fmt t))
 	  (org-format-timestamp timestamp fmt (eq boundary 'end)))
 
+;;; Yank media handler and DND
+(defun org-setup-yank-dnd-handlers ()
+  "Setup the `yank-media' and DND handlers for buffer."
+  (setq-local dnd-protocol-alist
+  (cons '("^file:///" . org--dnd-local-file-handler)
+dnd-protocol-alist))
+  (when (fboundp 'yank-media-handler)
+(yank-media-handler "image/.*" #'org--image-yank-media-handler)
+;; Looks like different DEs go for different handler names,
+;; https://larsee.com/blog/2019/05/clipboard-files/.
+(yank-media-handler "x/special-\\(?:gnome\|KDE\|mate\\)-files"
+#'org--copied-files-yank-media-handler)))
+
+(defcustom org-yank-image-save-type 'attach
+  "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."

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

[Visuwesh]

[ Please keep me in the CC as I don't follow the list.  ]

[ஞாயிறு செப்டம்பர் 24, 2023] Max Nikulin wrote:

> On 23/09/2023 17:28, Ihor Radchenko wrote:
>> Visuwesh writes:
>> 
>>> +  (let* ((ext (symbol-name (mailcap-mime-type-to-extension mimetype)))
>>> + (iname (read-string "Insert filename for image: "))
>> It would be nice if we auto-generate the file name here by
>> default. It
>> is what I would expect from yanking an image at least.
>
> Certainly it would be great to provide some default value allowing
> user to override it. However it may be not so trivial. Clipboard
> content may be just copy region from some graphics editor or a
> screenshot tool, so not associated with a file yet. In X11 xprop may
> be used to get clipboard owner application and its title. Wayland may
> be less permissive.
>
> I have tried to copy an image in Firefox. There is a chance to find
> file name (it may be image.php?id=1324 though) in text/html clipboard
> content, but it requires parsing of HTML
>
> xclip -selection clipboard -o -t text/html

I would rather not go down this rabbit hole since there is no way to
cover all the possible cases.

[ஞாயிறு செப்டம்பர் 24, 2023] Max Nikulin wrote:

> On 22/09/2023 21:52, Visuwesh wrote:
>> Attached patch adds yank-media and DND handler to attach files in the
>> clipboard and dropped onto an Emacs frame respectively.
>
> 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?

> Other notes are no more than opinion. I may easily miss something and
> verbose reply may be wasting of time. Do not hesitate to ask more
> details if you do not agree.
>
> 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).

>> +++ b/lisp/org.el
>
> I am in doubts if the following code is more suitable for org.el or
> for org-attach.el

I have the same doubts.

>> @@ -20254,6 +20257,146 @@ it has a `diary' type."
>>  (org-format-timestamp timestamp fmt t))
>>(org-format-timestamp timestamp fmt (eq boundary 'end)))
>>  +;;; Yank media handler and DND
>> +(defun org-setup-yank-dnd-handlers ()
>> +  "Setup the `yank-media' and DND handlers for buffer."
>> +  (setq-local dnd-protocol-alist
>> +  (cons '("^file:///" . org--dnd-local-file-handler)
>> +dnd-protocol-alist))
>> +  (yank-media-handler "image/.*" #'org--image-yank-media-handler)
>> +  ;; Looks like different DEs go for different handler names,
>> +  ;; https://larsee.com/blog/2019/05/clipboard-files/.
>> +  (yank-media-handler "x/special-\\(?:gnome\|KDE\|mate\\)-files"
>> +  #'org--copied-files-yank-media-handler))
>> +
>> +(defcustom org-media-image-save-type 'attach
>
> 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?

>> +  "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.

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

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 26, 2023] Ihor Radchenko wrote:

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

I don't see a way in org-attach-attach's mv method to change the
basename of the file post attachment so we have to live with this harm.

>>> 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 think it would be better to keep the registration part in org-mode's
definition in that case since if a user wants to override this
functionality, they can easily do so in org-mode-hook.

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

The patch handles non-images in the sense that they are simply attached
using cp/mv method when they are copy/cut to the clipboard from a file
manager.

But if your clipboard data contains video/mpeg for example, then the
patch does nothing.  yank-media would complain about no registered
handlers for video/mpeg.

BTW, before I forget again for the Nth time: there's an issue with how
yank-media works so cut files will not be handled properly unless
bug#65892 gets its clearance.  I hope the description in the linked bug
is clear enough.

>>>> +  "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.

That would be quite annoying IMO.  I say we let the user shoot
themselves in the foot.

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

How about the following prompt instead?

Basename for image file without extension:

Attached patch has several of the reviews considered.

>From a11658f82ce71850b52b853a4b44055b8f917486 Mon Sep 17 

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

[Visuwesh]

[செவ்வாய் செப்டம்பர் 26, 2023] Max Nikulin wrote:

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

The common request I see when a file is dropped is to associate it
somehow with the org-mode buffer.  org-attach is the most natural way to
do it.  If the users like the old behaviour, they can remove the entry
from the alist.

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

[Visuwesh]

[வெள்ளி செப்டம்பர் 29, 2023] Liu Hui wrote:

> Hi,
>
> 在 2023/9/27 16:29, Visuwesh 写道:
>
>> +*** Files and images can be attached by dropping onto Emacs
>> +
>> +Attachment method other than ~org-attach-method~ for dropped files can
>> +be specified using ~org-dnd-default-attach-method~.
>
>> +(defcustom org-dnd-default-attach-method nil
>> +  "Default attach method to use when DND action is unspecified.
>> +This attach method is used when the DND action is `private'.
>> +This is also used when `org-yank-image-save-type' is nil.
>> +When nil, use `org-attach-method'."
>
> I think the dnd feature should not be restricted to org-attach. I have
> often used it for opening file and inserting file link. How about
> supporting them and adding a new variable, such as
> org-dnd-default-method?

Thanks for your feedback.  Do you think asking during the time of drop
would be a viable option too?  I'm thinking of adding the defcustom
org-dnd-default-method with options such as

. attach -- as implemented here
. open -- open file
. file-link -- insert file links
. ask -- ask what to do after drop

I think the `ask' option would be nice to have too.  Perhaps, even as
the default?

>> +   ('ask (caddr (org-mks
>> + '(("c" "Copy" cp)
>> +   ("m" "Move" mv)
>> +   ("l" "Hard link" ln)
>> +   ("s" "Symbolic link" lns))
>> + "How to attach?"
>> + "Attach using method")))
>
> It is better to pop up a menu that allows users to proceed with the
> mouse, e.g. that in `dired-dnd-do-ask-action'. Options like
> 'open'/'file link' could be added too.

Thanks, I will go back to using rmc then.  It shows a nice dialog box
when you use the mouse.

> Thanks for your work.

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

[Visuwesh]

[சனி அக்டோபர் 07, 2023] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Attached patch considers your review and also another defcustom to tell
>> how to generate the filename which by default autogenerates a filename
>> based on current time.
>
> Thanks!
> I still disagree about :safe, but I can change it myself to something
> more restrictive like :safe (lambda (x) (eq x 'attach)))

OK, I will change it on my end then.  I can always override the :safe
function on my end.

> Also, it looks like we also need to define `x-dnd-direct-save-function',
> as Po Lu pointed in 
> https://list.orgmode.org/orgmode/87bkdccihf@yahoo.com/ 

I will get to it, hopefully by Sunday.

What do you think about adding a defcustom as requested by Liu Hui in
https://yhetil.org/orgmode/caoqtw-p6_w3heepjftkcfey2rpfgjfouhwmseoe2ajnpoi+...@mail.gmail.com/

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

[Visuwesh]

[சனி அக்டோபர் 07, 2023] Visuwesh wrote:

> [சனி அக்டோபர் 07, 2023] Ihor Radchenko wrote:
>
>> Visuwesh  writes:
>>
>>> Attached patch considers your review and also another defcustom to tell
>>> how to generate the filename which by default autogenerates a filename
>>> based on current time.
>>
>> Thanks!
>> I still disagree about :safe, but I can change it myself to something
>> more restrictive like :safe (lambda (x) (eq x 'attach)))
>
> OK, I will change it on my end then.  I can always override the :safe
> function on my end.
>
>> Also, it looks like we also need to define `x-dnd-direct-save-function',
>> as Po Lu pointed in 
>> https://list.orgmode.org/orgmode/87bkdccihf@yahoo.com/ 
>
> I will get to it, hopefully by Sunday.

This was far easier than I initially thought.  Patch attached.

>From 7bdd892c0cdb248341e3284e9aeee341f073d38d Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-type, org-yank-image-file-name-function)
(org-dnd-default-attach-method, org-dnd-method): New defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-attach-file, org--dnd-local-file-handler, org--dnd-xds-method)
(org--dnd-xds-function): Add yank-media and DND handlers.

* etc/ORG-NEWS: Advertise the new features.
---
 etc/ORG-NEWS |  20 +
 lisp/org.el  | 234 ++-
 2 files changed, 253 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..c4a58dd4d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,26 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluation, and then plotted afterwards.
 
+*** Images and files in clipboard can be attached
+
+Org can now attach images in clipboard and files copied/cut to the
+clipboard from file managers using the ~yank-media~ command which also
+inserts a link to the attached file.  This command was added in Emacs 29.
+
+Images can be saved to a separate directory instead of being attached,
+customize ~org-yank-image-save-type~.
+
+Image filename chosen can be customized by setting
+~org-yank-image-file-name-function~ which by default autogenerates a
+filename based on the current time.
+
+*** Files and images can be attached by dropping onto Emacs
+
+Attachment method other than ~org-attach-method~ for dropped files can
+be specified using ~org-dnd-default-attach-method~.
+
+Images dropped also respect the value of ~org-yank-image-save-type~.
+
 ** New functions and changes in function arguments
 *** =TYPES= argument in ~org-element-lineage~ can now be a symbol
 
diff --git a/lisp/org.el b/lisp/org.el
index d0b2355ea..cfb314e23 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4999,7 +4999,10 @@ The following commands are available:
   (org--set-faces-extend '(org-block-begin-line org-block-end-line)
  org-fontify-whole-block-delimiter-line)
   (org--set-faces-extend org-level-faces org-fontify-whole-heading-line)
-  (setq-local org-mode-loading nil))
+  (setq-local org-mode-loading nil)
+
+  ;; `yank-media' handler and DND support.
+  (org-setup-yank-dnd-handlers))
 
 ;; Update `customize-package-emacs-version-alist'
 (add-to-list 'customize-package-emacs-version-alist
@@ -20254,6 +20257,235 @@ it has a `diary' type."
 		(org-format-timestamp timestamp fmt t))
 	  (org-format-timestamp timestamp fmt (eq boundary 'end)))
 
+;;; Yank media handler and DND
+(defun org-setup-yank-dnd-handlers ()
+  "Setup the `yank-media' and DND handlers for buffer."
+  (setq-local dnd-protocol-alist
+  (cons '("^file:///" . org--dnd-local-file-handler)
+dnd-protocol-alist))
+  (when (fboundp 'yank-media-handler)
+(yank-media-handler "image/.*" #'org--image-yank-media-handler)
+;; Looks like different DEs go for different handler names,
+;; https://larsee.com/blog/2019/05/clipboard-files/.
+(yank-media-handler "x/special-\\(?:gnome\|KDE\|mate\\)-files"
+#'org--copied-files-yank-media-handler))
+  (when (boundp 'x-dnd-direct-save-function)
+(setq-local x-dnd-direct-save-function #'org--dnd-xds-function)))
+
+(defcustom org-yank-image-save-type 'attach
+  "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 &

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

[Visuwesh]

[ஞாயிறு அக்டோபர் 08, 2023] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> This was far easier than I initially thought.  Patch attached.
>
> Thanks!
> I tried to install the patch and I have two more comments.
>
>> +(defun org-yank-image-autogen-filename ()
>> +  "Autogenerate filename for image in clipboard."
>> +  (format-time-string "clipboard-%Y-%m-%d-%H:%M"))
>
> This is too coarse - no more than a single unique image name per minute.
> What about the default value of `org-id-ts-format' - "%Y%m%dT%H%M%S.%6N"?
> This is guaranteed to be unique.

OK, now done.

>> +(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-yank-image-save-type'.  The name for the
>> +image is prompted and the extension is automatically added to the
>> +end."
>> ...
>> +(if (null (eq org-yank-image-save-type 'attach))
>> +(setq link (org-link-make-string
>> +(concat "file:" (file-relative-name absname))
>> +filename))
>
> I do not like that the inserted image link is with description. Images
> with description cannot be previewed by default. I think that no
> description would be more handy as one could then M-x yank-media
> followed by M-x org-display-inline-images to see the inserted image
> immediately.

I didn't know about this.  Now adjusted in the attached patch.

>From f2d13548b970ebde90ea0a04be7951ef92d220a9 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-type, org-yank-image-file-name-function)
(org-dnd-default-attach-method, org-dnd-method): New defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-attach-file, org--dnd-local-file-handler, org--dnd-xds-method)
(org--dnd-xds-function): Add yank-media and DND handlers.

* etc/ORG-NEWS: Advertise the new features.
---
 etc/ORG-NEWS |  20 +
 lisp/org.el  | 224 ++-
 2 files changed, 243 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..c4a58dd4d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,26 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluation, and then plotted afterwards.
 
+*** Images and files in clipboard can be attached
+
+Org can now attach images in clipboard and files copied/cut to the
+clipboard from file managers using the ~yank-media~ command which also
+inserts a link to the attached file.  This command was added in Emacs 29.
+
+Images can be saved to a separate directory instead of being attached,
+customize ~org-yank-image-save-type~.
+
+Image filename chosen can be customized by setting
+~org-yank-image-file-name-function~ which by default autogenerates a
+filename based on the current time.
+
+*** Files and images can be attached by dropping onto Emacs
+
+Attachment method other than ~org-attach-method~ for dropped files can
+be specified using ~org-dnd-default-attach-method~.
+
+Images dropped also respect the value of ~org-yank-image-save-type~.
+
 ** New functions and changes in function arguments
 *** =TYPES= argument in ~org-element-lineage~ can now be a symbol
 
diff --git a/lisp/org.el b/lisp/org.el
index d0b2355ea..a7ec90f08 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4999,7 +4999,10 @@ The following commands are available:
   (org--set-faces-extend '(org-block-begin-line org-block-end-line)
  org-fontify-whole-block-delimiter-line)
   (org--set-faces-extend org-level-faces org-fontify-whole-heading-line)
-  (setq-local org-mode-loading nil))
+  (setq-local org-mode-loading nil)
+
+  ;; `yank-media' handler and DND support.
+  (org-setup-yank-dnd-handlers))
 
 ;; Update `customize-package-emacs-version-alist'
 (add-to-list 'customize-package-emacs-version-alist
@@ -20254,6 +20257,225 @@ it has a `diary' type."
 		(org-format-timestamp timestamp fmt t))
 	  (org-format-timestamp timestamp fmt (eq boundary 'end)))
 
+;;; Yank media handler and DND
+(defun org-setup-yank-dnd-handlers ()
+  "Setup the `yank-media' and DND handlers for buffer."
+  (setq-local dnd-protocol-alist
+  (cons '("^file:///" . org--dnd-local-file-handler)
+dnd-protocol-alist))
+  (when (fboundp 'yank-media-handler)
+(yank-media-handler "image/.*" #'org--image-yank-media-handler)
+ 

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

[Visuwesh]

[திங்கள் அக்டோபர் 09, 2023] Ihor Radchenko wrote:

> Thanks!
>
>> +(defun org--dnd-attach-file (url action)
>> ...
>> +(insert
>> + (org-link-make-string
>> +  (concat (if separatep
>> +  "file:"
>> +"attachment:")
>> +  (if separatep
>> +  (expand-file-name (file-name-nondirectory filename)
>> +org-yank-image-save-type)
>> +(file-name-nondirectory filename
>> + "\n")
>> +'private))
>
>> +(pcase org--dnd-xds-method
>> +  (`attach (insert (org-link-make-string
>> +(concat "attachment:" (file-name-nondirectory 
>> filename)))
>
>> +  (`file-link (insert (org-link-make-string (concat "file:" filename))
>> +  "\n"))
>
> Is there any particular reason why you insert a newline after the image
> link?

It is for when you drop multiple files onto a frame.  AFAIU/AFAICT
there's no way to know beforehand if multiple files will be dropped or
not.  I will look into it in bit more detail in the coming days and drop
the newline if only one file is dropped.

> Also, we might want to add a subsection describing the new customization to
> 17 Miscellaneous section of the manual. Otherwise, users might have
> difficulties discovering relevant settings to customize dnd and yank
> behavior.

OK, I will do so.

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

[Visuwesh]

[புதன் அக்டோபர் 11, 2023] Liu Hui wrote:

> Hi,
>
> Thanks for your work. I have two minor suggestions about the patch.
>
>> + (`file-link
>> + (let ((filename (dnd-get-local-file-name url)))
>> + (insert (org-link-make-string (concat "file:" filename
>
> I think it is better to abbreviate the file name for file-link, so it
> would be consistent with org-insert-link.

OK, will do.

>> + (caddr (read-multiple-choice
>> + "What to do with dropped file?"
>> + '((?a "attach" attach)
>> + (?o "open" open)
>> + (?f "insert file: link" file-link
>
> The dialog box is shown in the center of frame and I find it a little
> inconvenient compared with a menu popped up just at the mouse
> location. How about using x-popup-menu?

But isn't that for menus?  I don't know how convenient is a menu
compared to a dialog box.  But if the consensus is that a menu should be
popped, then I will adjust the query to use rmc or menu as per
use-dialog-box.

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

[Visuwesh]

[திங்கள் அக்டோபர் 09, 2023] Visuwesh wrote:

> [திங்கள் அக்டோபர் 09, 2023] Ihor Radchenko wrote:
>
>> Thanks!
>>
>>> +(defun org--dnd-attach-file (url action)
>>> ...
>>> +(insert
>>> + (org-link-make-string
>>> +  (concat (if separatep
>>> +  "file:"
>>> +"attachment:")
>>> +  (if separatep
>>> +  (expand-file-name (file-name-nondirectory filename)
>>> +org-yank-image-save-type)
>>> +(file-name-nondirectory filename
>>> + "\n")
>>> +'private))
>>
>>> +(pcase org--dnd-xds-method
>>> +  (`attach (insert (org-link-make-string
>>> +(concat "attachment:" (file-name-nondirectory 
>>> filename)))
>>
>>> +  (`file-link (insert (org-link-make-string (concat "file:" filename))
>>> +  "\n"))
>>
>> Is there any particular reason why you insert a newline after the image
>> link?
>
> It is for when you drop multiple files onto a frame.  AFAIU/AFAICT
> there's no way to know beforehand if multiple files will be dropped or
> not.  I will look into it in bit more detail in the coming days and drop
> the newline if only one file is dropped.

OK, seems like the actual handling is done by x-dnd-handle-uri-list
where the URI list is split and each URI is handled separately.  We can
override this function by our own by changing the entry in
x-dnd-types-alist but we need to do the same for pgtk-dnd-types-alist
and from what I can tell there are no such facilities for MS Windows and
NS?  I think we need to accept that we will have sub-optimal interface
for multi file drops.  WDYT?

Also, can I know what you think about using a popup-menu instead of a
dialog box for prompting as Liu Hui suggests in
https://yhetil.org/orgmode/caoqtw-mas6b2uh9z52ejn7ebwni+suhq9dwe0fky_rzvhox...@mail.gmail.com
?  If you're okay with it, I will write a function to use rmc or
popup-menu for prompting as per what use-dialog-box-p returns.

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

[Visuwesh]

[வெள்ளி அக்டோபர் 20, 2023] Ihor Radchenko wrote:

> Po Lu  writes:
>
>>> Because nobody added you manually to the CC in this branch of the
>>> discussion. You would only be automatically in the CC in the replies to
>>> your message (87bkdccihf@yahoo.com), but not the earlier branches.
>>
>> The follow-up I mentioned lists 87bkdccihf@yahoo.com within
>> In-Reply-To.
>
> I see. I use wide reply by default, personally. I did not drop you or
> anyone from CC in this thread on purpose.

I also use wide-reply but the problem was that I neglected to include Po
Lu in the CCs when I replied to a message in another sub-thread that
referred to Po Lu's message.  So the issue raised by Po Lu was addressed
but he was effectively dropped from the discussion due to my negligence.

>>> Do you mean something like a standardized entry in `dnd-protocol-alist'
>>> that is independent on OS? Instead of (REGEXP . FUNCTION),
>>> (SYMBOL . FUNCTION) with SYMBOL = 'file-list or so.
>>
>> I'm sorry, but I don't understand what you're proposing.  Would you
>> please couch it differently?
>
> Instead of passing dnd data as is from the OS, Emacs can convert it into
> a standardized format, independent of the OS. Then,
> `dnd-protocol-alist' can allow handlers for such standardized dnd type.
>
> In our scenario, the dnd data will be dropped file list. Emacs should
> internally detect such file lists for GNU/Linux / Windows / other
> platforms with dnd support and then convert them into the same format.
> Then, dnd users can add (file-list . FUNCTION) into `dnd-protocol-alist'
> and the FUNCTION will be passed with the converted data that will always
> be the same for all the OSes.
>
> Does it make sense?

BTW, I would also like to have something like dnd-protocol-alist but for
dropped _text_ instead.  Currently, every dropped text is handled by
dnd-insert-text but I would like to have a handler so that e.g., I can
add the relevant bibtex entry for the DOI _text_ (10.BLAH/BLAH no fancy
link) onto an Emacs window visiting a bibtex file.  I currently do this
via an advice but it would be nice to have something less hacky.

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

[Visuwesh]

[திங்கள் அக்டோபர் 09, 2023] Ihor Radchenko wrote:

> Thanks!
>
>> +(defun org--dnd-attach-file (url action)
>> ...
>> +(insert
>> + (org-link-make-string
>> +  (concat (if separatep
>> +  "file:"
>> +"attachment:")
>> +  (if separatep
>> +  (expand-file-name (file-name-nondirectory filename)
>> +org-yank-image-save-type)
>> +(file-name-nondirectory filename
>> + "\n")
>> +'private))
>
>> +(pcase org--dnd-xds-method
>> +  (`attach (insert (org-link-make-string
>> +(concat "attachment:" (file-name-nondirectory 
>> filename)))
>
>> +  (`file-link (insert (org-link-make-string (concat "file:" filename))
>> +  "\n"))
>
> Is there any particular reason why you insert a newline after the image
> link?

I think this can stay here until Po Lu writes the platform-agnostic code
that you requested further down this thread?

> Also, we might want to add a subsection describing the new customization to
> 17 Miscellaneous section of the manual. Otherwise, users might have
> difficulties discovering relevant settings to customize dnd and yank
> behavior.

I have now added these to the manual with a few relevant concept
indices.  Please check if they are understandable as I am terrible at
writing documentation.  Thanks.

>From e8b142db0d91e305cbefbb2c945fee7c40ed03f3 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-type, org-yank-image-file-name-function)
(org-dnd-default-attach-method, org-dnd-method): New defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-attach-file, org--dnd-local-file-handler, org--dnd-xds-method)
(org--dnd-xds-function, org--dnd-rmc): Add yank-media and DND
handlers.

* doc/org-manual.org: (Drag and Drop & ~yank-media~): Describe the new
feature in the manual.

* etc/ORG-NEWS: Advertise the new features.
---
 doc/org-manual.org |  40 
 etc/ORG-NEWS   |  20 
 lisp/org.el| 243 -
 3 files changed, 298 insertions(+), 5 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3e9d42f55..dcdaa98fa 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21095,6 +21095,46 @@ most recent since the mobile application searches files that were last
 pulled.  To get an updated agenda view with changes since the last
 pull, pull again.
 
+** Drag and Drop & ~yank-media~
+:PROPERTIES:
+:DESCRIPTION: Dropping and pasting files and images
+:END:
+
+#+cindex: dropping files
+#+vindex: org-dnd-method
+Org can attach, insert =file:= links, or open files dropped onto an
+Emacs frame.  By default, Org asks the user what must be done with the
+dropped file but this can be changed by customizing the user option
+~org-dnd-method~.  Changing the variable can make Org do any of the
+above mentioned actions without prompting.
+
+#+vindex: org-dnd-default-attach-method
+If Org cannot figure out which attachment method to use automatically,
+it defaults to using the attachment method mentioned in
+~org-dnd-default-attach-method~.  Org uses the attachment method
+mentioned in ~org-attach-method~ by default, so Org using the =cp=
+method to attach the dropped files.
+
+#+cindex: pasting files, images from clipboard
+From Emacs 29, Org can deal with images copied to the clipboard, and
+files copied from a file manager when pasted using the command
+~yank-media~.  Org deals with them differently.
+
+#+vindex: org-yank-image-save-type
+#+vindex: org-yank-image-file-name-function
+For images, Org attaches the image when pasting but this can be
+changed by customizing ~org-yank-image-save-type~ to save them under
+another directory instead.  The name given to these images are
+autogenerated by default but you can customize what name should be
+given to the pasted image by customizing
+~org-yank-image-file-name-function~.  This function takes no argument
+and should return the filename without extension to use as the image's
+filename.
+
+For files copied from a file manager, Org attaches them to the current
+heading using the =mv= or the =cp= method if the files were cut or
+copied in the file manager respectively.
+
 * Hacking
 :PROPERTIES:
 :DESCRIPTION: How to hack your way around.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..c4a58dd4d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,26 @@ return a matplotlib F

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

[Visuwesh]

[திங்கள் அக்டோபர் 23, 2023] Ihor Radchenko wrote:

>>> Also, we might want to add a subsection describing the new customization to
>>> 17 Miscellaneous section of the manual. Otherwise, users might have
>>> difficulties discovering relevant settings to customize dnd and yank
>>> behavior.
>>
>> I have now added these to the manual with a few relevant concept
>> indices.  Please check if they are understandable as I am terrible at
>> writing documentation.  Thanks.
>
> Thanks!
> Upon reading the manual sections I have further comments on the code:
>
> 1. org-yank-image-save-type feels a bit inconsistent. What about
>org-yank-image-save-method? "Type" sounds more like extension (png,
>jpeg, etc)

You're right, I have now changed the name to say method instead.

> 2. org-dnd-method allows either attaching files/images or putting them
>into a dedicated directory. Same for yanked images. But it is not the
>case for yanked files - they are always attached, which is not
>consistent. May we also allow dedicated directory for yanked files?
>Or maybe simply merge the org-dnd-method customization for yank and
>dnd together.

Hmm... yes, I now made yank-media also respect the value of
org-dnd-method.  I changed the name of org-dnd-method to
org-yank-dnd-method and similarly for the rest of the common user
options.

Here's the new patch:

>From c7492fc2adb72a45691124929527798bf9482c2b Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-method, org-yank-image-file-name-function)
(org-yank-dnd-method, org-yank-dnd-default-attach-method): New
defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-rmc, org--dnd-attach-file, org--dnd-local-file-handler)
(org--dnd-xds-method, org--dnd-xds-function): Add yank-media and DND
handlers.

* doc/org-manual.org: (Drag and Drop & ~yank-media~): Describe the new
feature in the manual.

* etc/ORG-NEWS: Advertise the new features.
---
 doc/org-manual.org |  45 +
 etc/ORG-NEWS   |  24 +
 lisp/org.el| 231 -
 3 files changed, 299 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3e9d42f55..7b14eb937 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21095,6 +21095,51 @@ most recent since the mobile application searches files that were last
 pulled.  To get an updated agenda view with changes since the last
 pull, pull again.
 
+** Drag and Drop & ~yank-media~
+:PROPERTIES:
+:DESCRIPTION: Dropping and pasting files and images
+:END:
+
+#+cindex: dropping files
+#+cindex: dragging files
+#+cindex: drag and drop
+#+cindex: dnd
+#+vindex: org-yank-dnd-method
+Org mode supports drag and drop (DnD) of files.  By default, Org asks
+the user what must be done with the dropped file: attach it, insert
+=file:= link, or open the file.  Customize ~org-yank-dnd-method~ to
+set the default DnD action.
+
+When DnD method is "attach", Org mode first consults DnD metadata to
+decide the attach method.  For example, when file/files are dragged
+from a file manager, Org may attach by copying or by moving.
+
+#+vindex: org-yank-dnd-default-attach-method
+If Org cannot figure out which attachment method to use from the
+metadata, it defaults to ~org-yank-dnd-default-attach-method~ [fn::By
+default, ~org-yank-dnd-default-attach-method~ is set to nil -- use the same
+value as ~org-attach-method~ (~cp~ by default).]
+
+#+cindex: pasting files, images from clipboard
+Starting from Emacs 29, Org mode supports ~yank-media~ command to yank
+images from the clipboard and files from a file manager.
+
+#+vindex: org-yank-image-save-method
+When yanking images from clipboard, Org saves the image on disk and
+inserts the image link to Org buffer.  Images are either saved as
+attachments to heading (default) or to a globally defined directory.
+The save location is controlled by ~org-yank-image-save-method~.
+
+#+vindex: org-yank-image-file-name-function
+The yanked images are saved under automatically generated name.  You
+can customize ~org-yank-image-file-name-function~ to make Org query
+the image names or change the naming scheme.
+
+When yanking files copied from a file manager, Org respects the value
+of ~org-yank-dnd-method~.  Image files pasted this way also respect
+the value of ~org-yank-image-save-method~ when the action to perform
+is =attach=.
+
 * Hacking
 :PROPERTIES:
 :DESCRIPTION: How to hack your way around.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..7c40ec0fe 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +59

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

[Visuwesh]

[ஞாயிறு நவம்பர் 05, 2023] Ihor Radchenko wrote:

> Po Lu  writes:
>
>> I have now installed an interface to this end into Emacs 30.  The
>> pertinent documentation is under the ``Drag and Drop'' node in the Lisp
>> reference manual.
> [...]
> Visuwesh, do you want to update your patch accordingly?

Yes, I intend to.  But this might not happen until December since I am
busy with the end of my semester.

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

[Visuwesh]

[ஞாயிறு நவம்பர் 05, 2023] Ihor Radchenko wrote:

> Po Lu  writes:
>
>> I have now installed an interface to this end into Emacs 30.  The
>> pertinent documentation is under the ``Drag and Drop'' node in the Lisp
>> reference manual.
>
> Thanks!
>
> [...]
>
> Visuwesh, do you want to update your patch accordingly?

I have now adjusted the patch to insert a space between links when the
Emacs version in <30, and when more than one file is dropped.

>From 93db10f9f0c618be5512fbd67cd7b7676d6b1b0c Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-method, org-yank-image-file-name-function)
(org-yank-dnd-method, org-yank-dnd-default-attach-method): New
defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-rmc, org--dnd-multi-local-file-handler)
(org--dnd-local-file-handler, org--dnd-attach-file, org--dnd-xds-method)
(org--dnd-xds-function): Add yank-media and DND handlers.

* doc/org-manual.org: (Drag and Drop & ~yank-media~): Describe the new
feature in the manual.

* etc/ORG-NEWS: Advertise the new features.
---
 doc/org-manual.org |  45 
 etc/ORG-NEWS   |  24 +
 lisp/org.el| 248 -
 3 files changed, 316 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3e9d42f55..7b14eb937 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21095,6 +21095,51 @@ most recent since the mobile application searches files that were last
 pulled.  To get an updated agenda view with changes since the last
 pull, pull again.
 
+** Drag and Drop & ~yank-media~
+:PROPERTIES:
+:DESCRIPTION: Dropping and pasting files and images
+:END:
+
+#+cindex: dropping files
+#+cindex: dragging files
+#+cindex: drag and drop
+#+cindex: dnd
+#+vindex: org-yank-dnd-method
+Org mode supports drag and drop (DnD) of files.  By default, Org asks
+the user what must be done with the dropped file: attach it, insert
+=file:= link, or open the file.  Customize ~org-yank-dnd-method~ to
+set the default DnD action.
+
+When DnD method is "attach", Org mode first consults DnD metadata to
+decide the attach method.  For example, when file/files are dragged
+from a file manager, Org may attach by copying or by moving.
+
+#+vindex: org-yank-dnd-default-attach-method
+If Org cannot figure out which attachment method to use from the
+metadata, it defaults to ~org-yank-dnd-default-attach-method~ [fn::By
+default, ~org-yank-dnd-default-attach-method~ is set to nil -- use the same
+value as ~org-attach-method~ (~cp~ by default).]
+
+#+cindex: pasting files, images from clipboard
+Starting from Emacs 29, Org mode supports ~yank-media~ command to yank
+images from the clipboard and files from a file manager.
+
+#+vindex: org-yank-image-save-method
+When yanking images from clipboard, Org saves the image on disk and
+inserts the image link to Org buffer.  Images are either saved as
+attachments to heading (default) or to a globally defined directory.
+The save location is controlled by ~org-yank-image-save-method~.
+
+#+vindex: org-yank-image-file-name-function
+The yanked images are saved under automatically generated name.  You
+can customize ~org-yank-image-file-name-function~ to make Org query
+the image names or change the naming scheme.
+
+When yanking files copied from a file manager, Org respects the value
+of ~org-yank-dnd-method~.  Image files pasted this way also respect
+the value of ~org-yank-image-save-method~ when the action to perform
+is =attach=.
+
 * Hacking
 :PROPERTIES:
 :DESCRIPTION: How to hack your way around.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..7c40ec0fe 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,30 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluation, and then plotted afterwards.
 
+*** Images and files in clipboard can be pasted
+
+Org asks the user what must be done when pasting images and files
+copied to the clipboard from a file manager using the ~yank-media~
+command.  The default action can be set by customizing
+~org-yank-dnd-method~.  The ~yank-media~ command was added in Emacs
+29.
+
+Images can be saved to a separate directory instead of being attached,
+customize ~org-yank-image-save-method~.
+
+Image filename chosen can be customized by setting
+~org-yank-image-file-name-function~ which by default autogenerates a
+filename based on the current time.
+
+*** Files and images can be attached by dropping onto Emacs
+
+By default, Org asks the user what to do with the dropped file like
+for pasted files.  The same user option ~org-yank

[BUG] ox-odt messes with auto-mode-alist [9.7-pre (release_9.6.11-1090-g76468c.dirty @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

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.


ox-odt.el contains the following lines at the end of file:

;;; Library Initializations

(dolist (desc org-odt-file-extensions)
  ;; Let Emacs open all OpenDocument files in archive mode.
  (add-to-list 'auto-mode-alist
   (cons (concat  "\\." (car desc) "\\'") 'archive-mode)))

Is there a reason why this is done?  This breaks the expected result of
opening .odt and friends using doc-view-mode, and causes unnecessary
confusion (it is not particularly easy to find too since grepping
through Emacs for "\\.odt" fails).

Emacs  : GNU Emacs 30.0.50 (build 42, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-01-31
Package: Org mode version 9.7-pre (release_9.6.11-1090-g76468c.dirty @ 
/home/viz/lib/emacs/straight/build/org/)

[PATCH] Add support for tables in Calc src block :var

[Visuwesh]

Attached patch adds support for passing tables as matrices (or vector)
to a Calc source block through the :var parameter.  There might be a
better way to do it than manually construct the data structure expected
by Calc for a matrix but given that it rarely sees changes in this area,
it shouldn't be a bother.
I also added tests for this feature, and other simple tests to ensure
everything works.  I checked that all the tests passed on my side.

>From 5dd444a3dd688b366e1151739f6a8e8088bb0623 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sat, 16 Mar 2024 09:10:53 +0530
Subject: [PATCH] ob-calc: Support passing tables as matrices with :var

A table with MxN dimensions is converted to a MxN matrix when given in
:var to a Calc source block.  A table with a single row is converted
to a vector (i.e., row vector).

* lisp/ob-calc.el (org-babel-execute-src-block:calc): Construct the
right data structure to pass tables as matrices to Calc.
* testing/examples/ob-calc-test.org:
* testing/lisp/test-ob-calc.el: Add tests for ob-calc, and this new
feature.
---
 lisp/ob-calc.el   | 10 +++-
 testing/examples/ob-calc-test.org | 57 ++
 testing/lisp/test-ob-calc.el  | 80 +++
 3 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100644 testing/examples/ob-calc-test.org
 create mode 100644 testing/lisp/test-ob-calc.el

diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index f36df77ff..c8bbcd16b 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -64,7 +64,15 @@
 	 (var-names (mapcar #'symbol-name org--var-syms)))
 (mapc
  (lambda (pair)
-   (calc-push-list (list (cdr pair)))
+   (let ((val (cdr pair)))
+ (calc-push-list
+  (list (if (listp val)
+(cons 'vec
+  (if (null (cdr val))
+  (car val)
+(mapcar (lambda (x) (if (listp x) (cons 'vec x) x))
+val)))
+  val
(calc-store-into (car pair)))
  vars)
 (mapc
diff --git a/testing/examples/ob-calc-test.org b/testing/examples/ob-calc-test.org
new file mode 100644
index 0..6df44c6a4
--- /dev/null
+++ b/testing/examples/ob-calc-test.org
@@ -0,0 +1,57 @@
+#+TITLE: Tests for ob-calc
+#+OPTIONS: ^:nil
+
+* Simple
+:PROPERTIES:
+:ID:   40e4cd26-fe15-45c0-938b-111e021a5a99
+:END:
+
+#+BEGIN_SRC calc :results silent
+	1 * 2
+#+END_SRC
+
+#+BEGIN_SRC calc :results silent
+	12 + 16 - 1
+#+END_SRC
+
+#+BEGIN_SRC calc :results silent
+	inv(a)
+#+END_SRC
+
+* Tables
+:PROPERTIES:
+:ID:   138938e1-f0ba-4c2b-babe-5d20f2b83557
+:END:
+
+#+NAME: ob-calc-table-1
+| 1 |  2 |  3 |
+| 5 |  6 |  7 |
+| 9 | 14 | 11 |
+
+#+NAME: ob-calc-table-2
+| 1 | 2 | 3 | 4 | 5 |
+
+#+NAME: ob-calc-table-3
+| 1 |
+| 2 |
+| 3 |
+
+#+BEGIN_SRC calc :results silent :var a=ob-calc-table-1
+	inv(a)
+#+END_SRC
+
+#+BEGIN_SRC calc :results silent :var a=ob-calc-table-2
+	a*2 - 2
+#+END_SRC
+
+#+BEGIN_SRC calc :results silent :var a=ob-calc-table-2
+	vmean(a)
+#+END_SRC
+
+#+BEGIN_SRC calc :results silent :var a=ob-calc-table-3
+	a
+#+END_SRC
+
+#+BEGIN_SRC calc :results silent :var a=ob-calc-table-2
+	a
+#+END_SRC
diff --git a/testing/lisp/test-ob-calc.el b/testing/lisp/test-ob-calc.el
new file mode 100644
index 0..443ccd64b
--- /dev/null
+++ b/testing/lisp/test-ob-calc.el
@@ -0,0 +1,80 @@
+;;; test-ob-calc.el --- tests for ob-calc.el -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2024  Visuwesh
+
+;; Author: Visuwesh 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Code:
+(require 'ob-calc)
+
+(unless (featurep 'ob-calc)
+  (signal 'missing-test-dependency "Support for Calc code blocks"))
+
+(ert-deftest ob-calc/simple-program-mult ()
+  "Test of simple multiplication."
+  (org-test-at-id "40e4cd26-fe15-45c0-938b-111e021a5a99"
+(org-babel-next-src-block)
+(should (equal "2" (org-babel-execute-src-block)
+
+(ert-deftest ob-calc/simple-program-arith ()
+  "Test of simple arithmetic."
+  (org-test-at-id "40e4cd26-fe15-45c0-938b-111e021a5a99"
+(org-babel-next-src-block 2)
+(should (equal "27" (org-babel-execute-src-block)
+
+(ert-deftest ob-calc/simple-program-symbolic ()
+  &qu

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[சனி மார்ச் 16, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Attached patch adds support for passing tables as matrices (or vector)
>> to a Calc source block through the :var parameter.  There might be a
>> better way to do it than manually construct the data structure expected
>> by Calc for a matrix but given that it rarely sees changes in this area,
>> it shouldn't be a bother.
>> I also added tests for this feature, and other simple tests to ensure
>> everything works.  I checked that all the tests passed on my side.
>
> Thanks!
> Since you are adding a new feature, may you also add an entry to etc/ORG-NEWS?

Now done.

>> -   (calc-push-list (list (cdr pair)))
>> +   (let ((val (cdr pair)))
>> + (calc-push-list
>> +  (list (if (listp val)
>> +(cons 'vec
>> +  (if (null (cdr val))
>> +  (car val)
>> +(mapcar (lambda (x) (if (listp x) (cons 'vec x) 
>> x))
>> +val)))
>> +  val
>
> It would be nice to add code comments explaining the Calc's internal
> format. Ideally, with references to Calc's manual or source code.
> Otherwise, this code looks like black magic :)

I hope the comment I added in the attached patch is clear enough.

>> +++ b/testing/examples/ob-calc-test.org
>> @@ -0,0 +1,57 @@
>> +#+TITLE: Tests for ob-calc
>> +#+OPTIONS: ^:nil
>
> Thanks a lot for adding many tests!
> Would you mind using `org-test-with-temp-text' instead of
> `org-test-at-id' as much as possible? Otherwise, looking at tests like

OK, I wasn't sure what test style to use since the README in testing/
does not talk about writing new tests.  Now I have adapted the tests to
use org-test-with-temp-text.

>From 29962bc3ec33e1e25f83f153b681d49182368592 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sat, 16 Mar 2024 17:04:14 +0530
Subject: [PATCH] ob-calc.el: Add support for tables in Calc source block :var

A table with MxN dimensions is converted to a MxN matrix when given in
:var to a Calc source block.  A table with a single row is converted
to a vector (i.e., row vector).

* lisp/ob-calc.el (org-babel-execute-src-block:calc): Construct the
right data structure to pass tables as matrices to Calc.
* testing/lisp/test-ob-calc.el: Add tests for ob-calc, and this new
feature.
* etc/ORG-NEWS: Announce the feature.
---
 etc/ORG-NEWS |   7 +++
 lisp/ob-calc.el  |  14 -
 testing/lisp/test-ob-calc.el | 115 +++
 3 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 testing/lisp/test-ob-calc.el

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ca73f06e7..197d7503d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1121,6 +1121,13 @@ Maxima's graphics packages (~draw~ or ~plot~); the default remains
 ~plot~.  The graphics terminal is now determined from the file-ending
 of the file-name set in the ~:file~ header argument.
 
+*** =ob-calc.el=: Support for tables in ~:var~
+
+=ob-calc= now supports tables in ~:var~.  They are converted to a
+matrix or a vector depending on the dimensionality of the table.  A
+table with a single row is converted to a vector, the rest are
+converted to a matrix.
+
 *** Images and files in clipboard can be pasted
 
 Org asks the user what must be done when pasting images and files
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index f36df77ff..810ed1735 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -64,7 +64,19 @@
 	 (var-names (mapcar #'symbol-name org--var-syms)))
 (mapc
  (lambda (pair)
-   (calc-push-list (list (cdr pair)))
+   (let ((val (cdr pair)))
+ (calc-push-list
+  ;; For a vector, Calc follows the format (vec 1 2 3 ...)  so
+  ;; a matrix becomes (vec (vec 1 2 3) (vec 4 5 6) ...).  See
+  ;; the comments in "Arithmetic routines." section of
+  ;; calc.el.
+  (list (if (listp val)
+(cons 'vec
+  (if (null (cdr val))
+  (car val)
+(mapcar (lambda (x) (if (listp x) (cons 'vec x) x))
+val)))
+  val
(calc-store-into (car pair)))
  vars)
 (mapc
diff --git a/testing/lisp/test-ob-calc.el b/testing/lisp/test-ob-calc.el
new file mode 100644
index 0..6d6ca104d
--- /dev/null
+++ b/testing/lisp/test-ob-calc.el
@@ -0,0 +1,115 @@
+;;; test-ob-calc.el --- tests for ob-calc.el -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2024  Visuwesh
+
+;; Author: Visuwesh 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[சனி மார்ச் 16, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Subject: [PATCH] ob-calc.el: Add support for tables in Calc source block :var
>
> Thanks!
> Applied, onto main.
> I modified the patch to enable ob-calc tests by default.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=89b0773c3

Thanks!

>>> Would you mind using `org-test-with-temp-text' instead of
>>> `org-test-at-id' as much as possible? Otherwise, looking at tests like
>>
>> OK, I wasn't sure what test style to use since the README in testing/
>> does not talk about writing new tests.  Now I have adapted the tests to
>> use org-test-with-temp-text.
>
> Yeah. We do not have a dedicated style document for Org mode tests.

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[திங்கள் மார்ச் 18, 2024] Fraga, Eric wrote:

> Thank you for this.  Potentially very useful.
>
> As you have managed to understand calc internals (to a much greater
> degrees than I have ever managed), do you know if there is any way to go
> the other way?  Specifically, I would love to make reference to calc
> variables, especially those defined using embedded calc, in org tables.

You give me far too credit: I merely placed an edebug trigger for
calc-push-list and used a simple-minded ' [1,2,3;4,5,6] RET to figure
out the vector format (then later I found the commentary).

If I get the time, I will try to look into your request.  Unfortunately,
I cannot promise anything since I am near the end of my semester making
me annoyingly busy.
[ I would like to make ob-calc turn matrices into tables in the result:
  like what ob-fortran and others already do.  ]

> Thanks again,
> eric

[BUG] ob-calc and decimal number in :var [9.7-pre (release_9.6.17-1446-g252971 @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

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.


In emacs -Q, try evaluating the source block

#+BEGIN_SRC calc :var thetarot=1.3
  1/thetarot
#+END_SRC

and witness the following error:

Debugger entered--Lisp error: (wrong-type-argument listp 1.3)
  nth(2 1.3)
  calc-div-fractions(1 1.3)
  math-div(1 1.3)
  math-mul-or-div(1 1.3 nil t)
  math-combine-prod(1 1.3 nil t t)
  math-simplify-one-divisor((1 1.3) (1.3))
  math-simplify-divisor((1 1.3) (1.3) nil t)
  math-simplify-divide((/ 1 1.3))
  #f(compiled-function (expr) #)((/ 1 1.3))
  math-simplify-step((/ 1 1.3))
  math-simplify((/ 1 1.3))
  calc-normalize-fancy((/ 1 1.3))
  calc-normalize((/ 1 1.3))
  math-evaluate-expr((/ 1 1.3))
  #f(compiled-function (line) #)("1/thetarot")
  mapc(#f(compiled-function (line) #) 
("1/thetarot"))
  org-babel-execute:calc("1/thetarot\11" ((:var thetarot . 1.3) 
(:colname-names) (:rowname-names) (:result-params "replace") (:result-type . 
value) (:results . "replace") (:exports . "code") (:session . "none") (:cache . 
"no") (:noweb . "no") (:hlines . "no") (:tangle . "no")))
  org-babel-execute-src-block(nil ("calc" "1/thetarot\11" ((:var thetarot . 
1.3) (:colname-names) (:rowname-names) (:result-params "replace") (:result-type 
. value) (:results . "replace") (:exports . "code") (:tangle . "no") (:hlines . 
"no") (:noweb . "no") (:cache . "no") (:session . "none")) "" nil 148 
"(ref:%s)"))
  org-ctrl-c-ctrl-c(nil)
  funcall-interactively(org-ctrl-c-ctrl-c nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
  command-execute(org-ctrl-c-ctrl-c)

This happens because the decimal number 1.3 is not in the format calc
expects.  A VERY DIRTY patch to do this is

diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index f36df77ff..6ef09032a 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -111,7 +116,7 @@ EL is taken from the output of `math-read-exprs'."
   (if (and (eq 'var (car el)) (member (cadr el) org--var-syms))
  (progn
(calc-recall (cadr el))
-   (prog1 (calc-top 1)
+   (prog1 (math-read-exprs (format "%S" (calc-top 1)))
  (calc-pop 1)))
(mapcar #'org-babel-calc-maybe-resolve-var el))
 el))

but unfortunately, I don't have the time currently to polish this up.
If someone doesn't beat me to it, I will send a more polished+tested
patch by the beginning of May (if I get a lot of free time, I can try to
make one in the meanwhile).

Emacs  : GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-02-17
Package: Org mode version 9.7-pre (release_9.6.17-1446-g252971 @ 
/home/viz/lib/emacs/straight/build/org/)

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[திங்கள் மார்ச் 18, 2024] Fraga, Eric wrote:

Good day, Eric!

> Thank you for this.  Potentially very useful.
>
> As you have managed to understand calc internals (to a much greater
> degrees than I have ever managed), do you know if there is any way to go
> the other way?  Specifically, I would love to make reference to calc
> variables, especially those defined using embedded calc, in org tables.

Can you please provide a minimal example for me to play around with?  I
realise I would like something like this too [*] but I don't know
concretely what this would/should look like.



[*] More specifically, I want to pass around src block evaluation
results in a table formula.

Re: [BUG] ob-calc and decimal number in :var [9.7-pre (release_9.6.17-1446-g252971 @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[வியாழன் மே 02, 2024] Ihor Radchenko wrote:

> Ihor Radchenko  writes:
>
>>> #+BEGIN_SRC calc :var thetarot=1.3
>>>   1/thetarot
>>> #+END_SRC
>>>
>>> and witness the following error:
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument listp 1.3)
>>>   nth(2 1.3)
>>
>> Confirmed.
>
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dd12e9c76

Great, thanks!  Unfortunately, I couldn't find the time to find a proper
fix, thank you for your fix.

[BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

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.


Consider the following table, and try to execute the PLOT line

#+PLOT: ind:1 deps:(3) type:2d with:lp
| Sede  | Max cites | H-index |
|---+---+-|
| Chile |257.72 |   21.39 |
| Leeds |165.77 |   19.68 |
| Sao Paolo | 71.00 |   11.50 |
| Stockholm |134.19 |   14.33 |
| Morelia   |257.56 |   17.67 |

and watch it fail (see the error message in the *gnuplot* buffer).
Although the 2d option in org-plot/preset-plot-types has :check-ind-type
set to a non-nil value, org-plot/gnuplot does not check the value of
:check-ind-type assigned in the 2d type given in the user-option.

Unless I misunderstood the code, the line

  ;; Check type of ind column (timestamp? text?)
  (when (plist-get params :check-ind-type)

should be

  ;; Check type of ind column (timestamp? text?)
  (when (plist-get (cdr type) :check-ind-type)

because (1) org-plot/collect-options only adds a select number of
keywords to the plist and :check-ind-type is not a part of the select
members, and (2) org-plot/gnuplot is never called with a non-nil value
for the optional argument PARAMS in tree.

BTW, the earlier check in the function for :data-dump should also fail
because

(plist-get (assoc 'grid org-plot/preset-plot-types) :data-dump) ;; => nil

but

(plist-get (cdr (assoc 'grid org-plot/preset-plot-types)) :data-dump) ;; => 
non-nil

where type ≡ (assoc 'grid org-plot/preset-plot-types) in
org-plot/gnuplot.

[ I cannot reproduce the grid example in worg's org-plot.org file, but
  even with the fix, I cannot reproduce it; more below.  ]

The other code smell I see is that the function checks for the PLOT line
twice.  Once near the beginning of the function, and once just after the
cleaning up of hline.  Is this simply an oversight?

Coming to the grid example, the doc-string of org-plot/preset-plot-types
options says:

- :data-dump - Function to dump the table to a datafile for ease of
  use.

  Accepts lambda function.  Default lambda body:
  (org-plot/gnuplot-to-data table data-file params)

but in fact, org-plot/gnuplot passes one more argument to the :data-dump
function:

  ;; Dump table to datafile
  (let ((dump-func (plist-get type :data-dump)))
(if dump-func
(funcall dump-func table data-file num-cols params)
  (org-plot/gnuplot-to-data table data-file params)))

but here's the catch: the :data-dump function in the grid option expects
the order

(lambda (table data-file params _num-cols)

which breaks things down the line.  What should be the actual order
here?  I looked at the history of those lines briefly using C-x v h but
I don't have the time to look into it properly to decide on the actual
argument order.

For now, I have attached a patch that fixes all the issues.  With the
patch, i can run the example covered in the bug report.  The grid
example given in worg passes but it doesn't look as expected.  I am not
sure what to blame here.

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 283d993..3be1b2f 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -679,8 +679,8 @@ (defun org-plot/gnuplot (&optional params)
 		tbl))
 	   (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table)
 			   (nth 0 table
-	   (type (assoc (plist-get params :plot-type)
-			org-plot/preset-plot-types))
+	   (type (cdr (assoc (plist-get params :plot-type)
+			 org-plot/preset-plot-types)))
gnuplot-script)

   (unless type
@@ -691,17 +691,13 @@ (defun org-plot/gnuplot (&optional params)
 	(setf params
 	  (plist-put params :labels (car table))) ; headers to labels
 	(setf table (delq 'hline (cdr table ; clean non-data from table
-  ;; Collect options.
-  (save-excursion (while (and (equal 0 (forward-line -1))
-  (looking-at "[[:space:]]*#\\+"))
-			(setf params (org-plot/collect-options params
   ;; Dump table to datafile
   (let ((dump-func (plist-get type :data-dump)))
 (if dump-func
-	(funcall dump-func table data-file num-cols params)
+	(funcall dump-func table data-file params num-cols)
 	  (org-plot/gnuplot-to-data table data-file params)))
   ;; Check type of ind column (timestamp? text?)
-  (when (plist-get params :check-ind-type)
+  (when (plist-get type :check-ind-type)
 	(let* ((ind (1- (plist-get params :ind)))
 	   (ind-column (mapcar (lambda (row) (nth ind row)) table)))
 	  (cond ((< ind 0) nil) ; ind is implicit

Emacs  : GNU Emacs 30.0.50 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-05-07
Package: 

Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[வெள்ளி மே 24, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Unless I misunderstood the code, the line
>>
>>   ;; Check type of ind column (timestamp? text?)
>>   (when (plist-get params :check-ind-type)
>>
>> should be
>>
>>   ;; Check type of ind column (timestamp? text?)
>>   (when (plist-get (cdr type) :check-ind-type)
>>
>> because (1) org-plot/collect-options only adds a select number of
>> keywords to the plist and :check-ind-type is not a part of the select
>> members, and (2) org-plot/gnuplot is never called with a non-nil value
>> for the optional argument PARAMS in tree.
>
> I do not think that it is right.
> AFAIU, the idea is that `org-plot/preset-plot-types' provides some
> default options, but the user can overwrite these defaults in the #+PLOT
> line. What you propose will disregard the values of
>
>  :set :line :map :title :file :ind :timeind :timefmt :textind
>  :deps :labels :xlabels :ylabels :xmin :xmax :ymin :ymax :ticks
>
> if they are customized by user in `org-plot/preset-plot-types'.

I don't follow your conclusion since this change will only affect the
value of :check-ind-type leaving the rest of the settings unaffected.

> I believe that the right way to address the problem will be
> `org-combine-plists' on the (1) org-plot/preset-plot-types; (2)
> org-plot/gnuplot-default-options; (3) #+PLOT lines in the buffer.

Looking at the definition of org-plot/add-options-to-plist and the Info
manual, I am not sure if :check-ind-type is supposed to be customised by
the PLOT line.  It seems to be more of an internal setting.  If you
agree to this, I can change the check to

(when (or (plist-get type :check-ind-type) (plist-get params 
:check-ind-type))

to heed the value of :check-ind-type in org-plot/gnuplot-default-options
(since PARAMS has the default values included earlier in the defun).

>> [...]
>> The other code smell I see is that the function checks for the PLOT line
>> twice.  Once near the beginning of the function, and once just after the
>> cleaning up of hline.  Is this simply an oversight?
>
> It is kinda intentional, but broken.
>
> Historically, users can put #+PLOT lines _after_ the table.
> However, after refactoring org-table.el, this is no longer working.
> See https://list.orgmode.org/orgmode/87o7a0p9ba.fsf@localhost/

OK, I will leave the check in then.

>> Coming to the grid example, the doc-string of org-plot/preset-plot-types
>> options says:
>>
>> - :data-dump - Function to dump the table to a datafile for ease of
>>   use.
>>
>>   Accepts lambda function.  Default lambda body:
>>   (org-plot/gnuplot-to-data table data-file params)
>>
>> but in fact, org-plot/gnuplot passes one more argument to the :data-dump
>> function:
>>
>>   ;; Dump table to datafile
>>   (let ((dump-func (plist-get type :data-dump)))
>> (if dump-func
>>  (funcall dump-func table data-file num-cols params)
>>(org-plot/gnuplot-to-data table data-file params)))
>>
>> but here's the catch: the :data-dump function in the grid option expects
>> the order
>>
>> (lambda (table data-file params _num-cols)
>>
>> which breaks things down the line.  What should be the actual order
>> here?  I looked at the history of those lines briefly using C-x v h but
>> I don't have the time to look into it properly to decide on the actual
>> argument order.
>
> The best order is de-facto calling convention in the code:
>
> (funcall dump-func table data-file num-cols params)
>
> The docstring and the default value should be fixed accordingly.

OK, will do this in a future patch.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[ Sorry, I do not have a better starting point for this.  ]

After updating Latex, I got the message:

Creating LaTeX preview images failed (exit code 252). Please see *Org 
Preview LaTeX Output* for details

which corresponds to

RUNNING: latex -interaction nonstopmode -output-directory /tmp/ 
/home/viz/doc/uni/notes/org-tex-KByBIT.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2025/dev/Debian) 
(preloaded 
format=/home/viz/.cache/org-persist/70/4b50e3-c1f1-4ed9-be3a-acf259bf6d3d-54035ced5d211d19e0eec7be4671c146)
 restricted \write18 enabled.
---! 
/home/viz/.cache/org-persist/70/4b50e3-c1f1-4ed9-be3a-acf259bf6d3d-54035ced5d211d19e0eec7be4671c146.fmt
 made by different executable version, strings are different
(Fatal format file error; I'm stymied)

Would it be possible to give a more informative message for this case?
It is not a showstopper since the error message by pdfTeX is informative
enough but something more informative from Org would be nice regardless.

Re: [ANN] Org mode 9.7 is out

[Visuwesh]

[ஞாயிறு ஜூன் 02, 2024] Juergen Fenn wrote:

> Am 02.06.24 um 22:11 Uhr schrieb Ihor Radchenko:
>> Juergen Fenn  writes:
>>
 Org normally asks you what format to insert, if multiple formats are
 available from clipboard.
>>> ...
>>> Well, the image I used is this one. It was available because I had
>>> downloaded it the other day:
>>>
>>> https://www.europeana.eu/fr/item/2021012/_42FFE0B5C39B7F9819D6D3692B2F4154
>>>
>>> The format is jpg. I have no idea why I get a tiff attachment when I try
>>> to include a local jpg file. Maybe the macOS clipboard offers several
>>> formats and Emacs/Org choses one option because it is offered first or
>>> for some other reason? Or some kind of conversion plays into this on the
>>> system level when copying to Emacs? Or there is something wrong or
>>> unsusual with the jpg file, perhaps it was a tiff file in the first
>>> place, later converted to jpg. I do not know.
>>
>> Even Linux clipboard offers several formats if I copy from browser.
>> After M-x yank-media, I get "Several types, available, choose one:"
>> prompt, with options to choose from png/pbm/xbm/xpm/jpeg format. I
>> guess it is also tiff in your case. Just choose another format in that
>> prompt.
>
> I'm afraid I forgot to mention that I don't get prompted, and I did not
> copy the image from my webbrowser. Rather, I downloaded the jpg file
> over Europeana's proxy from Finnish National Library and then copied
> this one with Command-c in Finder (the macOS file manager) from local
> system SSD. I do not understand how the tiff comes in here. But is is
> there in the data folder Org created. I tried to open it in Preview, I
> even changed the file ending to .jpg, but I cannot open it. The tiff
> file seems to be corrupt.
>

Please tell what is shown in the *Completions* buffer when you do M-x
yank-media-types RET after you copy the image to the clipboard.  I
suspect the problem is with the regexp used to detect the mime-type.

[BUG/FR] org-plot: replot on resize [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

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.


This is more of a FR than a bug but it would be nice to have working
replot-on-resize when the gnuplot terminal is qt, x11, etc.  To have
this functional, the data-file needs to be not deleted.

Emacs  : GNU Emacs 30.0.50 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-05-07
Package: Org mode version 9.7-pre (N/A @ 
/home/viz/lib/emacs/straight/build/org/)

Re: [ANN] Org mode 9.7 is out

[Visuwesh]

[புதன் ஜூன் 05, 2024] Juergen Fenn wrote:

> Am 03.06.24 um 07:06 Uhr schrieb Visuwesh:
>> [ஞாயிறு ஜூன் 02, 2024] Juergen Fenn wrote:
>>> [...]
>>> I'm afraid I forgot to mention that I don't get prompted, and I did not
>>> copy the image from my webbrowser. Rather, I downloaded the jpg file
>>> over Europeana's proxy from Finnish National Library and then copied
>>> this one with Command-c in Finder (the macOS file manager) from local
>>> system SSD. I do not understand how the tiff comes in here. But is is
>>> there in the data folder Org created. I tried to open it in Preview, I
>>> even changed the file ending to .jpg, but I cannot open it. The tiff
>>> file seems to be corrupt.
>>>
>>
>> Please tell what is shown in the *Completions* buffer when you do M-x
>> yank-media-types RET after you copy the image to the clipboard.  I
>> suspect the problem is with the regexp used to detect the mime-type.
>>
>
> Sorry for my late reply. I have updated to Org 9.7.2 in the meanwhile.
>
> M-x yank-media-types RET yields:
>
> Yank type:
> clipboard:image/tiff
> clipboard:STRING
> clipboard:text/plain

I'm afraid there's nothing much we can do.  IIUC, you copy the file from
a file manager, so Org expects clipboard to be something like

Possible completions are:
clipboard:x-special/gnome-copied-files
primary:...

where clipboard:x-special/gnome-copied-files gives

copy
file:///home/viz/tmp/2-gnus_stipple.png

but given there's neither image/jpeg nor a special type like the above,
Org's yank-media copies the image/tiff data (the regexp used by Org
looks for mime-types that match the regexp "image/.*").
I am guessing clipboard:text/plain contains the link to the file, am I
right?  But this feels fragile to rely on.

What happens when you copy multiple images to the clipboard from the
file manager?  Is there a difference in yank-media-types' output?  What
if you copy a non-image file to the clipboard? Say a PDF file.

I don't have access to a Mac but if you can find documentation on how
Finder puts the relevant data in the clipboard, that would be useful.
[ In Linux, you expect the x-special/gnome-copied-files or somesuch
  TARGET.  ]

BTW, we might have similar problems in Windows too.  See this thread in
emacs-devel when yank-media was initially added:
https://yhetil.org/emacs-devel/837ddk9tc8@gnu.org

> M-x yank-media RET still inserts an attachment with a tiff file that I
> cannot open in Preview.

Given the above, I hope you understand why this happens.

HTH.

Re: [ANN] Org mode 9.7 is out

[Visuwesh]

[புதன் ஜூன் 05, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> BTW, we might have similar problems in Windows too.  See this thread in
>> emacs-devel when yank-media was initially added:
>> https://yhetil.org/emacs-devel/837ddk9tc8@gnu.org
>
> Looking at that thread, I see
> https://yhetil.org/emacs-devel/yz18w18vybg7cb%...@idiocy.org/
>
> +  /* Dictionary for looking up NS types from MIME types, and vice versa.  */
> +  typeLookup
> += [NSDictionary
> +   dictionaryWithObjectsAndKeys:
> + @"text/plain",NSPasteboardTypeURL,
> +#if NS_USE_NSPasteboardTypeFileURL
> + @"text/plain",NSPasteboardTypeFileURL,
> +#else
> + @"text/plain",NSFilenamesPboardType,
> +#endif
> + @"text/html", NSPasteboardTypeHTML,
> + @"text/plain",NSPasteboardTypeMultipleTextSelection,
> + @"application/pdf",   NSPasteboardTypePDF,
> + @"image/png", NSPasteboardTypePNG,
> + @"application/rtf",   NSPasteboardTypeRTF,
> + @"application/rtfd",  NSPasteboardTypeRTFD,
> + @"STRING",NSPasteboardTypeString,
> + @"text/plain",NSPasteboardTypeTabularText,
> + @"image/tiff",NSPasteboardTypeTIFF,
> + nil];
>
> For images, only image/png and image/tiff are listed for some reason. No
> jpeg. (and no jpeg in the spec at
> https://developer.apple.com/documentation/appkit/nspasteboardtype)
>
> I suspect that image/tiff entry in the clipboard is garbled by Emacs.
> We may want to report this as a bug.
>
> We may also need to request a feature to support clipboard on MacOS
> better. Using the same example image.

Thanks for the analysis.  Given that Alan says GNUStep cannot handle
non-text clipboard items, I cannot propose anything myself.  It would be
nice if a Mac user can write a report and send it to the Emacs
developers.  Perhaps Juergen can do it?

There was a bug report about yank-media failing in Mac yesterday or
thereabouts so I think the clipboard situation in Mac has a lot to
improve.  Hopefully with Org's yank-media support the situation will
improve.

Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

Ping.  Can you answer my questions, Ihor, so that I may prepare a patch
accordingly?

[வெள்ளி மே 24, 2024] Visuwesh wrote:

> [வெள்ளி மே 24, 2024] Ihor Radchenko wrote:
>
>> Visuwesh  writes:
>>
>>> Unless I misunderstood the code, the line
>>>
>>>   ;; Check type of ind column (timestamp? text?)
>>>   (when (plist-get params :check-ind-type)
>>>
>>> should be
>>>
>>>   ;; Check type of ind column (timestamp? text?)
>>>   (when (plist-get (cdr type) :check-ind-type)
>>>
>>> because (1) org-plot/collect-options only adds a select number of
>>> keywords to the plist and :check-ind-type is not a part of the select
>>> members, and (2) org-plot/gnuplot is never called with a non-nil value
>>> for the optional argument PARAMS in tree.
>>
>> I do not think that it is right.
>> AFAIU, the idea is that `org-plot/preset-plot-types' provides some
>> default options, but the user can overwrite these defaults in the #+PLOT
>> line. What you propose will disregard the values of
>>
>>  :set :line :map :title :file :ind :timeind :timefmt :textind
>>  :deps :labels :xlabels :ylabels :xmin :xmax :ymin :ymax :ticks
>>
>> if they are customized by user in `org-plot/preset-plot-types'.
>
> I don't follow your conclusion since this change will only affect the
> value of :check-ind-type so how would it affect the rest of the
> settings?
>
>> I believe that the right way to address the problem will be
>> `org-combine-plists' on the (1) org-plot/preset-plot-types; (2)
>> org-plot/gnuplot-default-options; (3) #+PLOT lines in the buffer.
>
> Looking at the definition of org-plot/add-options-to-plist and the Info
> manual, I am not sure if :check-ind-type is supposed to be customised by
> the PLOT line.  It seems to be more of an internal setting.  If you
> agree to this, I can change the check to
>
> (when (or (plist-get type :check-ind-type) (plist-get params 
> :check-ind-type))
>
> to heed the value of :check-ind-type in org-plot/gnuplot-default-options
> (since PARAMS has the default values included earlier in the defun).
>
>>> [...]
>>> The other code smell I see is that the function checks for the PLOT line
>>> twice.  Once near the beginning of the function, and once just after the
>>> cleaning up of hline.  Is this simply an oversight?
>>
>> It is kinda intentional, but broken.
>>
>> Historically, users can put #+PLOT lines _after_ the table.
>> However, after refactoring org-table.el, this is no longer working.
>> See https://list.orgmode.org/orgmode/87o7a0p9ba.fsf@localhost/
>
> OK, I will leave the check in then.
>
>>> Coming to the grid example, the doc-string of org-plot/preset-plot-types
>>> options says:
>>>
>>> - :data-dump - Function to dump the table to a datafile for ease of
>>>   use.
>>>
>>>   Accepts lambda function.  Default lambda body:
>>>   (org-plot/gnuplot-to-data table data-file params)
>>>
>>> but in fact, org-plot/gnuplot passes one more argument to the :data-dump
>>> function:
>>>
>>>   ;; Dump table to datafile
>>>   (let ((dump-func (plist-get type :data-dump)))
>>> (if dump-func
>>> (funcall dump-func table data-file num-cols params)
>>>   (org-plot/gnuplot-to-data table data-file params)))
>>>
>>> but here's the catch: the :data-dump function in the grid option expects
>>> the order
>>>
>>> (lambda (table data-file params _num-cols)
>>>
>>> which breaks things down the line.  What should be the actual order
>>> here?  I looked at the history of those lines briefly using C-x v h but
>>> I don't have the time to look into it properly to decide on the actual
>>> argument order.
>>
>> The best order is de-facto calling convention in the code:
>>
>> (funcall dump-func table data-file num-cols params)
>>
>> The docstring and the default value should be fixed accordingly.
>
> OK, will do this in a future patch.

Re: [BUG/FR] org-plot: replot on resize [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[செவ்வாய் ஜூன் 04, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> This is more of a FR than a bug but it would be nice to have working
>> replot-on-resize when the gnuplot terminal is qt, x11, etc.  To have
>> this functional, the data-file needs to be not deleted.
>
> It should be doable.
> We can simply use `org-babel-temp-stable-file' and leave cleaning up to
> `org-babel-remove-temporary-stable-directory'.

The data writing functions themselves require a filename so the file
content cannot be used as DATA to org-babel-temp-stable-file.  What
should be DATA instead? (list table params)?

Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[புதன் ஜூன் 12, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> I do not think that it is right.
>>> AFAIU, the idea is that `org-plot/preset-plot-types' provides some
>>> default options, but the user can overwrite these defaults in the #+PLOT
>>> line. What you propose will disregard the values of
>>>
>>>  :set :line :map :title :file :ind :timeind :timefmt :textind
>>>  :deps :labels :xlabels :ylabels :xmin :xmax :ymin :ymax :ticks
>>>
>>> if they are customized by user in `org-plot/preset-plot-types'.
>>
>> I don't follow your conclusion since this change will only affect the
>> value of :check-ind-type leaving the rest of the settings unaffected.
>
> My point is that we will eventually need to merge TYPE and PARAMS to
> fix another bug - `org-plot/preset-plot-types' options like :set, :line,
> etc being ignored. So, instead of patching the way you proposed, we can
> merge TYPE and PARAMS into PARAMS, making the existing (plist-get params
> :check-ind-type) working.
>
> In other words, org-plot's handling of parameters is very broken
> now. There is more than one bug lurking there, and it may be more
> productive to fix things together.
>
> You solution will, of course, work, but only for this specific bug you
> described; not for other.

OK, thanks for the explanation.  I was unaware of the issue as I didn't
read the code closely enough.  What about the attached patch?

>From 2a153a5bc015b0e970ecde39fd2edbb515261349 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Thu, 13 Jun 2024 12:33:49 +0530
Subject: [PATCH] org-plot: Respect parameters given in
 `org-plot/preset-plot-types'

* lisp/org-plot.el (org-plot/preset-plot-types): Fix docstring and
correct the lambda argument order for the 'grid' plot type.
(org-plot/gnuplot): Merge the parameters given in
`org-plot/preset-plot-types' and the #+PLOT line to ensure the former
is respected everywhere.

Reported-by: Visuwesh 
Link: https://orgmode.org/list/87edbu4kdh@gmail.com
---
 lisp/org-plot.el | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 283d993..6d53830 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -349,7 +349,7 @@ (defcustom org-plot/preset-plot-types
 (grid :plot-cmd "splot"
 	  :plot-pre (lambda (_table _data-file _num-cols params _plot-str)
 		  (if (plist-get params :map) "set pm3d map" "set map"))
-	  :data-dump (lambda (table data-file params _num-cols)
+	  :data-dump (lambda (table data-file _num-cols params)
 		   (let ((y-labels (org-plot/gnuplot-to-grid-data
 	table data-file params)))
 			 (when y-labels (plist-put params :ylabels y-labels
@@ -391,8 +391,8 @@ (defcustom org-plot/preset-plot-types
 - :data-dump - Function to dump the table to a datafile for ease of
   use.
 
-  Accepts lambda function.  Default lambda body:
-  (org-plot/gnuplot-to-data table data-file params)
+  Accepts lambda function with arguments:
+  (table data-file num-cols params)
 
 - :plot-pre - Gnuplot code to be inserted early into the script, just
   after term and output have been set.
@@ -679,8 +679,8 @@ (defun org-plot/gnuplot (&optional params)
 		tbl))
 	   (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table)
 			   (nth 0 table
-	   (type (assoc (plist-get params :plot-type)
-			org-plot/preset-plot-types))
+	   (type (cdr (assoc (plist-get params :plot-type)
+			 org-plot/preset-plot-types)))
gnuplot-script)
 
   (unless type
@@ -695,6 +695,7 @@ (defun org-plot/gnuplot (&optional params)
   (save-excursion (while (and (equal 0 (forward-line -1))
   (looking-at "[[:space:]]*#\\+"))
 			(setf params (org-plot/collect-options params
+  (setq params (org-combine-plists type params))
   ;; Dump table to datafile
   (let ((dump-func (plist-get type :data-dump)))
 (if dump-func
-- 
2.43.0

Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[வியாழன் ஜூன் 13, 2024] Visuwesh wrote:

> [புதன் ஜூன் 12, 2024] Ihor Radchenko wrote:
>
>> Visuwesh  writes:
>>
>>>> I do not think that it is right.
>>>> AFAIU, the idea is that `org-plot/preset-plot-types' provides some
>>>> default options, but the user can overwrite these defaults in the #+PLOT
>>>> line. What you propose will disregard the values of
>>>>
>>>>  :set :line :map :title :file :ind :timeind :timefmt :textind
>>>>  :deps :labels :xlabels :ylabels :xmin :xmax :ymin :ymax :ticks
>>>>
>>>> if they are customized by user in `org-plot/preset-plot-types'.
>>>
>>> I don't follow your conclusion since this change will only affect the
>>> value of :check-ind-type leaving the rest of the settings unaffected.
>>
>> My point is that we will eventually need to merge TYPE and PARAMS to
>> fix another bug - `org-plot/preset-plot-types' options like :set, :line,
>> etc being ignored. So, instead of patching the way you proposed, we can
>> merge TYPE and PARAMS into PARAMS, making the existing (plist-get params
>> :check-ind-type) working.
>>
>> In other words, org-plot's handling of parameters is very broken
>> now. There is more than one bug lurking there, and it may be more
>> productive to fix things together.
>>
>> You solution will, of course, work, but only for this specific bug you
>> described; not for other.
>
> OK, thanks for the explanation.  I was unaware of the issue as I didn't
> read the code closely enough.  What about the attached patch?

Sorry for the noise, I copied the wrong link in the commit message.
Please see attached instead.

>From 2a153a5bc015b0e970ecde39fd2edbb515261349 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Thu, 13 Jun 2024 12:33:49 +0530
Subject: [PATCH] org-plot: Respect parameters given in
 `org-plot/preset-plot-types'

* lisp/org-plot.el (org-plot/preset-plot-types): Fix docstring and
correct the lambda argument order for the 'grid' plot type.
(org-plot/gnuplot): Merge the parameters given in
`org-plot/preset-plot-types' and the #+PLOT line to ensure the former
is respected everywhere.

Reported-by: Visuwesh 
Link: https://orgmode.org/list/87cypbjw50@gmail.com
---
 lisp/org-plot.el | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 283d993..6d53830 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -349,7 +349,7 @@ (defcustom org-plot/preset-plot-types
 (grid :plot-cmd "splot"
 	  :plot-pre (lambda (_table _data-file _num-cols params _plot-str)
 		  (if (plist-get params :map) "set pm3d map" "set map"))
-	  :data-dump (lambda (table data-file params _num-cols)
+	  :data-dump (lambda (table data-file _num-cols params)
 		   (let ((y-labels (org-plot/gnuplot-to-grid-data
 	table data-file params)))
 			 (when y-labels (plist-put params :ylabels y-labels
@@ -391,8 +391,8 @@ (defcustom org-plot/preset-plot-types
 - :data-dump - Function to dump the table to a datafile for ease of
   use.

-  Accepts lambda function.  Default lambda body:
-  (org-plot/gnuplot-to-data table data-file params)
+  Accepts lambda function with arguments:
+  (table data-file num-cols params)

 - :plot-pre - Gnuplot code to be inserted early into the script, just
   after term and output have been set.
@@ -679,8 +679,8 @@ (defun org-plot/gnuplot (&optional params)
 		tbl))
 	   (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table)
 			   (nth 0 table
-	   (type (assoc (plist-get params :plot-type)
-			org-plot/preset-plot-types))
+	   (type (cdr (assoc (plist-get params :plot-type)
+			 org-plot/preset-plot-types)))
gnuplot-script)

   (unless type
@@ -695,6 +695,7 @@ (defun org-plot/gnuplot (&optional params)
   (save-excursion (while (and (equal 0 (forward-line -1))
   (looking-at "[[:space:]]*#\\+"))
 			(setf params (org-plot/collect-options params
+  (setq params (org-combine-plists type params))
   ;; Dump table to datafile
   (let ((dump-func (plist-get type :data-dump)))
 (if dump-func
--
2.43.0

Re: [BUG/FR] org-plot: replot on resize [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[வெள்ளி ஜூன் 14, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>>> This is more of a FR than a bug but it would be nice to have working
>>>> replot-on-resize when the gnuplot terminal is qt, x11, etc.  To have
>>>> this functional, the data-file needs to be not deleted.
>>>
>>> It should be doable.
>>> We can simply use `org-babel-temp-stable-file' and leave cleaning up to
>>> `org-babel-remove-temporary-stable-directory'.
>>
>> The data writing functions themselves require a filename so the file
>> content cannot be used as DATA to org-babel-temp-stable-file.  What
>> should be DATA instead? (list table params)?
>
> All the things that contribute to what is written to the data file:
>
> ;; Dump table to datafile
>   (let ((dump-func (plist-get type :data-dump)))
> (if dump-func
>   (funcall dump-func table data-file num-cols params)
> (org-plot/gnuplot-to-data table data-file params)))
>
> So, you can set DATA to (list (or dump-func 'org-plot/gnuplot-to-data) table 
> num-cols params)

Done in the attached patch.

>From 0b81eb9da94cdf311bf54748b03d33a550d431cd Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sat, 15 Jun 2024 10:25:19 +0530
Subject: [PATCH] org-plot: Make data-file stable for replot-on-resize

* lisp/org-plot.el (org-plot/gnuplot): Use a stable data-file to make
replot-on-resize in GUI terminals work.

Reported-by: Visuwesh 
Link: https://orgmode.org/list/87mso7sl6g@gmail.com
---
 lisp/org-plot.el | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 283d993..8adfbc8 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -662,8 +662,7 @@ (defun org-plot/gnuplot (&optional params)
   (looking-at "[[:space:]]*#\\+"))
 (setf params (org-plot/collect-options params
 ;; collect table and table information
-(let* ((data-file (make-temp-file "org-plot"))
-   (table (let ((tbl (save-excursion
+(let* ((table (let ((tbl (save-excursion
(org-plot/goto-nearest-table)
(org-table-to-lisp
 		(when (pcase (plist-get params :transpose)
@@ -681,12 +680,11 @@ (defun org-plot/gnuplot (&optional params)
 			   (nth 0 table
 	   (type (assoc (plist-get params :plot-type)
 			org-plot/preset-plot-types))
-   gnuplot-script)
+   gnuplot-script data-file)
 
   (unless type
 	(user-error "Org-plot type `%s' is undefined" (plist-get params :plot-type)))
 
-  (run-with-idle-timer 0.1 nil #'delete-file data-file)
   (when (eq (cadr table) 'hline)
 	(setf params
 	  (plist-put params :labels (car table))) ; headers to labels
@@ -696,7 +694,11 @@ (defun org-plot/gnuplot (&optional params)
   (looking-at "[[:space:]]*#\\+"))
 			(setf params (org-plot/collect-options params
   ;; Dump table to datafile
-  (let ((dump-func (plist-get type :data-dump)))
+  (let* ((dump-func (plist-get type :data-dump)))
+(setq data-file (org-babel-temp-stable-file
+ (list (or dump-func 'org-plot/gnuplot-to-data)
+   table num-cols params)
+ "org-plot"))
 (if dump-func
 	(funcall dump-func table data-file num-cols params)
 	  (org-plot/gnuplot-to-data table data-file params)))
-- 
2.43.0

Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[சனி ஜூன் 15, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Sorry for the noise, I copied the wrong link in the commit message.
>> Please see attached instead.
>
> Thanks!
> I have some comments.
>
>> -   (type (assoc (plist-get params :plot-type)
>> -org-plot/preset-plot-types))
>> +   (type (cdr (assoc (plist-get params :plot-type)
>> + org-plot/preset-plot-types)))
>> gnuplot-script)
>
> This may break the existing customization.
> Later in the function, TYPE is used as an argument for
> `org-plot/gnuplot-term-extra' and `org-plot/gnuplot-script-preamble'.
> Some users may have these two custom options adjusted to the older
> calling convention.
>
> To not break things, we should pass the full `assoc' to these functions.

If you meant org-plot/gnuplot-script eventually calling these functions,
then I don't see how the above change will break things.  Even in
org-plot/gnuplot-script, TYPE passed to both these user options are

(let* ((type-name (plist-get params :plot-type))
   (type (cdr (assoc type-name org-plot/preset-plot-types

so there should be no harm done by the above change since TYPE is not an
argument taken by org-plot/gnuplot-script.

> Also, while you are at it, may your please clarify what TYPE means in
> the docstrings of `org-plot/gnuplot-term-extra' and
> `org-plot/gnuplot-script-preamble'?

OK.

>>  (setf params (org-plot/collect-options params
>> +  (setq params (org-combine-plists type params))
>
> May you also drop a short comment in the code that explains what this
> line does?

I will send an updated patch once my confusion is cleared.

Re: [BUG/FR] org-plot: replot on resize [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[சனி ஜூன் 15, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> So, you can set DATA to (list (or dump-func 'org-plot/gnuplot-to-data) 
>>> table num-cols params)
>>
>> Done in the attached patch.
>
> Thanks!
>
>>;; Dump table to datafile
>> -  (let ((dump-func (plist-get type :data-dump)))
>> +  (let* ((dump-func (plist-get type :data-dump)))
>
> Why let*?

Oops, leftover change from a previous iteration of the patch.  Now
fixed.

>> +(setq data-file (org-babel-temp-stable-file
>> + (list (or dump-func 'org-plot/gnuplot-to-data)
>> +   table num-cols params)
>> + "org-plot"))
>
> Please add in-code comment explaining why we need 
> `org-babel-temp-stable-file'.

Now done.

>From a922946b3965e117dc3bbbe5a4f3c67dcc832d68 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sat, 15 Jun 2024 10:25:19 +0530
Subject: [PATCH] org-plot: Make data-file stable for replot-on-resize

* lisp/org-plot.el (org-plot/gnuplot): Use a stable data-file to make
replot-on-resize in GUI terminals work.

Reported-by: Visuwesh 
Link: https://orgmode.org/list/87mso7sl6g@gmail.com
---
 lisp/org-plot.el | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 283d993..83483b2 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -662,8 +662,7 @@ (defun org-plot/gnuplot (&optional params)
   (looking-at "[[:space:]]*#\\+"))
 (setf params (org-plot/collect-options params
 ;; collect table and table information
-(let* ((data-file (make-temp-file "org-plot"))
-   (table (let ((tbl (save-excursion
+(let* ((table (let ((tbl (save-excursion
(org-plot/goto-nearest-table)
(org-table-to-lisp
 		(when (pcase (plist-get params :transpose)
@@ -681,12 +680,11 @@ (defun org-plot/gnuplot (&optional params)
 			   (nth 0 table
 	   (type (assoc (plist-get params :plot-type)
 			org-plot/preset-plot-types))
-   gnuplot-script)
+   gnuplot-script data-file)
 
   (unless type
 	(user-error "Org-plot type `%s' is undefined" (plist-get params :plot-type)))
 
-  (run-with-idle-timer 0.1 nil #'delete-file data-file)
   (when (eq (cadr table) 'hline)
 	(setf params
 	  (plist-put params :labels (car table))) ; headers to labels
@@ -697,6 +695,12 @@ (defun org-plot/gnuplot (&optional params)
 			(setf params (org-plot/collect-options params
   ;; Dump table to datafile
   (let ((dump-func (plist-get type :data-dump)))
+;; Use a stable temporary file to ensure that 'replot' upon
+;; resizing a GUI gnuplot terminal window works.
+(setq data-file (org-babel-temp-stable-file
+ (list (or dump-func 'org-plot/gnuplot-to-data)
+   table num-cols params)
+ "org-plot"))
 (if dump-func
 	(funcall dump-func table data-file num-cols params)
 	  (org-plot/gnuplot-to-data table data-file params)))
-- 
2.43.0

Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[திங்கள் ஜூன் 17, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>>> - (type (assoc (plist-get params :plot-type)
>>>> -  org-plot/preset-plot-types))
>>>> + (type (cdr (assoc (plist-get params :plot-type)
>>>> +   org-plot/preset-plot-types)))
>>>> gnuplot-script)
>>>
>>> This may break the existing customization.
>>> Later in the function, TYPE is used as an argument for
>>> `org-plot/gnuplot-term-extra' and `org-plot/gnuplot-script-preamble'.
>>> Some users may have these two custom options adjusted to the older
>>> calling convention.
>>>
>>> To not break things, we should pass the full `assoc' to these functions.
>>
>> If you meant org-plot/gnuplot-script eventually calling these functions,
>> then I don't see how the above change will break things.  Even in
>> org-plot/gnuplot-script, TYPE passed to both these user options are
>>
>> (let* ((type-name (plist-get params :plot-type))
>>(type (cdr (assoc type-name org-plot/preset-plot-types
>>
>> so there should be no harm done by the above change since TYPE is not an
>> argument taken by org-plot/gnuplot-script.
>
> Agree. I accidentally moved away from the function that is actually
> being changed to org-plot/gnuplot-script that has nothing to do with
> TYPE binding you are changing in the patch.
>
> So, your code is ok here.

Thanks, so please find attached.

>From 9755ccb636ab8e1d855bbc386bc6bab2203a2cd5 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Tue, 18 Jun 2024 10:39:27 +0530
Subject: [PATCH] org-plot: Respect parameters given in
 `org-plot/preset-plot-types'

* org-plot.el (org-plot/gnuplot-script-preamble)
(org-plot/gnuplot-term-extra): Explain what "plot type" means.
(org-plot/preset-plot-types): Fix docstring and correct the lambda
argument order for the 'grid' plot type.
(org-plot/gnuplot): Merge the parameters given in
`org-plot/preset-plot-types' and the #+PLOT line to ensure the former
is respected everywhere.

Reported-by: Visuwesh 
Link: https://orgmode.org/list/87cypbjw50@gmail.com
---
 lisp/org-plot.el | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 83483b2..b436613 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -302,9 +302,10 @@ (defgroup org-plot nil
 (defcustom org-plot/gnuplot-script-preamble ""
   "String of function to be inserted before the gnuplot plot command is run.
 
-Note that this is in addition to, not instead of other content generated in
-`org-plot/gnuplot-script'.  If a function, it is called with the plot type as
-the argument, and must return a string to be used."
+Note that this is in addition to, not instead of other content generated
+in `org-plot/gnuplot-script'.  If a function, it is called with the
+parameters used by the current plot type (see
+`org-plot/preset-plot-types'), and must return a string to be used."
   :group 'org-plot
   :type '(choice string function))
 
@@ -349,7 +350,7 @@ (defcustom org-plot/preset-plot-types
 (grid :plot-cmd "splot"
 	  :plot-pre (lambda (_table _data-file _num-cols params _plot-str)
 		  (if (plist-get params :map) "set pm3d map" "set map"))
-	  :data-dump (lambda (table data-file params _num-cols)
+	  :data-dump (lambda (table data-file _num-cols params)
 		   (let ((y-labels (org-plot/gnuplot-to-grid-data
 	table data-file params)))
 			 (when y-labels (plist-put params :ylabels y-labels
@@ -391,8 +392,8 @@ (defcustom org-plot/preset-plot-types
 - :data-dump - Function to dump the table to a datafile for ease of
   use.
 
-  Accepts lambda function.  Default lambda body:
-  (org-plot/gnuplot-to-data table data-file params)
+  Accepts function with arguments:
+  (table data-file num-cols params)
 
 - :plot-pre - Gnuplot code to be inserted early into the script, just
   after term and output have been set.
@@ -541,7 +542,8 @@ (defcustom org-plot/gnuplot-term-extra ""
   "String or function which provides the extra term options.
 E.g. a value of \"size 1050,650\" would cause
 \"set term ... size 1050,650\" to be used.
-If a function, it is called with the plot type as the argument."
+If a function, it is called with the parameters used by the current plot
+type, see `org-plot/preset-plot-types'."
   :group 'org-plot
   :type '(choice string function))
 
@@ -678,8 +680,8 @@ (defun org-plot/gnuplot (&optional params)
 		tbl))
 	   (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table)
 			   (nth 0 table
-	   (type (assoc (plist-get pa

Re: Cannot yank media when image come from Gnome screenshot

[Visuwesh]

[வெள்ளி ஜூலை 26, 2024] Ihor Radchenko wrote:

> Ihor Radchenko  writes:
>
>> ...
>> The error is originating from Emacs itself, not from Org mode.
>
> Sébastien reporting this upstream as bug#72254.
> The bug has been fixed and will become available in Emacs 30 release.
> The bug fix involved modifying Emacs C code, so we cannot do anything
> more to work around the problem on Org side.

Perhaps, you can have the patch posted by Robert as a workaround for
Emacs<30?  Patch is in https://yhetil.org/87wmlb8djy@gmail.com, and
Sébastien confirmed that it worked.

Re: [BUG] org-persist-write-all is slow because of use of pp [9.8-pre (release_9.7.8-713-g62cbac @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[சனி ஆகஸ்ட் 10, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> I am using the async LaTeX preview branch and org-persist-write-all
>> takes a lot of time to finish executing due to the use of pp when saving
>> the index file.  Changing org-persist-write:index to not pass a non-nil
>> PP argument to org-persist--write-elisp-file changes the execution time
>> of org-persist-write-all from 62 secs to just 8 secs.  For reference,
>>
>> (length org-persist--index) ;; ⇒ 1504
>>
>> I have attached the profiler report for org-persist--index of much
>> smaller length but if required I can reproduce a report for the full one
>> too.
>
> So much for the idea of readable index file.

It is unfortunate, indeed, since the pp version of the file is really
handy when looking into org-persist issues.  Though, I must mention that
the slowness reported in OP is compounded by my fairly aggressive CPU
governor settings (in hopes of improving battery life).

> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f9351456e7

Thanks for the quick fix!

[PATCH] Add repeat-map for navigation commands

[Visuwesh]

Ihor says:
> - visuwesh asked whether Org mode could have repeat maps for outline
>   navigation in Org mode (C-c C-n n n p n p ..., C-c C-f b f...)
>   - Such functionality has been added to outline-mode upstream
>   - Patches for Org mode equivalent are indeed welcome
> - They do not even have to be the past weekend after the meetup
>   Any time will do ;)
>   - For now, we at least have speed keys as an alternative
> https://orgmode.org/manual/Speed-Keys.html

Sorry for the month long delay.  I was busy with uni stuff so could not
find the time to invest into this properly.  I've attached a patch which
adds a repeat-map to org-keys.el but this pointed out that org-mode
lacks a org-up-heading command so I've resorted to using
outline-up-heading.

>From 8b980efcd9497e395f4d82a1304267ae4426b00d Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 9 Sep 2024 19:46:47 +0530
Subject: [PATCH] Add repeat-mode keymap for navigation commands

* org-keys.el (org-navigation-repeat-map): Add repeat-map to make
navigation easier when repeat-mode is turned on.
---
 lisp/org-keys.el | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 1daedaae8..ec32d212d 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -462,6 +462,25 @@ (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontrolleft)
 (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontrolup)
 (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontroldown)
 
+;;; Repeat-mode map.
+(defvar org-navigation-repeat-map (make-sparse-keymap)
+  "Repeat keymap for navigation commands.")
+(org-defkey org-navigation-repeat-map (kbd "b") #'org-backward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "C-b") #'org-backward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "f") #'org-forward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "C-f") #'org-forward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "n") #'org-next-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "C-n") #'org-next-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "p") #'org-previous-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "C-p") #'org-previous-visible-heading)
+(declare-function outline-up-heading "outline" (arg &optional invisible-ok))
+(org-defkey org-navigation-repeat-map (kbd "u") #'outline-up-heading)
+(org-defkey org-navigation-repeat-map (kbd "C-u") #'outline-up-heading)
+(map-keymap
+ (lambda (_key cmd)
+   (put cmd 'repeat-map 'org-navigation-repeat-map))
+ org-navigation-repeat-map)
+
  Extra keys for TTY access.
 
 ;;  We only set them when really needed because otherwise the
-- 
2.45.2


Emacs  : GNU Emacs 31.0.50 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-08-15
Package: Org mode version 9.8-pre (release_9.7.8-713-g62cbac @ 
/home/viz/lib/emacs/straight/build/org/)

Re: [PATCH] Add repeat-map for navigation commands

[Visuwesh]

[திங்கள் செப்டம்பர் 09, 2024] Ihor Radchenko wrote:

>> ... I've attached a patch which
>> adds a repeat-map to org-keys.el but this pointed out that org-mode
>> lacks a org-up-heading command so I've resorted to using
>> outline-up-heading.
>
> It is not the only one. But outline version should also work.

I just realised that we would need a few defalias-es if we are going to
have outline commands in the repeat-map to avoid overriding
outline-navigation-repeat-map when one uses outline-up-heading in
outline-minor-mode or outline-mode.

[திங்கள் செப்டம்பர் 09, 2024] Karthik Chikmagalur wrote:

>>> From 8b980efcd9497e395f4d82a1304267ae4426b00d Mon Sep 17 00:00:00 2001
>>> From: Visuwesh 
>>> Date: Mon, 9 Sep 2024 19:46:47 +0530
>>> Subject: [PATCH] Add repeat-mode keymap for navigation commands
>>>
>>> * org-keys.el (org-navigation-repeat-map): Add repeat-map to make
>>> navigation easier when repeat-mode is turned on.
>>
>> May you also add a news entry?
>> Ideally, we should also document this in the manual.

I will add this along with the above in the next patch.

> Do you think it makes sense to add repeat-maps for other next/previous
> commands in Org, such as org-next-link and org-previous-link?  I've been
> using this for a while (they don't use defvar-keymap as I wrote them a
> while ago):
>
> (defvar org-link-navigation-repeat-map
>   (let ((map (make-sparse-keymap)))
> (define-key map (kbd "n") #'org-next-link)
> (define-key map (kbd "p") #'org-previous-link)
> (define-key map (kbd "v") #'org-link-preview) ;toggle preview for link at 
> point
> map))
>
> (map-keymap
>  (lambda (_ cmd)
>(put cmd 'repeat-map 'org-link-navigation-repeat-map))
>  org-link-navigation-repeat-map)
>
> (defvar org-block-navigation-repeat-map
>   (let ((map (make-sparse-keymap)))
> (define-key map (kbd "f") #'org-next-block)
> (define-key map (kbd "b") #'org-previous-block)
> map))
>
> (put 'org-next-block 'repeat-map 'org-block-navigation-repeat-map)
> (put 'org-previous-block 'repeat-map 'org-block-navigation-repeat-map)

I also have a repeat-map for org-todo since I have
org-support-shift-select to t which makes changing the TODO when in the
body text quite inconvenient.

BTW, should we add C-n and friends to org-navigation-repeat-map or just
have n, p, etc.?  I personally find C-n in the repeat-map disruptive
since I usually want to move the cursor after jumping to a specific
heading, in which case C-n not being next-line is annoying.

Re: [PATCH] Add repeat-map for navigation commands

[Visuwesh]

[ஞாயிறு செப்டம்பர் 15, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> BTW, should we add C-n and friends to org-navigation-repeat-map or just
>> have n, p, etc.?  I personally find C-n in the repeat-map disruptive
>> since I usually want to move the cursor after jumping to a specific
>> heading, in which case C-n not being next-line is annoying.
>
> +1 for less disruptive :)

Please find attached.  I tried my best to write the manual entry but it
still reads awkward.

>From c66ff969e23d0d29746941383e5afa54d0e9e060 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 9 Sep 2024 19:46:47 +0530
Subject: [PATCH] Add repeat-mode keymap for navigation commands

* lisp/org-keys.el (org-up-heading): Add new alias for
outline-up-heading.
(org-mode-map): Remap outline-up-heading to the new alias.
(org-navigation-repeat-map, org-link-navigation-repeat-map)
(org-block-navigation-repeat-map): Add new repeat-maps to make
navigation easier.
* doc/org-manual.org (Repeating commands): Document the new feature in the manual.
* etc/ORG-NEWS (Some navigation commands can now be repeated): Announce it.
---
 doc/org-manual.org | 14 ++
 etc/ORG-NEWS   |  6 ++
 lisp/org-keys.el   | 34 ++
 3 files changed, 54 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 9365c66b1..254764c31 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21657,6 +21657,20 @@ of ~org-yank-dnd-method~.  Image files pasted this way also respect
 the value of ~org-yank-image-save-method~ when the action to perform
 is =attach=.
 
+** Repeating commands
+:PROPERTIES:
+:DESCRIPTION: Repeating navigation commands
+:END:
+
+#+cindex: repeat-mode, org-mode
+#+cindex: repeating navigation commands
+When ~repeat-mode~ is turned on, headline motion commands, link and
+block navigation commands by only pressing a single key.  For example,
+when navigation to the next headline using {{{kbd(C-c C-n)}}}, a
+repeat map is activated that lets you quickly execute headline motion
+commands.  When a key not in the map is pressed, it exits ~repeat-mode~
+and the command corresponding to the key is executed.
+
 * Hacking
 :PROPERTIES:
 :DESCRIPTION: How to hack your way around.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 392788055..8acc2f6b4 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -77,6 +77,12 @@ You can now create links to =shortdoc= documentation groups for Emacs
 Lisp functions (see =M-x shortdoc-display-group=).  Requires Emacs 28
 or newer.
 
+*** Some navigation commands can now be repeated
+
+When ~repeat-mode~ is turned on, certain navigation can be repeated.
+These include the headline navigation commands, ~org-next-link~ and
+~org-previous-link~, and ~org-next-block~ and ~org-previous-block~.
+
 ** New and changed options
 
 # Chanes deadling with changing default values of customizations,
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 1daedaae8..f6de753af 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -232,6 +232,7 @@ (declare-function org-up-element "org" ())
 (declare-function org-update-statistics-cookies "org" (all))
 (declare-function org-yank "org" (&optional arg))
 (declare-function orgtbl-ascii-plot "org-table" (&optional ask))
+(declare-function outline-up-heading "outline" (arg &optional invisible-ok))
 
 
 
@@ -409,6 +410,8 @@ (define-key org-mode-map [remap outline-next-visible-heading]
 (define-key org-mode-map [remap outline-previous-visible-heading]
   #'org-previous-visible-heading)
 (define-key org-mode-map [remap outline-show-children] #'org-fold-show-children)
+(defalias 'org-up-heading #'outline-up-heading)
+(define-key org-mode-map [remap outline-up-heading] #'org-up-heading)
 
  Make `C-c C-x' a prefix key
 (org-defkey org-mode-map (kbd "C-c C-x") (make-sparse-keymap))
@@ -462,6 +465,37 @@ (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontrolleft)
 (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontrolup)
 (org-defkey org-mode-map (kbd "C-S-") #'org-shiftcontroldown)
 
+;;; Repeat-mode map.
+(defvar org-navigation-repeat-map (make-sparse-keymap)
+  "Repeat keymap for navigation commands.")
+(org-defkey org-navigation-repeat-map (kbd "b") #'org-backward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "f") #'org-forward-heading-same-level)
+(org-defkey org-navigation-repeat-map (kbd "n") #'org-next-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "p") #'org-previous-visible-heading)
+(org-defkey org-navigation-repeat-map (kbd "u") #'org-up-heading)
+(map-keymap
+ (lambda (_key cmd)
+   (put cmd 'repeat-map 'org-navigation-repeat-map))
+ org-navigation-repeat-map)
+
+(defvar org-link-navigation-repeat-map (make-sparse

Re: [FR] yank media: allow customization of absolute path a filter for type candidates

[Visuwesh]

[திங்கள் செப்டம்பர் 16, 2024] pinmacs wrote:

> Hi,
>
> So I was using org-download, and I would like to replace it entirely 
> with yank-media
>
> and what I am missisng is:
>
> 1. do a variable for selecting absolute path: to be able to have a file 
> link that works with absolute path; and the reason is that being 
> relative, this, does not combine good when you move your latex export 
> somewhere else (in my case, I usually move it to /tmp/, and from there I 
> decide when I want to save something persistently), hence it fails, and 
> I got tired on fixing the links, in fact, the absolute path sometimes is 
> smaller than the relative one 
> =file:/tmp/clipboard-20240916T013308.png]]= vs 
> =[[file:../../../tmp/clipboard-20240916T011913.png]]=

This can be done in the org side.  I guess adding another defcustom
would be the way to go? I don't see how it is possible to make
org-yank-image-save-method accept another option.

> 2. do a variable that allow a list that would filter and reduce the type 
> candidates of yank-media. In org-download, everything was png so I was 
> not having the "Several types available, choose one" with 7 options. But 
> then is like, oh, maybe I would like to be able to switch between png 
> (synthetic image), jpg (natural image)... anyway, I hope you see 
> customizing this is interesting for the users.

This needs to be done in the Emacs side.  The querying is done in
yank-media and nothing much can be done from org-mode.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[திங்கள் அக்டோபர் 14, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Attached patch adds support for yanking LibreOffice Calc tables as Org
>> tables.  Tables from docx files (or LO's equivalent) cannot be yanked
>> though since the mimetype for them are richtext or HTML.
>
> Thanks!
>
> I just tried your patch (make repro) with a simple table
>
> foo   bar 
> 1 2   3
>
> I got
>
> * This is test
> | f\0o\0o\0 | \0b\0a\0r\0 | \0|
> | \01\0 | \02\0   | \03\0 |
> | \0| |   |
>
> Something is off with encoding.

I cannot reproduce it on my end.  I tried with different documents and
document types (Excel and LO format).  Would it be possible to send the
faulty file?

>> +(defun org--libreoffice-table-handler (_mimetype data)
>> +  "Insert LibreOffice Calc table DATA as an Org table.
>> +DATA is in the TSV format."
>> +  (let ((beg (point)))
>> +(insert data)
>> +;; LibreOffice source code defines
>> +;; 'application/x-libreoffice-tsvc' as Text TSV-Calc so it should
>> +;; be safe to handle this as TSV always.
>> +(org-table-convert-region beg (point) '(16
>
> What if the point is in the middle of something else?
> For example, in the middle of another table.
> Then, conversion may yield wild outcomes.
> Maybe it is safer to convert region in a temporary buffer and
> insert the final result into the Org document being edited.

Even if we do the processing in a temporary buffer, we would still end
up inserting the table after point.  I say we leave it to the user to be
prudent and not call yank-media when in the middle of a table or
somesuch.  We do not do any special handling in other handlers, so why
do it here?

Re: [PATCH] Add repeat-map for navigation commands

[Visuwesh]

[சனி அக்டோபர் 12, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Thank you for the review, and sorry for the delay.  Can you review the
>> attached please?
>
> Applied, onto main, with minor amendments to the manual entry and to the
> news entry.

Thank you for the follow up on the documentation cleanup!

> Thanks!
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b6a72e134d

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[ Sorry if this got sent twice.  My internet connection dropped the
  previous time I sent the mail.  ]

[செவ்வாய் அக்டோபர் 15, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> [ Sorry, I do not have a better starting point for this.  ]
>> 
>> After updating Latex, I got the message:
>> ...
>> Would it be possible to give a more informative message for this case?
>> It is not a showstopper since the error message by pdfTeX is informative
>> enough but something more informative from Org would be nice regardless.
>
> Visuwesh, are you still experiencing this problem?

AFAIU, it would be a problem again when I update LaTeX.  I had to clear
the cache to get LaTeX preview working again.  The problematic file is
given in the error message.

> If yes, this message is also a ping to Karthik :)

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[சனி அக்டோபர் 19, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Also, do note that any text exceeding
>>> `org-table-convert-region-max-lines' will lead to
>>> `org-table-convert-region' throwing an error.
>>
>> Catching that and messaging the user should be sufficient?
>
> Maybe. Or we may catch and ask user to lift the restriction temporarily.
> Something like:
>
> Inserting large table with more than `org-table-convert-region-max-lines' 
> . Continue? (yes/no)

Ah, something like what Calc does.  Yes, I will go with this approach.
Thanks for the suggestion.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[சனி அக்டோபர் 19, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> My LibreOffice version is
>>
>> % libreoffice --version
>> LibreOffice 24.2.5.2 420(Build:2)
>
> LibreOffice 7.6.7.2 60(Build:2)

It might not be the version after all...  I downloaded the AppImage from
https://appimages.libreitalia.org/ (listed in
https://www.libreoffice.org/download/appimage/) and it does not have
NULL bytes at all:

Debugger entered: (#("1\0112\0113\n4\0115\0116\n" 0 12 (foreign-selection 
application/x-libreoffice-tsvc)))
  (progn (debug nil (gui-get-selection 'PRIMARY 
'application/x-libreoffice-tsvc)))


\011 is the TAB character.

% ./LibreOffice-7.4.6.2.basic-x86_64.AppImage --version
LibreOffice 7.4.6.2 5b1f5509c2decdade7fda905e3e1429a67acd63d

>>> As you can see, the data contains \0 characters.
>>
>> Just to be sure that yank-media is not in the middle of encoding
>> problem, can you say what
>>
>> (gui-get-selection 'PRIMARY 'application/x-libreoffice-tsvc)
>>
>> returns?  If it contains NULL bytes too, then I would be completely
>> clueless.
>
> Debugger entered--returning value: 
> #("1\0\11\0002\0\11\0003\0\n\0004\0\11\0005\0\11\0006\0\n\0" 0 24 
> (foreign-selection application/x-libreoffice-tsvc))
>   (gui-get-selection PRIMARY application/x-libreoffice-tsvc)
>   (progn (debug) (gui-get-selection 'PRIMARY 'application/x-libreoffice-tsvc))

Thanks so it is confirmed that yank-media does not do any conversion.
What if you instead do

(x-get-selection-internal 'PRIMARY 'application/x-libreoffice-tsvc)

?  I am not sure if it will reveal anything.  Also, what is the value of
x-select-request-type?

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[சனி அக்டோபர் 19, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Debugger entered--returning value: 
>>> #("1\0\11\0002\0\11\0003\0\n\0004\0\11\0005\0\11\0006\0\n\0" 0 24 
>>> (foreign-selection application/x-libreoffice-tsvc))
>>>   (gui-get-selection PRIMARY application/x-libreoffice-tsvc)
>>>   (progn (debug) (gui-get-selection 'PRIMARY 
>>> 'application/x-libreoffice-tsvc))
>>
>> Thanks so it is confirmed that yank-media does not do any conversion.
>> What if you instead do
>>
>> (x-get-selection-internal 'PRIMARY 'application/x-libreoffice-tsvc)
>
> Debugger entered--returning value: 
> #("1\0\11\0002\0\11\0003\0\n\0004\0\11\0005\0\11\0006\0\n\0" 0 24 
> (foreign-selection STRING))
>   (x-get-selection-internal PRIMARY application/x-libreoffice-tsvc)
>   (progn (debug) (x-get-selection-internal 'PRIMARY 
> 'application/x-libreoffice-tsvc))
>
>> ?  I am not sure if it will reveal anything.  Also, what is the value of
>> x-select-request-type?
>
> nil

Sorry, I am seriously out of clues.  We could outright remove the NULL
bytes if they do not change the underlying text but this feels like a
hack...  I hope someone else can reproduce this issue on their end.  I
do not have another Linux system in which I could freely install Emacs
and test this out.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[வியாழன் அக்டோபர் 17, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Consider the following example:
>>>
>>> * Heading 
>>>
>>> M-x yank-media ... will slurp the heading
>>>
>>> | * Heading a | b | c |
>>>
>>> In contrast, the existing handlers will only insert some text at point,
>>> never touching the text around.
>>
>> Would it be sufficient to unconditionally insert a newline after point?
>> Maybe even after going to end of current element (if that can be done).
>
> It will be more fragile compared to using temporary buffer.
> As an alternative, you can apply narrowing around the call to
> `org-table-convert-region'.

Thanks for the explanation.  I understand your initial suggestion.  I
will use a temp buffer in an updated patch.

> Also, do note that any text exceeding
> `org-table-convert-region-max-lines' will lead to
> `org-table-convert-region' throwing an error.

Catching that and messaging the user should be sufficient?

I will post an updated patch if someone comments on how to resolve the
encoding issue.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[சனி அக்டோபர் 19, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Here is the recipe
>>> 1. make repro (I tried with the latest Emacs master and with Emacs 29)
>>> 2. Open test.odt (attached)
>>> 3. M-x org-mode
>>> 4. Copy the non-empty cell area
>>> 5. M-x yank-media  app 
>>> 6. Observe encoding problems
>>
>> Thanks for the reproducer.  I think this might be locale-dependent.  I
>> fail to reproduce on my end with the following locale settings:
>>
>> LANG=en_GB.UTF-8
>> LC_COLLAGE=ta_IN.UTF-8
>> LC_MONETARY=ta_IN.UTF-8
>> LC_NUMERIC=ta_IN.UTF-8
>>
>> locale-coding-system = 'utf-8-unix
>>
>> I have no idea how to deal with locale issues like this unfortunately.
>
> I tested a bit further, and it might not be locale. Maybe it is some
> LibreOffice version issue or build issue.

My LibreOffice version is

% libreoffice --version
LibreOffice 24.2.5.2 420(Build:2)

> Below is the DATA passed to yank handler:
>
> Debugger entered--entering a function:
> * org--libreoffice-table-handler(application/x-libreoffice-tsvc 
> #("1\0\11\0002\0\11\0003\0\n\0004\0\11\0005\0\11\0005\0\n\0" 0 24 
> (foreign-selection application/x-libreoffice-tsvc)))
>   yank-media()
>
> As you can see, the data contains \0 characters.

Just to be sure that yank-media is not in the middle of encoding
problem, can you say what

(gui-get-selection 'PRIMARY 'application/x-libreoffice-tsvc)

returns?  If it contains NULL bytes too, then I would be completely
clueless.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[சனி அக்டோபர் 19, 2024] Rens Oliemans wrote:

> Visuwesh  writes:
>
>> I hope someone else can reproduce this issue on their end. I do not have
>> another Linux system in which I could freely install Emacs and test this
>> out.
>
> I'm not familiar with yank-media in any way, but here are the results of the
> commands you sent in this thread. They're all tested on the test.ods sent by
> Ihor.
>
> $ libreoffice --version
> LibreOffice 24.2.6.2 420(Build:2)
>
> (version)
> "GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, 
> cairo version 1.18.2)"
>
>>>> Just to be sure that yank-media is not in the middle of encoding
>>>> problem, can you say what
>>>>
>>>> (gui-get-selection 'PRIMARY 'application/x-libreoffice-tsvc)
>>>>
>>>> returns?
>
> (gui-get-selection 'PRIMARY 'application/x-libreoffice-tsvc)
>
> nil. However,
>
> (gui-get-selection 'CLIPBOARD 'application/x-libreoffice-tsvc)
>
> #("foobar 
> 1 2   3
> " 0 15 (foreign-selection application/x-libreoffice-tsvc))
>
>> What if you instead do
>>
>>   (x-get-selection-internal 'PRIMARY 'application/x-libreoffice-tsvc)  
>>
>> ?
>
> (x-get-selection-internal 'PRIMARY 'application/x-libreoffice-tsvc)
>
> nil. However,
>
> (x-get-selection-internal 'CLIPBOARD 'application/x-libreoffice-tsvc)
>
> #("foobar 
> 1 2   3
> " 0 15 (foreign-selection STRING))
>
> Also:
>
> Debugger entered--entering a function:
> * org--libreoffice-table-handler(application/x-libreoffice-tsvc 
> #("foo\11bar\11\n1\0112\0113\n" 0 15 (foreign-selection STRING)))
>   yank-media()
>
>> Also, what is the value of x-select-request-type?
>
> nil.
>
> `current-locale-environment' is "en_US.UTF-8"
>
> I hope that this is helpful.

Thank you, this helps a lot!  The fact that you had to change PRIMARY to
CLIPBOARD should not be a problem in practise: (1) LO should be putting
the data in the CLIPBOARD anyway, and (2) yank-media abstracts this away
for us.

If possible, could you please try LibreOffice 7.6.4? The version Ihor
has installed in his system.  There is an AppImage available for you to
try.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[திங்கள் அக்டோபர் 21, 2024] Rens Oliemans wrote:

> Visuwesh  writes:
>
>> If possible, could you please try LibreOffice 7.6.4? The version Ihor
>> has installed in his system.  There is an AppImage available for you to
>> try.
>
> Yep, on 7.6.4 the problem occurs.
>
> $ ./LibreOffice-7.6.4.1.basic-x86_64.AppImage --version
> LibreOffice 7.6.4.1 e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
>
> Debugger entered--entering a function:
> * org--libreoffice-table-handler(application/x-libreoffice-tsvc 
> #("f\0o\0o\0\11\0b\0a\0r\0\11\0\n\0001\0\11\0002\0\11\0003\0\n\0" 0 30 
> (foreign-selection STRING)))
>   yank-media()
>
> , resulting in
>
> | f\0o\0o\0 | \0b\0a\0r\0 | \0|
> | \01\0 | \02\0   | \03\0 |
> | \0| |   |
>
> To narrow it down a bit more: the problem exists in 7.6.5.2, and does not 
> exist in the
> following release, 7.6.6.3.

Thank you!  So it is most likely not locale related---a major headache
saved.  I will look into this soon (cannot promise anything this week
unfortunately).

Re: [PATCH] Add repeat-map for navigation commands

[Visuwesh]

[ஞாயிறு செப்டம்பர் 22, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Please find attached.  I tried my best to write the manual entry but it
>> still reads awkward.
>
> Thanks!
>
>> * lisp/org-keys.el (org-up-heading): Add new alias for
>> outline-up-heading.
>
> Please quote Elisp symbols as `outline-up-heading'.
>
>> +** Repeating commands
>> +:PROPERTIES:
>> +:DESCRIPTION: Repeating navigation commands
>> +:END:
>> +
>> +#+cindex: repeat-mode, org-mode
>> +#+cindex: repeating navigation commands
>> +When ~repeat-mode~ is turned on, headline motion commands, link and
>> +block navigation commands by only pressing a single key.  For example,
>> +when navigation to the next headline using {{{kbd(C-c C-n)}}}, a
>> +repeat map is activated that lets you quickly execute headline motion
>> +commands.  When a key not in the map is pressed, it exits ~repeat-mode~
>> +and the command corresponding to the key is executed.
>
> 1. You can link to "9.11 Repeating a Command" section of Emacs manual
> 2. I think that it is a good idea to provide a more clear example.
>Something like: "Instead of pressing C-c C-n repeatedly, you can
>omit C-c and just use C-c C-n n n p u... to move around."
> 3. We need to clarify which bindings are default (n, p, u, f,
>b). Probably as a table.
>
>> +*** Some navigation commands can now be repeated
>> +
>> +When ~repeat-mode~ is turned on, certain navigation can be repeated.
>> +These include the headline navigation commands, ~org-next-link~ and
>> +~org-previous-link~, and ~org-next-block~ and ~org-previous-block~.
>
> Example and a link to Emacs manual would also be good here.
> And we probably need to mention `org-navigation-repeat-map' to let users
> know what to customize if they prefer alternative bindings.

Thank you for the review, and sorry for the delay.  Can you review the
attached please?

>From cffbbe543d466cbdd2b76bfe5be6a7d693bc30f9 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 9 Sep 2024 19:46:47 +0530
Subject: [PATCH] Add repeat-mode keymap for navigation commands

* lisp/org-keys.el (org-up-heading): Add new alias for
`outline-up-heading'.
(org-mode-map): Remap `outline-up-heading' to the new alias.
(org-navigation-repeat-map, org-link-navigation-repeat-map)
(org-block-navigation-repeat-map): Add new repeat-maps to make
navigation easier.
* doc/org-manual.org (Repeating commands): Document the new feature in the manual.
* etc/ORG-NEWS (Some navigation commands can now be repeated): Announce it.
---
 doc/org-manual.org | 43 +++
 etc/ORG-NEWS   | 10 ++
 lisp/org-keys.el   | 34 ++
 3 files changed, 87 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 9365c66b1..e533fe890 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21657,6 +21657,49 @@ of ~org-yank-dnd-method~.  Image files pasted this way also respect
 the value of ~org-yank-image-save-method~ when the action to perform
 is =attach=.
 
+** Repeating commands
+:PROPERTIES:
+:DESCRIPTION: Repeating navigation commands
+:END:
+
+#+cindex: repeat-mode, org-mode
+#+cindex: repeating navigation commands
+When ~repeat-mode~ is turned on, headline motion commands, link and
+block navigation commands by only pressing a single key.  For example,
+instead of typing {{{kbd(C-c C-n)}}} repeatedly, you can omit C-c and
+just type {{{kbd(C-c C-n n n n p u ...)}}} to move to different
+headlines.  When a key not in the map is pressed, it exits
+~repeat-mode~ and the command corresponding to the key is executed
+(see the [[info:emacs#Repeating][Emacs user manual]]).
+
+By default, the following commands are made repeatable in separate
+repeat-maps.
+
+~org-navigation-repeat-map~:
+
+| Command   | Key binding| Repeat key   |
+|---++--|
+| ~org-next-visible-heading~| {{{kbd(C-c C-n)}}} | {{{kbd(n)}}} |
+| ~org-previous-visible-heading~| {{{kbd(C-c C-p)}}} | {{{kbd(p)}}} |
+| ~org-forward-heading-same-level~  | {{{kbd(C-c C-f)}}} | {{{kbd(f)}}} |
+| ~org-backward-heading-same-level~ | {{{kbd(C-c C-b)}}} | {{{kbd(b)}}} |
+| ~org-up-heading~  | {{{kbd(C-c C-u)}}} | {{{kbd(u)}}} |
+
+
+~org-block-navigation-repeat-map~:
+
+| Command  | Key binding| Repeat key   |
+|--++--|
+| ~org-next-block~ | {{{kbd(C-c M-f)}}} | {{{kbd(f)}}} |
+| ~org-previous-block~ | {{{kbd(C-c M-b)}}} | {{{kbd(b)}}} |
+
+~org-link-navigation-repeat-map~:
+
+| Command | Key binding| Repeat key   |
+|-++--|
+| ~or

[PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

Attached patch adds support for yanking LibreOffice Calc tables as Org
tables.  Tables from docx files (or LO's equivalent) cannot be yanked
though since the mimetype for them are richtext or HTML.

>From 0cd4b1c5402256ed64c9e1711db11ad215c6c1a3 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 14 Oct 2024 22:04:23 +0530
Subject: [PATCH] Add `yank-media' handler for LibreOffice Calc tables

* lisp/org.el (org--libreoffice-table-handler): Add new `yank-media'
handler for tables copied from LibreOffice Calc documents.
(org-setup-yank-dnd-handlers): Register it.
* doc/org-manual.org: (Drag and Drop & ~yank-media~): Update the
manual to mention the new feature.
* etc/ORG-NEWS: Announce the new feature.
---
 doc/org-manual.org |  6 +-
 etc/ORG-NEWS   |  5 +
 lisp/org.el| 14 +-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 451fd72cd..e8da07356 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21640,7 +21640,8 @@ value as ~org-attach-method~ (~cp~ by default).]
 
 #+cindex: pasting files, images from clipboard
 Starting from Emacs 29, Org mode supports ~yank-media~ command to yank
-images from the clipboard and files from a file manager.
+images from the clipboard, files from a file manager and tables copied
+from LibreOffice Calc documents.
 
 #+vindex: org-yank-image-save-method
 When yanking images from clipboard, Org saves the image on disk and
@@ -21658,6 +21659,9 @@ of ~org-yank-dnd-method~.  Image files pasted this way also respect
 the value of ~org-yank-image-save-method~ when the action to perform
 is =attach=.
 
+When yanking tables copied from LibreOffice Calc documents, they are
+inserted as Org tables when yanking them.
+
 ** Repeating commands
 :PROPERTIES:
 :DESCRIPTION: Repeating navigation commands
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5d421172f..37ee9a52f 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -114,6 +114,11 @@ The keybindings in the repeat-maps can be changed by customizing
 
 See the new [[info:org#Repeating commands]["Repeating commands"]] section in Org mode manual.
 
+*** Tables copied from LibreOffice Calc documents can be pasted as Org tables
+
+Tables copied into the clipboard from LibreOffice Calc documents can
+now be pasted as an Org table using ~yank-media~.
+
 ** New and changed options
 
 # Chanes deadling with changing default values of customizations,
diff --git a/lisp/org.el b/lisp/org.el
index 6177856c3..82ad40527 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20860,7 +20860,9 @@ (defun org-setup-yank-dnd-handlers ()
 ;; Looks like different DEs go for different handler names,
 ;; https://larsee.com/blog/2019/05/clipboard-files/.
 (yank-media-handler "x/special-\\(?:gnome\\|KDE\\|mate\\)-files"
-#'org--copied-files-yank-media-handler))
+#'org--copied-files-yank-media-handler)
+(yank-media-handler "application/x-libreoffice-tsvc"
+#'org--libreoffice-table-handler))
   (when (boundp 'x-dnd-direct-save-function)
 (setq-local x-dnd-direct-save-function #'org--dnd-xds-function)))
 
@@ -20953,6 +20955,16 @@ (defun org--copied-files-yank-media-handler (_mimetype data)
   (org--dnd-local-file-handler f action sep)
 (message "File `%s' is not readable, skipping" f)
 
+(defun org--libreoffice-table-handler (_mimetype data)
+  "Insert LibreOffice Calc table DATA as an Org table.
+DATA is in the TSV format."
+  (let ((beg (point)))
+(insert data)
+;; LibreOffice source code defines
+;; 'application/x-libreoffice-tsvc' as Text TSV-Calc so it should
+;; be safe to handle this as TSV always.
+(org-table-convert-region beg (point) '(16
+
 (defcustom org-yank-dnd-method 'ask
   "Action to perform on the dropped and the pasted files.
 When the value is the symbol,
-- 
2.45.2

Re: [BUG] org-id-find might change the major-mode of a buffer [9.8-pre (release_9.7.8-713-g62cbac @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[ஞாயிறு செப்டம்பர் 22, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> The patch below is what I had in mind.  With it, I can no longer
>> reproduce the recipe above.
>> ...
>
> The patch looks reasonable.
> May you format it properly, adding a proper commit message? See
> https://orgmode.org/worg/org-contribute.html#commit-messages

Please find attached.

>From 9ac977253620e719b239e08b2ff8aa1082ae8db3 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sun, 22 Sep 2024 14:38:54 +0530
Subject: [PATCH] org-id: Guard against unwarranted major-mode change when
 querying id

* lisp/org-id.el (org-id-find-id-file): Only fallback to the
current-buffer filename when it is an org-mode buffer.  This avoids
accidental change of the major-mode when querying a non-existent id
from a non-org-mode buffer.

Reported-by: Visuwesh 
Link: https://list.orgmode.org/87ikuuwmz4@gmail.com/
---
 lisp/org-id.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index e247fab1d..17568ab31 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -705,8 +705,9 @@ (defun org-id-find-id-file (id)
 	   (hash-table-p org-id-locations)
 	   (gethash id org-id-locations))
   ;; Fall back on current buffer
-  (buffer-file-name (or (buffer-base-buffer (current-buffer))
-			(current-buffer)
+  (when (derived-mode-p 'org-mode)
+(buffer-file-name (or (buffer-base-buffer (current-buffer))
+			  (current-buffer))
 
 (defun org-id-find-id-in-file (id file &optional markerp)
   "Return the position of the entry ID in FILE.
-- 
2.45.2

Re: [BUG] org-id-find might change the major-mode of a buffer [9.8-pre (release_9.7.8-713-g62cbac @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[ஞாயிறு செப்டம்பர் 22, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> The patch looks reasonable.
>>> May you format it properly, adding a proper commit message? See
>>> https://orgmode.org/worg/org-contribute.html#commit-messages
>>
>> Please find attached.
>
> Thanks!
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5dc7028d7f
> Fixed.

Thank you!

Re: [PATCH] Add repeat-map for navigation commands

[Visuwesh]

[ஞாயிறு செப்டம்பர் 22, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Please find attached.  I tried my best to write the manual entry but it
>> still reads awkward.
>
> Thanks!
>
>> * lisp/org-keys.el (org-up-heading): Add new alias for
>> outline-up-heading.
>
> Please quote Elisp symbols as `outline-up-heading'.

Oops, will fix.

>> +** Repeating commands
>> +:PROPERTIES:
>> +:DESCRIPTION: Repeating navigation commands
>> +:END:
>> +
>> +#+cindex: repeat-mode, org-mode
>> +#+cindex: repeating navigation commands
>> +When ~repeat-mode~ is turned on, headline motion commands, link and
>> +block navigation commands by only pressing a single key.  For example,
>> +when navigation to the next headline using {{{kbd(C-c C-n)}}}, a
>> +repeat map is activated that lets you quickly execute headline motion
>> +commands.  When a key not in the map is pressed, it exits ~repeat-mode~
>> +and the command corresponding to the key is executed.
>
> 1. You can link to "9.11 Repeating a Command" section of Emacs manual

Can you please tell how to link to an Info node?  I see two different
style of linking to another manual in Introduction/Activation and I'm
confused.  I do not know how ox-texinfo works.

> 2. I think that it is a good idea to provide a more clear example.
>Something like: "Instead of pressing C-c C-n repeatedly, you can
>omit C-c and just use C-c C-n n n p u... to move around."
> 3. We need to clarify which bindings are default (n, p, u, f,
>b). Probably as a table.

OK, will do this as well.

>> +*** Some navigation commands can now be repeated
>> +
>> +When ~repeat-mode~ is turned on, certain navigation can be repeated.
>> +These include the headline navigation commands, ~org-next-link~ and
>> +~org-previous-link~, and ~org-next-block~ and ~org-previous-block~.
>
> Example and a link to Emacs manual would also be good here.
> And we probably need to mention `org-navigation-repeat-map' to let users
> know what to customize if they prefer alternative bindings.

Thanks, will do this in a future patch.  Hopefully, by this week.

Re: [FR] yank media: allow customization of absolute path a filter for type candidates

[Visuwesh]

[ஞாயிறு செப்டம்பர் 22, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>>> 1. do a variable for selecting absolute path: to be able to have a file 
>>> link that works with absolute path; and the reason is that being 
>>> relative, this, does not combine good when you move your latex export 
>>> somewhere else (in my case, I usually move it to /tmp/, and from there I 
>>> decide when I want to save something persistently), hence it fails, and 
>>> I got tired on fixing the links, in fact, the absolute path sometimes is 
>>> smaller than the relative one 
>>> =file:/tmp/clipboard-20240916T013308.png]]= vs 
>>> =[[file:../../../tmp/clipboard-20240916T011913.png]]=
>>
>> This can be done in the org side.  I guess adding another defcustom
>> would be the way to go? I don't see how it is possible to make
>> org-yank-image-save-method accept another option.
>
> We can re-use `org-link-file-path-type'.
> Probably, simply by factoring out the cond from `org-insert-link' and
> then reusing it in yank handler.

I think this will indeed be the best.  We can reuse this everywhere we
insert the link in yank-media+DND code (which IIRC uses the same
function at the very end).

>>> 2. do a variable that allow a list that would filter and reduce the type 
>>> candidates of yank-media. In org-download, everything was png so I was 
>>> not having the "Several types available, choose one" with 7 options. But 
>>> then is like, oh, maybe I would like to be able to switch between png 
>>> (synthetic image), jpg (natural image)... anyway, I hope you see 
>>> customizing this is interesting for the users.
>>
>> This needs to be done in the Emacs side.  The querying is done in
>> yank-media and nothing much can be done from org-mode.
>
> That's one option - we can ask Emacs devs to provide a customization for
> `yank-media' to auto-select specific type once it is available.
>
> Another possibility is making "image/.*" customizable in
> (yank-media-handler "image/.*" #'org--image-yank-media-handler)
>
> Then, users may limit image types that can be inserted into Org by
> setting that regexp to something like "image/png".

I am leaning towards doing it in the Emacs side since it would get rid
of similar annoyance(s) in other yank-media handlers, not just Org.

If no one beats me to it before the end of this week, I will propose a
patch to take care of (1).  It would be preferable pinmacs if can take
care of (2) if we decide to take care of it from the Emacs side since I
will probably not be able to describe the situation well.

[BUG] org-id-find might change the major-mode of a buffer [9.8-pre (release_9.7.8-713-g62cbac @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

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.


Hello,

I have code in my init that calls org-id-find to get the entry ID refers
to.  When the ID is non-existent, the function unintentionally changes
the major-mode of the current buffer.
[ This almost caused me to lose a PDF file, but thankfully I could
  recover it because of Emacs backup.  Admittedly this happened because
  I was half-panicking and half-confused.  ]

To reproduce,

1. emacs -Q
2. M-: (require 'org-id)
3. Visit any file (M-x find-library RET org-id RET)
4. M-: (org-id-find "non-existent")
5. Witness the major-mode change

This all happens in org-id-find-id-in-file where when VISITING is
non-nil, the buffer is (re)used whether or not it was originally in
org-mode.  The problem is complicated by the use of find-file-noselect
when MARKERP argument to org-id-find is non-nil.  Perhaps,
org-id-find-id-file should check if the current-buffer is derived from
org-mode before returning the buffer-file-name. WDYT?

Emacs  : GNU Emacs 31.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0, Xaw scroll bars)
 of 2024-09-09
Package: Org mode version 9.8-pre (release_9.7.8-713-g62cbac @ 
/home/viz/lib/emacs/straight/build/org/)

Re: [BUG] org-id-find might change the major-mode of a buffer [9.8-pre (release_9.7.8-713-g62cbac @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 17, 2024] Visuwesh wrote:

> 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.
> 
>
> Hello,
>
> I have code in my init that calls org-id-find to get the entry ID refers
> to.  When the ID is non-existent, the function unintentionally changes
> the major-mode of the current buffer.
> [ This almost caused me to lose a PDF file, but thankfully I could
>   recover it because of Emacs backup.  Admittedly this happened because
>   I was half-panicking and half-confused.  ]
>
> To reproduce,
>
> 1. emacs -Q
> 2. M-: (require 'org-id)
> 3. Visit any file (M-x find-library RET org-id RET)
> 4. M-: (org-id-find "non-existent")
> 5. Witness the major-mode change
>
> This all happens in org-id-find-id-in-file where when VISITING is
> non-nil, the buffer is (re)used whether or not it was originally in
> org-mode.  The problem is complicated by the use of find-file-noselect
> when MARKERP argument to org-id-find is non-nil.  Perhaps,
> org-id-find-id-file should check if the current-buffer is derived from
> org-mode before returning the buffer-file-name. WDYT?

The patch below is what I had in mind.  With it, I can no longer
reproduce the recipe above.

diff --git a/lisp/org-id.el b/lisp/org-id.el
index e247fab1d..17568ab31 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -705,8 +705,9 @@ (defun org-id-find-id-file (id)
   (hash-table-p org-id-locations)
   (gethash id org-id-locations))
   ;; Fall back on current buffer
-  (buffer-file-name (or (buffer-base-buffer (current-buffer))
-   (current-buffer)
+  (when (derived-mode-p 'org-mode)
+(buffer-file-name (or (buffer-base-buffer (current-buffer))
+ (current-buffer))
 
 (defun org-id-find-id-in-file (id file &optional markerp)
   "Return the position of the entry ID in FILE.

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

[செவ்வாய் அக்டோபர் 15, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Something is off with encoding.
>>
>> I cannot reproduce it on my end.  I tried with different documents and
>> document types (Excel and LO format).  Would it be possible to send the
>> faulty file?
>
> Here is the recipe
> 1. make repro (I tried with the latest Emacs master and with Emacs 29)
> 2. Open test.odt (attached)
> 3. M-x org-mode
> 4. Copy the non-empty cell area
> 5. M-x yank-media  app 
> 6. Observe encoding problems

Thanks for the reproducer.  I think this might be locale-dependent.  I
fail to reproduce on my end with the following locale settings:

LANG=en_GB.UTF-8
LC_COLLAGE=ta_IN.UTF-8
LC_MONETARY=ta_IN.UTF-8
LC_NUMERIC=ta_IN.UTF-8

locale-coding-system = 'utf-8-unix

I have no idea how to deal with locale issues like this unfortunately.

>>>> +(insert data)
>>>> +;; LibreOffice source code defines
>>>> +;; 'application/x-libreoffice-tsvc' as Text TSV-Calc so it should
>>>> +;; be safe to handle this as TSV always.
>>>> +(org-table-convert-region beg (point) '(16
>>>
>>> What if the point is in the middle of something else?
>>> For example, in the middle of another table.
>>> Then, conversion may yield wild outcomes.
>>> Maybe it is safer to convert region in a temporary buffer and
>>> insert the final result into the Org document being edited.
>>
>> Even if we do the processing in a temporary buffer, we would still end
>> up inserting the table after point.  I say we leave it to the user to be
>> prudent and not call yank-media when in the middle of a table or
>> somesuch.  We do not do any special handling in other handlers, so why
>> do it here?
>
> Consider the following example:
>
> * Heading 
>
> M-x yank-media ... will slurp the heading
>
> | * Heading a | b | c |
>
> In contrast, the existing handlers will only insert some text at point,
> never touching the text around.

Would it be sufficient to unconditionally insert a newline after point?
Maybe even after going to end of current element (if that can be done).

Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh]

Sorry for the late reply.  I was busy with uni.

[திங்கள் அக்டோபர் 21, 2024] Visuwesh wrote:

> [திங்கள் அக்டோபர் 21, 2024] Rens Oliemans wrote:
>
>> Visuwesh  writes:
>>
>>> If possible, could you please try LibreOffice 7.6.4? The version Ihor
>>> has installed in his system.  There is an AppImage available for you to
>>> try.
>>
>> Yep, on 7.6.4 the problem occurs.
>>
>> $ ./LibreOffice-7.6.4.1.basic-x86_64.AppImage --version
>> LibreOffice 7.6.4.1 e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
>>
>> Debugger entered--entering a function:
>> * org--libreoffice-table-handler(application/x-libreoffice-tsvc 
>> #("f\0o\0o\0\11\0b\0a\0r\0\11\0\n\0001\0\11\0002\0\11\0003\0\n\0" 0 30 
>> (foreign-selection STRING)))
>>   yank-media()
>>
>> , resulting in
>>
>> | f\0o\0o\0 | \0b\0a\0r\0 | \0|
>> | \01\0 | \02\0   | \03\0 |
>> | \0| |   |
>>
>> To narrow it down a bit more: the problem exists in 7.6.5.2, and does not 
>> exist in the
>> following release, 7.6.6.3.
>
> Thank you!  So it is most likely not locale related---a major headache
> saved.  I will look into this soon (cannot promise anything this week
> unfortunately).

For reasons that escape me completely, I did not see null bytes in the
selection in

% ./LibreOffice-7.6.4.1.standard.help-x86_64.AppImage --version
LibreOffice 7.6.4.1 e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1

But considering that the chances of having null bytes in documents are
very low, I decided to bruteforce strip them.

[சனி அக்டோபர் 19, 2024] Visuwesh wrote:

> [சனி அக்டோபர் 19, 2024] Ihor Radchenko wrote:
>
>> Visuwesh  writes:
>>
>>>> Also, do note that any text exceeding
>>>> `org-table-convert-region-max-lines' will lead to
>>>> `org-table-convert-region' throwing an error.
>>>
>>> Catching that and messaging the user should be sufficient?
>>
>> Maybe. Or we may catch and ask user to lift the restriction temporarily.
>> Something like:
>>
>> Inserting large table with more than `org-table-convert-region-max-lines' 
>> . Continue? (yes/no)
>
> Ah, something like what Calc does.  Yes, I will go with this approach.
> Thanks for the suggestion.

I have now done this in the attached patch.  I use a temporary buffer to
convert the table, and also decode it as per buffer-file-coding-system
of the Org buffer as I could not tell whether LibreOffice always uses
UTF-8 or not.  I believe buffer-file-coding-system should be utf-8 on
most systems so it should be a safe choice.

>From f392dc1f3eb550c3d833683113c2d958f7f9b722 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 14 Oct 2024 22:04:23 +0530
Subject: [PATCH] Add `yank-media' handler for LibreOffice Calc tables

* lisp/org.el (org--libreoffice-table-handler): Add new `yank-media'
handler for tables copied from LibreOffice Calc documents.
(org-setup-yank-dnd-handlers): Register it.
* doc/org-manual.org: (Drag and Drop & ~yank-media~): Update the
manual to mention the new feature.
* etc/ORG-NEWS: Announce the new feature.
---
 doc/org-manual.org |  6 +-
 etc/ORG-NEWS   |  5 +
 lisp/org.el| 27 ++-
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 95846b475..e23e388a0 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21684,7 +21684,8 @@ value as ~org-attach-method~ (~cp~ by default).]
 
 #+cindex: pasting files, images from clipboard
 Starting from Emacs 29, Org mode supports ~yank-media~ command to yank
-images from the clipboard and files from a file manager.
+images from the clipboard, files from a file manager and tables copied
+from LibreOffice Calc documents.
 
 #+vindex: org-yank-image-save-method
 When yanking images from clipboard, Org saves the image on disk and
@@ -21702,6 +21703,9 @@ of ~org-yank-dnd-method~.  Image files pasted this way also respect
 the value of ~org-yank-image-save-method~ when the action to perform
 is =attach=.
 
+Yanking tables copied from LibreOffice Calc documents are inserted as
+Org tables.
+
 ** Repeating commands
 :PROPERTIES:
 :DESCRIPTION: Repeating navigation commands
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 08857962b..9ad2da5d4 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -136,6 +136,11 @@ The keybindings in the repeat-maps can be changed by customizing
 
 See the new [[info:org#Repeating commands]["Repeating commands"]] section in Org mode manual.
 
+*** Tables copied from LibreOffice Calc documents can be pasted as Org tables
+
+Tables copied into the clipboard from LibreOffice Calc documents can
+now be pasted as an Org table using ~yank-medi

Re: Bad interaction between org-capture entry type and file+function target?

[Visuwesh]

[வியாழன் நவம்பர் 21, 2024] Visuwesh wrote:

> In the attached file "test.org", I want to capture new headings above
> "Projects" always.  To achieve this, I used a file+function target to
> move the point above "Projects" like below
>
> [...]
>
> However, when evaluating this sexp, the heading "test" is always
> appended to the end of file contrary to what the docstring says:
>
> (file+function "path/to/file" function-finding-location)
> A function to find the right location in the file
>
> This is because of the 'else' clause in the cond form in
> org-capture-place-entry:
>
> [...]
>
> Should this be here?  Am I misunderstanding the documentation?  After
> all, it is too terse (the same text is in the Info manual too).  The
> documentation for the 'entry' type does not mention this quirk either:
>
> entry   an Org node, with a headline.  Will be filed
> as the child of the target entry or as a  
> top-level entry.  Its default template is:
>   "* %?\n%a"
>
> The documentation for :prepend does mention that entries will be
> inserted at the end if it is nil but I would think that using a function
> would rule this out.
>
> Changing the type to 'plain' from 'entry' works as expected though.

I just thought of a situation where this behaviour would be desired: a
template could use FUNCTION-FINDING-LOCATION to ask the user to choose a
heading (from a list, using org-ql, etc.) to capture the entry to go
_under_ it.  Here, the function would simply move the point to be on the
heading.
[ I am actually in the process of writing such a capture template.  ]

So perhaps an indicator to tell org-capture that I want to insert the
heading exactly _at_point_ is required instead?

Bad interaction between org-capture entry type and file+function target?

[Visuwesh]

In the attached file "test.org", I want to capture new headings above
"Projects" always.  To achieve this, I used a file+function target to
move the point above "Projects" like below

(let* ((heading "test")
   (file ".pdf")
   (org-capture-templates
`(("n" "blah"
   entry
   (file+function "/tmp/test.org"
  ,(lambda ()
 (goto-char (point-min))
 (re-search-forward "^\\* Projects")
 (goto-char (match-beginning 0))
 (insert "\n")
 (forward-char -1)))
   ,(concat "* " heading "\n"
":PROPERTIES:\n"
":NOTER_DOCUMENT: " file "\n"
":END:\n\n")
   :immediate-finish t
   :empty-lines-before 1
  (org-capture nil "n"))

However, when evaluating this sexp, the heading "test" is always
appended to the end of file contrary to what the docstring says:

(file+function "path/to/file" function-finding-location)
A function to find the right location in the file

This is because of the 'else' clause in the cond form in
org-capture-place-entry:

(when exact-position (goto-char exact-position))
(cond
 ;; Force insertion at point.
 (insert-here?
  )
 ;; Insert as a child of the current entry.
 ((org-capture-get :target-entry-p)
  ...)
 ;; Insert as a top-level entry at the beginning of the file.
 (reversed?
  ...)
 ;; Otherwise, insert as a top-level entry at the end of the file.
 (t (goto-char (point-max))
^^^
;; Make sure that last point is not folded.
(org-fold-core-cycle-over-indirect-buffers
  (org-fold-region (max 1 (1- (point-max))) (point-max) nil

Should this be here?  Am I misunderstanding the documentation?  After
all, it is too terse (the same text is in the Info manual too).  The
documentation for the 'entry' type does not mention this quirk either:

entry   an Org node, with a headline.  Will be filed
as the child of the target entry or as a  
top-level entry.  Its default template is:
  "* %?\n%a"

The documentation for :prepend does mention that entries will be
inserted at the end if it is nil but I would think that using a function
would rule this out.

Changing the type to 'plain' from 'entry' works as expected though.

* Heading 1
blah blah blah

* Heading 2


* Projects
** Some subheading
something else here

* Glossary
** Some more subheading
something here

Re: [PATCH] Turn org-mouse features into minor-modes

[Visuwesh]

[புதன் ஜனவரி 08, 2025] Visuwesh wrote:

> [வெள்ளி டிசம்பர் 27, 2024] Ihor Radchenko wrote:
>
>> Visuwesh  writes:
>>
>>> [ Resending it as it seems like it never reached the mailing list.  ]
>>>
>>> To make loading org-mouse less annoying for all, I was thinking of
>>> introducing minor-modes like in the attached patch.  If this approach is
>>> acceptable, I will get to calling out the change in NEWS and updating
>>> the manual if required.  We could also add a `add-hook' call to turn on
>>> the minor-mode automatically to preserve the old behaviour if required.
>>> WDYT?
>>
>> Thanks!
>> Adding minor modes is indeed a good  idea.
>> Although they should probably be globalized to keep things closer to the
>> existing behavior.
>>
>> We do not need to preserve the old behavior - side effects are to be
>> eradicated even if the cost is introducing a breaking change.
>> NEWS announcement is good enough.
>
> I've now attached a patch to this effect.  I hope the NEWS entry is
> legible.

Oops, I made a mistake when switching around branches.  Now the
globalised minor-mode is actually present in the attached patch.  Sorry
for the noise.

>From bf809910761020bd86d089788467539843c3f7fd Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 23 Dec 2024 12:41:13 +0530
Subject: [PATCH] org-mouse: Make it possible to turn on and off the feature

Introduce new minor-modes `org-mouse-minor-mode' and
`org-mouse-agenda-minor-mode' to make it easy to turn on/off the mouse
support.

* lisp/org-mouse.el (org-mode-hook, org-agenda-mode-hook): Remove the
lambda which makes it unnecessarily difficult to reverse the effect of
loading this file.
(org-mouse--old-mouse-map): New variable to hold the original
definition of org-mouse-map.
(org-mouse-minor-mode-map, org-mouse-minor-mode)
(org-mouse-agenda-minor-mode-map, org-mouse-agenda-minor-mode): Add
new minor-modes to easily toggle the mouse features on and off per
buffer.
(global-org-mouse-minor-mode, global-org-mouse-agenda-minor-mode): Add
globalised minor-modes to preserve backwards compatibility.

* etc/ORG-NEWS: Announce the breaking change.

Link: https://list.orgmode.org/87seqad1sl@gmail.com
---
 etc/ORG-NEWS  |  15 ++
 lisp/org-mouse.el | 132 --
 2 files changed, 95 insertions(+), 52 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c9bb192de..99d5b6b58 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -18,6 +18,21 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 # require user action for most Org mode users.
 # Sorted from most important to least important.
 
+*** ~org-mouse~ is no longer activated by default by anymore
+
+To follow Emacs [[info:elisp#Coding Conventions][coding conventions]] and to avoid confusion of users who
+accidentally get ~org-mouse~ autoloaded due to help completion, the
+library does not modify ~org-mode-map~ and other variables during
+loading anymore.
+
+To enable the ~org-mouse~ features, the new minor-modes
+~org-mouse-minor-mode~ and ~org-mouse-agenda-minor-mode~ should be
+enabled.
+
+To turn on the features in all ~org-mode~ and ~org-agenda-mode~
+buffers, you can use the globalized versions
+~global-org-mouse-minor-mode~ and ~global-org-mouse-agenda-minor-mode~.
+
 *** You may need to update =org-protocol= bookmarklets for browsers
 
 In Firefox-133, and Firefox-128.5 ESR the previously suggested
diff --git a/lisp/org-mouse.el b/lisp/org-mouse.el
index 928d18d66..e20256cf0 100644
--- a/lisp/org-mouse.el
+++ b/lisp/org-mouse.el
@@ -866,48 +866,59 @@ (defun org-mouse-down-mouse (event)
 ;; events to `mouse-drag-region'.
 (put 'org-mouse-down-mouse 'ignored-mouse-command t)
 
-(add-hook 'org-mode-hook
-  (lambda ()
-(setq org-mouse-context-menu-function #'org-mouse-context-menu)
-
-(when (memq 'context-menu org-mouse-features)
-  (org-defkey org-mouse-map [mouse-3] nil)
-  (org-defkey org-mode-map [mouse-3] #'org-mouse-show-context-menu))
-(org-defkey org-mode-map [down-mouse-1] #'org-mouse-down-mouse)
-(when (memq 'context-menu org-mouse-features)
-  (org-defkey org-mouse-map [C-drag-mouse-1] #'org-mouse-move-tree)
-  (org-defkey org-mouse-map [C-down-mouse-1] #'org-mouse-move-tree-start))
-(when (memq 'yank-link org-mouse-features)
-  (org-defkey org-mode-map [S-mouse-2] #'org-mouse-yank-link)
-  (org-defkey org-mode-map [drag-mouse-3] #'org-mouse-yank-link))
-(when (memq 'move-tree org-mouse-features)
-  (org-defkey org-mouse-map [drag-mouse-3] #'org-mouse-move-tree)
-  (org-defkey org-mouse-map [down-mouse-3] #'org-mouse-move-

Re: [PATCH] ob-calc: Format vector and matrix results as Org table

[Visuwesh]

[செவ்வாய் டிசம்பர் 24, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Attached patch formats vector and matrix results from a Calc source
>> block as Org table.  To test, try
>> ...
>> now.  The patch passes the old tests, and I added three new tests to
>> check the correctness of this conversion.
>
> Thanks!
>
> etc/ORG-NEWS entry seems to be displaced. It should be under Org 9.8
> heading.
>
> Also, the patch does not apply onto the latest main.
>
>> -#+BEGIN_SRC calc :results silent :var a=ob-calc-table-1
>> +#+BEGIN_SRC calc :results silent verbatim :var a=ob-calc-table-1
>
> You had to change the tests, so we have a breaking change.
>
> The change can be viewed as a bug fix since ob-calc previously did not
> conform to babel conventions, so I do not object changing the defaults.
> However, we need to inform the affected users and put the announcement
> into "breaking changes" section. We should also recommend changing
> org-babel-default-header-args:calc to restore the old behavior.

Thanks, these should be fixed in the attached patch.

>From 8ab27ec0c0732648d9c684decf8eda0e5e0ef1b5 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Thu, 26 Dec 2024 18:36:24 +0530
Subject: [PATCH] ob-calc: Format vector and matrix results as Org tables

* lisp/ob-calc.el: (org-babel-execute:calc): Format vector and matrix
results as Org tables using the raw Calc object.
* testing/lisp/test-ob-calc.el (ob-calc/matrix-inversion)
(ob-calc/matrix-algebra, ob-calc/matrix-correct-conv-column)
(ob-calc/matrix-correct-conv-row): Use ':results verbatim' for the old
tests.
(ob-calc/conv-scalar, ob-calc/conv-vector, ob-calc/conv-matrix): Add
new tests to verify correct conversion of vector, matrix, and scalar
results with ':results replace'.
* etc/ORG-NEWS: Announce the new feature.

Link: https://list.orgmode.org/878qsj1kjl@gmail.com
---
 etc/ORG-NEWS | 16 ++
 lisp/ob-calc.el  | 29 -
 testing/lisp/test-ob-calc.el | 42 
 3 files changed, 78 insertions(+), 9 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index f932c4ea2..f0112f33c 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -83,6 +83,22 @@ This should have minimal impact on non-iCalendar exporters, since
 users who manually set ~org-export-with-timestamps~ to ~active~ will
 now have diary timestamps included as well.
 
+*** =ob-calc.el=: Vector and matrix are now inserted as Org tables by default
+
+~ob-calc~ now formats vector and matrix results as Org tables.  This
+conservation can be overriden using the ~:results verbatim~ keyword on
+a per source block basis.
+
+To get back the old behaviour, add
+
+#+BEGIN_SRC emacs-lisp
+(with-eval-after-load 'ob-calc
+  (setq org-babel-header-args:calc
+(append '(:results . "verbatim") org-babel-header-args:calc)))
+#+END_SRC
+
+to your configuration.
+
 ** New features
 
 # We list the most important features, and the features that may
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index 171fd1b04..222c1f9be 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -114,11 +114,30 @@ (defun org-babel-execute:calc (body params)
   ))
  (mapcar #'org-trim
 	 (split-string (org-babel-expand-body:calc body params) "[\n\r]"
-  (save-excursion
-(with-current-buffer "*Calculator*"
-  (prog1
-  (calc-eval (calc-top 1))
-(calc-pop 1)
+  (let ((result (prog1
+;; Cannot use 'top' as SEPARATOR reliably when the
+;; top of the stack has a vector.
+(calc-eval (calc-top 1) 'raw)
+  (calc-eval 1 'pop)))
+(calc-line-numbering)
+lisp-table)
+(org-babel-reassemble-table
+ (org-babel-result-cond (cdr (assq :result-params params))
+   (calc-eval result)
+   (if (Math-vectorp result)
+   (progn
+ (dolist (r (if (math-matrixp result)
+(cdr result) ; Ignore the 'vec item.
+  (list result)))
+   (setq r (cdr r)) ; Ignore the 'vec item.
+   (push (mapcar (lambda (x) (math-format-stack-value (list x 1 nil))) r)
+ lisp-table))
+ (setq lisp-table (nreverse lisp-table)))
+ (calc-eval result)))
+ (org-babel-pick-name
+  (cdr (assq :colname-names params)) (cdr (assq :colnames params)))
+ (org-babel-pick-name
+  (cdr (assq :rowname-names params)) (cdr (assq :rownames params))
 
 (defun org-babel-calc-maybe-resolve-var (el)
 "Resolve user variables in EL.
diff --git a/testing/lisp/test-ob-calc.el b/testing/lisp/test-ob-calc.el
index f6e8a5a2f..de6656a4e 100644
--- a/testing/lisp/test-ob-calc.el
+++ b/testing/lisp/t

Re: Unexpected error using org-gnus-follow-link

[Visuwesh]

[திங்கள் டிசம்பர் 23, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Do you want to make a patch to that effect?
>>
>> How about the attached?  It falls back to the default value if the key
>> is not found in the alist.
>
> I'd rather just throw an error. If the value is not right in the
> customization, the user likely tried to customize things but failed to
> follow the value format. Falling back in such situation will create a
> headache "why Org is doing not what I tell Org to do?".
>
> Also, (cdr (assq 'gnus org-link-frame-setup)) = nil is not the only
> possible incorrect customization. I'd rather check if the cdr is a
> function and throw a descriptive error otherwise asking to fix
> `org-link-frame-setup'.

How about the attached?

BTW, I hope the function would not erroneously signal an error when the
frame setup function isn't yet loaded because of the fboundp check (but
I guess the chances of that are quite slim).

>From a12fc868aba018814be366594a21cad46827f05d Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 23 Dec 2024 11:59:16 +0530
Subject: [PATCH] Error if org-link-frame-setup is ill-defined

* lisp/ol.el (org-link-frame-setup-function): Define new helper
function get the frame-setup-function for the corresponding link-type.
* lisp/ol-gnus.el (org-gnus-follow-link):
* lisp/org.el (org-open-file): Use the new function to better inform
the user when the user option `org-link-frame-setup-function' is
ill-defined.

Reported-by: Eric Fraga 
Link: https://list.orgmode.org/874j39vz29@ucl.ac.uk/
---
 lisp/ol-gnus.el |  2 +-
 lisp/ol.el  | 10 ++
 lisp/org.el | 12 ++--
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el
index b9ee8683f..2b20e80b2 100644
--- a/lisp/ol-gnus.el
+++ b/lisp/ol-gnus.el
@@ -227,7 +227,7 @@ (defun org-gnus-open (path _)
 (defun org-gnus-follow-link (&optional group article)
   "Follow a Gnus link to GROUP and ARTICLE."
   (require 'gnus)
-  (funcall (cdr (assq 'gnus org-link-frame-setup)))
+  (funcall (org-link-frame-setup-function))
   (when gnus-other-frame-object (select-frame gnus-other-frame-object))
   (let ((group (org-no-properties group))
 	(article (org-no-properties article)))
diff --git a/lisp/ol.el b/lisp/ol.el
index fa16b5920..757f2b1fd 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1539,6 +1539,16 @@ (defun org-link-add-angle-brackets (s)
   (unless (equal (substring s -1) ">") (setq s (concat s ">")))
   s)
 
+(defun org-link-frame-setup-function (link-type)
+  "Return the frame setup function for the link type LINK-TYPE.
+This signals an error if the value of the key LINK-TYPE in
+`org-link-frame-setup' is not a function."
+  (let ((fun (cdr (assq link-type org-link-frame-setup
+(if (fboundp fun)
+fun
+  (error "The frame setup configuration for `%s' link type is ill-defined"
+ link-type
+
 
 ;;; Built-in link types
 
diff --git a/lisp/org.el b/lisp/org.el
index 2e91dd508..6af67359d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8489,7 +8489,7 @@ (defun org-open-file (path &optional in-emacs line search)
 	(and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait
  ((or (stringp cmd)
 	  (eq cmd 'emacs))
-  (funcall (cdr (assq 'file org-link-frame-setup)) file)
+  (funcall (org-link-frame-setup-function 'file) file)
   (widen)
   (cond (line (org-goto-line line)
 		  (when (derived-mode-p 'org-mode) (org-fold-reveal)))
@@ -8517,7 +8517,7 @@ (defun org-open-file (path &optional in-emacs line search)
   ;; `org-file-apps' with sexp instead of a function for `cmd'.
   (user-error "Please see Org News for version 9.0 about \
 `org-file-apps'--Error: Deprecated usage of %S" cmd))
- (t (funcall (cdr (assq 'file org-link-frame-setup)) file)))
+ (t (funcall (org-link-frame-setup-function 'file) file)))
 (funcall save-position-maybe)))
 
 ;;;###autoload
@@ -15311,20 +15311,20 @@ (defun org-modify-ts-extra (ts-string pos nincrements increment-step)
 	(setq hour (mod hour 24))
 	(setq pos-match-group 1
   new (format "-%02d:%02d" hour minute)))
-   
+
((org-pos-in-match-range pos 6) ;; POS on "dmwy" repeater char.
 	(setq pos-match-group 6
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 6 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 5) ;; POS on X in "Xd" repeater.
 	(setq pos-match-group 5
   ;; Never drop below X=1.
   new (format "%d" (max 1 (+ nincrements (string-to-number (match-string 5 ts-string)))
-   
+
((org-pos-in-match-range pos 9) ;; POS on "dmwy" repeater in warning interval.
 	(setq pos-match-group 9
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 9 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 8) ;; POS on X in "Xd" in warning interval.
 	(setq pos-match-group 8
   ;; Never drop below X=0.
-- 
2.45.2

Re: Unexpected error using org-gnus-follow-link

[Visuwesh]

[திங்கள் டிசம்பர் 23, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Do you want to make a patch to that effect?
>>
>> How about the attached?  It falls back to the default value if the key
>> is not found in the alist.
>
> I'd rather just throw an error. If the value is not right in the
> customization, the user likely tried to customize things but failed to
> follow the value format. Falling back in such situation will create a
> headache "why Org is doing not what I tell Org to do?".
>
> Also, (cdr (assq 'gnus org-link-frame-setup)) = nil is not the only
> possible incorrect customization. I'd rather check if the cdr is a
> function and throw a descriptive error otherwise asking to fix
> `org-link-frame-setup'.

How about the attached?

BTW, I hope the function would not erroneously signal an error when the
frame setup function isn't yet loaded because of the fboundp check (but
I guess the chances of that are quite slim).

>From a12fc868aba018814be366594a21cad46827f05d Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 23 Dec 2024 11:59:16 +0530
Subject: [PATCH] Error if org-link-frame-setup is ill-defined

* lisp/ol.el (org-link-frame-setup-function): Define new helper
function get the frame-setup-function for the corresponding link-type.
* lisp/ol-gnus.el (org-gnus-follow-link):
* lisp/org.el (org-open-file): Use the new function to better inform
the user when the user option `org-link-frame-setup-function' is
ill-defined.

Reported-by: Eric Fraga 
Link: https://list.orgmode.org/874j39vz29@ucl.ac.uk/
---
 lisp/ol-gnus.el |  2 +-
 lisp/ol.el  | 10 ++
 lisp/org.el | 12 ++--
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el
index b9ee8683f..2b20e80b2 100644
--- a/lisp/ol-gnus.el
+++ b/lisp/ol-gnus.el
@@ -227,7 +227,7 @@ (defun org-gnus-open (path _)
 (defun org-gnus-follow-link (&optional group article)
   "Follow a Gnus link to GROUP and ARTICLE."
   (require 'gnus)
-  (funcall (cdr (assq 'gnus org-link-frame-setup)))
+  (funcall (org-link-frame-setup-function))
   (when gnus-other-frame-object (select-frame gnus-other-frame-object))
   (let ((group (org-no-properties group))
 	(article (org-no-properties article)))
diff --git a/lisp/ol.el b/lisp/ol.el
index fa16b5920..757f2b1fd 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1539,6 +1539,16 @@ (defun org-link-add-angle-brackets (s)
   (unless (equal (substring s -1) ">") (setq s (concat s ">")))
   s)
 
+(defun org-link-frame-setup-function (link-type)
+  "Return the frame setup function for the link type LINK-TYPE.
+This signals an error if the value of the key LINK-TYPE in
+`org-link-frame-setup' is not a function."
+  (let ((fun (cdr (assq link-type org-link-frame-setup
+(if (fboundp fun)
+fun
+  (error "The frame setup configuration for `%s' link type is ill-defined"
+ link-type
+
 
 ;;; Built-in link types
 
diff --git a/lisp/org.el b/lisp/org.el
index 2e91dd508..6af67359d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8489,7 +8489,7 @@ (defun org-open-file (path &optional in-emacs line search)
 	(and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait
  ((or (stringp cmd)
 	  (eq cmd 'emacs))
-  (funcall (cdr (assq 'file org-link-frame-setup)) file)
+  (funcall (org-link-frame-setup-function 'file) file)
   (widen)
   (cond (line (org-goto-line line)
 		  (when (derived-mode-p 'org-mode) (org-fold-reveal)))
@@ -8517,7 +8517,7 @@ (defun org-open-file (path &optional in-emacs line search)
   ;; `org-file-apps' with sexp instead of a function for `cmd'.
   (user-error "Please see Org News for version 9.0 about \
 `org-file-apps'--Error: Deprecated usage of %S" cmd))
- (t (funcall (cdr (assq 'file org-link-frame-setup)) file)))
+ (t (funcall (org-link-frame-setup-function 'file) file)))
 (funcall save-position-maybe)))
 
 ;;;###autoload
@@ -15311,20 +15311,20 @@ (defun org-modify-ts-extra (ts-string pos nincrements increment-step)
 	(setq hour (mod hour 24))
 	(setq pos-match-group 1
   new (format "-%02d:%02d" hour minute)))
-   
+
((org-pos-in-match-range pos 6) ;; POS on "dmwy" repeater char.
 	(setq pos-match-group 6
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 6 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 5) ;; POS on X in "Xd" repeater.
 	(setq pos-match-group 5
   ;; Never drop below X=1.
   new (format "%d" (max 1 (+ nincrements (string-to-number (match-string 5 ts-string)))
-   
+
((org-pos-in-match-range pos 9) ;; POS on "dmwy" repeater in warning interval.
 	(setq pos-match-group 9
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 9 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 8) ;; POS on X in "Xd" in warning interval.
 	(setq pos-match-group 8
   ;; Never drop below X=0.
-- 
2.45.2

[PATCH] Turn org-mouse features into minor-modes

[Visuwesh]

[ Resending it as it seems like it never reached the mailing list.  ]

To make loading org-mouse less annoying for all, I was thinking of
introducing minor-modes like in the attached patch.  If this approach is
acceptable, I will get to calling out the change in NEWS and updating
the manual if required.  We could also add a `add-hook' call to turn on
the minor-mode automatically to preserve the old behaviour if required.
WDYT?

>From a4162d9e9204735ecd6ac864ed467e87362ace32 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 23 Dec 2024 12:41:13 +0530
Subject: [PATCH] org-mouse: Make it possible to turn on and off the feature

Introduce new minor-modes `org-mouse-minor-mode' and
`org-mouse-agenda-minor-mode' to make it easy to turn on/off the mouse
support.

* lisp/org-mouse.el (org-mode-hook, org-agenda-mode-hook): Remove the
lambda which makes it unnecessarily difficult to reverse the effect of
loading this file.
(org-mouse--old-mouse-map): New variable to hold the original
definition of org-mouse-map.
(org-mouse-minor-mode-map, org-mouse-minor-mode)
(org-mouse-agenda-minor-mode-map, org-mouse-agenda-minor-mode): Add
new minor-modes to easily toggle the mouse features on and off per
buffer.
---
 lisp/org-mouse.el | 120 ++
 1 file changed, 68 insertions(+), 52 deletions(-)

diff --git a/lisp/org-mouse.el b/lisp/org-mouse.el
index 7f85653f2..eb4355d2f 100644
--- a/lisp/org-mouse.el
+++ b/lisp/org-mouse.el
@@ -866,48 +866,59 @@ (defun org-mouse-down-mouse (event)
 ;; events to `mouse-drag-region'.
 (put 'org-mouse-down-mouse 'ignored-mouse-command t)
 
-(add-hook 'org-mode-hook
-  (lambda ()
-(setq org-mouse-context-menu-function #'org-mouse-context-menu)
-
-(when (memq 'context-menu org-mouse-features)
-  (org-defkey org-mouse-map [mouse-3] nil)
-  (org-defkey org-mode-map [mouse-3] #'org-mouse-show-context-menu))
-(org-defkey org-mode-map [down-mouse-1] #'org-mouse-down-mouse)
-(when (memq 'context-menu org-mouse-features)
-  (org-defkey org-mouse-map [C-drag-mouse-1] #'org-mouse-move-tree)
-  (org-defkey org-mouse-map [C-down-mouse-1] #'org-mouse-move-tree-start))
-(when (memq 'yank-link org-mouse-features)
-  (org-defkey org-mode-map [S-mouse-2] #'org-mouse-yank-link)
-  (org-defkey org-mode-map [drag-mouse-3] #'org-mouse-yank-link))
-(when (memq 'move-tree org-mouse-features)
-  (org-defkey org-mouse-map [drag-mouse-3] #'org-mouse-move-tree)
-  (org-defkey org-mouse-map [down-mouse-3] #'org-mouse-move-tree-start))
-
-(when (memq 'activate-stars org-mouse-features)
-  (font-lock-add-keywords
-   nil
+(defvar org-mouse-minor-mode-map
+  (let ((map (make-sparse-keymap)))
+(org-defkey map [mouse-3] #'org-mouse-show-context-menu)
+(org-defkey map [down-mouse-1] #'org-mouse-down-mouse)
+map)
+  "Keymap for `org-mouse-minor-mode'.")
+
+(defvar-local org-mouse--old-mouse-map (copy-keymap org-mouse-map))
+(define-minor-mode org-mouse-minor-mode
+  "Minor mode to enable better mouse support in `org-mode'."
+  :global nil
+  (let ((fl-fun (if org-mouse-minor-mode
+(lambda (mode kw)
+  (font-lock-add-keywords mode kw t))
+  #'font-lock-remove-keywords)))
+(setq org-mouse-context-menu-function
+  (and org-mouse-minor-mode #'org-mouse-context-menu))
+(when org-mouse-minor-mode
+  ;; Without `copy-keymap', later `org-defkey' calls modify the
+  ;; value of keymap `org-mouse--old-mouse-map' holds.
+  (setq org-mouse--old-mouse-map (copy-keymap org-mouse-map)))
+(setq org-mouse-map (copy-keymap org-mouse--old-mouse-map))
+(org-defkey org-mouse-minor-mode-map [S-mouse-2] nil)
+(org-defkey org-mouse-minor-mode-map [drag-mouse-3] nil)
+(when org-mouse-minor-mode
+  (when (memq 'context-menu org-mouse-features)
+(org-defkey org-mouse-map [mouse-3] nil)
+(org-defkey org-mouse-map [C-drag-mouse-1] #'org-mouse-move-tree)
+(org-defkey org-mouse-map [C-down-mouse-1] #'org-mouse-move-tree-start))
+  (when (memq 'yank-link org-mouse-features)
+(org-defkey org-mouse-minor-mode-map [S-mouse-2] #'org-mouse-yank-link)
+(org-defkey org-mouse-minor-mode-map [drag-mouse-3] #'org-mouse-yank-link))
+  (when (memq 'move-tree org-mouse-features)
+(org-defkey org-mouse-map [drag-mouse-3] #'org-mouse-move-tree)
+(org-defkey org-mouse-map [down-mouse-3] #'org-mouse-move-tree-start)))
+(when (memq 'activate-stars org-mouse-features)
+  (funcall fl-fun nil
`((,org-outline-

Re: Unexpected error using org-gnus-follow-link

[Visuwesh]

[வியாழன் டிசம்பர் 26, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Also, (cdr (assq 'gnus org-link-frame-setup)) = nil is not the only
>>> possible incorrect customization. I'd rather check if the cdr is a
>>> function and throw a descriptive error otherwise asking to fix
>>> `org-link-frame-setup'.
>>
>> How about the attached?
>
> You still do not check if the value is a function.
> Consider totally wrong values like '(wrong). `fboundp' will then throw
> an error.  You may consider `functionp' instead.

Ah, I wasn't aware that functionp also returned t if you gave a symbol.
Thanks for the hint.

>> +(defun org-link-frame-setup-function (link-type)
>> +  "Return the frame setup function for the link type LINK-TYPE.
>> +This signals an error if the value of the key LINK-TYPE in
>> +`org-link-frame-setup' is not a function."
>> +  (let ((fun (cdr (assq link-type org-link-frame-setup
>> +(if (fboundp fun)
>> +fun
>> +  (error "The frame setup configuration for `%s' link type is 
>> ill-defined"
>> + link-type
>
> In the error, we can also show the problematic value to aid the user.

Now done.

>> @@ -15311,20 +15311,20 @@ (defun org-modify-ts-extra (ts-string pos 
>> nincrements increment-step)
>>  (setq hour (mod hour 24))
>>  (setq pos-match-group 1
>>new (format "-%02d:%02d" hour minute)))
>> -   
>> +
>> ...
>
> Please remove irrelevant whitespace-only changes.

Done.  Please find attached.

>From ee57860915308dc9bf30172cfd94f8985b536361 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Mon, 23 Dec 2024 11:59:16 +0530
Subject: [PATCH] Error if org-link-frame-setup is ill-defined

* lisp/ol.el (org-link-frame-setup-function): Define new helper
function get the frame-setup-function for the corresponding link-type.
* lisp/ol-gnus.el (org-gnus-follow-link):
* lisp/org.el (org-open-file): Use the new function to better inform
the user when the user option `org-link-frame-setup-function' is
ill-defined.

Reported-by: Eric Fraga 
Link: https://list.orgmode.org/874j39vz29@ucl.ac.uk/
---
 lisp/ol-gnus.el |  2 +-
 lisp/ol.el  | 10 ++
 lisp/org.el |  4 ++--
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el
index b9ee8683f..2b20e80b2 100644
--- a/lisp/ol-gnus.el
+++ b/lisp/ol-gnus.el
@@ -227,7 +227,7 @@ (defun org-gnus-open (path _)
 (defun org-gnus-follow-link (&optional group article)
   "Follow a Gnus link to GROUP and ARTICLE."
   (require 'gnus)
-  (funcall (cdr (assq 'gnus org-link-frame-setup)))
+  (funcall (org-link-frame-setup-function))
   (when gnus-other-frame-object (select-frame gnus-other-frame-object))
   (let ((group (org-no-properties group))
 	(article (org-no-properties article)))
diff --git a/lisp/ol.el b/lisp/ol.el
index fa16b5920..102b68bab 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1539,6 +1539,16 @@ (defun org-link-add-angle-brackets (s)
   (unless (equal (substring s -1) ">") (setq s (concat s ">")))
   s)
 
+(defun org-link-frame-setup-function (link-type)
+  "Return the frame setup function for the link type LINK-TYPE.
+This signals an error if the value of the key LINK-TYPE in
+`org-link-frame-setup' is not a function."
+  (let ((fun (cdr (assq link-type org-link-frame-setup
+(if (functionp fun)
+fun
+  (error "The frame setup configuration `%S' for `%s' link type is ill-defined"
+ fun link-type
+
 
 ;;; Built-in link types
 
diff --git a/lisp/org.el b/lisp/org.el
index 2e91dd508..2c35bed5f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8489,7 +8489,7 @@ (defun org-open-file (path &optional in-emacs line search)
 	(and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait
  ((or (stringp cmd)
 	  (eq cmd 'emacs))
-  (funcall (cdr (assq 'file org-link-frame-setup)) file)
+  (funcall (org-link-frame-setup-function 'file) file)
   (widen)
   (cond (line (org-goto-line line)
 		  (when (derived-mode-p 'org-mode) (org-fold-reveal)))
@@ -8517,7 +8517,7 @@ (defun org-open-file (path &optional in-emacs line search)
   ;; `org-file-apps' with sexp instead of a function for `cmd'.
   (user-error "Please see Org News for version 9.0 about \
 `org-file-apps'--Error: Deprecated usage of %S" cmd))
- (t (funcall (cdr (assq 'file org-link-frame-setup)) file)))
+ (t (funcall (org-link-frame-setup-function 'file) file)))
 (funcall save-position-maybe)))
 
 ;;;###autoload
-- 
2.45.2

Re: [PATCH] ob-calc: Format vector and matrix results as Org table

[Visuwesh]

[செவ்வாய் டிசம்பர் 24, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Attached patch formats vector and matrix results from a Calc source
>> block as Org table.  To test, try
>> ...
>> now.  The patch passes the old tests, and I added three new tests to
>> check the correctness of this conversion.
>
> Thanks!
>
> etc/ORG-NEWS entry seems to be displaced. It should be under Org 9.8
> heading.
>
> Also, the patch does not apply onto the latest main.

I guess I mixed up main and master on my local clone (I probably have a
dummy master branch).

>> -#+BEGIN_SRC calc :results silent :var a=ob-calc-table-1
>> +#+BEGIN_SRC calc :results silent verbatim :var a=ob-calc-table-1
>
> You had to change the tests, so we have a breaking change.
>
> The change can be viewed as a bug fix since ob-calc previously did not
> conform to babel conventions, so I do not object changing the defaults.
> However, we need to inform the affected users and put the announcement
> into "breaking changes" section. We should also recommend changing
> org-babel-default-header-args:calc to restore the old behavior.

Can you tell what to put in here to retain the old behaviour?  I am not
a regular user of babel and know next to nothing about these header
arguments to suggest the right setting of
org-babel-default-header-args:calc to gain back the old behaviour.

Thanks for the review.

Re: [PATCH] Turn org-mouse features into minor-modes

[Visuwesh]

[வெள்ளி டிசம்பர் 27, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> [ Resending it as it seems like it never reached the mailing list.  ]
>>
>> To make loading org-mouse less annoying for all, I was thinking of
>> introducing minor-modes like in the attached patch.  If this approach is
>> acceptable, I will get to calling out the change in NEWS and updating
>> the manual if required.  We could also add a `add-hook' call to turn on
>> the minor-mode automatically to preserve the old behaviour if required.
>> WDYT?
>
> Thanks!
> Adding minor modes is indeed a good  idea.
> Although they should probably be globalized to keep things closer to the
> existing behavior.

That would make it hard to toggle the feature on/off on a per-buffer
basis, which was my intention behind using a minor mode.  I don't have
strong opinions here so if you think otherwise, I will use a global
minor mode instead.  If we go the global route, shall I make it so that
activating it would enable mouse support for both org-mode and
org-agenda-mode?

> We do not need to preserve the old behavior - side effects are to be
> eradicated even if the cost is introducing a breaking change.

Thanks, this will save some headache.

> NEWS announcement is good enough.

Noted.

Re: [BUG] yank-media doesn't work

[Visuwesh]

[வியாழன் டிசம்பர் 26, 2024] the_wurfkreuz wrote:

> It gives this:
>
> [TIMESTAMP TARGETS SAVE_TARGETS MULTIPLE STRING UTF8_STRING TEXT 
> chromium/x-source-url text/html text/plain text/plain\;charset=utf-8]

No wonder nothing happened.  There's no image/* element here so we
cannot do anything here.  What does text/html contain?  (But I do not
want to go into the rabbit hole of extracting the image from the HTML
string, and insert it, etc.  I will delegate the job to someone more
strong-willed than me.)

> Also, it works correctly if i switch from wayland to X11.

Are non-PGTK configurations supported outside of X11?  I would assume
not.  This could be a source of trouble too.

In any case, nothing much can be done from Org's side.  This is clearly
an Emacs bug (or a mismatch of user environment and toolkit).

Re: Unexpected error using org-gnus-follow-link

[Visuwesh]

[வியாழன் டிசம்பர் 12, 2024] Fraga, Eric wrote:

> Hello all,
>
> I upgraded both Emacs (from git) and org (elpa) in the last couple of
> days.  Today I find that I get the following error using
> org-open-at-point:
>
> Debugger entered--Lisp error: (void-function nil)
>   nil()
>   org-gnus-follow-link("nnml+outlook:mail.dt2022" "[...]")
>   org-gnus-open("nnml+outlook:mail.dt2022#[...]" nil)
>   org-link-open((link (:standard-properties [1994 nil 2111 2179 2181 0 nil 
> nil nil nil nil nil nil nil # nil nil (paragraph 
> (:standard-properties [1994 1994 1994 2182 2182 0 nil nil element t (3 . 
> 1815) nil nil nil # nil nil (item ...)]))] :type "gnus" 
> :type-explicit-p t :path "nnml+outlook:mail.dt2022#[...]" :format bracket 
> :raw-link "gnus:nnml+outlook:mail.dt2022#[...]" :application nil 
> :search-option nil)) nil)
>   org-open-at-point(nil)
>   funcall-interactively(org-open-at-point nil)
>   command-execute(org-open-at-point)
>
> with message reference elided.
>
> I cannot really reduce this to a minimal example or use -Q due to need
> to have gnus configured.
>
> Any suggestions on how to resolve this?  The vast majority of my TODO
> entries have gnus email links and they have always worked just fine.
> The problem could, of course, be with gnus but I cannot tell from the
> above backtrace.

A shot in the dark after looking at org-gnus-follow-link: what is the
value of org-link-frame-setup?  Does it have the gnus entry?

Re: [BUG] yank-media doesn't work

[Visuwesh]

[Monday December 16, 2024] the_wurfkreuz wrote:

> Also, it seems as if the bug is easier to trigger if i copy an image
> from teleram in comparison to other things i've tried. But i'm not
> completely sure about this.
>
>
>  Оригинальное Сообщение 
> 16.12.2024 23:32, the_wurfkreuz  написал:
>
>>  Ah, no, the problem is still here.
>>  
>>  > I am assuming that you're running the PGTK build
>>  
>>  I compiled emacs with gtk3:
>>  
>>   ./configure --with-tree-sitter \
>>  --with-gif --with-png --with-jpeg --with-tiff \
>>  --with-imagemagick --with-x-toolkit=gtk3 --with-xwidgets \
>>  --without-rsvg \
>>  WEBKIT_CFLAGS="$(pkg-config --cflags webkit2gtk-4.1)" \
>>  WEBKIT_LIBS="$(pkg-config --libs webkit2gtk-4.1)" \
>>  CPPFLAGS="-I/usr/lib/gcc/x86_64-linux-gnu/14/include" \
>>  --with-mailutils
>>  
>>  I'm running emacs on wayland.
>>  

I am on Xorg and using the Lucid toolkit.  I cannot reproduce this when
I copy an image from Telegram.  When you get this again, could you try
evaluating

(gui-get-selection 'CLIPBOARD 'TARGETS)

?  If you can find a reliable reproducer from emacs -Q, please file a
bug report with the reproduction steps clearly written using M-x
report-emacs-bug RET as this is clearly an Emacs bug, not an Org one.

Re: [BUG] yank-media doesn't work

[Visuwesh]

[திங்கள் டிசம்பர் 02, 2024] the_wurfkreuz via "General discussions about 
Org-mode." wrote:

> When using the yank-media command to paste images, the results are
> inconsistent. This issue persists even when running Emacs with emacs
> -Q.
>
> In some instances, the command successfully pastes the image.
> At other times, it fails with the message: "yank-media: No handler in
> the current buffer for anything on the clipboard."
> Alternatively, it may display: "Timed out waiting for property-notify event."
>
> Occasionally, attempting the command twice in quick succession results
> in success on the second attempt, though this is rare.
> Copying images directly from a web browser using the "Copy Image"
> option generally works without issue.However, copying images using the
> command grim -g "$(slurp)" - | wl-copy or from Telegram often results
> in the aforementioned errors.
> Emacs : GNU Emacs 30.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.43, cairo version 1.18.0)
> Package: Org mode version 9.8-pre (release_9.7.16-169-ge87ecf)

I am assuming that you're running the PGTK build.  I am quite sure this
is the same bug as bug#72254.  How recent is the build of your Emacs 30?
Does it include the fix for bug#72254: 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-30&id=11e7ae3964e192b0e4bcc437a04278ee727e720b

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[வெள்ளி டிசம்பர் 13, 2024] Visuwesh wrote:

> [...]
> Some caveats:
>
>   1. You need to ensure that all the calc-embedded variables that you
>  use in the formula need to be active and evaluated beforehand.
>   2. The calc-embedded var is considered at last after everything else
>  in org-table-get-constant in the advice.  This would be the best
>  way to go forward.
>
> It would be nice to lift the restrict in (1) but I think it would be
> better to leave it to the user to ensure everything stays updated since
> the user may want to use the old value.  However, ensuring all the vars
> are active and eval-ed would be a royal pain when you're quickly
> evaluating a table formula.
>
> Here's the case I used to test this hack:
>
> x := 3
>
> y := 5
>
> z := 5 x - y => 10
>
>
> | 1 | 20 |
>
> #+TBLFM: $2=$z*2

OK, this was not so simple as I thought!  Consider the following
example:

x := 3

a := 3 x => 9

y := 5

x := 2

z := 5.2 x - y => 5.4

Update x := 3 and y first.  Then update `a' and `z'.  `z' will be 10.6.
Now update x := 2, and update `z' and `a'.  `z' updates to 5.4 as shown
above but `a' remains 9!  Calc looks for the nearest value of the
variable `x' from the definition of `z'.  The Elisp variable that stores
the var information looks like this:

(cdar calc-embedded-active)

([# # # # # #
   #("x := 3" 0 6 (fontified t)) nil
   (calcFunc-assign (var x var-x) 3) (var x var-x) nil
   (calcFunc-assign (var x var-x) 3) nil nil nil nil]
 [# # # # # #
   #("a := 3 x => 9" 0 13 (fontified t)) nil
   (calcFunc-evalto
(calcFunc-assign (var a var-a) (* 3 (var x var-x))) 9)
   (var a var-a) (((var x var-x))) 9 nil nil nil nil]
 [# # # # # #
   #("y := 5" 0 6 (fontified t)) nil
   (calcFunc-assign (var y var-y) 5) (var y var-y) nil
   (calcFunc-assign (var y var-y) 5) nil nil nil nil]
 [# # # # # #
   #("x := 2" 0 6 (fontified t)) nil
   (calcFunc-assign (var x var-x) 2) (var x var-x) nil
   (calcFunc-assign (var x var-x) 2) nil nil nil nil]
 [# # # # # #
   "z := 5.2 x - y => 5.4" nil
   (calcFunc-evalto
(calcFunc-assign (var z var-z)
 (- (* (float 52 -1) (var x var-x))
(var y var-y)))
(float 54 -1))
   (var z var-z) (((var y var-y)) ((var x var-x)))
   (float 54 -1) nil nil nil nil])

Notice how there are two entries for `x'.  Worse still, change x := 3 to
x := 3.3 and update it.  Evaluating the same expression again now yields
three entries for `x'!

([# # # # # #
   #("x := 3" 0 6 (fontified t)) nil
   (calcFunc-assign (var x var-x) 3) (var x var-x) nil
   (calcFunc-assign (var x var-x) 3) nil nil nil nil]
 [# # # # # #
   #("x := 3.3" 0 8 (fontified t)) nil
   (calcFunc-assign (var x var-x) (float 33 -1)) (var x var-x)
   nil (calcFunc-assign (var x var-x) (float 33 -1)) nil nil
   nil nil]
 ...
 ...
 [# # # # # #
   #("x := 2" 0 6 (fontified t)) nil
   (calcFunc-assign (var x var-x) 2) (var x var-x) nil
   (calcFunc-assign (var x var-x) 2) nil nil nil nil]
 ...)

Which begs the question: what should be `x'?

In any case, the code I posted above had a problem with decimals.  The
code still picks the first value of VAR that shows up in the list above.

(defun vz/calc-embedded-get-var (var)
  "Return the value of active `calc-embedded' VAR in current buffer."
  (let* ((info (cdr (assq (current-buffer) calc-embedded-active)))
 (var-info
  (seq-find
   (lambda (x)
 ;; 9 is the variable name: (var XXX var-XXX)
 (eq var (nth 1 (aref x 9
   info))
 old-val)
(when (and info var-info)
  ;; This is called the `old-val' in `calc-embedded-update'.
  ;; This can be nil when the formula isn't evaled I think?
  ;; (aref VAR-INFO 8) is again repeated in 11th slot when the
  ;; variable is simply as assignment.
  (let ((calc-line-numbering))
;; For the below trick, see `calc-embedded-update' again.
(math-format-stack-value
 (list (or (if (and (consp (setq old-val (aref var-info 11)))
(eq (car old-val) 'calcFun-assign))
   (car (last old-val))
 old-val)
   ;; 8 is the eval form: (calcFun-evalto ...) or
   ;; (calcFun-assign ...)
 

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

Sorry for getting back after so long!

[புதன் ஏப்ரல் 03, 2024] Fraga, Eric wrote:

> On Saturday, 30 Mar 2024 at 18:34, Visuwesh wrote:
>>> Specifically, I would love to make reference to calc variables,
>>> especially those defined using embedded calc, in org tables.
>>
>> Can you please provide a minimal example for me to play around with?  I
>> realise I would like something like this too [*] but I don't know
>> concretely what this would/should look like.
>
> So, embedded calc processes expressions in any buffer, including org
> mode, which might look like this:
>
> x := 3
>
> y := 5
>
> z := 3 x - y => 4
>
> where, in this case, the value of z has been determined by calc and the
> answer given after the => in the line.  The beauty of embedded calc is
> you can change the value of x and the subsequent expressions will be
> updated automatically (well, with C-x * u).
>
> I would then love to be able to have a table that would allow me to
> include the value of any variable, e.g. z above, something like
>
> | var | value |
> |-+---|
> | x   | 3 |
> | z   | 4 |
>
> where the values in the second column are obtained by querying Calc.

Here's a hack I cooked up:

(defun vz/calc-embedded-get-var (var)
  "Return the value of active `calc-embedded' VAR in current buffer."
  (let* ((info (cdr (assq (current-buffer) calc-embedded-active)))
 (var-info
  (seq-find
   (lambda (x)
 ;; 9 is the variable name: (var XXX var-XXX)
 (eq var (nth 1 (aref x 9
   info))
 old-val)
(when (and info var-info)
  ;; This is called the `old-val' in `calc-embedded-update'.
  ;; This can be nil when the formula isn't evaled I think?
  ;; (aref VAR-INFO 8) is again repeated in 11th slot when the
  ;; variable is simply as assignment.
  (or (if (consp (setq old-val (aref var-info 11)))
  (car (last old-val))
old-val)
  ;; 8 is the eval form: (calcFun-evalto ...) or
  ;; (calcFun-assign ...)
  (car (last (aref var-info 8)))

(define-advice org-table-get-constant (:around (oldfun name) 
vz/consider-calc-embedded-var)
  "Check if NAME is a `calc-embedded' at last."
  (let ((val (funcall oldfun name)))
(if (equal val "#UNDEFINED_NAME")
(or (number-to-string (vz/calc-embedded-get-var (intern name)))
val)
  val)))

Some caveats:

  1. You need to ensure that all the calc-embedded variables that you
 use in the formula need to be active and evaluated beforehand.
  2. The calc-embedded var is considered at last after everything else
 in org-table-get-constant in the advice.  This would be the best
 way to go forward.

It would be nice to lift the restrict in (1) but I think it would be
better to leave it to the user to ensure everything stays updated since
the user may want to use the old value.  However, ensuring all the vars
are active and eval-ed would be a royal pain when you're quickly
evaluating a table formula.

Here's the case I used to test this hack:

x := 3

y := 5

z := 5 x - y => 10


| 1 | 20 |
#+TBLFM: $2=$z*2

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[வெள்ளி டிசம்பர் 13, 2024] Fraga, Eric wrote:

> Response below/inline for email Visuwesh wrote:
>> (original email sent 13 Dec 2024 at 14:32)
>> 
>> Update x := 3 and y first.  Then update `a' and `z'.  `z' will be 10.6.
>> Now update x := 2, and update `z' and `a'.  `z' updates to 5.4 as shown
>> above but `a' remains 9!  
>
> Yes, this is expected behaviour.  Calc assumes a sequential evaluation,
> especially when the same variable is given a value more than once.  It's
> not like most modelling languages which look at the ensemble of
> equations simultaneously.

I assumed this was the case.  It does make sense when you take the whole
picture together.  You are likely to use the same variable name (such as
T for temperature) everywhere so it would be best to use the nearest
one.

> [...]
>
>> Which begs the question: what should be `x'?
>
> Ideally, it would follow the Calc convention and would be the value last
> given (before point, where the table is), I guess.

When we have

x := 3

| 1 | 3 |
#+TBLFM:$2=$x

x := 6

| 1 | 6 |
#+TBLFM:$2=$x

value of `x' for the first table should be 3, and for the second 6.
However, when we have something like

x := 3
a := 2 * x
x := 2
z := 0.5 * x

| 1 | |
#+TBLFM:$2=$x*$z

what should $2 evaluate to?  $z is straight-forward: $z=1.  But what
about $x?  Should it be 2 or 3?  If we go by Calc's convention, it
should be 3.  Do you agree?

> But, at least, for simple cases where variables are not overwritten,
> what you have done would be sufficient (and a really nice addition to
> the Calc package!).
>
> I intend to use it for sure.

I am glad to be of help, and hope the quick hack actually works
reliably.

Re: Unexpected error using org-gnus-follow-link

[Visuwesh]

[வியாழன் டிசம்பர் 12, 2024] Fraga, Eric wrote:

> Response below/inline for email Visuwesh wrote:
>> (original email sent 12 Dec 2024 at 20:32)
>> 
>> A shot in the dark after looking at org-gnus-follow-link: what is the
>> value of org-link-frame-setup?  Does it have the gnus entry?
>
> Wow!  What an excellent shot in the dark. :-)
>
> I happened to play with the orgrr package which unfortunately actually
> changes that variable.  Resetting it to the default works just fine.
>
> Many thanks.

Glad to be of help.

> It does beg the question: should org fail more gracefully and/or give an
> error message in such a context?

I quickly checked the usage of that defcustom and Org does not fall back
gracefully in other places too.  While we can fix it, it would be good
to inform the maintainers of orgrr about this too.

[PATCH] ob-calc: Format vector and matrix results as Org table

[Visuwesh]

Attached patch formats vector and matrix results from a Calc source
block as Org table.  To test, try

#+NAME: test
| 1 | 2 |

#+BEGIN_SRC calc :var t=test
  2 * t
#+END_SRC

It should return

#+RESULTS:
| 2 | 4 |

now.  The patch passes the old tests, and I added three new tests to
check the correctness of this conversion.

>From f58dddf37728248e05cbdf2dcb56517f6723261e Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sat, 14 Dec 2024 00:23:14 +0530
Subject: [PATCH] ob-calc: Format vector and matrix results as Org tables

* lisp/ob-calc.el: (org-babel-execute:calc): Format vector and matrix
results as Org tables using the raw Calc object.
* testing/lisp/test-ob-calc.el (ob-calc/matrix-inversion)
(ob-calc/matrix-algebra, ob-calc/matrix-correct-conv-column)
(ob-calc/matrix-correct-conv-row): Use ':results verbatim' for the old
tests.
(ob-calc/conv-scalar, ob-calc/conv-vector, ob-calc/conv-matrix): Add
new tests to verify correct conversion of vector, matrix, and scalar
results with ':results replace'.
* etc/ORG-NEWS: Announce the new feature.
---
 etc/ORG-NEWS |  6 ++
 lisp/ob-calc.el  | 29 -
 testing/lisp/test-ob-calc.el | 42 
 3 files changed, 68 insertions(+), 9 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ca73f06e7..fa98c41e6 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -946,6 +946,12 @@ properties, links to headlines in the file can also be made more
 robust by using the file id instead of the file path.
 
 ** New features
+*** =ob-calc.el=: Vector and matrix results can be formatted as Org tables
+
+~ob-calc~ can now format vector and matrix results as Org tables.
+This conversion can be overriden using the usual ~:results verbatim~
+keyword.
+
 *** =ob-tangle.el=: New flag to remove tangle targets before writing
 
 When ~org-babel-tangle-remove-file-before-write~ is set to ~t~ the
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index 810ed1735..e3fdc0cbd 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -110,11 +110,30 @@ (defun org-babel-execute:calc (body params)
   ))
  (mapcar #'org-trim
 	 (split-string (org-babel-expand-body:calc body params) "[\n\r]"
-  (save-excursion
-(with-current-buffer (get-buffer "*Calculator*")
-  (prog1
-  (calc-eval (calc-top 1))
-(calc-pop 1)
+  (let ((result (prog1
+;; Cannot use 'top' as SEPARATOR reliably when the
+;; top of the stack has a vector.
+(calc-eval (calc-top 1) 'raw)
+  (calc-eval 1 'pop)))
+(calc-line-numbering)
+lisp-table)
+(org-babel-reassemble-table
+ (org-babel-result-cond (cdr (assq :result-params params))
+   (calc-eval result)
+   (if (Math-vectorp result)
+   (progn
+ (dolist (r (if (math-matrixp result)
+(cdr result) ; Ignore the 'vec item.
+  (list result)))
+   (setq r (cdr r)) ; Ignore the 'vec item.
+   (push (mapcar (lambda (x) (math-format-stack-value (list x 1 nil))) r)
+ lisp-table))
+ (setq lisp-table (nreverse lisp-table)))
+ (calc-eval result)))
+ (org-babel-pick-name
+  (cdr (assq :colname-names params)) (cdr (assq :colnames params)))
+ (org-babel-pick-name
+  (cdr (assq :rowname-names params)) (cdr (assq :rownames params)))
 
 (defun org-babel-calc-maybe-resolve-var (el)
 "Resolve user variables in EL.
diff --git a/testing/lisp/test-ob-calc.el b/testing/lisp/test-ob-calc.el
index 6d6ca104d..cfa1fb4f6 100644
--- a/testing/lisp/test-ob-calc.el
+++ b/testing/lisp/test-ob-calc.el
@@ -55,7 +55,7 @@ (ert-deftest ob-calc/matrix-inversion ()
 | 5 |  6 |  7 |
 | 9 | 14 | 11 |
 
-#+BEGIN_SRC calc :results silent :var a=ob-calc-table-1
+#+BEGIN_SRC calc :results silent verbatim :var a=ob-calc-table-1
 	inv(a)
 #+END_SRC "
 (should (equal "[[-1, 0.625, -0.125], [0.25, -0.5, 0.25], [0.5, 0.125, -0.125]]"
@@ -67,7 +67,7 @@ (ert-deftest ob-calc/matrix-algebra ()
 #+NAME: ob-calc-table-2
 | 1 | 2 | 3 | 4 | 5 |
 
-#+BEGIN_SRC calc :results silent :var a=ob-calc-table-2
+#+BEGIN_SRC calc :results silent verbatim :var a=ob-calc-table-2
 	a*2 - 2
 #+END_SRC"
 (should (equal "[0, 2, 4, 6, 8]"
@@ -93,7 +93,7 @@ (ert-deftest ob-calc/matrix-correct-conv-column ()
 | 2 |
 | 3 |
 
-#+BEGIN_SRC calc :results silent :var a=ob-calc-table-3
+#+BEGIN_SRC calc :results silent verbatim :var a=ob-calc-table-3
 	a
 #+END_SRC"
 (should (equal "[[1], [2], [3]]"
@@ -105,11 +105,45 @@ (ert-deftest ob-calc/matrix-correct-conv-row ()
 #+NAME: ob-calc-table-2
 | 1 | 2 | 3 | 4 | 5 |
 
-#+BEGIN_SRC calc :results silent :var a=ob-calc-table-2
+#+BEGIN_SRC calc :res

Re: Cannot yank media when image come from Gnome screenshot

[Visuwesh]

[திங்கள் ஜனவரி 20, 2025] Ihor Radchenko wrote:

> Ihor Radchenko  writes:
>
>>> Ihor> Yes, behind version check, pgtk build check, and, ideally, after
>>> Ihor> checking that such method is not yet defined.
>>>
>>> The cl-defmethod itself checks itʼs being run in a pgtk emacs, so not
>>> sure we need more than that.
>>
>> The idea is to avoid modifying things outside Org mode unless strictly
>> necessary.
>
> Looks like this patch is not happening unless somebody else (who
> actually uses Emacs GTK build) steps up and creates it against Org mode.
> Visuwesh?

I will have a look when I have time.  (I don't use the GTK build
though.)