Re: [ANN] Org mode 9.7 is out

[Juergen Fenn]

Am 03.06.24 um 07:06 Uhr schrieb 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.
>

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

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

BTW, Org identifies with a rather longish string that used to be shorter
in Org 9.6:

Org mode version 9.7.2 (release_N/A-N/A-88dd2c @
/Users/juergenfenn/.emacs.d/elpa/org-9.7.2/)

Regards,
Jürgen.

Structure templates moving point

[Psionic K]

As of 9.7.2

Using `org-insert-structure-template' to add comment blocks to a
document where I previously added comment blocks is moving the point
to unrelated comments, and definitely not to the body of the block
that was just inserted.

The display buffer behavior is at least no longer creating frames I
didn't want, but shouldn't it be a pop-up buffer?

Likely to workaround by adding more snippets and disabling the command.

Re: [PATCH] Add support for shortdoc link type

[Bruno Cardoso]

On 2024-05-17, 11:55 -0300, Bruno Cardoso  wrote:

> On 2024-05-16, 17:58 +0700, Max Nikulin  wrote:
>>
>> Thank you. Now your patch can be applied on my side as well.
>>
>> Please, proceed with the copyright agreement form.
>
> Thank you very much, Max. Just sent the form.

Hi all. My copyright assignment with the FSF is complete.

[BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

[Suhail Singh]

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.


Any code block in a language that isn't intended to be executed results in a
warning from 'suspicious-language-in-src-block checker.  For instance:

#+begin_src conf
  [Unit]
  Description=Blah
#+end_src

In the above example, conf-mode exists and is used by Org to provide
syntax highlighting and yet, org-lint reports a warning.

Emacs  : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @ 
/home/user/.emacs.d/elpa/org-9.7.2/)
-- 
Suhail

[BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

[Suhail Singh]

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

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

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


When there is, say, an "example" result block that is indented (i.e.,
the entire block including the delimiters is indented) and it contains
some asterisks in the middle, org-lint considers it to be a possible
case of misplaced-heading.  Case in point:

#+begin_src org
  - Some words
,#+begin_example
  this is a line with asterisks** in the middle
,#+end_example
#+end_src

The lint check should guard against occurrences that happen within code
blocks.

Emacs  : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @ 
/home/user/.emacs.d/elpa/org-9.7.2/)
-- 
Suhail

Re: [FR] Adding explicitly negative :results Type option

[Ihor Radchenko]

Weaver Marquez  writes:

> There is behavior that only happens if `:results' Type is not set at all.
> I'd like to request a new Type option that would easily negate a
> default arg without having to clear the default header args variable.
>
> By Type, I mean these:
> 
>
> Case 1: With no default header args
>   , elisp
>   | (concat "My String")
>
>   , result
>   | My String
>
> Case 2: With default `:results scalar'
>
>   , elisp
>   | (concat "My String")
>
>   , result
>   | "My String"
> ...
> I think this would be useful even if the better solution is getting used
> to setting buffer/header local variables. It could also help library authors
> ensure that a certain code block like above will work as intended.

What about introducing an additional :results Type option - :results
auto? We will also make it the default.

Then, you can use :results auto to override whatever result type is
inferred from parent heading/global option/variable.

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

Re: [PATCH 1/2] org-capture: Allow entry template to start without heading

[Ihor Radchenko]

Ihor Radchenko  writes:

> I have improved your patches a little, fixing the regular expression
> used to match headings ("^*" is not accurate, you need
> org-outline-regexp-bol), and adding another test case.
> See the attached.
>
> Before I install the patches, may I know if you have FSF copyright
> assignment? See https://orgmode.org/worg/org-contribute.html#copyright

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0c8fba93f
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a62f75c84

I added you to the contributor list:
https://git.sr.ht/~bzg/worg/commit/05c4acae

Thanks for your contribution!

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

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

[Ihor Radchenko]

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

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

Re: [PATCH] org-test: Fix zone-dependent miscalculation of days of week

[Ihor Radchenko]

Kyle Meyer  writes:

>> If my guess is right, there will always be some timezone where a given
>> number seconds from epoch is a different day...
>> I am not sure how to address this problem.
>
> How about my patch?  Notice that format-time-string is invoked with ZONE
> set to t so that TIME is always taken as UTC.
> ...
> ;;; locale en_US.UTF-8
> ;; local time zone (Japan in this demo)
> (format-time-string "%A %T %z" 259200) => "Sunday 09:00:00 +0900"
> ;; force UTC
> (format-time-string "%A %T %z" 259200 t) => "Sunday 00:00:00 +"

Oops. I missed that you added `t' argument.
It indeed makes sense.
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=de0df5b92

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

