Re: [BUG] org-element-context doesn't recognize link inside property drawer [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Gustavo Barros  writes:

> When a link is placed as a property value, `org-element-context' does
> not recognize it as a link.

It is expected and intentional: 
https://list.orgmode.org/orgmode/877d8llha9@nicolasgoaziou.fr/.

> In particular, the "link" element is not present, as would be the case
> if the exact same link were not inside the property drawer. On the
> other hand, the link is active (fontified, works, etc.). Thus,
> `org-element.el` and `ol.el` seem to disagree as to what that part of
> the buffer actually is.

This is intentional. org-agenda and fontification deliberately recognize
links in more contexts compared to org-element and export. Same for
timestamps. For example, see `org-at-timestamp-p'.

For ol.el, the links are open inside property drawer for convenience.
Below is a code responsible for this case from `org-open-at-point':

   ;; No valid link at point.  For convenience, look if something
   ;; looks like a link under point in some specific places.
   ((memq type '(comment comment-block node-property keyword))
(call-interactively #'org-open-at-point-global))

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

[FR] Should we preserve point when calling `org-open-at-point' (C-c C-o) on a heading (was: [BUG] Point position with org-open-at-point on a heading [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1

[Ihor Radchenko]

Gustavo Barros  writes:

> When point is on a heading, `org-open-at-point' offers to open links
> in the subtree. This is a very useful feature, and I use it a lot.
> However, in this case, `org-open-at-point' not only opens the link,
> but also moves point to said link. Perhaps there's some reason why
> point is not preserved in this case. But for me at least, this is not
> what I'd expect, and I find it somewhat disrupting, especially when
> I'm working on a folded tree (defeats speed keys, etc.).

I see no particular reason.

> How about adding a `save-excursion' for this case inside `org-open-at-point'?

+1.
But maybe others have objections.

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

Re: Case insensitivity of simple [[links]]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> A while ago, I asked about case insensitivity of the syntactically
> simplest "[[links]]" in Org.  I am interested in using these links
> because they are the most practical with the "literal" view.
>
> In 'emacs -Q' Org 9.6.9, "[[links]]" are case _sensitive_ when looking
> for headings.  This was originally not the case, and case _insensitive_
> linking was broken in Org 7 and then fixed in Org 8, as per [1] and [2].
> Is it broken again?  I ask because 'org-link-search' documentation says
> that search is "case-insensitive and ignores white spaces".

Currently, headline matching in `org-link-search' and
`org-export-resolve-fuzzy-link' is case-sensitive.

> On top of the above, yesterday I noticed that
>
>   (setq org-link-search-must-match-exact-headline nil)
>
> makes "[[link]]" find "* Link" when clicked.  My joy was short-lived,
> however, as I soon found that I cannot export anything due to
>
>   org-export-data: Unable to resolve link: "link".

This is because of different reason - Org export is not able to export
fuzzy links that do not point to a named target:

