Re: Possible bug getting bounds of URL at point?

[Karl Fogel]

On 17 Jul 2024, Ihor Radchenko wrote:
The notion of "URL", and especially "URL at point" in Org mode 
needs to

be special. Consider something like

[[https://orgmode.org][this is a very long and /convoluted/
description of this url; all the text here is clickable as a 
link]].


Org mode will consider point anywhere inside the link as "at 
URL".

That "URL" will be https://orgmode.org, and it is indeed what
(thing-at-point 'url) will return on that link in Org mode, even 
when

point is on the link description.
Hope it makes sense.

What does not make sense in such scenario is returning
(bounds-of-thing-at-point 'url) to not include point. So, we 
instead

return the relevant syntax object - link object. And that object
includes description, brackets, and whitespace after.

There is no reason to make plain links special in this regard, so 
we

don't.


Thank you for the explanation, Ihor.

I'm sure there are people depending on the fact that the rest of 
the line, after a plain link, is still part of the same node.  My 
code does a manipulation of just the link itself -- for example, 
in one keystroke, it turns


 https://example.org/

into

 [[https://example.org/][example.org]]

In order for that to work, I needed the bounds to be the start and 
end of the link text itself.  But that was easy to do: I just 
temporarily override `bounds-of-thing-at-point-provider-alist' in 
Org Mode, so that I get the default thingatpt handler instead.


So: problem solved.

Best regards,
-Karl

Re: Possible bug getting bounds of URL at point?

[Karl Fogel]

On 16 Jul 2024, Ihor Radchenko wrote:
Assume we have this line in an Org Mode buffer (note there are 
three trailing spaces after the final "m" -- hopefully the MTAs 
and MUAs will leave those spaces there):


  https://example.com   

Let's say the initial "h" is at position 22205, the position 
right 
after the final "m" is 4, and the final position on the 
line 
(after the three spaces) is 7.


With point anywhere inside the URL, if I run 
(bounds-of-thing-at-point 'url), I currently get this result:


  (22205 . 7)

But I expected this result instead:

  (22205 . 4)

Is (22205 . 7) correct, and I'm just misunderstanding how 
URL 
boundaries are supposed to work in Org Mode?


This is correct. Trailing whitespace belongs to the preceding 
node in

Org syntax. This is not a bug.

Moreover, if you have something like
[[https//orgmode.org][description]]
the whole thing will be considered a URL.


Thank you, Ihor.

I admit that I don't immediately understand why this is a good 
thing.  The user asked for the bounds of the URL at point, but got 
instead the bounds of some other thing (the Org "node"). 
Especially in the case of a standalone URL, with no description 
text, I don't see how including the whitespace is useful.


However, there could be issues here that I'm not familiar with. 
It sounds like you've already thought this out and concluded that 
that including the trailing whitespace is the right behavior.  If 
you have time to explain why in more detail, I'd appreciate a 
chance to learn more about it.  However, if you don't have time to 
do that, it's no problem.


I can change the code I'm writing to do things a different way, so 
this behavior need not interfere with my current task, in any 
case.


Best regards,
-Karl

Possible bug getting bounds of URL at point?

[Karl Fogel]

In Org Mode buffers, `bounds-of-thing-at-point-provider-alist' 
names a Org-Mode-specific URL provider:


 ((url . org--bounds-of-link-at-point))

That handler is defined in org.el:

 (defun org--bounds-of-link-at-point ()
   "`bounds-of-thing-at-point' provider function."
   (let ((context (org-element-context)))
 (when (eq (org-element-type context) 'link)
   (cons (org-element-begin context)
 (org-element-end context)

(This is in the tree as of today, commit f2141541b45.)

I think this is causing URL boundaries to be calculated 
incorrectly.


REPRODUCTION:

Assume we have this line in an Org Mode buffer (note there are 
three trailing spaces after the final "m" -- hopefully the MTAs 
and MUAs will leave those spaces there):


 https://example.com   

Let's say the initial "h" is at position 22205, the position right 
after the final "m" is 4, and the final position on the line 
(after the three spaces) is 7.


With point anywhere inside the URL, if I run 
(bounds-of-thing-at-point 'url), I currently get this result:


 (22205 . 7)

But I expected this result instead:

 (22205 . 4)

Is (22205 . 7) correct, and I'm just misunderstanding how URL 
boundaries are supposed to work in Org Mode?


I haven't yet debugged into `org-element-end' (nor into 
`org-element-property', which is what `org-element-end' wraps). 
First I want to check that my expectations are correct.


Is there a bug here?

Best regards,
-Karl

Re: [FR] A more general case than footnotes

[Karl Fogel]

On 02 Nov 2023, Suhail Singh wrote:

Karl Fogel  writes:

My original announcement post from a year ago [2] is a good 
place to get a quick

overview of how oref.el works.

...

[2] 
https://lists.gnu.org/archive/html/emacs-humanities/2022-10/msg9.html



From [2]:
Thus, in "jones-interview.org" you might have this:

Blah blah blah and then she said that the rockets had reached 
speeds

of .3c in testing scenarios on a few occasions.  [ref:1c3a90a9]


Is it intended to be [ref:1c3a90a9] or is it supposed to be
[[ref:1c3a90a9]] (i.e., a regular link without description)?


The former: [ref:1c3a90a9]

oref.el isn't specific to Org Mode -- it's for use with any 
text-based format.  In fact, our company's typical usage involves 
references that cross between text files of different formats: 
e.g., LaTeX <--> Markdown, Org <--> DocBook Lite XML, etc.


Now, "[[ref:1c3a90a9]]" contains "[ref:1c3a90a9]" of course, so in 
an Org Mode file one could format oref origin links as regular Org 
Mode links without descriptions.  But personally I find that I'm 
never doing that -- I just put "[ref:1c3a90a9]".



On a related note, how are the references exported?


There is no provision for exporting.  That's an Org Mode concept, 
but not an oref.el concept.


Best regards,
-Karl

Re: [PATCH] Fix warning about using `eq' to compare strings.

[Karl Fogel]

On 01 Nov 2023, Ihor Radchenko wrote:

Bastien  writes:

Karl Fogel  writes:

Hi, everyone.  Small fix attached -- it just makes a warning 
go

away.


Applied against the main branch, thanks!


Unfortunately, fixing this warning breaks org-table logic and 
tests.

See previous discussion in
https://list.orgmode.org/orgmode/20230827214320.46754-1-salu...@me.com/


Oh my goodness.  That is... sigh.  Wow.

This is now beyond the "trivial fix" level of effort that I was 
prepared to invest to make this warning go away.  Like Rudolf 
Adamkovič and others before him, I now retire to my country 
estate, to simultaneously lick my wounds and rest on my laurels 
(which I guess is better than licking my laurels and resting on my 
wounds).


Thank you for noticing, and for adding the FIXME later.

Best regards,
-Karl

Re: [FR] A more general case than footnotes

[Karl Fogel]

Ihor Radchenko writes: 

Maske  writes:


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.


See:
- 
https://list.orgmode.org/orgmode/118435e8-0b20-46fd-af6a-88de8e19f...@app.fastmail.com/
- 
https://list.orgmode.org/orgmode/cajniy+ovd0ncwzztpit5t7wvsblbgllxzmpub5tgq3gshsg...@mail.gmail.com/
- 
https://list.orgmode.org/orgmode/CAJcAo8s=cjNY-7-mA1zQk3R9HEWYreTatdVeHfJ39ccM9=k...@mail.gmail.com/


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


At my company, I implemented something that (I think) does what 
Maske and those earlier threads are getting at:


https://code.librehq.com/ots/ots-tools/-/blob/main/emacs-tools/oref.el

We often use it with Org Mode files, but it's not specific to Org 
Mode -- it works with any plaintext format.  In fact, our most 
common use case is cross-referencing from precise locations in 
LaTeX files to precise locations in Org Mode files.


A couple of days ago I happened to post [1] on the Emacs 
Humanities list about a updated version of oref.el.  Maske noticed 
that post, and referred me to this thread here.


My original announcement post from a year ago [2] is a good place 
to get a quick overview of how oref.el works.


At the time I wrote oref.el, I didn't know about org-id.el.  But 
it wouldn't be too hard to make oref.el automagically compatible 
with Org ":ID:" properties.  I.e., `oref-do-ref' would jump to 
them, copy them, etc, in just the same way it currently does with 
native oref references.  And the oref ref files cache would just 
become the union of `oref-ref-files-cache' and `org-id-files'. 
While I'll hand-wave a bit on the details right now, I think there 
is a natural compatibility available.  If people are interested in 
this extension of oref.el, let me know.


Best regards,
-Karl

[1] 
https://lists.gnu.org/archive/html/emacs-humanities/2023-10/msg1.html


[2] 
https://lists.gnu.org/archive/html/emacs-humanities/2022-10/msg9.html

[PATCH] Fix warning about using `eq' to compare strings.

[Karl Fogel]

Hi, everyone.  Small fix attached -- it just makes a warning go 
away.


Best regards,
-Karl

>From a1a939191af1a195f260037510d407e7483ba05f Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Mon, 30 Oct 2023 10:33:29 -0500
Subject: [PATCH] lisp/org-table.el: fix warning about `eq' usage

* lisp/org-table.el (org-table-make-reference): Use `equal' instead of
`eq' to compare strings.

This change makes the following warning go away:

  Warning (comp): org-table.el:2867:23: \
  Warning: `eq' called with literal string that may never match (arg 2)

This change does not affect the behavior of `org-table-make-reference'
because `eq' treats all instances of the empty string as the same
object anyway, e.g., `(eq (string-trim "aaabbb" "a+" "b+") "")' ==> t.
The only effect of this change is to eliminate the warning.
---
 lisp/org-table.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index f5a433c7d..860d7720d 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -2864,7 +2864,7 @@ list, `literal' is for the format specifier L."
   (if lispp
 	  (if (eq lispp 'literal)
 	  elements
-	(if (and (eq elements "") (not keep-empty))
+	(if (and (equal elements "") (not keep-empty))
 		""
 	  (prin1-to-string
 	   (if numbers (string-to-number elements) elements
-- 
2.42.0

Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.

[Karl Fogel]

On 25 Feb 2023, Max Nikulin wrote:

On 25/02/2023 07:13, Karl Fogel wrote:

Okay, today I did some research and found that every "C-c
C-" binding is used in Org Mode except for "C-c 
C-g". While

that one is technically reserved for the mode's use


No, there is an explicit exception for C-g, see (info "(elisp) 
Key

Binding Conventions") in "Tips and Conventions" appendix.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html


Ah, thanks for pointing that out.

Even C-c C-x prefix is quite busy. Other modifiers might be a 
rescue:

C-c M-something.

However perhaps M-x with fuzzy completion allowing typos (and 
ideally

synonyms) might be a better solution.


Well, sure -- we get that for free.

I think we can consider this proposal over.  While I find 
`org-fold-hide-subtree' very useful, the Org Mode default keyspace 
is very busy already, and we don't hear anyone proposing to drop 
something else in favor of `org-fold-hide-subtree'.  Anyone can 
custom-bind it themselves, of course (which is what I'll continue 
doing).



No, [Ctrl+Tab] and [Ctrl+Shift+Tab] is widely used in other
applications to switch to next/previous tabs. I would strongly 
prefer
to keep it consistent across as much applications as 
possible. (There

are corner cases like e.g. vim with multiple tabs running in a
terminal application having several tabs as well. E.g. gnome 
terminal
is able to pass [Ctrl+PgDn], a [Ctrl+Tab] alternative, while it 
has
single tab, but intercepts the same shortcut when more terminal 
tabs

are opened, so vim keys have to be used.)


Agreed.

Best regards,
-Karl

Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.

[Karl Fogel]

Okay, today I did some research and found that every "C-c 
C-" binding is used in Org Mode except for "C-c C-g". 
While that one is technically reserved for the mode's use, I 
suspect the reason it's unbound is that people are accustomed to 
using C-g as a quit command (and they get that effect if they 
accidentally type C-c, because then they type C-g and it's just an 
undefined key -- i.e., it quits, which is what the user wanted).


Note that while "C-c C-h" does not appear to be bound, it actually 
is: it gets you a help buffer about the Org Mode keybindings 
(which then, ironically, does not list "C-c C-h" as one of the 
bindings).


(It's not clear to me whether Emacs's conventions consider "C-c 
C-i" to be a letter or whether they treat "C-i" as "TAB" and 
consider it special; based on the previous evidence in this 
thread, maybe the latter, so we shouldn't consider "C-c C-i" to be 
available.)


I think what this is telling me is that Org Mode keybinding real 
estate is quite valuable :-), and that unless there are other 
people who feel as strongly as I do that `org-fold-hide-subtree' 
is amazingly useful, we probably won't decide to bind it by 
default in Org Mode.  So I should just continue to bind it to a 
custom key myself and continue to live a glorious life all alone 
in my private keymap splendour.


Best regards,
-Karl

I wrote:

On 23 Feb 2023, Max Nikulin wrote:

On 23/02/2023 00:01, Karl Fogel wrote:

 =C2=A0(when (not (keymap-lookup nil "C-"))
 =C2=A0=C2=A0 (keymap-local-set "C-" 
 'org-fold-hide-subtree))

So FWIW C- is not bound in Org Mode buffers for me, in=20
Emacs
30.x (i.e., recent development builds).


lisp/tab-bar.el:130:  (unless (global-key-binding [(control=20
tab)])
lisp/tab-bar.el:131:(global-set-key [(control tab)]=20
#'tab-next))

Minibuffer file cache completion should not be relevant to 
Org=20

buffers.


Ah, I don't use tab-bar at all (at least not as far as I know), 
so=20

I'm not 100% sure what the above is saying.

Are you saying that the only current default binding for 
C-=20
in Emacs is that one in tab-bar.el, and therefore we should 
feel=20

free to rebind it in Org Mode?  If so, we should still be=20
cautious, since Emacs has policies for maintaining the 
keybinding=20

space.  Generally, the space "C-c C-" is reserved for=20
major modes, so ideally we should find something in there if 
we=20
can -- although Org Mode has used up a lot of that space 
already=20

:-), so I'm not sure what's left, unless we decide to swap out=20
some existing binding in favor of this one.

(I realize this contradicts what I said in my inital post.  I 
had=20

forgotten that C- was not part of the mode-reserved space.)

Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.

[Karl Fogel]

On 23 Feb 2023, Max Nikulin wrote:

On 23/02/2023 00:01, Karl Fogel wrote:

  (when (not (keymap-lookup nil "C-"))
    (keymap-local-set "C-" 'org-fold-hide-subtree))
So FWIW C- is not bound in Org Mode buffers for me, in 
Emacs

30.x (i.e., recent development builds).


lisp/tab-bar.el:130:  (unless (global-key-binding [(control 
tab)])
lisp/tab-bar.el:131:(global-set-key [(control tab)] 
#'tab-next))


Minibuffer file cache completion should not be relevant to Org 
buffers.


Ah, I don't use tab-bar at all (at least not as far as I know), so 
I'm not 100% sure what the above is saying.


Are you saying that the only current default binding for C- 
in Emacs is that one in tab-bar.el, and therefore we should feel 
free to rebind it in Org Mode?  If so, we should still be 
cautious, since Emacs has policies for maintaining the keybinding 
space.  Generally, the space "C-c C-" is reserved for 
major modes, so ideally we should find something in there if we 
can -- although Org Mode has used up a lot of that space already 
:-), so I'm not sure what's left, unless we decide to swap out 
some existing binding in favor of this one.


(I realize this contradicts what I said in my inital post.  I had 
forgotten that C- was not part of the mode-reserved space.)


Best regards,
-Karl

Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.

[Karl Fogel]

On 22 Feb 2023, Max Nikulin wrote:

On 22/02/2023 14:29, Karl Fogel wrote:
I put it on "C-" because that's normally unbound in Org 
Mode,

and because so many of the Org Mode cycling commands involve
modified tab already.


Perhaps C- is not the best choice:

9092c289b6bea38bb519e6c59a60237ae5af8f08
author Bastien Mon Jun 1 14:39:28 2020 +0200

Bind `org-force-cycle-archived' to C-c C-TAB

* lisp/org-keys.el (org-mode-map): Bind 
`org-force-cycle-archived'

to C-c C-TAB instead of C-TAB to avoid conflict with native Emacs
keybinding.


Ah, clearly it is not a good choice -- thank you for noticing 
that.


I think there are two separate questions here:

1) Would it be useful to bind `org-fold-hide-subtree' by default?

2) If yes to (1), then is there a good key to bind it to?  (C-c 
C-something, I guess.)


If we agree on (1), then let's figure out the answer to (2).  I 
don't know if anyone else agrees about (1) yet, though.


By the way, the binding in my Org Mode hook looks like this:

 (when (not (keymap-lookup nil "C-"))
   (keymap-local-set "C-" 'org-fold-hide-subtree))

So FWIW C- is not bound in Org Mode buffers for me, in Emacs 
30.x (i.e., recent development builds).  However, I agree with 
Bastien's logic: C- is not in the reserved keymap space, so 
Emacs might bind it (and perhaps does bind it in other modes).


I don't know how widely-used `org-cycle-force-archived' is (that's 
the new name of that function).  I don't use it, personally, so if 
we decide against (1)+(2) above, then perhaps I'll just override 
that binding for myself instead.


Best regards,
-Karl

PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.

[Karl Fogel]

Hey everyone, is there a reason we don't bind 
`org-fold-hide-subtree' by default in Org Mode?


I bind it to C- and now find this to be one of the most 
useful keybindings in Org Mode.  I suspect my workflow is pretty 
typical.


The use case is simple:

When reading material within a certain heading level, one often 
decides that one is done with that section (and therefore done 
with everything inside it -- including anything at deeper levels 
of nesting).  So one just folds the entire subtree around point 
and moves on, without changing the visibility of any of the 
sibling-or-higher subtrees around it (because often the next place 
one is going is one of them).


This is one of my most frequent actions in Org Mode.  In fact, I 
think it might be the most common Org Mode command I run.


It seems like an obvious thing have bound to a key, and yet Org 
Mode doesn't bind it by default.  Should we?


(I put it on "C-" because that's normally unbound in Org 
Mode, and because so many of the Org Mode cycling commands involve 
modified tab already.  But I don't feel strongly about the 
particular key, as long as it's fast to type; maybe there's a 
better key available.)


I looked for prior discussion about this in the archives and 
didn't find anything: 
https://list.orgmode.org/?q=org-fold-hide-subtree


Best regards,
-Karl

Re: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format

[Karl Fogel]

On 23 Apr 2022, Ihor Radchenko wrote:

Applied.
The patch is now on main as 67efaa739.


Thanks, Ihor!

Best regards,
-Karl

Re: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format

[Karl Fogel]

On 15 Apr 2022, Robert Pluim wrote:
On Fri, 15 Apr 2022 17:33:33 +0800, Ihor Radchenko 
 said:
   Ihor> - Org mode no longer uses ChangeLog entries to 
   document changes.
   Ihor> - Instead, special commit messages are used, as 
   described in the

   Ihor> - `CONTRIBUTE' file in the main Emacs repository.
   Ihor> + Instead, special commit messages are used.  The 
   commit message
   Ihor> + format generally follows Emacs conventions, as 
   described in the
   Ihor> + `CONTRIBUTE' file in the main Emacs repository. 
   Several more

   Ihor> + Org-specific conventions are described in
   Ihor> + 
   [[https://orgmode.org/worg/org-contribute.html#commit-messages][worg/org-contribute#commit-messages]].


It might be good to mention `magit-generate-changelog' there as 
an
easy way to produce the ChangeLog format entry (it doesnʼt 
require you
to iterate over the diff hunks, and you can call it from the 
magit

commit buffer).


I really like the patch, Ihor -- it's already a big improvement! 
(I haven't tested Robert's suggestion of 
`magit-generate-changelog', but it seems like a reasonable hint to 
include, given Magit's popularity.)


Best regards,
-Karl

Re: Removing obsolete function `org-truely-invisible-p'.

[Karl Fogel]

On 07 Apr 2022, Ihor Radchenko wrote:

Karl Fogel  writes:

Unfortunately, the 'CONTRIBUTE' file at the top level of the 
Org 
Mode source tree gives incomplete guidance on commit messages 
(it 
just says to follow what Emacs does, so I did that).  I didn't 
realize that 
https://orgmode.org/worg/org-contribute.html#commit-messages 
has 
further, slightly different guidance.


Could you elaborate?

We have the following in etc/CONTRIBUTE:


* Main contribution rules
...
See 
[[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] 
for guidance on how to contribute effectively.


Sure, I'll elaborate.

The "..." in your quoted text above contains, among other things, 
this item:


  - Org mode no longer uses ChangeLog entries to document 
  changes. 
Instead, special commit messages are used, as described in 
the `CONTRIBUTE' file in the main Emacs repository. 

That item is just one in a list of several items in section 4 
(which is under the top-level heading "Main contribution rules"). 
At the very end of the "Main contribution rules" top-level section 
comes this line:


 See 
 [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] 
 for guidance on how to contribute effectively.


So when I went searching in CONTRIBUTE specifically for guidance 
on commit messages, I searched for the string "commit message". 
That took me to the item I quote above, which states pretty 
clearly that the Emacs guidelines apply here.  It does not state 
that there is any other source of guidance about commit messages, 
nor does it say anything to indicate that Org Mode has commit 
message guidelines that are a superset of (i.e., more complicated 
than) Emacs's guidelines.  The string "commit message" does not 
appear anywhere else in Org Mode's CONTRIBUTE file.


So, naturally, after I read that item, I assumed that I was ready 
to write the commit message, since I already knew Emacs's 
guidelines.


Meanhwile, the https://orgmode.org/worg/org-contribute.html page 
is a bit long, and it starts out with a bunch of very generic 
guidance that is not useful to developer contributing a code 
patch.  (I'm not saying that material isn't useful, by the way.  I 
think it's good to have it there.  I'm just saying it doesn't 
provide anything useful to one particular demographic.  But it's 
still good because someone might be making some other kind of 
contribution.)


In that page, the part about "Commit messages and ChangeLog 
entries" starts about three-quarters of the way down.  Virtually 
none of the material preceding it had anything to do with my 
circumstances, and since I had just seen very clear guidance (in 
CONTRIBUTE) about how to write commit messages, I timed out before 
making it that far.


A good solution to this would be to revise the item in CONTRIBUTE 
to make it clear that there is special Org Mode guidance on commit 
messages that goes beyond what Emacs itself wants.  I was too 
tired to go through the process to contribute that change though, 
so instead I wrote this long email :-). 


Thanks! Merged as d80aa2776 to main.


Thank you very much!

Best regards,
-Karl

Re: Removing obsolete function `org-truely-invisible-p'.

[Karl Fogel]

On 05 Apr 2022, Ihor Radchenko wrote: 
Sorry for not being clear. I was referring to the commit message 
- it is

what you commonly see in git log.

Having something like


commit-hash Mark function obsolete & fix spelling of its name


in git log is confusing because it is unclear what the commit is
changing. If you look at
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/
then you can see that we generally follow certain style of the
commit messages: changed-file-or-library: What is changed
Also see 
https://orgmode.org/worg/org-contribute.html#commit-messages


Oh, it was clear you were referring to the commit message -- what 
I now realize is that you were referring to the first line of the 
commit message (the summary line).


Unfortunately, the 'CONTRIBUTE' file at the top level of the Org 
Mode source tree gives incomplete guidance on commit messages (it 
just says to follow what Emacs does, so I did that).  I didn't 
realize that 
https://orgmode.org/worg/org-contribute.html#commit-messages has 
further, slightly different guidance.


Thanks.  I'm happy to adhere to the local standards, once I figure 
out what they are :-).



I think we have a misunderstanding here. Unused functions are not
necessarily obsolete. For example, we have org-list-to-texinfo, 
which is
not used anywhere in the codebase, but could be useful for 
developers.


org-compat.el contains functions that are planned for removal in 
future
(and obsolete for the time being), obsolete function/variable 
names, and

compatibility functions.

As I mentioned in my previous email, I am slightly reluctant to 
remove
org-truely-invisible-p. It means that it should remain available 
and no
plans to remove it should be made (unless there are multiple 
devs/users
who prefer removal). Hence, the function should stay in 
org-macs.el.
org-macs.el is meant to store general-purpose functions that can 
be

useful for development of the whole Org mode ecosystem.

If we decide that org-truely-invisible-p stays in org-macs, we 
should

fix the issue with its name. Renaming requires creating obsolete
function name alias in org-compat.el to make sure that nothing 
gets
broken unexpectedly for people who use org-truely-invisible-p 
with its

current name.

Hope I clarified my logic.


You did!


FYI, I do not know an easy way to search mailing list archives by
Message-ID. Message-ID itself does not even provide information 
which

mailing list it is referring to (maybe it is e.g. Emacs devel).
That's why I prefer links - they can often be found using 
archive.org if

nothing.

On the other hand, extra information would not heart. In addition 
to

link.


Makes sense, yup.  Actually, I usually include the link -- I just 
didn't think of it in this case because I rarely visit the Org 
Mode mailing list archives (unlike the Emacs Devel archives, which 
I often do visit, and therefore my commits in Emacs always include 
the link when referring to a mailing list post).


A revised patch is attached.  Now it's so simple that I think the 
commit message doesn't need to point to the mailing list 
discussion anyway.  Review welcome.


Best regards,
-Karl

>From 2cef1fdbe2b2aa40a2bb081eab4b2e2808000670 Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Thu, 31 Mar 2022 19:02:38 -0500
Subject: [PATCH] lisp/org-macs.el: Fix spelling of `org-truly-invisible-p'

* lisp/org-macs.el (org-truly-invisible-p): Fix spelling of name.
* lisp/org-compat.el (org-truely-invisible-p): Add compatibility
  alias for the old name.
---
 lisp/org-compat.el | 4 
 lisp/org-macs.el   | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git lisp/org-compat.el lisp/org-compat.el
index 38d330de6..00716ae13 100644
--- lisp/org-compat.el
+++ lisp/org-compat.el
@@ -752,6 +752,10 @@ context.  See the individual commands for more 
information."
 
 (define-obsolete-function-alias 'org-get-last-sibling 
'org-get-previous-sibling "9.4")
 
+(define-obsolete-function-alias 'org-truely-invisible-p
+  'org-truly-invisible-p "9.6"
+  "Compatibility alias for legacy misspelling of `org-truly-invisible-p'.")
+
  Obsolete link types
 
 (eval-after-load 'ol
diff --git lisp/org-macs.el lisp/org-macs.el
index b39af9103..a09115e7c 100644
--- lisp/org-macs.el
+++ lisp/org-macs.el
@@ -1151,7 +1151,7 @@ fontification."
  (folding-only (memq value '(org-hide-block outline)))
  (t value
 
-(defun org-truely-invisible-p ()
+(defun org-truly-invisible-p ()
   "Check if point is at a character currently not visible.
 This version does not only check the character property, but also
 `visible-mode'."
-- 
2.35.1

Re: Removing obsolete function `org-truely-invisible-p'.

[Karl Fogel]

On 04 Apr 2022, Ihor Radchenko wrote:
From bb229b4f8f78ae52962d7bc90c8b1d4993af8263 Mon Sep 17 
00:00:00 2001

From: Karl Fogel 
Date: Thu, 31 Mar 2022 19:02:38 -0500
Subject: [PATCH] Mark function obsolete & fix spelling of its 
name


This commit message is a bit confusing. I would mention the 
function
name: "Mark `org-truely-invisible-p' obsolete and fix spelling of 
its

name"


* lisp/org-macs.el (org-truely-invisible-p): Move to...
* lisp/org-compat.el (org-truly-invisible-p): ...here, and 
add...

  (org-truely-invisible-p): ...this compatibility alias.


It does mention both names :-).  But I'm happy to rewrite in the 
style you suggest above; I was just trying to follow the 
CONTRIBUTE guidelines.



It is too much.
We can either
1. Obsolete org-truely-invisible-p. Then, there is not much point
  renaming it.
2. Rename it without obsoletion. Then, there is not much point 
moving

  the function definition to org-compat.


Hmm.  From the prior conversation in this thread, I thought we'd 
decided to do both.  There are two separate issues here:


1) The function is no longer used in Org Mode or Emacs.

2) Unrelatedly, the function's name has a misspelling.

(1) suggests that the function should be moved to 'org-compat.el' 
(if I understand correctly what that file is for).


(2) is usually fixed with a rename and a compatibility alias -- 
i.e., this is what we would do for any function, whether used or 
unused.


In your message 87h7b5rm6f.fsf@localhost of 19 Dec 2021, you 
wrote:


I feel slightly reluctant about removal. If nothing, this 
function can
be a reminder about visible-mode and keeping it has little 
downside.
Though if others think that removing would be better, I would 
also be

fine with it.

Renaming sounds reasonable. Just need to define obsolete alias 
for the

old name in org-compat.el.


My patch was based on the above, and on the fact that obsolete 
(i.e., unused) functions apparently get moved to org-compat.el, at 
least based on what I see already in that file.



  From: Ihor Radchenko
  Subject: Re: Removing obsolete function 
  `org-truely-invisible-p'.

  To: Karl Fogel
  Cc: Org Mode
  Date: Sun, 19 Dec 2021 17:14:32 +0800
  Message-ID: <87h7b5rm6f.fsf@localhost>


I usually just leave an ML link in such cases:
https://orgmode.org/list/87h7b5rm6f.fsf@localhost


As long as the ML link contains the Message-ID, as appears to be 
the case here, yeah.  Mailing list archives can move, which causes 
links to suddenly stop working.  But if the Message-ID is in the 
link, then (with a little extra work) one can always find the 
message in the new archive.


(The reason I typically include more is to make things as easy as 
possible for those who are searching in a local archive using 
their regular mailreader.  But I can switch to the above way if 
you'd prefer.)


Best regards,
-Karl

Re: Removing obsolete function `org-truely-invisible-p'.

[Karl Fogel]

On 19 Dec 2021, Ihor Radchenko wrote:

Karl Fogel  writes:

Should we just remove `org-truely-invisible-p'?  Or at least 
correct the spelling of its name ("truely" should be "truly")?


I feel slightly reluctant about removal. If nothing, this 
function can
be a reminder about visible-mode and keeping it has little 
downside.
Though if others think that removing would be better, I would 
also be

fine with it.

Renaming sounds reasonable. Just need to define obsolete alias 
for the

old name in org-compat.el.

Could you prepare a patch? Having a patch may encourage more 
feedback.


Sure; please see attached.

Best regards,
-Karl

>From bb229b4f8f78ae52962d7bc90c8b1d4993af8263 Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Thu, 31 Mar 2022 19:02:38 -0500
Subject: [PATCH] Mark function obsolete & fix spelling of its name

* lisp/org-macs.el (org-truely-invisible-p): Move to...
* lisp/org-compat.el (org-truly-invisible-p): ...here, and add...
  (org-truely-invisible-p): ...this compatibility alias.

There are no callers of this function in Org Mode, nor in current
Emacs (on the 'master and 'emacs-28' branches at least).  We discussed
whether to remove it entirely, and for now seem to have tentatively
decided not to remove it.  See this thread for more details:

  From: Ihor Radchenko
  Subject: Re: Removing obsolete function `org-truely-invisible-p'.
  To: Karl Fogel
  Cc: Org Mode
  Date: Sun, 19 Dec 2021 17:14:32 +0800
  Message-ID: <87h7b5rm6f.fsf@localhost>
---
 lisp/org-compat.el | 12 
 lisp/org-macs.el   |  7 ---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git lisp/org-compat.el lisp/org-compat.el
index 38d330de6..43d44211e 100644
--- lisp/org-compat.el
+++ lisp/org-compat.el
@@ -402,6 +402,18 @@ See `org-link-parameters' for documentation on the other 
parameters."
 (make-obsolete 'org-add-link-type "use `org-link-set-parameters' instead." 
"9.0")
 
  Functions unused in Org core.
+
+;; Not used since commit 3baf246f4f (Nicolas Goaziou, 2016-04-28)
+(defun org-truly-invisible-p ()
+  "Check if point is at a character currently not visible.
+This version does not only check the character property, but also
+`visible-mode'."
+  (unless (bound-and-true-p visible-mode)
+(org-invisible-p)))
+(define-obsolete-function-alias 'org-truely-invisible-p
+  'org-truly-invisible-p "2022-03-31"
+  "Compatibility alias for legacy misspelling of `org-truly-invisible-p'.")
+
 (defun org-table-recognize-table.el ()
   "If there is a table.el table nearby, recognize it and move into it."
   (when (org-at-table.el-p)
diff --git lisp/org-macs.el lisp/org-macs.el
index b39af9103..fb3c441e1 100644
--- lisp/org-macs.el
+++ lisp/org-macs.el
@@ -1151,13 +1151,6 @@ fontification."
  (folding-only (memq value '(org-hide-block outline)))
  (t value
 
-(defun org-truely-invisible-p ()
-  "Check if point is at a character currently not visible.
-This version does not only check the character property, but also
-`visible-mode'."
-  (unless (bound-and-true-p visible-mode)
-(org-invisible-p)))
-
 (defun org-invisible-p2 ()
   "Check if point is at a character currently not visible.
 If the point is at EOL (and not at the beginning of a buffer too),
-- 
2.35.1

Re: Org Mode "Contribute", "Maintenance" pages don't give repository.

[Karl Fogel]

On 05 Dec 2021, Daniel Fleischer wrote:
You're right; I'll think of a way to present the git repo link, 
i.e. the
code earlier and more prominently for those who just want to jump 
and

examine the code.


+1, and thanks!

Re: Org Mode "Contribute", "Maintenance" pages don't give repository.

[Karl Fogel]

On 04 Dec 2021, Daniel Fleischer wrote:
The "Contribute" page at 
https://orgmode.org/worg/org-contribute.html does not mention
git://git.sv.gnu.org/emacs/org-mode.git .  Actually, now that I 
look around, the "Maintenance" page at
https://orgmode.org/worg/org-maintenance.html doesn't mention 
the repository address either.  It does mention the word

"repository" a few times, but never actually links to it.


I've added a link to the org-maintenance page but there was a 
link in
the org-contribute, in the "Your first commit as an Org 
maintainer"
section. The git.sv.gnu.org is a shorthand for 
git.savannah.gnu.org.


Thanks for reporting this,


Thanks, Daniel!

You're right about repository link on the Contribute page.  It 
might still be good to mention it earlier, like in the "Ways that 
involve programming" section or even just in the first paragraph 
of the page.


The reason I suggest this is that often when someone is hot on the 
trail of debugging something, they haven't yet decided whether 
they want to become a contributor or not.  They just know they 
want to ook at the latest sources so they can first figure out 
more about whatever ${technical_thing} they encountered.  So 
making the latest sources very easy to find is a way of making it 
more likely that someone becomes a contributor, by removing a 
commonly-encountered barrier.


Best regards,
-Karl

Org Mode "Contribute", "Maintenance" pages don't give repository.

[Karl Fogel]

The "Contribute" page at 
https://orgmode.org/worg/org-contribute.html does not mention 
git://git.sv.gnu.org/emacs/org-mode.git .  Actually, now that I 
look around, the "Maintenance" page at 
https://orgmode.org/worg/org-maintenance.html doesn't mention the 
repository address either.  It does mention the word "repository" 
a few times, but never actually links to it.


These oversights would be pretty easy to fix (if there is 
agreement that they shoud be fixed), so I haven't attached a patch 
here.  It would be quick for someone who already maintains those 
pages to make the necessary changes.


The only place I see the repository is at the top of the home page 
of
https://orgmode.org/.  That's nice and prominent :-), but 
developers would probably expect to find the address on those 
other two pages as well.


Best regards,
-Karl

Removing obsolete function `org-truely-invisible-p'.

[Karl Fogel]

The function `org-truely-invisible-p' is defined in 
'lisp/org-macs.el', but it is not used anywhere anymore in Org 
Mode, nor is it used anywhere in GNU Emacs (I checked on both 
'emacs-28' branch and 'master' branch).


The last (and possibly only?) call to that function was removed 
from `org-beginning-of-line' in this commit:


 commit 3baf246f4f73005a4eacd7c368f7222f95d50243
 Author: Nicolas Goaziou 
 AuthorDate: Thu Apr 28 23:28:15 2016 +0200
 Commit: Nicolas Goaziou 
 CommitDate: Thu Apr 28 23:28:15 2016 +0200
 
 Handle correctly `shift-select-mode'
 
 * lisp/org.el (org-beginning-of-line): Handle correctly 
 `shift-select-mode'.
 
 Reported-by: Mathieu Marques 

 

Then, a few months later in commit 87116700e6e, Nicholas moved the 
function to 'org-macs.el', where it has been sitting unused ever 
since.


Should we just remove `org-truely-invisible-p'?  Or at least 
correct the spelling of its name ("truely" should be "truly")?


It seems fairly unlikely to me that people are using it in their 
own code, although of course I cannot be sure of that.  Partly, I 
believe that because surely someone else would have noticed the 
misspelling by now, if enough people were using it :-).


Best regards,
-Karl

Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

[Karl Fogel]

On 05 Dec 2019, Adam Porter wrote:
>Karl Fogel  writes:
>> Unless you meant make a new interactive function to display a vertical
>> hierarchy and base it on the existing Org Mode functions you informed
>> me of the existence of?  But I don't think there's a way to do that
>> without adding some new parameters to those existing functions, and,
>> as you point out, that's probably not worth the extra complexity.
>
>Forgive me, I think I misunderstood you.  Yes, I meant to make a new
>interactive function for displaying the vertical hierarchy.

Oh, I still learned things from the code you posted in your previous message, 
though, thanks.  (I didn't know about `thread-first', for example, even though 
it's been around for a while.)

Yes, what I'd meant was that ideally this would just be an interactive wrapper 
around `org-format-outline-path'.  Unfortunately there's no way to get the 
behavior I want from that function currently.  This is not a showstopper -- I 
agree with you that adding yet more arguments to that function is not a 
complexity cost worth paying here.

Another thing is that `org-get-outline-path' returns only the title portion of 
each heading, rather than the full heading.  Even though the titles are all I 
need right now, I still would normally prefer that the underlying function 
provide more generality (i.e., return the full headings) and then the caller 
would use `(nth 4 heading)' or whatever to get the part it needs.  That way if 
one wants to do something more sophisticated when displaying headings -- 
involving tags, for example -- the necessary information would be available.

Again, these are not things that need to be "solved" in Org Mode; I'm not even 
sure we should consider them to be problems.  I'm just explaining my earlier 
comment about how the existing functions in Org Mode don't provide quite the 
substrate I was hoping for for this particular task.

>BTW, you might also find the org-sticky-header package helpful.

Ah, very nice -- thank you!

(https://github.com/alphapapa/org-sticky-header, for those who want the 
convenience of the a quick link.)

Best regards,
-Karl

Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

[Karl Fogel]

On 03 Dec 2019, Adam Porter wrote:
>You might consider adjusting your fontification settings.  The
>single-line outline path can be quite readable with the right faces (see
>attached example).

That's a useful hint generally, thank you.  However, for most of the Org Mode 
files I work with, the heading lengths are pretty long, so I need vertical 
stacking in the minibuffer when displaying all the headings down to point.

>I'd recommend against adding more optional arguments to that function,
>because it already has four.  Emacs/Org already have enough problems
>with code like (org-whatever nil t nil t nil nil t).

Sure, I can see how that tradeoff might not be worth it.

>> There should also be some way to access the new functionality
>> interactively; the solution might be a new interactive wrapper
>> function with its own name, or maybe some new variables?  I don't
>> know; I haven't thought it all the way through yet.
>
>> Is there any interest in or opposition to such a patch?  I'd like to
>> get a sense of whether it would be able to land in Org Mode before I
>> start working on it.
>
>I'd recommend simply making a new interactive function, putting it in
>your personal config, and sharing it publicly (e.g. here and on
>/r/orgmode).  Use it "in anger" for a while, and solicit feedback from
>other users for a while.  Then, if it still seems widely useful enough
>to deserve being added to Org proper, apply what you've learned in the
>meantime to improve and simplify its implementation before proposing a
>patch.

Well, I already posted it here, so that's done.   Those functions are publicly 
packaged (albeit with the `ots-' prefix) here:

  https://github.com/OpenTechStrategies/ots-tools/blob/master/emacs-tools/ots.el

Unless you meant make a new interactive function to display a vertical 
hierarchy and base it on the existing Org Mode functions you informed me of the 
existence of?  But I don't think there's a way to do that without adding some 
new parameters to those existing functions, and, as you point out, that's 
probably not worth the extra complexity.

>You might also consider sending it to my "unpackaged.el" repo, which
>might make a good home for it: http://github.com/alphapapa/unpackaged.el

That's a nice collection!  I'm enjoying browsing through it.

I effectively already have a personal unpackaged-elisp repository at 
https://svn.red-bean.com/repos/kfogel/trunk/.emacs (if these functions weren't 
already in 'ots-tools', they'd be there).

Best regards,
-Karl

Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

[Karl Fogel]

On 03 Dec 2019, Adam Porter wrote:
>This seems to duplicate functionality from org-get-outline-path.  As
>well, org-eldoc displays in the minibuffer the outline path for the
>heading at point.

Thank you, Adam -- I didn't know about those.  I had searched for something 
like that before implementing my own, but I think I searched using the term 
"heading" or something instead of "outline", unfortunately, so I never found 
them.

Now that I know about `org-display-outline-path', the one improvement I'd like 
to make is to enable it to display the headings with per-level indentation, and 
treat the first level specially (with an anchoring dot instead of a directional 
arrow), as my code did.  It's a lot more readable that way displayed in the 
minibuffer.

I suppose I would implement this by adding two new optional arguments to 
`org-display-outline-path':

  * `per-level-indentation': add a newline followed by  in front of each SEPARATOR

  * `level-1-prefix': a special prefix for the first level's heading

...and make corresponding changes to the helper functions of course.  There 
should also be some way to access the new functionality interactively; the 
solution might be a new interactive wrapper function with its own name, or 
maybe some new variables?  I don't know; I haven't thought it all the way 
through yet.

Is there any interest in or opposition to such a patch?  I'd like to get a 
sense of whether it would be able to land in Org Mode before I start working on 
it.

Best regards,
-Karl

Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

[Karl Fogel]

On 03 Dec 2019, Adam Porter wrote:
>This seems to duplicate functionality from org-get-outline-path.  As
>well, org-eldoc displays in the minibuffer the outline path for the
>heading at point.

By the way, when I run `M-x eldoc-mode' in a Org Mode buffer, I get this 
message:

  "There is no ElDoc support in this buffer"

Am I doing it wrong?

[PROPOSAL] New function `org-headings-to-point' and displayer.

[Karl Fogel]

Hi.  I've been using this for a while and find it very handy.

If people like this and want it in Org Mode, I'll do the rest of the work to 
package it up as a patch, with ChangeLog entry, NEWS, etc, and post it here for 
review before committing.

To try it out, just evaluate both functions and then run

  `M-x org-display-headings-to-point'

from somewhere deep in an org subtree.  Comments/feedback welcome.

Best regards,
-Karl

(defun org-headings-to-point ()
  "Return all the Org Mode headings leading to point."
  (when (not (eq major-mode 'org-mode))
(error "ERROR: this only works in Org Mode"))
  (let ((headings (list (org-heading-components
(save-excursion
  (save-match-data
(save-restriction
  (widen)
  (while (org-up-heading-safe)
(setq headings (cons (org-heading-components) headings)
  headings)))

(defun org-display-headings-to-point ()
  "Display Org Mode heading titles from level 1 to current subtree.
Display each title on its own line, indented proportionally to its level."
  (interactive)
  (let* ((heading-titles (mapcar (lambda (heading)
   (nth 4 heading))
 (org-headings-to-point)))
 (level 0)
 (hierarchy (mapcar (lambda (title)
  (prog1
  (if (zerop level)
  (concat "• " title)
(concat "\n" 
(make-string (* level 2) ? )
"→ " title))
(setq level (1+ level
heading-titles)))
(display-message-or-buffer (string-join hierarchy

Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

On 02 Dec 2019, Marco Wahl wrote:
>Karl Fogel  writes:
>> Since `widen' itself is already available via C-x n w, it might be
>> better to save a special flag value like that for some special
>> behavior that we (or someone else) might think of in the future.  I'm
>> pretty sure that anyone using `org-narrow-to-subtree' must also know
>> about the `widen' command, too.
>
>Okay, this sounds sound.
>
>Let me be a bit more explicit about my wish: I vote for the prefix arg 0
>to widen because this fits to the logic to view the whole file as level
>0 subtree.  With this perspective on the feature the effect of a numeric
>prefix argument is clear as day:
>
>...
>C-u 2 M-x org-narrow... => Narrow to the level-2 subtree containing point.
>C-u 1 M-x org-narrow... => Narrow to the level-1 subtree containing point.
>C-u 0 M-x org-narrow... => Narrow to the level-0 subtree containing point.
>
>The last line stands in opposition to the current behavior.
>
>C-u 0 M-x org-narrow... => Narrow to the level-1 subtree containing point.
>^  ^

Oh, yes, I get the logic, from a consistency standpoint.

My only concern is that a) it's unnecessary, because `widen' is available, and 
b) some day we might think of a better special meaning for C-u 0 (and in the 
meantime it could error instead of narrowing to the current level-1 subtree).

But I don't feel strongly about it either way.  Perhaps consistency is 
desirable here, although I tend to think that consistency is overrated in UI/UX 
in general -- the famous example of "`transpose-chars' at the end of a line" 
comes to mind.

Hmm, but on the other hand, your proposed consistency *would* be good if 
anyone's ever calling `org-narrow-to-subtree' from Lisp with an algorithmically 
calculated STEPS argument.  I can't imagine what kind of circumstance that 
would be, but if it's a general principle of Org Mode to consider "level 0" to 
be the entire buffer, then we should probably go with your proposed behavior.  
So I guess I'm tentatively +1...

Does anyone else have any thoughts on this?

Best regards,
-Karl

Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

On 02 Dec 2019, Marco Wahl wrote:
>What about numeric prefix arg 0 to reveal the whole buffer (aka
>'widen')?  I think this would be a logical completion to the feature.

Since `widen' itself is already available via C-x n w, it might be better to 
save a special flag value like that for some special behavior that we (or 
someone else) might think of in the future.  I'm pretty sure that anyone using 
`org-narrow-to-subtree' must also know about the `widen' command, too.

Thoughts?

Best regards,
-Karl

Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

On 01 Dec 2019, Marco Wahl wrote:
>I guess it's a good idea to write to Bastien explicitly.

I will do so.

>Thanks for asking about the version.  AFAICT there is a feature freeze
>right now for version 9.3.  This means you would commit to the 'next'
>branch which shall be the next master branch after the release.  And
>also you would add the news entry in section [Version Next] in
>etc/ORG-NEWS.

Ah, okay.  Thanks for letting me know; I'll do all that.

Best regards,
-Karl

Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

On 01 Dec 2019, Marco Wahl wrote:
>+1
>
>I think your enhancement is great and worth a news entry.  What about
>pushing your code if nobody objects within one week?

Thanks, Marco; I'm glad you like it.  I'll wait a week and then push (unless 
there's discussion, in which case we'll see what the outcome of the discussion 
is first, of course).

I just created a "kfogel" account at https://code.orgmode.org/ and uploaded my 
SSH key.  Should I mail Bastien about push access, or is posting here enough?

Regarding a news entry: that means the 9.3 section of etc/ORG-NEWS, right?  I 
will add a news entry to the commit at push time.

Best regards,
-Karl

[PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

This is the enhancement to `org-narrow-to-subtree' that I suggested back in May 
[1].

It allows you to choose what level subtree to narrow to.  There are two ways to 
specify the subtree: use repeated C-u's to select "upward" from the current 
subtree, or use a direct numeric prefix arg to specify the subtree "downward" 
from level 1.  (This is a somewhat unusual prefix argument usage, but it's 
useful to be able to choose from either direction, and the convenience of using 
C-u to select upward is quite enormous -- I expect it to be the common case, 
and it's pretty much the only way I use the feature.)

The prefix arg is optional, of course: if you don't pass it, then 
`org-narrow-to-subtree' behaves the same way it has always behaved.

Best regards,
-Karl

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-05/msg00225.html

>From bbeca3c5444646685085c134b10f4883812068a0 Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Sat, 30 Nov 2019 01:33:15 -0600
Subject: [PATCH] Use prefix arg to narrow to a specific subtree

* lisp/org.el (org-narrow-to-subtree): Take a prefix arg and use
  it to choose which subtree to narrow to.  See thread for context:

  https://lists.gnu.org/archive/html/emacs-orgmode/2019-05/msg00225.html
  From: Karl Fogel
  To: Org Mode
  Subject: Re: [PROPOSAL] Use prefix arg to control scope \
   of org-narrow-to-subtree.
  Date: Fri, 31 May 2019 02:33:03 -0500
  Message-ID: <87y32ncc40@red-bean.com>
---
 lisp/org.el | 41 ++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 90f222c8b..9b16c59e6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7743,11 +7743,46 @@ If yes, remember the marker and the distance to BEG."
 (move-marker (car x) (+ beg (cdr x
   (setq org-markers-to-move nil))
 
-(defun org-narrow-to-subtree ()
-  "Narrow buffer to the current subtree."
-  (interactive)
+(defun org-narrow-to-subtree (&optional steps)
+  "Narrow buffer to current subtree or to one specified by prefix arg STEPS.
+
+Interactively, use the prefix argument in one of two ways to
+narrow to a specific subtree: either give one or more C-u's to
+specify a subtree that many levels upward from the current
+subtree (that is, go up as many levels as the number of C-u's
+given -- each C-u counts for one level), or give a strictly
+numeric argument to narrow to the subtree that is that many
+levels downward from the current top level (level 1) subtree.
+
+From Lisp, if you want the C-u (upward) behavior, pass STEPS as a
+list with the desired number as its sole element.  Otherwise,
+pass STEPS as a number to get the other (downward) behavior.
+
+If STEPS would specify a subtree higher than the current level 1
+subtree, then just narrow to that level 1 subtree (in other
+words, you can use \"a lot of\" C-u's to narrow quickly to the
+current top subtree).  If STEPS would specify a subtree deeper
+than the current subtree, just narrow to the current subtree."
+  (interactive "P")
   (save-excursion
 (save-match-data
+  (widen)
+  (if steps
+	  (if (listp steps)
+	  (progn
+		(setq steps (car steps))
+		(when (< steps 0)
+		  (error "Argument cannot be negative"))
+		(setq steps (round (log steps 4
+	(when (< steps 0) ; awkward duplication, but hard to avoid
+	  (error "Argument cannot be negative"))
+	(let ((cur-level (org-outline-level)))
+	  (setq steps (max (- cur-level steps) 0
+	(setq steps 0))
+  (while (> steps 0)
+	(if (org-up-heading-safe)
+	(setq steps (1- steps))
+	  (setq steps 0)))
   (org-with-limited-levels
(narrow-to-region
 	(progn (org-back-to-heading t) (point))
-- 
2.24.0

Re: [O] Bug: Org commit d07d8ff41 breaks square-brace links in recent Emacs. [9.2.6 (release_9.2.6-538-g23113f @ /home/kfogel/src/org-mode/lisp/)]

[Karl Fogel]

On 18 Sep 2019, Marco Wahl wrote:
>Karl Fogel  writes:
>> Hi.  It appears that commit d07d8ff4163 in Org Mode causes 
>> square-brace-enclosed links to display incorrectly.
>>
>> The buggy behavior is simple to describe: if you write a link like this
>>
>>   [[URL][LINK-TEXT]]
>>
>> then URL will be displayed instead of LINK-TEXT (and LINK-TEXT goes unused: 
>> URL is still also given as the underlying link).
>
>This was a little accident with the regexp match groups AFAICT.  This is
>fixed in master.

Thanks for the quick fix, Marco.  I can confirm that links are working again 
now.

Best regards,
-Karl

[O] Bug: Org commit d07d8ff41 breaks square-brace links in recent Emacs. [9.2.6 (release_9.2.6-538-g23113f @ /home/kfogel/src/org-mode/lisp/)]

[Karl Fogel]

Hi.  It appears that commit d07d8ff4163 in Org Mode causes 
square-brace-enclosed links to display incorrectly.

The buggy behavior is simple to describe: if you write a link like this

  [[URL][LINK-TEXT]]

then URL will be displayed instead of LINK-TEXT (and LINK-TEXT goes unused: URL 
is still also given as the underlying link).

I haven't debugged this, but it seems to be caused by this commit in Org Mode:

> commit d07d8ff416373e5a4f2d91ed1d7f9cb3a80b8439
> Author: Max Mouratov 
> AuthorDate: Thu Aug 29 22:48:22 2019 +0500
> Commit: Nicolas Goaziou 
> CommitDate: Mon Sep 16 18:55:04 2019 +0200
> 
> Prevent loss of `re-search-forward' results
> 
> * org.el (org-activate-links): `match-beginning' and `match-end` should
> be called shortly after `re-search-forward'. Otherwise, they may return
> values corresponding to a different invocation of `re-search-forward'.
> 
> TINYCHANGE
> 
> M lisp/org.el

Here's how to verify

  1) Revert just commit d07d8ff41 in your Org Mode source tree
  2) 'make'
  3) 'make autoloads'
  4) Restart Emacs

With that commit reverted, links behave correctly.  When I restored the commit 
(and rebuilt, etc), links behaved incorrectly again.

This is all with the latest 'master' branch of Emacs (commit 746b20c237), with 
latest development Org Mode (commit 23113feb9a, which is only one commit beyond 
the suspect commit).

Best regards,
-Karl


Emacs  : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.11)
 of 2019-09-17
Package: Org mode version 9.2.6 (release_9.2.6-538-g23113f @ 
/home/kfogel/src/org-mode/lisp/)

Re: [O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

On 25 Apr 2019, Nicolas Goaziou wrote:
>Hello,
>
>Karl Fogel  writes:
>
>> My proposal is for each raw prefix arg (each `C-u' prefix) to expand
>> the narrowing level outward/upward by one.  So in the above situation:
>
>I suggest to use a numeric argument for that. M-1 for one level, M-2 for
>two levels, maybe M-0 equivalent to current behaviour. C-u can be
>a shortcut for M-1.

Thanks to you and Alan Tyree for your encouraging replies.

In a followup message, you added:

> Further to my previous message: there is already provision for a
> numerical prefix in org-tree-to-indirect-buffer.  I suppose that it
> and org-narrow-to-subtree should behave the same.

Ahhh, okay, hmmm -- I didn't know about `org-tree-to-indirect-buffer'.  This 
makes the situation somewhat more complex.  Let me explain:

First, I agree it should be a numeric argument, and we can treat "C-u" 
specially, making each C-u be equivalent to one increment.  E.g., "C-u" is 
"M-1", as you said, and "C-u C-u" is "M-2", etc.  This may be a slightly 
unusual behavior in Emacs, but given the low numbers we're talking about here, 
and the high convenience of just being able to repeat C-u a certain number of 
times to indicate that number of levels, I think it's well worth it.

However, my orginal thought was that the number would be relative *from* the 
level point is currently at.  In other words, if you're in the 5th nested 
subtree down ("* " is the most recent heading prefix), then `M-1 
org-narrow-to-subtree' would narrow to the next level up -- the 4th-level 
nesting.

Unfortunately, this is the opposite of how `org-tree-to-indirect-buffer' 
interprets prefixes:

  "With a numerical prefix ARG, go up to this level and then take that tree.
   If ARG is negative, go up that many levels."

In other words, in `org-tree-to-indirect-buffer', the number is counted down 
from the absolute reference point of the top level (although you can use a 
negative number to get the behavior I was proposing for 
`org-narrow-to-subtree').

I'd like to be consistent with existing commands.  But still, most of the time 
a user would (I conjecture) want to choose their narrowing level *relative* to 
the level of where point currently is.  That's certainly what I always want: 
I'm at a certain nesting level, and either I want to narrow to that level, or 
to the one right above it, or to the one above that, etc.  I'm always thinking 
in terms relative to where I am now, not relative to the far-away top level.  
In fact, I'm not necessarily even aware of the absolute nesting count of where 
I am now -- and I don't need to know either, for the purposes of narrowing.

So here's my updated proposal:

Purely numeric prefix arguments behave as in `org-tree-to-indirect-buffer', but 
each C-u behaves as an increment in the other direction (i.e., the way negative 
numbers behave for `org-tree-to-indirect-buffer').  Numeric arguments would 
thus be consistent with `org-tree-to-indirect-buffer', but there would still be 
a way, using repeated "C-u"s, to quickly and conveniently indicate a nesting 
level relative to where one currently is.

Thoughts?

Best regards,
-Karl

>> If you offer too many `C-u's, such that the narrowing would be wider
>> than the current surrounding first-level subtree, then there are two
>> possible ways we could handle it:
>>
>> 1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.
>>
>> 2) Throw an error.
>>
>> I prefer (1), because it would be the more useful behavior, even
>> though (2) would be easier to implement (since `org-back-to-heading'
>> already throws the error).  However, I'd welcome others' feedback on
>> that question, or on any other aspect of this proposal.
>
>1 sounds good.
>
>I think it is a good idea.
>
>Thank you.
>
>Regards,

[O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

Hi.  This is a feature proposal -- if the consensus is that it would be 
welcomed, I'm happy to code it.  I just didn't want to take the time to write 
it if there's no chance for it to be accepted upstream (since I don't want to 
be maintaining my own personal branch of Org Mode).

It would be useful if `org-narrow-to-subtree' could optionally narrow to the 
next subtree(s) up, rather than only to the subtree point is currently in.  For 
example, assume this text:

   * This is the first level
   Some text here.
   ** This is the second level
   Some other text here.
   *** This is the third level
   By now we all know this song.
   It is such a pretty song.
    This is the fourth level
   But do we have to sing it all day long?
   This car trip is getting incong
   * This is the fifth level
   ruously unrhymed.

Further assume that point is on the "c" of "car trip".  

In the current Org Mode, if you type `C-x n s', it will narrow to the 
fourth-level subtree (with the fifth level included in the narrowed buffer, of 
course).

Since `org-narrow-to-subtree' takes no arguments at all right now, it's 
conveniently ripe for improvement :-).

My proposal is for each raw prefix arg (each `C-u' prefix) to expand the 
narrowing level outward/upward by one.  So in the above situation:

  - `C-u C-x n s' would narrow to the third-level subtree

  - `C-u C-u C-x n s' would narrow to the second-level subtree

And so on.

If you offer too many `C-u's, such that the narrowing would be wider than the 
current surrounding first-level subtree, then there are two possible ways we 
could handle it:

1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.

2) Throw an error.

I prefer (1), because it would be the more useful behavior, even though (2) 
would be easier to implement (since `org-back-to-heading' already throws the 
error).  However, I'd welcome others' feedback on that question, or on any 
other aspect of this proposal.

Best regards,
-Karl

Re: [O] Displaying deadline datestamp in todo agenda list?

[Karl Fogel]

Matt Lundin  writes:
>Here's a working implementation, using org-agenda-add-custom-command and
>the built-in mechanism for skipping non-deadline entries (you can get
>rid of ots-org-entry-skip-non-deadline). I also added some justification
>(the -22) to accommodate my rather long timestamp strings. Adjust as
>needed:
>
>(org-add-agenda-custom-command
> '("d" "Deadlines and scheduled work" alltodo ""
>   ((org-agenda-skip-function '(org-agenda-skip-entry-if 'notdeadline))
>(org-agenda-prefix-format '((todo . " %i %-22(org-entry-get nil 
> \"DEADLINE\") %-12:c %s")))
>(org-agenda-sorting-strategy '(deadline-up)
>
>Matt

Matt, I can't thank you enough -- this is great.  (Our company runs on Org 
Mode, so this will help more free software hackers than just me :-) .)

The core trick is obviously "(org-entry-get nil \"DEADLINE\")".  I knew about 
embedding a Lisp expression into the format string, but didn't know about that 
particular function -- now that I know it exists, I suspect we'll be using it a 
lot.  And the "(org-agenda-skip-entry-if 'notdeadline)" part saves us a bunch 
of custom code too.

This is the best kind of solution: it solved the immediate problem and gives us 
infrastructure for solving future problems as well.

Thanks!

-Karl

Re: [O] Displaying deadline datestamp in todo agenda list?

[Karl Fogel]

Sigh, sorry.  I messed up one important background fact in my original post, by 
mistakenly presenting these as the example Org Mode entries I was working with: 

>   * STARTED <2016-05-23> Org Mode scheduling test KIWI.
> DEADLINE: <2016-05-23>
> 
>   * TODO <2016-05-25> Org Mode scheduling test MELON.
> DEADLINE: <2016-05-25>
> 
>   * STARTED <2016-05-24> Org Mode scheduling test LIME.
> DEADLINE: <2016-05-24>
> 
>   * STARTED <2016-06-16> Org Mode scheduling test TARDIGRADE.
> SCHEDULED: <2016-05-23> DEADLINE: <2016-06-16>

The above is wrong (I copied-and-pasted from a later incarnation that included 
redundant timestamps).  The block should look like below, i.e., *without* 
datestamps in the todo headings:

   * STARTED Org Mode scheduling test KIWI.
 DEADLINE: <2016-05-23>
 
   * TODO Org Mode scheduling test MELON.
 DEADLINE: <2016-05-25>
 
   * STARTED Org Mode scheduling test LIME.
 DEADLINE: <2016-05-24>
 
   * STARTED Org Mode scheduling test TARDIGRADE.
 SCHEDULED: <2016-05-23> DEADLINE: <2016-06-16>

The rest of the post is as before, and I'll just reproduce it here (with the 
mistake corrected) in case it's easier for people to follow up to:

---
Original post, but with correction:
---

I'm using the DEADLINE keyword with TODO entries, and I'd like the DEADLINE 
date to be displayed as a datestamp next to each TODO item, when I list 
deadlined todo items.  In other words, I don't want to have to duplicate the 
DEADLINE timestamp as a timestamp on the TODO line itself in my Org Mode file 
-- since the timestamp is already present as the value of the DEADLINE keyword, 
can't Org Mode just use it?

Assume I have these Org Mode entries:

  * STARTED Org Mode scheduling test KIWI.
DEADLINE: <2016-05-23>

  * TODO Org Mode scheduling test MELON.
DEADLINE: <2016-05-25>

  * STARTED Org Mode scheduling test LIME.
DEADLINE: <2016-05-24>

  * STARTED Org Mode scheduling test TARDIGRADE.
SCHEDULED: <2016-05-23> DEADLINE: <2016-06-16>

And I have this custom code to bind "d" to show just the TODO items that have 
deadlines, in my `org-agenda' keymap:

  (defun ots-org-entry-skip-non-deadline ()
"Return non-nil iff this org entry does not have the DEADLINE keyword."
(if (not (org-entry-get (point) "DEADLINE"))
(progn (outline-next-heading) (1- (point)
  
  (defvar ots-org-agenda-custom-commands-updated-p nil
"If non-nil, we've already updated `org-agenda-custom-commands',
  so don't do it again.")
  
  ;; TBD: Oh, could use `org-add-agenda-custom-command' to do this.
  (unless ots-org-agenda-custom-commands-updated-p
(unless (boundp 'org-agenda-custom-commands)
  (setq org-agenda-custom-commands ()))
(setq org-agenda-custom-commands
  (cons '("d" "Deadlines and scheduled work" alltodo ""
  ((org-agenda-skip-function 'ots-org-entry-skip-non-deadline)
   ;; Add code here to control deadline date display?
   (org-agenda-prefix-format '((agenda . " %i %-12:c%?-12t% s")
   (timeline . "  % s")
   (todo . " %i %-12:c %s")
   (tags . " %i %-12:c")
   (search . " %i %-12:c")))
   (org-agenda-sorting-strategy '(deadline-up
org-agenda-custom-commands))
(setq ots-org-agenda-custom-commands-updated-p t))

Now if I do `M-x org-agenda' and then type `d', the four items are displayed 
like this:

  Global list of TODO items of type: ALL
  Available with ‘N r’: (0)[ALL] (1)TODO (2)STARTED (3)DONE
OTS:   STARTED   Org Mode scheduling test KIWI.
OTS:   STARTED   Org Mode scheduling test LIME.
OTS:   TODO  Org Mode scheduling test MELON.
OTS:   STARTED   Org Mode scheduling test TARDIGRADE.
  
But what I want is for each to show its corresponding DEADLINE datestamp, say 
like this:

  Global list of TODO items of type: ALL
  Available with ‘N r’: (0)[ALL] (1)TODO (2)STARTED (3)DONE
OTS: <2016-05-23>  STARTED   Org Mode scheduling test KIWI.
OTS: <2016-05-24>  STARTED   Org Mode scheduling test LIME.
OTS: <2016-05-25>  TODO  Org Mode scheduling test MELON.
OTS: <2016-06-16>  STARTED   Org Mode scheduling test TARDIGRADE.

I haven't found any way to make that happen.  After reading various Info pages, 
I started digging into the Org Mode code.  Now I'm looking at 
`org-agenda-get-todos' in org-agenda.el, which calls `org-agenda-format-item', 
passing "" as the first argument (EXTRA).  The doc string for 
`org-agenda-format-item' says:

  "EXTRA must be a string to replace the `%s' specifier in the prefix format."

I thought that maybe passing (org-agenda-get-deadlines) there instead of "" 
would supply `org-agen

[O] Displaying deadline datestamp in todo agenda list?

[Karl Fogel]

I'm using the DEADLINE keyword with TODO entries, and I'd like the DEADLINE 
date to be displayed as a datestamp next to each TODO item, when I list 
deadlined todo items.  In other words, I don't want to have to duplicate the 
DEADLINE timestamp as a timestamp on the TODO line itself in my Org Mode file 
-- since the timestamp is already present as the value of the DEADLINE keyword, 
can't Org Mode just use it?

Assume I have these Org Mode entries:

  * STARTED <2016-05-23> Org Mode scheduling test KIWI.
DEADLINE: <2016-05-23>

  * TODO <2016-05-25> Org Mode scheduling test MELON.
DEADLINE: <2016-05-25>

  * STARTED <2016-05-24> Org Mode scheduling test LIME.
DEADLINE: <2016-05-24>

  * STARTED <2016-06-16> Org Mode scheduling test TARDIGRADE.
SCHEDULED: <2016-05-23> DEADLINE: <2016-06-16>

And I have this custom code to bind "d" to show just the TODO items that have 
deadlines, in my `org-agenda' keymap:

  (defun ots-org-entry-skip-non-deadline ()
"Return non-nil iff this org entry does not have the DEADLINE keyword."
(if (not (org-entry-get (point) "DEADLINE"))
(progn (outline-next-heading) (1- (point)
  
  (defvar ots-org-agenda-custom-commands-updated-p nil
"If non-nil, we've already updated `org-agenda-custom-commands',
  so don't do it again.")
  
  ;; TBD: Oh, could use `org-add-agenda-custom-command' to do this.
  (unless ots-org-agenda-custom-commands-updated-p
(unless (boundp 'org-agenda-custom-commands)
  (setq org-agenda-custom-commands ()))
(setq org-agenda-custom-commands
  (cons '("d" "Deadlines and scheduled work" alltodo ""
  ((org-agenda-skip-function 'ots-org-entry-skip-non-deadline)
   ;; Add code here to control deadline date display?
   (org-agenda-prefix-format '((agenda . " %i %-12:c%?-12t% s")
   (timeline . "  % s")
   (todo . " %i %-12:c %s")
   (tags . " %i %-12:c")
   (search . " %i %-12:c")))
   (org-agenda-sorting-strategy '(deadline-up
org-agenda-custom-commands))
(setq ots-org-agenda-custom-commands-updated-p t))

Now if I do `M-x org-agenda' and then type `d', the four items are displayed 
like this:

  Global list of TODO items of type: ALL
  Available with ‘N r’: (0)[ALL] (1)TODO (2)STARTED (3)DONE
OTS:   STARTED   Org Mode scheduling test KIWI.
OTS:   STARTED   Org Mode scheduling test LIME.
OTS:   TODO  Org Mode scheduling test MELON.
OTS:   STARTED   Org Mode scheduling test TARDIGRADE.
  
But what I want is for each to show its corresponding DEADLINE datestamp, say 
like this:

  Global list of TODO items of type: ALL
  Available with ‘N r’: (0)[ALL] (1)TODO (2)STARTED (3)DONE
OTS: <2016-05-23>  STARTED   Org Mode scheduling test KIWI.
OTS: <2016-05-24>  STARTED   Org Mode scheduling test LIME.
OTS: <2016-05-25>  TODO  Org Mode scheduling test MELON.
OTS: <2016-06-16>  STARTED   Org Mode scheduling test TARDIGRADE.

I haven't found any way to make that happen.  After reading various Info pages, 
I started digging into the Org Mode code.  Now I'm looking at 
`org-agenda-get-todos' in org-agenda.el, which calls `org-agenda-format-item', 
passing "" as the first argument (EXTRA).  The doc string for 
`org-agenda-format-item' says:

  "EXTRA must be a string to replace the `%s' specifier in the prefix format."

I thought that maybe passing (org-agenda-get-deadlines) there instead of "" 
would supply `org-agenda-format-item' with the information it needs, but alas, 
that doesn't work and in fact the third call or so of 
`org-agenda-get-deadlines' raises an error.  (The doc strings for 
`org-agenda-get-todos and `org-agenda-get-deadlines' don't say all that much; 
it's quite possible I'm misunderstanding what the latter is for.)

However, if I pass a hardcoded non-empty value of EXTRA to the call to 
`org-agenda-format-item', it works.  That is, if I pass the hardcoded string 
"DEADLINE: <2016-05-24>" as the EXTRA argument in `org-agenda-get-todos', thus 
changing this line:

  txt (org-agenda-format-item "" txt level category tags t)

to this:

  txt (org-agenda-format-item "FISH" txt level category tags t)

...I get this result:

  Global list of TODO items of type: ALL
  Available with ‘N r’: (0)[ALL] (1)TODO (2)STARTED (3)DONE
OTS: FISH  STARTED   Org Mode scheduling test KIWI.
OTS: FISH  STARTED   Org Mode scheduling test LIME.
OTS: FISH  TODO  Org Mode scheduling test MELON.
OTS: FISH  STARTED   Org Mode scheduling test TARDIGRADE.

Okay, that's roughly what I expected, given that in my custom setting of 
`org-agenda-custom-commands', I set `org-agenda-prefix-format' so that the 
`todo' entry'

Re: [O] [PATCH] Improve success message from org-remove-file.

[Karl Fogel]

Nicolas Goaziou  writes:
>Karl Fogel  writes:
>
>> The attached patch improves the interactive success message from
>> `org-remove-file'.  Comments / suggestions welcome, of course; I've
>> tried to follow http://orgmode.org/worg/org-contribute.html here.
>
>Applied, thank you.
>
>I added "TINYCHANGE" at the end of your commit message.

Thanks for applying the change.

I didn't include "TINYCHANGE" on purpose.  The guidelines say:

  | If the change is a minor change made by a committer without
  | copyright assignment to the FSF, the commit message should also
  | contain the cookie TINYCHANGE (anywhere in the message). When we
  | later produce the ChangeLog file for Emacs, the change will be
  | marked appropriately.

However, I *do* have copyright assignment on file with the FSF (for
Emacs), so I interpreted the above as meaning I shouldn't include
"TINYCHANGE".  What is the right thing to do here?

Best,
-Karl

[O] [PATCH] Improve success message from org-remove-file.

[Karl Fogel]

The attached patch improves the interactive success message from
`org-remove-file'.  Comments / suggestions welcome, of course; I've
tried to follow http://orgmode.org/worg/org-contribute.html here.

Best,
-Karl

>From 846d66a15c73a336c110f5238307242f9192e8c3 Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Mon, 24 Nov 2014 11:32:42 -0600
Subject: [PATCH] org.el: Improve accuracy of message

* lisp/org.el (org-remove-file): Reword success message.

Before this change, when `org-remove-file' succeeded in removing a
file from `org-agenda-files', it would display this unduly alarming
message to the user: "Removed file: foo.org".  This made it seem as
though the file itself were removed from the filesystem, rather than
simply being delisted from `org-agenda-files'.

After this change, the message "Removed from Org Agenda list: foo.org"
is displayed instead, so the user will experience only the normal
level of panic involved in using Org Mode, not the increased panic
that results from thinking a file has been removed when it hasn't.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 38c5726..9372191 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18465,7 +18465,7 @@ Optional argument FILE means use this file instead of the current."
 	(progn
 	  (org-store-new-agenda-file-list files)
 	  (org-install-agenda-files-menu)
-	  (message "Removed file: %s" afile))
+	  (message "Removed from Org Agenda list: %s" afile))
   (message "File was not in list: %s (not removed)" afile
 
 (defun org-file-menu-entry (file)
-- 
2.1.3

Re: [O] [PATCH] org-agenda-list (from git) giving "args-out-of-range error"

[Karl Fogel]

David Maus  writes:
>I pushed the fix with some small cleanup of the commit
>message. Somehow the patchtracker included the mailbody in the commit
>message.

Thank you!

FWIW, I used 'git format-patch' to generate the patch; not sure if that
had anything to do with the resulting patchtracker behavior.


pgp315l3hxmAF.pgp
Description: PGP signature

Re: [O] [PATCH] org-agenda-list (from git) giving "args-out-of-range error"

[Karl Fogel]

Nick Dokos  writes:
>Exactly what you've done: send the patch to the list.
>
>Modulo possible changelog formatting issues (see
>http://orgmode.org/worg/org-contribute.html#sec-5 for the gory details),
>the patch looks good to me. Thanks for submitting it!

Oh, thanks -- I should have looked for those guidelines first.  Here is
the same patch, but with a properly-done log message this time.

I already have copyright assignment papers on file at the FSF for Emacs
itself, by the way; does that cover us for Org Mode too?

>From 7809b35a6e88640006753e28bcb87a6b66a80639 Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Wed, 29 Feb 2012 13:42:35 -0600
Subject: [PATCH] Fix bug whereby a date-only line caused an error when
 generating an agenda

* lisp/org-agenda.el (org-agenda-highlight-todo): Handle the case of a heading 
that has a date but no todo keyword.

This is a fix for the args-out-of-range bug discussed in these threads:

  http://thread.gmane.org/gmane.emacs.orgmode/52621
  http://thread.gmane.org/gmane.emacs.orgmode/52793
  http://thread.gmane.org/gmane.emacs.orgmode/52786
  http://thread.gmane.org/gmane.emacs.orgmode/52810

The discussions involved Ilya Shlyakhter, James Atwood, Nick Dokos,
and myself, and the subject headers are:

  bug report: agenda timeline crashes
  Bug report: weekly agenda and blank, timestamped headers
  org-agenda-list (from git) giving "args-out-of-range error"

TINYCHANGE
---
 lisp/org-agenda.el |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 98a2cc0..ac1b5b1 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5889,8 +5889,18 @@ could bind the variable in the options section of a 
custom command.")
   (let ((pl (text-property-any 0 (length x) 'org-heading t x)))
(setq re (get-text-property 0 'org-todo-regexp x))
(when (and re
+  ;; Test `pl' because if there's no heading content,
+  ;; there's no point matching to highlight.  Note
+  ;; that if we didn't test `pl' first, and there
+  ;; happened to be no keyword from `org-todo-regexp'
+  ;; on this heading line, then the `equal' comparison
+  ;; afterwards would spuriously succeed in the case
+  ;; where `pl' is nil -- causing an args-out-of-range
+  ;; error when we try to add text properties to text
+  ;; that isn't there.
+  pl
   (equal (string-match (concat "\\(\\.*\\)" re "\\( +\\)")
-   x (or pl 0)) pl))
+   x pl) pl))
  (add-text-properties
   (or (match-end 1) (match-end 0)) (match-end 0)
   (list 'face (org-get-todo-face (match-string 2 x)))
-- 
1.7.9

[O] [PATCH] org-agenda-list (from git) giving "args-out-of-range error"

[Karl Fogel]

Nick Dokos  writes:
>There have been a couple of recent reports on this problem (headlines
>with just a timestamp cause this error) in addition to the ones you
>found:
>
>http://thread.gmane.org/gmane.emacs.orgmode/52621
>http://thread.gmane.org/gmane.emacs.orgmode/52786
>
>The first one contains a diagnosis and a (possibly wrong) suggested fix.

Thank you, Nick.  I eventually found the same cause, by doing a
binary-search reduction of the problematic .org file until I knew
exactly which headline was the source of the problem.  It was a
second-level headline with a date but no content...

  ** <2012-02-27 Mon>

...as described in James Atwood's mail (the second one you list above).

It's relevant that the line ends immediately after the ">".  If there is
even one space after the ">", then the bug does not reproduce.  This
makes sense, given the code.  I have a tentative patch, which is
attached.  What's the typical way to submit such things for review?

>From 8a4c65479b2f62cbffe32735c4afac5dd6a1ecae Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Wed, 29 Feb 2012 13:06:06 -0600
Subject: [PATCH] * lisp/org-agenda.el (org-agenda-highlight-todo): Handle the
 case of a heading that has a date but no todo keyword. 
 This is a fix for the args-out-of-range bug discussed in
 these threads

  http://thread.gmane.org/gmane.emacs.orgmode/52621
  http://thread.gmane.org/gmane.emacs.orgmode/52793
  http://thread.gmane.org/gmane.emacs.orgmode/52786
  http://thread.gmane.org/gmane.emacs.orgmode/52810

among Ilya Shlyakhter, James Atwood, Nick Dokos, and myself.  The subject 
headers are:

  bug report: agenda timeline crashes
  Bug report: weekly agenda and blank, timestamped headers
  org-agenda-list (from git) giving "args-out-of-range error"
---
 lisp/org-agenda.el |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 98a2cc0..ac1b5b1 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5889,8 +5889,18 @@ could bind the variable in the options section of a 
custom command.")
   (let ((pl (text-property-any 0 (length x) 'org-heading t x)))
(setq re (get-text-property 0 'org-todo-regexp x))
(when (and re
+  ;; Test `pl' because if there's no heading content,
+  ;; there's no point matching to highlight.  Note
+  ;; that if we didn't test `pl' first, and there
+  ;; happened to be no keyword from `org-todo-regexp'
+  ;; on this heading line, then the `equal' comparison
+  ;; afterwards would spuriously succeed in the case
+  ;; where `pl' is nil -- causing an args-out-of-range
+  ;; error when we try to add text properties to text
+  ;; that isn't there.
+  pl
   (equal (string-match (concat "\\(\\.*\\)" re "\\( +\\)")
-   x (or pl 0)) pl))
+   x pl) pl))
  (add-text-properties
   (or (match-end 1) (match-end 0)) (match-end 0)
   (list 'face (org-get-todo-face (match-string 2 x)))
-- 
1.7.9

[O] org-agenda-list (from git) giving "args-out-of-range error"

[Karl Fogel]

[please keep me CC'd, as I'm a digest subscriber on this list]

Suddenly "C-c a a" (`org-agenda-list') has started giving me this error:

   args-out-of-range #("  ots:" 0 14 (org-category ...

Backtrace attached.  This is with today's bleeding edge Org Mode code,
pulled from git://orgmode.org/org-mode.git.

I think the bug must be content-sensitive, since the only thing that
changed was the content of some of my .org files (the ones listed in
`org-agenda-files').  After encountering the bug, I upgraded to
bleeding-edge org-mode, and saw that the bug reproduces there too.

I can't find much on the Net about this problem, though this expired
StackOverflow question seems to be the same thing:

  
http://stackoverflow.com/questions/9460109/when-i-press-c-c-a-a-to-view-agenda-i-get-a-args-out-of-range-error

That question is gone from StackOverflow now, but Google's cache still
has it:

  
http://webcache.googleusercontent.com/search?q=cache:QsaNSsILOegJ:stackoverflow.com/questions/9460109/when-i-press-c-c-a-a-to-view-agenda-i-get-a-args-out-of-range-error+emacs+org-mode+agenda+%22args-out-of-range%22&cd=5&hl=en&ct=clnk&gl=us

There are also some reports of org agenda exports failing similarly, but
I'm not doing an export.  And there's this, about how blank headlines
cause a similar error:

  http://comments.gmane.org/gmane.emacs.orgmode/46444

Oh, I just found this -- it might be relevant:

  
http://article.gmane.org/gmane.emacs.orgmode/41045/match=agenda+args+out+of+range

I'll see if I can reproduce what that person found.

Anyway, I can do Elisp debugging, and will start to do that unless
someone here recognizes this problem and can add some information.

Backtrace attached below.

-Karl

(I had to rectangularly truncate this backtrace to avoid showing
confidential information, sorry, but the call stack is there anyway.)

Debugger entered--Lisp error: (args-out-of-range #("  ots:" 0 14 (org-c
  match-string(2 #("  ots:" 0 14 (org-category "ots" tags nil org-highe
  (org-get-todo-face (match-string 2 x))   
  (list (quote face) (org-get-todo-face (match-string 2 x)))   
  (add-text-properties (or (match-end 1) (match-end 0)) (match-end 0) (list (qu
  (progn (add-text-properties (or (match-end 1) (match-end 0)) (match-end 0) (l
  (if (and re (equal (string-match (concat "\\(\\.*\\)" re "\\( +\\)") x (or pl
  (when (and re (equal (string-match (concat "\\(\\.*\\)" re "\\( +\\)") x (or 
  (let ((pl (text-property-any 0 (length x) (quote org-heading) t x))) (setq re
  (if (eq x (quote line)) (save-excursion (beginning-of-line 1) (setq re (org-g
  (let ((org-done-keywords org-done-keywords-for-agenda) (case-fold-search nil)
  org-agenda-highlight-todo(#("  ots:" 0 14 (org-category "ots" tags ni
  mapcar(org-agenda-highlight-todo (#("  ots:TODO  Karl to check in w/ 
  (setq list (mapcar (quote org-agenda-highlight-todo) list))  
  org-finalize-agenda-entries((#("  ots:TODO  Karl to check in w/ Ray n
  (insert (org-finalize-agenda-entries (org-agenda-add-time-grid-maybe rtnall n
  (if rtnall (insert (org-finalize-agenda-entries (org-agenda-add-time-grid-may
  (progn (setq day-cnt (1+ day-cnt)) (insert (if (stringp org-agenda-format-dat
  (if (or rtnall org-agenda-show-all-dates) (progn (setq day-cnt (1+ day-cnt)) 
  (while (setq d (pop day-numbers)) (setq date (calendar-gregorian-from-absolut
  (let* ((span (org-agenda-ndays-to-span (or span org-agenda-ndays org-agenda-s
  org-agenda-list(nil) 
  call-interactively(org-agenda-list)  
  (cond ((setq entry (assoc keys org-agenda-custom-commands)) (if (or (symbolp 
  (let* ((prefix-descriptions nil) (org-agenda-window-setup (if (equal (buffer-
  (catch (quote exit) (let* ((prefix-descriptions nil) (org-agenda-window-setup
  org-agenda(nil)
  call-interactively(org-agenda nil nil)