Re: How to contribute to the brazilian Org-Mode community

[Ihor Radchenko]

Kauê Patrick de Oliveira  writes:

> I am a brazilian student at University of São Paulo. Currently, I'm doing a
> project with my professor in which I create presentations for classes using
> Org-Mode and, especially, the Beamer Export feature. Now, I want to
> contribute to the brazilian Org-Mode community (through the translate of
> part of the Org manual or another guide, for example), but I don't know
> how. I would be extremely grateful if someone could point me in the right
> direction.

Thanks for your interest!

Here are some instructions on how to approach translations:
https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/translations/README

However, be warned that translating something as big as Org mode manual,
may be a daunting task for one person. You may consider starting from
something shorter, like
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/orgcard.tex
or
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-guide.org

Another option is helping to translate Org mode web page. Here is an
example of Chinese translation:
https://git.sr.ht/~bzg/orgweb/tree/master/item/zh-CN
(you do not need to use PO files here; we currently do not have
infrastructure for PO files in Org website).

You may also proofread the existing translations we have for Org mode
export. See the values (C-h v) of `org-export-dictionary' and
`org-clock-clocktable-language-setup'.

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

Re: What might ‘org-element-at-point’ be doing in *scratch*?

[Christian Moe]

Ihor Radchenko  writes:

> Christian Moe  writes:
>
>> After upgrading to 9.7.1 on Emacs 27.1, I get a curious warning on Emacs
>> start-up:
>>
>> "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org
>> buffer # (fundamental-mode)"
>>
>> It does not happen with 'emacs -Q', but it also did not happen before
>> the upgrade, so I don't know what in my configuration now triggers it,
>> or why anything would want to do this.
>
> Try M-x debug-on-entry org-element-at-point and you may then get clues
> from the backtrace.

Thanks! Nothing the matter with Org; pardon the noise.  Culprit found:
some old code of mine that called org-get-id on load for bad reasons,
and which Emacs has so far suffered in silence.

Yours,
Christian

Re: What might ‘org-element-at-point’ be doing in *scratch*?

[Ihor Radchenko]

Christian Moe  writes:

> After upgrading to 9.7.1 on Emacs 27.1, I get a curious warning on Emacs
> start-up:
>
> "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org
> buffer # (fundamental-mode)"
>
> It does not happen with 'emacs -Q', but it also did not happen before
> the upgrade, so I don't know what in my configuration now triggers it,
> or why anything would want to do this.

Try M-x debug-on-entry org-element-at-point and you may then get clues
from the backtrace.

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

What might ‘org-element-at-point’ be doing in *scratch*?

[Christian Moe]

Hi,

After upgrading to 9.7.1 on Emacs 27.1, I get a curious warning on Emacs
start-up:

"Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org
buffer # (fundamental-mode)"

It does not happen with 'emacs -Q', but it also did not happen before
the upgrade, so I don't know what in my configuration now triggers it,
or why anything would want to do this.

Anyone else seeing this?

Yours,
Christian

Re: [BUG] Attachments not resolved correctly from symlinked Org files

[Ihor Radchenko]

Ihor Radchenko  writes:

> What about the approach we already use in
> `org-attach-id-to-path-function-list' - check if an attachment directory
> already exists, generated using any rule, and only if not, create a new?
>
> Similarly, in `org-attach-dir', we can first check local attachment
> directory and return it if it exists. Then, we check attachment
> directory for the symlink source, and return it when it exists.
> If none exists, create attachment locally or relative to the symlink
> source, according to some customization. The default will be creating
> locally, to follow the existing behavior.