(defun org-export-resolve-fuzzy-link (link info &rest pseudo-types)
  "Return LINK destination.

INFO is a plist holding contextual information.

Return value can be an object or an element:

- If LINK path matches a target object (i.e. <>) return it.

- If LINK path exactly matches the name or results affiliated keyword
  (i.e. #+NAME: path or #+RESULTS: name) of an element, return that
  element.

- If LINK path exactly matches any headline name, return that
  element.

- Otherwise, throw an error.

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

Re: [BUG] org-element-context doesn't recognize link inside property drawer [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]

[Gustavo Barros]

Hi Ihor,

On Sat, 23 Sept 2023 at 05:28, Ihor Radchenko  wrote:
>
> Gustavo Barros  writes:
>
> > When a link is placed as a property value, `org-element-context' does
> > not recognize it as a link.
>
> It is expected and intentional: 
> https://list.orgmode.org/orgmode/877d8llha9@nicolasgoaziou.fr/.
>
> > In particular, the "link" element is not present, as would be the case
> > if the exact same link were not inside the property drawer. On the
> > other hand, the link is active (fontified, works, etc.). Thus,
> > `org-element.el` and `ol.el` seem to disagree as to what that part of
> > the buffer actually is.
>
> This is intentional. org-agenda and fontification deliberately recognize
> links in more contexts compared to org-element and export. Same for
> timestamps. For example, see `org-at-timestamp-p'.
>
> For ol.el, the links are open inside property drawer for convenience.
> Below is a code responsible for this case from `org-open-at-point':
>
>;; No valid link at point.  For convenience, look if something
>;; looks like a link under point in some specific places.
>((memq type '(comment comment-block node-property keyword))
> (call-interactively #'org-open-at-point-global))

I didn't know that. Thanks for the detailed answer.

Best,
Gustavo.

Re: [FR] Should we preserve point when calling `org-open-at-point' (C-c C-o) on a heading (was: [BUG] Point position with org-open-at-point on a heading [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/

[Gustavo Barros]

Hi Ihor,

On Sat, 23 Sept 2023 at 05:32, Ihor Radchenko  wrote:
>
> I see no particular reason.
>

Thanks for the reply.

> +1.
> But maybe others have objections.

And for the support. :-)

Best,
Gustavo.

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

[Ihor Radchenko]

Visuwesh  writes:

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

Thanks for the patch!
See my comments below.

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

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

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

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

Maybe org-yank-image-save-type?

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

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

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

[Ihor Radchenko]

Suhail Singh  writes:

> Ihor Radchenko writes:
>
>> I am a bit confused. What do you mean by "git author date" and "git
>> commit date"?
>
> In the output of `git log --pretty=fuller`, there is AuthorDate which is
> distinct from CommitDate. In case unfamiliar, an elaboration on the
> distinction: .

I see now.
But do you actually use one but not other in practice?

>> I think that we should use an alternative approach. Both "git time" and
>> "fs time" are only an approximation. The true decision to re-publish an
>> article should be triggered by article text being modified. So, we may
>> better decide based on the file text hash, not the modification times.
>
> For it to work, the "file text hash" would have to also take into
> account the "file text hash" of included files, or the decision to
> re-publish would have to be predicated on the hash of included files as
> well. I.e., the equivalent of this logic in
> org-publish-cache-file-needs-publishing :
>
>   (let ((mtime (org-publish-cache-mtime-of-src filename)))
> (or (time-less-p pstamp mtime)
> (cl-some (lambda (ct) (time-less-p mtime ct))
>  included-files-mtime)))

And the code right above the quoted already looks into INCLUDEs. It
should not be too hard to add buffer hash calculation there.

> But assuming the existence of equivalent logic, yes something like a
> file hash would work. In fact, at least in the case of git, the VCS
> could even be queried for it (via git hash-object).

Probably an overkill. It will only work for files without includes and
force us to use exactly the same hash algorithm.

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

Re: [FR] Should we preserve point when calling `org-open-at-point' (C-c C-o) on a heading (was: [BUG] Point position with org-open-at-point on a heading [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/

[Max Nikulin]

On 23/09/2023 15:33, Ihor Radchenko wrote:

Gustavo Barros writes:

Perhaps there's some reason why
point is not preserved in this case. But for me at least, this is not
what I'd expect, and I find it somewhat disrupting, especially when
I'm working on a folded tree (defeats speed keys, etc.).


I see no particular reason.


Maybe the following is a false alarm. I hope `save-excursion' will not 
break the "RET to open all" option, `org-open-at-point' is called 
recursively this case.


I am not an active user of this feature. I tried it likely in the 
context of another discussion and faced some issues. Perhaps that 
heading had several links to other locations in the same file and I did 
not get a window per link.

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

[Suhail Singh]

Ihor Radchenko writes:

> But do you actually use one but not other in practice?

As in, could users have a preference for one vs the other in practice?
Yes, since the choice isn't without consequence, it's conceivable
(generally speaking) that some would prefer one over the other. FWIW, in
my specific case, I use CommitDate, but I am not convinced it's "the
right thing" in all situations.

Not having conducted a survey, I also cannot comment on the frequency
with which users have a desired preference for one vs the other. I am
also not aware of general rules where users would necessarily prefer one
over the other, but it's possible they may exist. My point was to simply
point out that there is more than one interpretation of
"vc-modification-time".

> It should not be too hard to add buffer hash calculation there.

No disagreement there.

> It will only work for files without includes and force us to use
> exactly the same hash algorithm.

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

If I understand you correctly, the logic you have in mind, would be
something like this:

- during publish, compare the file hash of the file being published as
  well as all included files
- if the values for all are the same as in the cache, don't publish (if
  user has signalled such intent via the equivalent of
  org-publish-use-timestamps-flag)
- if the value of any one is different, re-publish and update cache with
  the updated file hashes

It doesn't matter how the specific file hash is obtained, as long as the
mechanism is being used consistently and the file hash of the included
files are also being consulted in an appropriate way.

-- 
Suhail

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.

Calc/TBLFM: how to conditionally insert hours:minutes?

[Chris Keschnat]

Hi,
I am trying to understand how to set hours:minutes values in tables 
conditionally.

Just setting hours directly works:

| 40:03:00 |
| 40:03:00 |
| 40:03:00 |
#+TBLFM: $1=40:03;T

But when doing that conditionally (first row different from the others),
I do not understand the behavior:

This seemed to work:

| 19:55:00 |
| 40:03:00 |
| 40:03:00 |
#+TBLFM: $1=if(@# <= 1, 19:55, 40:03);T

But after adjusting the minutes, this happens:

| 19:55:00 |
| 00:00:40 |
| 00:00:40 |
#+TBLFM: $1=if(@# <= 1, 19:55, 40:01);T

What would be the correct way to do this?

PS: I have found that the same happens when I add parentheses:

| 40:03:00 |
| 40:03:00 |
| 40:03:00 |
#+TBLFM: $1=(40:03);T

| 00:00:40 |
| 00:00:40 |
| 00:00:40 |
#+TBLFM: $1=(40:01);T

PPS: I came across this when trying to understand the formulas here
https://github.com/clange/org-mode

Thanks
Chris

[ANN] org-super-agenda v1.3 released

[Adam Porter]

Hi all,

FYI, I've released v1.3 of org-super-agenda:

https://github.com/alphapapa/org-super-agenda/releases/tag/v1.3

It should be available on MELPA soon.

Thanks,
Adam