Dates in headlines

Dates in headlines

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

I think I've read somewhere that it is a "bad practice" to use dates in 
headlines, is it correct? I haven't found it in the manual.

Like:

**** <2022-06-29 mi. 10:30> Meeting

Best regards

[-- Attachment #2: Type: text/html, Size: 602 bytes --]

Re: Dates in headlines

[Jean Louis]

On 2022-06-28 12:06, Ypo wrote:
> I think I've read somewhere that it is a "bad practice" to use dates
> in headlines, is it correct? I haven't found it in the manual.
> 
> Like:
> 
> **** <2022-06-29 mi. 10:30> Meeting
> 
> Best regards

In many of my notes I use dates in titles of the section. Note creation 
is not always equal to date to which not relates. When it is useful, use 
it.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Dates in headlines

[Samuel Wales]

this iirc has been obsolete for many years and ime and on ml never was
an issue.  i tried to find out why it was mentioned but did not find
anything.  it might have been an ambiguity in the manual to do with
active tses like in your example?  e.g. the agenda will remove the
active ts at least in certain cases, but that is a deliberate feature.

i successfully rely on inactive as below.  they are sorted by the ts.
a capture template inserts them.

much better than date trees for my case.  always show, sorted at
bottom, no hierarchy, nothing out of sync, can scan and bisect to find
an entry or get a sense of number, can change a ts and sort again,
looks the same in the agenda, etc.


***** LOG [2021-07-01 Thu] vulcans mediating with klingons
***** LOG [2021-06-28 Mon 15:44] brawl.  scottie of course :(.
***** LOG [2021-06-28 Mon 15:44] hauled away AS garbage?
***** LOG [2021-06-28 Mon 15:44] klingons said garbage scow


On 6/28/22, Ypo <ypuntot@gmail.com> wrote:
> I think I've read somewhere that it is a "bad practice" to use dates in
> headlines, is it correct? I haven't found it in the manual.
>
> Like:
>
> **** <2022-06-29 mi. 10:30> Meeting
>
> Best regards
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Dates in headlines

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

Thanks, Jean and Samuel, I will keep using them without remorse then :-)

Best regards!



El 28/06/2022 a las 23:13, Jean Louis escribió:
 > On 2022-06-28 12:06, Ypo wrote:
 >> I think I've read somewhere that it is a "bad practice" to use dates
 >> in headlines, is it correct? I haven't found it in the manual.
 >>
 >> Like:
 >>
 >> **** <2022-06-29 mi. 10:30> Meeting
 >>
 >> Best regards
 >
 > In many of my notes I use dates in titles of the section. Note 
creation is not always equal to date to which not relates. When it is 
useful, use it.

El 29/06/2022 a las 1:23, Samuel Wales escribió:
> this iirc has been obsolete for many years and ime and on ml never was
> an issue.  i tried to find out why it was mentioned but did not find
> anything.  it might have been an ambiguity in the manual to do with
> active tses like in your example?  e.g. the agenda will remove the
> active ts at least in certain cases, but that is a deliberate feature.
>
> i successfully rely on inactive as below.  they are sorted by the ts.
> a capture template inserts them.
>
> much better than date trees for my case.  always show, sorted at
> bottom, no hierarchy, nothing out of sync, can scan and bisect to find
> an entry or get a sense of number, can change a ts and sort again,
> looks the same in the agenda, etc.
>
>
> ***** LOG [2021-07-01 Thu] vulcans mediating with klingons
> ***** LOG [2021-06-28 Mon 15:44] brawl.  scottie of course :(.
> ***** LOG [2021-06-28 Mon 15:44] hauled away AS garbage?
> ***** LOG [2021-06-28 Mon 15:44] klingons said garbage scow
>
>
> On 6/28/22, Ypo<ypuntot@gmail.com>  wrote:
>> I think I've read somewhere that it is a "bad practice" to use dates in
>> headlines, is it correct? I haven't found it in the manual.
>>
>> Like:
>>
>> **** <2022-06-29 mi. 10:30> Meeting
>>
>> Best regards
>>

[-- Attachment #2: Type: text/html, Size: 2726 bytes --]

Re: Dates in headlines

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

I found it again:

"If the headline contains a timestamp, it is removed from the link, 
which results in a wrong link—you should avoid putting a timestamp in 
the headline."

https://orgmode.org/manual/Handling-Links.html#FOOT28



> ------------------------------------------------------------------------
> this iirc has been obsolete for many years and ime and on ml never was
> an issue.  i tried to find out why it was mentioned but did not find
> anything.  it might have been an ambiguity in the manual to do with
> active tses like in your example?  e.g. the agenda will remove the
> active ts at least in certain cases, but that is a deliberate feature.
>
> i successfully rely on inactive as below.  they are sorted by the ts.
> a capture template inserts them.
>
> much better than date trees for my case.  always show, sorted at
> bottom, no hierarchy, nothing out of sync, can scan and bisect to find
> an entry or get a sense of number, can change a ts and sort again,
> looks the same in the agenda, etc.
>
>
> ***** LOG [2021-07-01 Thu] vulcans mediating with klingons
> ***** LOG [2021-06-28 Mon 15:44] brawl.  scottie of course :(.
> ***** LOG [2021-06-28 Mon 15:44] hauled away AS garbage?
> ***** LOG [2021-06-28 Mon 15:44] klingons said garbage scow
>
>
> On 6/28/22, Ypo<ypuntot@gmail.com>  wrote:
> >/I think I've read somewhere that it is a "bad practice" to use dates in/
> >/headlines, is it correct? I haven't found it in the manual./
> >
> >/Like:/
> >
> >/**** <2022-06-29 mi. 10:30> Meeting/
> >
> >/Best regards/
> >
> *From*: 	Samuel Wales
> *Subject*: 	Re: Dates in headlines
> *Date*: 	Tue, 28 Jun 2022 16:23:02 -0700
>

[-- Attachment #2: Type: text/html, Size: 2663 bytes --]

Re: Dates in headlines

[Ihor Radchenko]

Ypo <ypuntot@gmail.com> writes:

> I found it again:
>
> "If the headline contains a timestamp, it is removed from the link, 
> which results in a wrong link—you should avoid putting a timestamp in 
> the headline."
>
> https://orgmode.org/manual/Handling-Links.html#FOOT28

Unless I miss something, this footnote is plain wrong. The timestamps
are not removed. At least not when I run M-x org-store-link on a
headline with timestamp with emacs -Q.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Numbered footnotes in the manual interfere with diff (was: Dates in headlines)

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

>> https://orgmode.org/manual/Handling-Links.html#FOOT28
>
> Unless I miss something, this footnote is plain wrong. The timestamps
> are not removed. At least not when I run M-x org-store-link on a
> headline with timestamp with emacs -Q.

I think we should just remove this footnote.

Bastien,
Do you have any suggestion on how to deal with changing footnotes in the
manual? When I delete this footnote, all the footnotes must be
re-numbered creating a lot of garbage in the diff. Is it ok? Or should
we prefer inline footnote definitions in the manual to avoid such
situations?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Numbered footnotes in the manual interfere with diff

[Bastien]

Ihor Radchenko <yantar92@gmail.com> writes:

> Do you have any suggestion on how to deal with changing footnotes in the
> manual? When I delete this footnote, all the footnotes must be
> re-numbered creating a lot of garbage in the diff. Is it ok? Or should
> we prefer inline footnote definitions in the manual to avoid such
> situations?

I propose to use inline footnotes for notes of one paragraph and to
use regular footnotes for notes spanning over more than one paragraph.
This will enhance both diffs readability and that of the manual's .org
source.

WDYT?

-- 
 Bastien

Re: Numbered footnotes in the manual interfere with diff

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Do you have any suggestion on how to deal with changing footnotes in the
>> manual? When I delete this footnote, all the footnotes must be
>> re-numbered creating a lot of garbage in the diff. Is it ok? Or should
>> we prefer inline footnote definitions in the manual to avoid such
>> situations?
>
> I propose to use inline footnotes for notes of one paragraph and to
> use regular footnotes for notes spanning over more than one paragraph.
> This will enhance both diffs readability and that of the manual's .org
> source.
>
> WDYT?

All the footnotes only span a single paragraph.
However, multiple footnotes span several sentences and thus look
cumbersome when inlined.

Should we just inline the one-sentence footnotes?

Also, there is one footnote that is indexed (does it even work?):

#+findex: org-date
#+findex: org-anniversary
#+findex: org-cyclic
#+findex: org-block

[fn:60] When working with the standard diary expression functions, you

I am not attaching the patch. Instead, you can run M-:
(yant/replace-all-footnotes) inside doc/org-manual.org


(defun yant/replace-footnote-with-def (fn)
  "Replace FN footnote-reference with inline footnote.
Move point to the end of the FN."
  (goto-char (org-element-property :end fn))
  (when (and (org-element-property :label fn)
	     (eq (org-element-type fn) 'footnote-reference))
    (let ((definition
	    (save-excursion
	      (org-footnote-goto-definition (org-element-property :label fn))
	      (let ((def (org-element-context)))
		(org-wrap
		 (org-trim
		  (buffer-substring-no-properties
		   (org-element-property :contents-begin def)
		   (org-element-property :contents-end def)))
                 nil 1)))))
      (when definition
	(replace-region-contents
         (org-element-property :begin fn)
         (org-element-property :end fn)
         (lambda () (format "[fn:: %s]%s" definition (make-string (or (org-element-property :post-blank fn) 0) ?\s))))
        (org-fill-paragraph)))))

(defun yant/replace-all-footnotes ()
  "Replace all footnotes in buffer with their definition."
  (org-with-wide-buffer
   (goto-char (point-min))
   (while (re-search-forward org-footnote-re nil t)
     (backward-char)
     (let ((fn (org-element-context)))
       (yant/replace-footnote-with-def fn)))))


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Numbered footnotes in the manual interfere with diff

[Bastien]

Hi Ihor,

Ihor Radchenko <yantar92@gmail.com> writes:

> Should we just inline the one-sentence footnotes?

Yes, this would be a progress already.

> Also, there is one footnote that is indexed (does it even work?):

AFACT it does not work and I think it should not work, we can remove
these index entries.

-- 
 Bastien

Re: Numbered footnotes in the manual interfere with diff

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

> Hi Ihor,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Should we just inline the one-sentence footnotes?
>
> Yes, this would be a progress already.

Done.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0641ece57b9d980b63e3a3bb6dc4d467eff3051b

I also documented this in doc/Documentation_Standards.org

>> Also, there is one footnote that is indexed (does it even work?):
>
> AFACT it does not work and I think it should not work, we can remove
> these index entries.

Instead of removing, I moved the entries to the footnote reference.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=180966c645547bf8e0f78ea28d63a686a286d2b2

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Numbered footnotes in the manual interfere with diff

[Bastien]

Ihor Radchenko <yantar92@gmail.com> writes:

> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0641ece57b9d980b63e3a3bb6dc4d467eff3051b
>
> I also documented this in doc/Documentation_Standards.org

Great, thank you.

>>> Also, there is one footnote that is indexed (does it even work?):
>>
>> AFACT it does not work and I think it should not work, we can remove
>> these index entries.
>
> Instead of removing, I moved the entries to the footnote reference.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=180966c645547bf8e0f78ea28d63a686a286d2b2

Even better, thanks.

-- 
 Bastien

Re: Numbered footnotes in the manual interfere with diff (was: Dates in headlines)

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>>> https://orgmode.org/manual/Handling-Links.html#FOOT28
>>
>> Unless I miss something, this footnote is plain wrong. The timestamps
>> are not removed. At least not when I run M-x org-store-link on a
>> headline with timestamp with emacs -Q.
>
> I think we should just remove this footnote.

Done on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5adde9f3fed4e0d1003860002f21c827276f1d19

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Dates in headlines

[Max Nikulin]

On 19/08/2022 12:58, Ihor Radchenko wrote:
> Ypo writes:
> 
>> I found it again:
>>
>> "If the headline contains a timestamp, it is removed from the link,
>> which results in a wrong link—you should avoid putting a timestamp in
>> the headline."
>>
>> https://orgmode.org/manual/Handling-Links.html#FOOT28
> 
> Unless I miss something, this footnote is plain wrong. The timestamps
> are not removed. At least not when I run M-x org-store-link on a
> headline with timestamp with emacs -Q.

I have realized that "first wins" parsing principle (consider +a =b+ 
c*d=) may mean a problem for timestamp at the end of link text. So

     [[file:test.txt][Test [2023-01-28 Sat]]]

requires a zero-width space after the bracket closing the timestamp. The 
same is applicable to fuzzy link to headings. So either

     [[*Heading \[2023-01-28 Sat\]][Heading [2023-01-28 Sat]​]]
ZWS in between--------------------------------------------^^

or

     [[*Heading \[2023-01-28 Sat\]]]

should be used. `org-insert-link' handles it correctly, but when typing 
links from keyboard, users should be aware of such kind of pitfall. So 
timestamps in headings may be source of some inconvenience.

May it happen that in some old Org version timestamps at the end of 
headings were removed due by code intended to handle statistics cookie 
[1/10]?

Re: Dates in headlines

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> May it happen that in some old Org version timestamps at the end of 
> headings were removed due by code intended to handle statistics cookie 
> [1/10]?

I do not see how.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Dates in headlines

[Max Nikulin]

On 03/02/2023 03:37, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> May it happen that in some old Org version timestamps at the end of
>> headings were removed due by code intended to handle statistics cookie
>> [1/10]?
> 
> I do not see how.

A patch for `org-store-link' tests reminded me about this topic. The 
footnote on dates in heading title was added in response to

Links to datestamped headings broken? Thu, 24 Feb 2011 16:49:14 +1300
https://list.orgmode.org/86pqqi9jnp.wl%25sguest@bayfield-high.school.nz/T/#u

3765304c8 2011-06-28 15:30:50 +0200 Bastien Guerry: doc/org.texi: 
footnote: don't put timestamps in headlines.

however removing of timestamps was dropped during migration to org-element:

a0be28eeb 2012-12-22 23:06:08 +0100 Bastien Guerry: org.el 
(org-make-org-heading-search-string): Rewrite using org-element.el

Cleaning up of statistics cookies, tags, comment and todo keywords were 
re-added, but timestamps are preserved since that commit.

Re: Dates in headlines

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> A patch for `org-store-link' tests reminded me about this topic. The 
> footnote on dates in heading title was added in response to
>
> Links to datestamped headings broken? Thu, 24 Feb 2011 16:49:14 +1300
> https://list.orgmode.org/86pqqi9jnp.wl%25sguest@bayfield-high.school.nz/T/#u
>
> 3765304c8 2011-06-28 15:30:50 +0200 Bastien Guerry: doc/org.texi: 
> footnote: don't put timestamps in headlines.
>
> however removing of timestamps was dropped during migration to org-element:

I have removed this footnote in 5adde9f3f.
Are you saying that there are still some bugs related to this topic?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Dates in headlines

[Max Nikulin]

On 18/07/2023 16:24, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> The footnote on dates in heading title was added in response to
>>
>> Links to datestamped headings broken? Thu, 24 Feb 2011 16:49:14 +1300
>>
>> 3765304c8 2011-06-28 15:30:50 +0200 Bastien Guerry: doc/org.texi:
>> footnote: don't put timestamps in headlines.
>>
>> however removing of timestamps was dropped during migration to org-element:
> 
> I have removed this footnote in 5adde9f3f.
> Are you saying that there are still some bugs related to this topic?

My intention was just to explain origin of that footnote and to confirm 
that it was an obsolete one. I have no idea why timestamps were removed 
while storing links to headings in the initial Org mode commit. Perhaps, 
the change to preserve timestamps was not intentional, but since it 
happened a decade ago and nobody has complained, there is no point in 
changing current behavior.