Re: [FR] A more general case than footnotes

[Maske]

Hi Ihor

It seems Rick gave a step towards the direction of links to points? It 
would seem that if the Search Option would be available for internal 
links, it would work. Then maybe we would just miss a convenient way for 
generating unique <>.


Bests.

On 09/10/2023 13:24, Ihor Radchenko wrote:

Maske  writes:


See:
-
-
-

The idea is not new, but we need someone to implement it one way or another.

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

https://list.orgmode.org/orgmode/118435e8-0b20-46fd-af6a-88de8e19f...@app.fastmail.com/
  

Rick is suggesting the use of internal links with the search option of 
file links. I believe this would be a positive step towards improving 
the linking ecosystem. By relying on unique IDs rather than file names, 
these links would remain functional even if headings are refiled or 
files are moved.

However, I don't see the need for ID inheritance.


https://list.orgmode.org/orgmode/cajniy+ovd0ncwzztpit5t7wvsblbgllxzmpub5tgq3gshsg...@mail.gmail.com/
  



Hello Alan.
It is possible to achieve this by utilizing the Search Option of file 
links. For instance, you can link to the point 
<<20231014T033851.173165>> from any other file using the following 
format: [[file:~/xx.org::20231014T033851.173165]]



https://list.orgmode.org/orgmode/CAJcAo8s=cjNY-7-mA1zQk3R9HEWYreTatdVeHfJ39ccM9=k...@mail.gmail.com/
  

Hi, Samuel. A similar approach is feasible, but it involves using file 
links instead of internal links.




I propose links to arbitrary points in different files.  > > Furthermore, I think it would be a very nice new feature, probably 

more > opinions than mine should be heard.

Link 

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin  writes:

>> May you elaborate? I am not talking about implementation details, but
>> about the reasonable defaults for the export. Not necessary ASCII, but
>> other backends as well.
> I am rather skeptical concerning a variant that is pleasant to read in 
> all cases. That is why I suggest to provide tools that allow to 
> customize export accordingly their writing styles.

Maybe then we can simply provide default :export for html and latex, but
nothing else?

> ASCII is a special case since it uses end note style to present link 
> targets.
>
> Whether code is added before link description or after it, either 
> parenthesis are used or not, the following functions may be convenient 
> for Org and for users:
> - export argument as inline source block
> - add an item to ASCII list of links

I wouldn't oppose improving ox-ascii API. Feel free to submit a patch.

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

>> What about [[Link][link]]?
>
> That makes Org documents hard to read in *plain text*, that is without
> the "descriptive links" fontification.  Here is my note again, compare:
>
> EXAMPLE 1: Hard-to-read, unhelpful markup:
>
>   The set of [[Cellular membrane][cellular membrane]]-bound
>   [[Organelle][organelle]]s inside of the [[Eukaryotic cell][eukaryotic
>   cell]] that work together on the synthesis and distribution of
>   [[Protein][protein]]s and [[Lipid][lipid]]s.
>
> EXAMPLE 2: Lightweight, helpful markup:
>
>   The set of [[cellular membrane]]-bound [[organelle]]s inside of the
>   [[eukaryotic cell]] that work together on the synthesis and
>   distribution of [[protein]]s and [[lipid]]s.

Note that there is generally no guarantee that [[name]] link will be
exported as "name" by any particular backend. Your workaround with
num:nil is just a workaround that may or may not work in future.

>> Judging from your example, I am not sure if it is an actual problem
>> with Org mode. I am still to see a use case when case-insensitivity
>> would be useful. Now, I am inclined to fix the docstring (and possibly
>> the manual), clarifying about case-sensitivity of the internal links.
>
> For me, this is not only "an actual problem with Org" but the biggest
> problem, and the only big problem, I have with Org.
>
> As a markup language, Org is "99% there" in having some of the *most
> practical* plain text [[link]]s available, but then falls short on case
> sensitivity, ending up with the exact opposite.
>
> Now, I could use descriptive links, which hide the [[Wart][wart]] behind
> fontification tricks, but that would not solve my problem.  Why?  I need
> to use other plain text tools, such as Git, with my densely linked Org
> documents.

