Re: incorrect documentation for file-desc header argument?

[Eric S Fraga]

On Wednesday, 29 Jul 2020 at 01:03, Kyle Meyer wrote:
> So, I'd say this is a documentation bug.

Yes or else many of my org files would cease to work as intended!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-682-geac255

org-mode 9.3 links gnus

[Joseph Vidal-Rosset]

Hello,

With org-mode  9.3 I have  not solved the  problem of links  for getting
emails in the Archives messages ("Tous les messages");

The following  function in my setup  provide a link that  fails. I quote
it:

;; Merci à  Bob Newell , avec ce code, le lien de l'email est modifié 
correctement dès l'usage de la fonction refile C-c C-w
  (defun jr/fix-the-link (&rest args)
 (interactive)
 (save-excursion
   (find-file "~/Dropbox/Orgzly/todo.org")
   (goto-char (point-min))
   (while (search-forward "gnus:INBOX#" nil t)
 (replace-match "gnus:\\[Gmail\\]/Tous les messages#"))
   (save-buffer)))
(advice-add 'org-capture-finalize :after #'jr/fix-the-link)

;; si cela échoue, cette fonction peut prendre le relai:

(defun hs/replace ()
   (interactive)
   (goto-char 1)
   (let ((search-invisible t)) (replace-string "gnus:INBOX#" 
"gnus:\\[Gmail\\]/Tous les messages#")))
(define-key global-map (kbd "C-c r") 'hs/replace)

I get this error message:

gnus-select-newsgroup: Couldn’t activate group \[Gmail\]/Tous les messages: NO 
(NONEXISTENT) Unknown Mailbox: \[Gmail\]/Tous les messages (Failure) [2 times]


I had not this problem with org-mode 9.1,  and I do not know if there is
a solution, in spite of this message:

https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00065.html

Your help is welcome !

Best wishes,

Jo.

Re: Repeating task hourly

[Gustavo Barros]

Hi Kyle, Hi Kevin,

On Tue, 28 Jul 2020 at 22:29, Kyle Meyer  wrote:

> Kevin Liu writes:
>
>>> Is there any way to do this or are the docs out of date?
>>
>> I made a few quick changes to org-habit and it works prima facie.  Will
>> continue testing for a bit.
>
> The hourly repeater came in ec921a2a6 (Support hourly repeat cookies,
> 2012-04-20), well after the "less than 1d" guard was added in
> org-habit.el.  So, perhaps it'd make sense to update org-habit.el to
> support hour repeaters, particularly if habit users say there's a need.
>
> As a non-habit user reading through (info "(org)Tracking your habits"),
> I'm a bit worried that your patch only works superficially.  That node
> talks about "graphs that show every day" and "colors for each day"; does
> that sort of logic break down with your proposed changes?

As far as I know, indeed, org-habit provides essentially a consistency
graph, which shows in the agenda the regularity of the task for a
certain period, being the day the least (and only) unit of the graph (1
day = 1 character).

I don't think the proposed change would break anything (just a cursory
look though) but, unless I'm missing something Kevin has in mind, I
don't see how it would be of use, because an hourly repeater cannot
really be properly conveyed in the consistency graph of org-habit.  So,
as far as I understand, there is nothing wrong either in the
documentation or in org-habits.  It is just that habits tasks are a
particular kind of repeating task, and tasks that repeat in frequencies
smaller than a day cannot be properly represented in the consistency
graphs, though they work as documented in other cases.

Kevin, how do you see an hourly repeater would work with org-habit's
consistency graph?  Or, more generally, what would be the purpose of an
hourly repeated habit task?

Best,
Gustavo.

Re: org-mode 9.3 links gnus

[Eric S Fraga]

On Wednesday, 29 Jul 2020 at 12:01, Joseph Vidal-Rosset wrote:
>  (replace-match "gnus:\\[Gmail\\]/Tous les messages#"))

I wonder whether you have too many \\ (or even any) in this and the
similar replace-string that comes later?  Why do you have these at all?
The string argument to both replace-match and replace-string [1] is not
a regexp so [] do not mean anything special.

Have you tried with just "gnus:[Gmail]/..."?

eric

Footnotes:
[1] and according to the documentation, replace-string should only be
 used interactively and you should use replace-match instead.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-682-geac255

Re: org-mode 9.3 links gnus

[Joseph Vidal-Rosset]

Hi Eric,

You are probably right, I guess a change between 9.1 and 9.3 on this point.
I just downgraded to emacs 26.1 and to org-mode 9.1 because I also noticed
that org-export-head https://github.com/itf/org-export-head i.e. the org
blog exporter that I am using does not work with org-mode 9.3,
unfortunately, and Ivan has no time to adapt this tool to the last release
of org-mode. That's too bad...