See the attached tentative patch.

>From add9e512fa80e53bfa396ebc4d0bdf35b3bee089 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Tue, 4 Jun 2024 11:30:44 +0200
Subject: [PATCH] org-attach-dir-from-id: Search existing attachments for
 symlinks

* lisp/org-attach.el (org-attach-dir-from-id): When current buffer
displays a symlinked file, search for existing attachments in the
original file dir.
* etc/ORG-NEWS (=org-attach= now considers symlinked files when
searching pre-existing attach dirs): Announce the change.

Reported-by: Karthik Chikmagalur 
Link: https://orgmode.org/list/87seyydnf7.fsf@localhost
---
 etc/ORG-NEWS   |  8 
 lisp/org-attach.el | 39 +--
 2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4b0b77ca8..4ac88f139 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -41,6 +41,14 @@ all the references are resolved in the generated png.
 # This also includes changes in function behavior from Elisp perspective.
 
 ** Miscellaneous
+*** =org-attach= now considers symlinked files when searching pre-existing attach dirs
+
+When Org buffer is opened from a symlink, Org mode looks into the
+original file directory when searching if an attach directory already exists.
+This way, attachments will remain accessible when opening symlinked Org file.
+
+When no attach dir exists, Org mode will still prefer creating it in
+the "default" directory - where the symlink is located.
 
 * Version 9.7
 
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 16f6e1e29..d4bff03ad 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -433,22 +433,42 @@ (defun org-attach-dir-get-create ()
   (make-directory attach-dir t))
 attach-dir))
 
-(defun org-attach-dir-from-id (id   existing)
+(defun org-attach-dir-from-id (id  existing)
   "Return a folder path based on `org-attach-id-dir' and ID.
 Try id-to-path functions in `org-attach-id-to-path-function-list'
 ignoring nils.  If EXISTING is non-nil, then return the first path
-found in the filesystem.  Otherwise return the first non-nil value."
+found in the filesystem.  Otherwise return the first non-nil value.
+
+The existing paths are searched in
+1. `org-attach-id-dir';
+2. in \"data/\" dir - the default value of `org-attach-id-dir';
+3. if current buffer is a symlink, (1) and (2) searches are repeated
+   in the `default-directory' of symlink target."
   (let ((fun-list org-attach-id-to-path-function-list)
 (base-dir (expand-file-name org-attach-id-dir))
-(default-base-dir (expand-file-name "data/"))
+(fallback-dirs (list (expand-file-name "data/")))
 preferred first)
+(when (and (buffer-file-name)
+   (file-symlink-p (buffer-file-name)))
+  (let ((default-directory
+ (file-name-directory
+  (file-truename (buffer-file-name)
+(cl-pushnew (expand-file-name org-attach-id-dir) fallback-dirs)
+(cl-pushnew (expand-file-name "data/") fallback-dirs)))
+(setq fallback-dirs (delete base-dir fallback-dirs))
+(setq fallback-dirs (seq-filter #'file-directory-p fallback-dirs))
 (while (and fun-list
 (not preferred))
   (let* ((name (funcall (car fun-list) id))
  (candidate (and name (expand-file-name name base-dir)))
- ;; Try the default value `org-attach-id-dir' as a fallback.
- (candidate2 (and name (not (equal base-dir default-base-dir))
-  (expand-file-name name default-base-dir
+ ;; Try the default value `org-attach-id-dir', and linked
+ ;; dirs if buffer is a symlink as a fallback.
+ (fallback-candidates
+  (and name (mapcar
+ (lambda (dir) (expand-file-name name dir))
+ fallback-dirs)))
+ (fallback-candidates
+  (seq-filter #'file-directory-p fallback-candidates)))
 (setq fun-list (cdr fun-list))
 (when candidate
   (if (or (not existing) (file-directory-p candidate))
@@ -456,10 +476,9 @@ (defun org-attach-dir-from-id (id   existing)
 (unless first
   (setq first candidate)))
   (when (and existing
- candidate2
- (not (file-directory-p