I can see how this can be helpful in certain scenarios.
I made headline and radio target link matching case-insensitive on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ed42dc34a
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ec2399330

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

Re: [BUG] Inactive interval is not correctly displayed in agenda view (was: [BUG?] Org-agenda doesn't work with this error : Search failed: "\]+\)>")

[Cletip Cletip]

Very cool, thanks !

Le mer. 11 oct. 2023 à 11:03, Ihor Radchenko  a écrit :

> Ihor Radchenko  writes:
>
> >> if I have the following heading :
> >>
> >> * A test
> >>  [2023-10-10 Tue 17:25]--[2023-10-10 Tue 17:30]
> >>  <2023-10-10 Tue 17:25>--<2023-10-10 Tue 17:30>
> >>
> >> The "org interval" are not respected for the inactive timestamp. See
> what
> >> is the result in org-agenda :
> >>
> >>  17:25-17:30   A test
> >>  17:25-17:25  [ A test
> >>  17:30-17:30  [ A test
> >>
> >> The first line is what I want : a beginning hour, with a end. But, the
> two
> >> other are not normal : it must be the same line.
> >
> > I can reproduce. Indeed looks odd.
> > I will look closer at this problem later.
>
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e1569918c
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Add new word before an org-agenda entry (like "MODIFIED")

[Cletip Cletip]

I know how to create a custom agenda block, but how insert this ? Can I
just have some leads ?

Le jeu. 12 oct. 2023 à 13:39, Ihor Radchenko  a écrit :

> Cletip Cletip  writes:
>
> > Here's an example for clarification:
> > Consider this line in org-agenda:
> >
> > 14:08-14:10 Clocked: (0:02) name-of-the-heading
> >
> > I want exactly the same thing, but not with the "Clocked" word !
>
> This is not easy. The supported log types are hard-coded in
> `org-agenda-get-progress'.
>
> You may need to implement a custom agenda block type to achieve what you
> want.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Add new word before an org-agenda entry (like "MODIFIED")

[Ihor Radchenko]

Cletip Cletip  writes:

> I know how to create a custom agenda block, but how insert this ? Can I
> just have some leads ?

No, I did not mean custom agenda block. I meant custom agenda block
_type_ (just like agenda, alltodo, tags, etc).

Implementing a new custom block type involves writing a lot of Elisp.
Basically, you will need to write a custom version of, for example,
`org-tags-view' function that will collect, insert, and format text into
agenda buffer. It is the most generic, lowest level customization of Org
agenda.

After you have such function, you can use it in
`org-agenda-custom-commands' as

("key" "Agenda name" my-custom-agenda-type-function "Argument passed to your 
function"
  ...)

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

[PATCH] Fix :var parameter for fish shell code blocks

[Elias Kueny]

>From 0d8067348d033e159a460233773e442c0775a8bb Mon Sep 17 00:00:00 2001
From: Elias Kueny 
Date: Sat, 14 Oct 2023 00:20:55 +0200
Subject: [PATCH] lisp/ob-shell.el: Adapt the `:var' header parameter to fish

* ob-shell.el (org-babel-variable-assignments:shell): allow the `:var'
keyword on fish code blocks to work with fish variables.

The fish shell uses the syntax `set variable value' instead of
`value=value' to set a shell variable.  This caused org-babel to
return an syntax error when attempting to execute a fish code block
with a `:var' parameter.  This change adds a helper function to use
the correct format.

TINYCHANGE
---
 lisp/ob-shell.el | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
index fe4c7af72..9f3b614e6 100644
--- a/lisp/ob-shell.el
+++ b/lisp/ob-shell.el
@@ -167,6 +167,11 @@ defun org-babel--variable-assignments:sh-generic
   "Return a list of statements declaring the values as a generic variable."
   (format "%s=%s" varname (org-babel-sh-var-to-sh values sep hline)))

+(defun org-babel--variable-assignments:fish
+(varname values &optional sep hline)
+  "Return a list of statements declaring the values as a fish variable."
+  (format "set %s %s" varname (org-babel-sh-var-to-sh values sep hline)))
+
 (defun org-babel--variable-assignments:bash_array
 (varname values &optional sep hline)
   "Return a list of statements declaring the values as a bash array."
@@ -212,8 +217,11 @@ defun org-babel-variable-assignments:shell
(if (string-suffix-p "bash" shell-file-name)
 	   (org-babel--variable-assignments:bash
 (car pair) (cdr pair) sep hline)
- (org-babel--variable-assignments:sh-generic
-	  (car pair) (cdr pair) sep hline)))
+ (if (string-suffix-p "fish" shell-file-name)
+	 (org-babel--variable-assignments:fish
+  (car pair) (cdr pair) sep hline)
+   (org-babel--variable-assignments:sh-generic
+	(car pair) (cdr pair) sep hline
  (org-babel--get-vars params

 (defun org-babel-sh-var-to-sh (var &optional sep hline)
--
2.41.0

Hello,

I found an issue with fish shell code blocks, in that the `:var' parameter 
generates a command that is not syntaxically correct. Fish uses `set variable 
value' instead of `variable = value'. As a result, org-babel throws an error 
when executing the code block. This patch fixes this by adding an exception to 
org-babel-variable-assignments:shell on the model of what it already does for 
bash.

Example of code block triggering the error:
#+begin_src fish :var test
echo $test
#+end_src

Best regards,
Elias

Re: Event management

[Rainer Hansen]

Ihor Radchenko  writes:
> In the absence of an API, the best I can see you can do is automating
> the cleanup. Either using text manipulation in Elisp or some kind of
> HTML parsing library (for example, see
> https://github.com/yantar92/org-capture-ref/blob/master/org-capture-ref.el#L1026
> where I extract some metadata from various HTML pages).

thanks for the answer and for sharing the link to the example. Yes,
automating the cleanup is the way to go. I will try to automate the
cleanup. 

[BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

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.


I have a repeatedly-scheduled TODO with this entry for the schedule:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

The TODO is marked with 'sometag'.

In the regular agenda view (C-a a) I narrow with /sometag.
Then S-I to start the clock.
Finally, t and C-c C-c to close today's action.

The result is that the agenda shows the current time (in this case 9:41)
instead of the correct 6 minutes. Note that the task's LOGBOOK entry
correctly shows 0:06 minutes.

I expected to see the usual 6 minutes for the task in the agenda view.
Today is the first time I noticed this anomaly, but perhaps it has been
happening previously?
Not sure if this is new as of today: [2023-10-14 Sat 09:47] (CDT time)

A sample task:
* TODO sometask with sometag :sometag:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

Emacs : GNU Emacs 30.0.50 (build 40, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)

of 2023-10-14
Package: Org mode version 9.7-pre (release_9.6.10-840-g9fcbd1 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2

org-columns--summary-mean-time [BUG]

[Sławomir Grochowski]

Dear All,

I'm not sure if this is a bug or I need to change something?

(org-columns--summary-mean-time '("17:00" "18:00") nil) ;=> "17:30" ; ok
(org-columns--summary-mean-time '("22:00" "02:00") nil) ;=> "12:00" ;
should be 00:00
(org-columns--summary-mean-time '("22:00" "03:00") nil) ;=> "12:30" ;
should be 00:30

What do you think?

Regards,
Sławomir Grochowski

Re: org-columns--summary-mean-time [BUG]

[Ihor Radchenko]

Sławomir Grochowski  writes:

> I'm not sure if this is a bug or I need to change something?
>
> (org-columns--summary-mean-time '("17:00" "18:00") nil) ;=> "17:30" ; ok
> (org-columns--summary-mean-time '("22:00" "02:00") nil) ;=> "12:00" ;
> should be 00:00
> (org-columns--summary-mean-time '("22:00" "03:00") nil) ;=> "12:30" ;
> should be 00:30

The function computes mean duration. I see nothing wrong.

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

Re: org-columns--summary-mean-time [BUG]

[Sławomir Grochowski]

In ex. I want to have an average time when I go to bed.
So on Monday I went to bed at 22:00 and on Tuesday at 02:00.
So the average time would be midnight 00:00.
But it returns 12:00 which is noon.





On Sat, Oct 14, 2023 at 8:50 PM Ihor Radchenko  wrote:

> Sławomir Grochowski  writes:
>
> > I'm not sure if this is a bug or I need to change something?
> >
> > (org-columns--summary-mean-time '("17:00" "18:00") nil) ;=> "17:30" ; ok
> > (org-columns--summary-mean-time '("22:00" "02:00") nil) ;=> "12:00" ;
> > should be 00:00
> > (org-columns--summary-mean-time '("22:00" "03:00") nil) ;=> "12:30" ;
> > should be 00:30
>
> The function computes mean duration. I see nothing wrong.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: org-columns--summary-mean-time [BUG]

[Ihor Radchenko]

Sławomir Grochowski  writes:

> In ex. I want to have an average time when I go to bed.
> So on Monday I went to bed at 22:00 and on Tuesday at 02:00.
> So the average time would be midnight 00:00.
> But it returns 12:00 which is noon.

As I said, it is because it does not calculate an average time of the
day, but an average duration:

 ‘@mean’Arithmetic mean of ages (in days/hours/mins/seconds).

You can customize `org-columns-summary-types' to have a column summary
you need for your purposes.

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

Re: org-columns--summary-mean-time [BUG]

[Sławomir Grochowski]

But I'm talking about:
(":mean" . org-columns--summary-mean-time)
not  ("@mean" . org-columns--summary-mean-age).

So this is the right function (":mean" . org-columns--summary-mean-time)?
Or do I need to write a new one?

On Sat, Oct 14, 2023 at 9:19 PM Ihor Radchenko  wrote:

> Sławomir Grochowski  writes:
>
> > In ex. I want to have an average time when I go to bed.
> > So on Monday I went to bed at 22:00 and on Tuesday at 02:00.
> > So the average time would be midnight 00:00.
> > But it returns 12:00 which is noon.
>
> As I said, it is because it does not calculate an average time of the
> day, but an average duration:
>
>  ‘@mean’Arithmetic mean of ages (in days/hours/mins/seconds).
>
> You can customize `org-columns-summary-types' to have a column summary
> you need for your purposes.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: org-columns--summary-mean-time [BUG]

[Ihor Radchenko]

Sławomir Grochowski  writes:

> But I'm talking about:
> (":mean" . org-columns--summary-mean-time)
> not  ("@mean" . org-columns--summary-mean-age).
>
> So this is the right function (":mean" . org-columns--summary-mean-time)?
> Or do I need to write a new one?

I think you still need to write a new one.

@mean works on (1) timestamps; (2) durations, while :mean works only on
durations.

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

Re: org-columns--summary-mean-time [BUG]

[Sławomir Grochowski]

Now I get it. Thank you for explanation.


On Sat, Oct 14, 2023 at 9:39 PM Ihor Radchenko  wrote:

> Sławomir Grochowski  writes:
>
> > But I'm talking about:
> > (":mean" . org-columns--summary-mean-time)
> > not  ("@mean" . org-columns--summary-mean-age).
> >
> > So this is the right function (":mean" . org-columns--summary-mean-time)?
> > Or do I need to write a new one?
>
> I think you still need to write a new one.
>
> @mean works on (1) timestamps; (2) durations, while :mean works only on
> durations.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>