Best wishes,

Jo.

Le mer. 29 juil. 2020 à 13:37, Eric S Fraga  a écrit :

> On Wednesday, 29 Jul 2020 at 12:01, Joseph Vidal-Rosset wrote:
> >  (replace-match "gnus:\\[Gmail\\]/Tous les messages#"))
>
> I wonder whether you have too many \\ (or even any) in this and the
> similar replace-string that comes later?  Why do you have these at all?
> The string argument to both replace-match and replace-string [1] is not
> a regexp so [] do not mean anything special.
>
> Have you tried with just "gnus:[Gmail]/..."?
>
> eric
>
> Footnotes:
> [1] and according to the documentation, replace-string should only be
>  used interactively and you should use replace-match instead.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-682-geac255
>

Re: Repeating task hourly

[Gustavo Barros]

Hi Kevin,

On Wed, 29 Jul 2020 at 11:46, Kevin Liu  wrote:


On 29 July 2020 04:06, Gustavo Barros  wrote:


Kevin, how do you see an hourly repeater would work with org-habit's
consistency graph?  Or, more generally, what would be the purpose of 
an

hourly repeated habit task?


An example of an hourly repeated habit task is exercise.  You might 
want

to stretch in the morning and then again at night.

You raise a good point that the consistency graph isn't as useful as 
it
could be.  All it shows now is that the habit was done at least once 
on

that day.  I think this is still a little useful, if only to visually
separate a habit from other tasks on the agenda.  It could be made 
more

useful by replacing the * with a count of the number of times the task
was done that day, but that would be another patch.


I get why a task (exercising, taking medicine, etc) is usefully repeated 
a number of times a day, of course.  But a regular repeating task is 
perfectly fine for this.  Furthermore, considering the only thing 
org-habit does is to provide the consistency graph for the task, and if 
this does not really work for hourly repeaters, I still don't see the 
gain here.  And there would be other ways, in my view more appropriate 
ones, to separate some tasks, if that's desired.  IMHO, what you are 
proposing is just eliminating an error message which was deliberately 
placed there by the author, considering what org-habit is designed to 
do.  But this is just an user speaking, take this as a data point.


Anyway, you have replied just for me, off-list.  I presume you meant 
otherwise, and your point is relevant in the list, so I reincluded the 
CCs to it.


Best,
Gustavo.

Re: Repeating task hourly

[Kevin Liu]

On 29 July 2020 08:15, Gustavo Barros  wrote:

> Furthermore, considering the only thing org-habit does is to provide
> the consistency graph for the task, and if this does not really work
> for hourly repeaters, I still don't see the gain here.  And there
> would be other ways, in my view more appropriate ones, to separate
> some tasks, if that's desired.  IMHO, what you are proposing is just
> eliminating an error message which was deliberately placed there by
> the author, considering what org-habit is designed to do.  But this is
> just an user speaking, take this as a data point.

The graph works for hourly repeaters in exactly the same way as it works
in all other cases.  It illustrates whether the task was done on a given
day.

The gain is being able to use org-habit at all with hourly repeating
tasks.  At the moment, this is unnecessarily precluded, and not even by
the error I removed; the actual error that pops up if you build the
agenda with an hourly habit is rather cryptic:

if: Invalid duration string: .+5h

As Kyle mentioned, I don't think authorial intent counts for a whole lot
here since the code was last touched in 2009, years before hourly
repeaters were added.

Re: Repeating task hourly

[Gustavo Barros]

On Wed, 29 Jul 2020 at 12:41, Kevin Liu  wrote:

The graph works for hourly repeaters in exactly the same way as it 
works
in all other cases.  It illustrates whether the task was done on a 
given

day.


But what will happen is that the task will be both "done" and "due" on 
the same day.  Which face shall org-habit use?  Which symbol?  The task 
will be shown in the agenda, all right, whether the consistency graph is 
meaningful is another matter.


As Kyle mentioned, I don't think authorial intent counts for a whole 
lot

here since the code was last touched in 2009, years before hourly
repeaters were added.


I'm not so sure.  Take a look at commit be2806d281 "Fixes to the 
consistency graph in org-habit", by John Wiegley, in 2009-10-22.


There the following error check was then introduced:

   (unless (> sr-days 0)
 (error "Habit's scheduled repeat period is less than 1d"))

