Re: [O] Relation between todo-mode.el and Org-mode?
On Wed, 12 Jun 2013 20:01:14 +0200 Thorsten Jolitz wrote: > on the 'emacs-devel' mailing list I saw the announcement of a new > version of `todo-mode.el', which I found a bit surprising - I would not > have expected that something else as Org-mode is used nowadays to manage > todo lists with Emacs? > > How is the relation between these two packages - if there is any? > Anybody with more insights? I'm the one who wrote the new version of todo-mode.el and I didn't make any attempt to borrow features or code from Org mode, which I know very little about. I started using, and making changes to, Todo mode well before Org existed. After Org appeared I briefly looked at its todo list UI, but I was used to and liked Todo mode's UI and handling of todo lists and Org's UI and handling didn't appeal to me as much for the way I use todo lists, so I didn't try using it any further, and because I kept working on Todo mode, changing it to suit my needs, I haven't felt compelled to try Org again. I know, of course, that Org does a lot more than todo lists. I've been casually monitoring this list for a couple of months, but due to my unfamiliarity can't follow most of the discussions. Maybe I'll give Org another try. Steve Berman
Re: [O] Relation between todo-mode.el and Org-mode?
On Thu, 27 Jun 2013 17:32:17 +0200 Bastien wrote: > Just one question: do you get feedback from todo-mode.el users? > Do you know if there are some/many out there? Just curious to > see other's people use. Since I became the maintainer more than four years ago there haven't been any bug reports or feature requests, and there were few prior to that. The ones there were, years before, were what got me interested in Todo mode in the first place. I don't know of any users of the old version. I think it had a nice UI but limited functionality, so I'd guess most people who want to manage todo lists in Emacs already use Org mode. I guess I'm an exception, because I had already started adding functionality to Todo mode before Org mode existed and that kept me sticking with it. Steve Berman
Org mode entry in Emacs Info menu
The update of Org mode to 9.3 in the Emacs sources (http://git.savannah.gnu.org/cgit/emacs.git/commit/doc/misc/org.texi?h=emacs-27&id=165f7383822086d465519ebe6e4283723923f097) contains this change to doc/misc/org.texi: -@dircategory Emacs editing modes +@dircategory Emacs which resulted in moving the Org mode entry in the Emacs Info menu, prompting Emacs bug#39556 (https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-02/msg00372.html). I also find the new menu item placement inappropriate. Was this relocation intended, and if so, why? Steve Berman
Re: Org mode entry in Emacs Info menu
On Wed, 12 Feb 2020 18:01:07 +0100 Bastien wrote: > Hi Stephen, > > I don't think this was intentional, I reverted to the old > dircategory, thanks to you and Drew for reporting this. Thanks for restoring it. Steve Berman
Re: bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding
[I added emacs-orgmode@gnu.org in the Cc:] On Mon, 03 May 2021 18:07:25 +0200 Stephen Berman wrote: > By default `i' is a prefix key in calendar-mode for commands that insert > diary entries. But if you happen to display a buffer that activates > org-mode machinery, then `i' in calendar-mode becomes bound to > org-agenda-diary-entry and typing it can raise a wrong-type-argument > error. This can happen by visiting a file in Org mode. To reproduce: > > 0. emacs -Q > 1. (sanity check:) Type `M-x calendar RET' and then in the Calendar >buffer type `i C-h': the *Help* buffer displays all the commands >invoked by `i' plus one or more keys. > 2. Visit the file `ORG-NEWS' (e.g. by typing `C-h n C-x C-f O TAB RET'). > 3. Type `M-x calendar RET' and then in the Calendar buffer type `i' > => Wrong type argument: commandp, org-agenda-diary-entry > > This can also catch users by surprise, e.g. in Gnus. To reproduce, > replace step 2 above by the following: > > 2a. Type `M-x gnus', answer `y' at the prompt; in the Gnus buffer type > `B RET news.gmane.io RET'. > 2b. In the *Gnus Browse Server* buffer type `C-s humani' to put point on > the gmane.emacs.humanities group; type RET to enter it. > 2c. Type `j <87sg6wulu6.fsf@localhost> RET', which displays an article > containing an org-mode source code block. > 3. As above, resulting in the same error (when done from emacs -Q). > > The Org mode manual (info "(org) Agenda Commands") does describe its use > of the `i' binding in the Calendar, and if Org mode has its own versions > of the commands that use `i' by default in calendar-mode, then > overriding the calendar-mode bindings is no problem for Org Agenda > users, but those bindings should not be overridden just by displaying a > buffer that happens to be in org-mode or happens to contain an Org > source code block. The following patch fixes the problem for me: diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el index 1f4e2e8308..b68e5b58fc 100644 --- a/lisp/org/org-compat.el +++ b/lisp/org/org-compat.el @@ -1151,8 +1151,8 @@ org--setup-calendar-bindings ((guard (not (lookup-key calendar-mode-map "c"))) (local-set-key "c" #'org-calendar-goto-agenda)) (_ nil)) - (unless (and (boundp 'org-agenda-diary-file) - (eq org-agenda-diary-file 'diary-file)) + (when (and (boundp 'org-agenda-diary-file) + (not (eq org-agenda-diary-file 'diary-file))) (local-set-key org-calendar-insert-diary-entry-key #'org-agenda-diary-entry))) I have to admit, though, that I don't understand why the version with `unless' results in the bug, since in the recipes I gave org-agenda-diary-file is unbound and, indeed, when I instrument the unpatched org--setup-calendar-bindings and step through it on calling `calendar', the org-calendar-insert-diary-entry-key local-set-key call is skipped as expected. But "c" does get locally set, so if I type `c' in the Calendar buffer, it displays the Org Agenda, and if I then type `i' in the Calendar buffer, I now get prompted with a choice menu for the type of diary entry, but whichever I choose, the result is the user-error "Don't know which date to use for diary entry", evidently because there is indeed no org-agenda-diary-file with the necessary text properties. So somehow the "i" binding is made even though the code should prevent this (and does under Edebug but not when executed normally). With the above patch, after typing `c' in the Calendar buffer, `i' is still unbound, as it should be, but if I changed the value of org-agenda-diary-file from the default 'diary-file to some file, then `i' works with Org Agenda as documented. Steve Berman
Re: [SOLVED] (kinda) Calendar vs. org-agenda exit
On Wed, 23 Jun 2021 18:16:52 +0200 to...@tuxteam.de wrote: > On Wed, Jun 23, 2021 at 05:28:36PM +0200, to...@tuxteam.de wrote: > > [calendar insert-diary-entry doing funny things] > > OK, I solved it by setting `org-calendar-insert-diary-entry-key' to > [106], which is a ?j. It was set to ?i, which hijacked calendar's > original key map. > > Now I still don't know whether it's intended that Org hijacks that > key in calendar, whether I did something stupid, but at least I have > my toys back. Just remember to not push ?j. > > Anyway, you set me on the right track, so thanks for that! See also bug#48199 (also CC'd at https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00582.html). I continue to use the patch I posted there and have had no problems with it (but I don't use org-mode much). Steve Berman
Re: [SOLVED] (kinda) Calendar vs. org-agenda exit
On Thu, 24 Jun 2021 14:09:46 +0200 to...@tuxteam.de wrote: > On Thu, Jun 24, 2021 at 12:13:40PM +0200, Stephen Berman wrote: >> On Wed, 23 Jun 2021 18:16:52 +0200 to...@tuxteam.de wrote: >> >> > On Wed, Jun 23, 2021 at 05:28:36PM +0200, to...@tuxteam.de wrote: >> > >> > [calendar insert-diary-entry doing funny things] >> > >> > OK, I solved it by setting `org-calendar-insert-diary-entry-key' to >> > [106], which is a ?j. It was set to ?i, which hijacked calendar's >> > original key map. >> > >> > Now I still don't know whether it's intended that Org hijacks that >> > key in calendar, whether I did something stupid, but at least I have >> > my toys back. Just remember to not push ?j. >> > >> > Anyway, you set me on the right track, so thanks for that! >> >> See also bug#48199 (also CC'd at >> https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00582.html). >> I continue to use the patch I posted there and have had no problems with >> it (but I don't use org-mode much). > > Oh, I see, thanks. For me, it's a bit confusing that this bug receives > so little attention. Hijacking other modes's keymaps isn't... friendly, > after all. I can't imagine that it is happening by intention. Yeah, the next time Org is merged to the Emacs master branch, forcing me to first stash and then reapply my patch locally, I'll ask if anyone objects to the patch being committed to master. Maybe that will get someone's attention (and if not, I may just go ahead and commit it -- if it then still gets no one's attention, it must be ok ;-). Steve Berman
Re: bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding
On Sun, 09 May 2021 19:21:31 +0200 Stephen Berman wrote: > [I added emacs-orgmode@gnu.org in the Cc:] > > On Mon, 03 May 2021 18:07:25 +0200 Stephen Berman > wrote: > >> By default `i' is a prefix key in calendar-mode for commands that insert >> diary entries. But if you happen to display a buffer that activates >> org-mode machinery, then `i' in calendar-mode becomes bound to >> org-agenda-diary-entry and typing it can raise a wrong-type-argument >> error. This can happen by visiting a file in Org mode. To reproduce: >> >> 0. emacs -Q >> 1. (sanity check:) Type `M-x calendar RET' and then in the Calendar >>buffer type `i C-h': the *Help* buffer displays all the commands >>invoked by `i' plus one or more keys. >> 2. Visit the file `ORG-NEWS' (e.g. by typing `C-h n C-x C-f O TAB RET'). >> 3. Type `M-x calendar RET' and then in the Calendar buffer type `i' >> => Wrong type argument: commandp, org-agenda-diary-entry >> >> This can also catch users by surprise, e.g. in Gnus. To reproduce, >> replace step 2 above by the following: >> >> 2a. Type `M-x gnus', answer `y' at the prompt; in the Gnus buffer type >> `B RET news.gmane.io RET'. >> 2b. In the *Gnus Browse Server* buffer type `C-s humani' to put point on >> the gmane.emacs.humanities group; type RET to enter it. >> 2c. Type `j <87sg6wulu6.fsf@localhost> RET', which displays an article >> containing an org-mode source code block. >> 3. As above, resulting in the same error (when done from emacs -Q). >> >> The Org mode manual (info "(org) Agenda Commands") does describe its use >> of the `i' binding in the Calendar, and if Org mode has its own versions >> of the commands that use `i' by default in calendar-mode, then >> overriding the calendar-mode bindings is no problem for Org Agenda >> users, but those bindings should not be overridden just by displaying a >> buffer that happens to be in org-mode or happens to contain an Org >> source code block. > > The following patch fixes the problem for me: > > diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el > index 1f4e2e8308..b68e5b58fc 100644 > --- a/lisp/org/org-compat.el > +++ b/lisp/org/org-compat.el > @@ -1151,8 +1151,8 @@ org--setup-calendar-bindings > ((guard (not (lookup-key calendar-mode-map "c"))) > (local-set-key "c" #'org-calendar-goto-agenda)) > (_ nil)) > - (unless (and (boundp 'org-agenda-diary-file) > -(eq org-agenda-diary-file 'diary-file)) > + (when (and (boundp 'org-agenda-diary-file) > + (not (eq org-agenda-diary-file 'diary-file))) > (local-set-key org-calendar-insert-diary-entry-key > #'org-agenda-diary-entry))) > > > > I have to admit, though, that I don't understand why the version with > `unless' results in the bug, since in the recipes I gave > org-agenda-diary-file is unbound and, indeed, when I instrument the > unpatched org--setup-calendar-bindings and step through it on calling > `calendar', the org-calendar-insert-diary-entry-key local-set-key call > is skipped as expected. But "c" does get locally set, so if I type `c' > in the Calendar buffer, it displays the Org Agenda, and if I then type > `i' in the Calendar buffer, I now get prompted with a choice menu for > the type of diary entry, but whichever I choose, the result is the > user-error "Don't know which date to use for diary entry", evidently > because there is indeed no org-agenda-diary-file with the necessary text > properties. So somehow the "i" binding is made even though the code > should prevent this (and does under Edebug but not when executed > normally). > > With the above patch, after typing `c' in the Calendar buffer, `i' is > still unbound, as it should be, but if I changed the value of > org-agenda-diary-file from the default 'diary-file to some file, then > `i' works with Org Agenda as documented. > > Steve Berman On Thu, 24 Jun 2021 17:04:02 +0200 Nicolas Goaziou wrote: > Hello, > > Stephen Berman writes: > >> Yeah, the next time Org is merged to the Emacs master branch, forcing me >> to first stash and then reapply my patch locally, I'll ask if anyone >> objects to the patch being committed to master. > > Sure, go ahead. Thanks, done in commit 19f2f26 on master. Closing the bug. Steve Berman
Re: help with a regexp
On Wed, 14 Jul 2021 20:43:24 -0400 John Kitchin wrote: > Hi all, I could use a bit of help with a regexp. I am trying to fine tune the > org-ref citation regexp to > make it orthogonal to org-cite. > > I want to recognize these as org-ref links > > [[cite:schuett-2018-schnet]] >cite:schuett-2018-schnet > > but not > > [cite:@schuett-2018-schnet] > > so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [. > > right now the cite: in the org-cite syntax is getting flagged as bad cite > link which I want to avoid. > > is this doable? For your example this is sufficient (for real usage you probably want to add more context to the right of 'cite'): (re-search-forward "\\[\\[cite:\\|[^[]cite:") Steve Berman
Re: help with a regexp
On Thu, 15 Jul 2021 10:40:40 +0200 Stephen Berman wrote: > On Wed, 14 Jul 2021 20:43:24 -0400 John Kitchin > wrote: > >> Hi all, I could use a bit of help with a regexp. I am trying to fine tune >> the org-ref citation regexp to >> make it orthogonal to org-cite. >> >> I want to recognize these as org-ref links >> >> [[cite:schuett-2018-schnet]] >>cite:schuett-2018-schnet >> >> but not >> >> [cite:@schuett-2018-schnet] >> >> so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [. >> >> right now the cite: in the org-cite syntax is getting flagged as bad cite >> link which I want to avoid. >> >> is this doable? > > For your example this is sufficient (for real usage you probably want to > add more context to the right of 'cite'): > > (re-search-forward "\\[\\[cite:\\|[^[]cite:") Or simply: (re-search-forward "\\[\\[\\|[^[]cite:") Steve Berman