Considering `sr-days' was then let-bound with:

   (scheduled-repeat (org-get-repeat "SCHEDULED"))
   (sr-days (org-habit-duration-to-days scheduled-repeat))

And that `org-habit-duration-to-days' performs its conversion of the 
repeaters to days with `floor', I'd say it is pretty deliberate.  If 
this was before the introduction of hourly repeaters, I'd take this to 
be even more meaningful, not less.


Best,
Gustavo.

custom time format extension

[Orm Finnendahl]

Hi,

 when exporting timestamps it always bothered me that timestamps with
start and end time on the same day got exported with a full date for
the start and end times separated by a dash.

After thinking about this for some time I implemented a method today,
which combines the advantage of being utmost flexible while
maintaining full backwards compatibility.

This is how it works: The cdr of org-time-stamp-custom-formats
normally contains a format string for formatting timestamps with
start/end time. When supplying a list of three strings instead of the
single format string to the cdr of org-time-stamp-custom-formats, the
first, second and third elements of that list are interpreted as
follows:

The first element is the full format in case start and end of the
timestamp are not on the same day. The second element of the list is
the format string for the start time of the timestamp. The third
element of the list is a format string for the end time of the
timestamp. (BTW: Supplying a list as second element of a dotted list
is equivalent to supplying a list with four strings to
org-time-stamp-custom-formats)

Below the mail is a short example for german date strings.

In case somebody is interested, I can provide the code off list. If
any of the maintainers is reading on this list and thinks it should
get revised and maybe adopted for orgmode, please let me know how to
issue pull requests for the code. I tried to be minimally invasive ;-)

--
Orm

---
Example:

(org-time-stamp-custom-formats '("%a %d.%m.%Y" . ("%a %d.%m.%Y %H:%M Uhr"
  "%a %d.%m.%Y %H:%M"
  "%H:%M Uhr")))

Formatting

<2020-11-21 Sa>  -> Sa 21.11.2020

<2020-11-21 Sa 10:00-18:00>  -> Sa 21.11.2020 10:00--18:00 Uhr


<2020-11-21 Sa 10:00>--<2020-11-22 So 18:00> -> Sa 21.11.2020 10:00 Uhr--So 
22.11.2020 18:00 Uhr

Re: incorrect documentation for file-desc header argument?

[Matt Huszagh]

Kyle Meyer  writes:

> Yeah, that looks to be the intended result of that thread.  That
> thread's patch was applied with a58a4f0ad (new source block header
> argument :filelinkdescr, 2012-03-27).  However, shortly after, that
> treatment was intentionally changed (670c7f31c, 2012-03-31):
>
> simplified implementation of :file-desc header argument
>   
> This will no longer insert the value of the :file header argument as
> the description if the description is left blank (as this changes
> the meaning of the :file header argument).
>   
> The desc handling logic is moved to the `org-babel-result-to-file'
> function.
>
> So, I'd say this is a documentation bug.

Thanks for the clarification Kyle. I've attached a patch that I believe
clarifies the documentation to match the current behavior.

Matt
>From a9cd13f3d7b120a24b3416f8f8ba0892a8e47221 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Tue, 28 Jul 2020 22:10:12 -0700
Subject: [PATCH] org-manual.org: Modify file-desc header argument to match
 action

---
 doc/org-manual.org | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b61644626..0f012d4df 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17436,9 +17436,8 @@ default behavior is to automatically determine the result type.
 
   #+cindex: @samp{file-desc}, header argument
   The =file-desc= header argument defines the description (see
-  [[*Link Format]]) for the link.  If =file-desc= has no value, Org
-  uses the generated file name for both the "link" and
-  "description" parts of the link.
+  [[*Link Format]]) for the link.  If =file-desc= has no value, the
+  "description" part of the link will be omitted.
 
   #+cindex: @samp{sep}, header argument
   By default, Org assumes that a table written to a file has
-- 
2.27.0

Re: incorrect documentation for file-desc header argument?

[Kyle Meyer]

Matt Huszagh writes:

> Thanks for the clarification Kyle. I've attached a patch that I believe
> clarifies the documentation to match the current behavior.

Thank you.  Applied (521d7f5fe), tweaking the commit message a bit to
align more closely with the conventions described at
.

Re: WIP: Org-plot work

[TEC]

I now have a more complete patch set if any maintainers would be 
ready to receive and review it.


TEC  writes:


Hi All,

I’ve just finished re-working my modifications to org-plot into what I hope is a
form that may (in 9.5?) be merged at some point.
I stayed up later that I wanted getting this finished, so I’ll save the 
monolouge
on what I’ve done for later, but I thought I’d share the current state of my
efforts for anyone interested.

If that’s you, please let me know what you think :)

All the best,

Timothy.