* removal of org-maybe-keyword-time-regexp @ 2020-03-11 17:21 Julien Cubizolles 2020-03-11 21:09 ` Nicolas Goaziou 0 siblings, 1 reply; 7+ messages in thread From: Julien Cubizolles @ 2020-03-11 17:21 UTC (permalink / raw) To: emacs-orgmode I'm using org-caldav (https://github.com/dengste/org-caldav/) to synchronize the calendar on my Android phone and Org. Recently this synchronization stopped working because org-caldav relies on org-maybe-keyword-time-regexp that has been dropped from Org. As a workaround, could this variable be reintroduced in org so as not to break this very useful package ? Julien. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removal of org-maybe-keyword-time-regexp 2020-03-11 17:21 removal of org-maybe-keyword-time-regexp Julien Cubizolles @ 2020-03-11 21:09 ` Nicolas Goaziou 2020-03-11 21:29 ` Eric Abrahamsen 0 siblings, 1 reply; 7+ messages in thread From: Nicolas Goaziou @ 2020-03-11 21:09 UTC (permalink / raw) To: Julien Cubizolles; +Cc: emacs-orgmode Hello, Julien Cubizolles <j.cubizolles@free.fr> writes: > I'm using org-caldav (https://github.com/dengste/org-caldav/) to > synchronize the calendar on my Android phone and Org. Recently this > synchronization stopped working because org-caldav relies on > org-maybe-keyword-time-regexp that has been dropped from Org. As a > workaround, could this variable be reintroduced in org so as not to > break this very useful package ? Could you contact upstream instead? AFAICT, they use this variable only twice. The first occurrence doesn't seem useful (they check for a planning info keyword in a headline, which cannot happen), it is probably enough to look for `org-ts-regexp-both'. I'm not sure about the second one. I guess it would be better for them to use something like: (and (re-search-forward "org-planning-line-re" nil t) (org-at-planning-p) (progn (org-skip-whitespace) (looking-at org-ts-regexp-both))) The (small) issue here is that we cannot properly deprecate a variable that is not replaced with something else (i.e., we're not using `define-obsolete-variable-alias' here). Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removal of org-maybe-keyword-time-regexp 2020-03-11 21:09 ` Nicolas Goaziou @ 2020-03-11 21:29 ` Eric Abrahamsen 2020-03-11 22:20 ` Nicolas Goaziou 0 siblings, 1 reply; 7+ messages in thread From: Eric Abrahamsen @ 2020-03-11 21:29 UTC (permalink / raw) To: emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > Julien Cubizolles <j.cubizolles@free.fr> writes: > >> I'm using org-caldav (https://github.com/dengste/org-caldav/) to >> synchronize the calendar on my Android phone and Org. Recently this >> synchronization stopped working because org-caldav relies on >> org-maybe-keyword-time-regexp that has been dropped from Org. As a >> workaround, could this variable be reintroduced in org so as not to >> break this very useful package ? > > Could you contact upstream instead? > > AFAICT, they use this variable only twice. The first occurrence doesn't > seem useful (they check for a planning info keyword in a headline, which > cannot happen), it is probably enough to look for `org-ts-regexp-both'. > > I'm not sure about the second one. I guess it would be better for them > to use something like: > > (and (re-search-forward "org-planning-line-re" nil t) > (org-at-planning-p) > (progn > (org-skip-whitespace) > (looking-at org-ts-regexp-both))) > > The (small) issue here is that we cannot properly deprecate a variable > that is not replaced with something else (i.e., we're not using > `define-obsolete-variable-alias' here). But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a simply explanatory string. I was also recently bit by the removal of a bunch of regexps (in my case, link regexps), and it would have been useful to have some sort of a pointer, either in the obsolescence message or in the docs, about what we're supposed to do instead. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removal of org-maybe-keyword-time-regexp 2020-03-11 21:29 ` Eric Abrahamsen @ 2020-03-11 22:20 ` Nicolas Goaziou 2020-03-11 22:57 ` Eric Abrahamsen 0 siblings, 1 reply; 7+ messages in thread From: Nicolas Goaziou @ 2020-03-11 22:20 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode Hello, Eric Abrahamsen <eric@ericabrahamsen.net> writes: > But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a > simply explanatory string. You're right. However, I'm not sure what the CURRENT-NAME should be, besides "don't use this, you probably want something else" Also, my suggestions still holds: it is useful to warn upstream about it. > I was also recently bit by the removal of a bunch of regexps (in my > case, link regexps), and it would have been useful to have some sort of > a pointer, either in the obsolescence message or in the docs, about what > we're supposed to do instead. I'm not sure about what "bunch of regexps" you are talking about. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removal of org-maybe-keyword-time-regexp 2020-03-11 22:20 ` Nicolas Goaziou @ 2020-03-11 22:57 ` Eric Abrahamsen 2020-03-12 8:21 ` Nicolas Goaziou 0 siblings, 1 reply; 7+ messages in thread From: Eric Abrahamsen @ 2020-03-11 22:57 UTC (permalink / raw) To: emacs-orgmode On 03/11/20 23:20 PM, Nicolas Goaziou wrote: > Hello, > > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a >> simply explanatory string. > > You're right. However, I'm not sure what the CURRENT-NAME should be, > besides "don't use this, you probably want something else" I would have liked to know what the "something else" was! Or even "Org link regexps have been rewritten", something like that. > Also, my suggestions still holds: it is useful to warn upstream about > it. Absolutely. I don't think Org has a responsibility to maintain backwards compatibility for these variables, and upstream packages should be tracking changes. But the more help we can provide, the better. >> I was also recently bit by the removal of a bunch of regexps (in my >> case, link regexps), and it would have been useful to have some sort of >> a pointer, either in the obsolescence message or in the docs, about what >> we're supposed to do instead. > > I'm not sure about what "bunch of regexps" you are talking about. Looks like commit "Move link-related core functions out of \"org.el\"". Nearly a year ago -- I wasn't paying attention! But defining link regexps as aliases of other link regexps meant that the regexps matched, but the match groups were off: that led to silent failure, and took quite a while to debug. I guess I would have preferred a loud failure. Anyway, it's not a big deal, I only bring it up because someone else did! Eric ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removal of org-maybe-keyword-time-regexp 2020-03-11 22:57 ` Eric Abrahamsen @ 2020-03-12 8:21 ` Nicolas Goaziou 2020-03-12 19:03 ` Eric Abrahamsen 0 siblings, 1 reply; 7+ messages in thread From: Nicolas Goaziou @ 2020-03-12 8:21 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode Hello, Eric Abrahamsen <eric@ericabrahamsen.net> writes: > I would have liked to know what the "something else" was! Or even "Org > link regexps have been rewritten", something like that. I added an obsolescence warning about it in "org-compat.el". It will still break upstream, since there is no replacement for the variable. > Looks like commit "Move link-related core functions out of \"org.el\"". > Nearly a year ago -- I wasn't paying attention! But defining link > regexps as aliases of other link regexps meant that the regexps matched, > but the match groups were off: that led to silent failure, and took > quite a while to debug. I guess I would have preferred a loud failure. Most variables were only renamed. It's possible that a few of them changed match groups, but that was probably not intentional (I cannot remember). The only intended change was `org-link-bracket-re', which is documented in ORG-NEWS. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removal of org-maybe-keyword-time-regexp 2020-03-12 8:21 ` Nicolas Goaziou @ 2020-03-12 19:03 ` Eric Abrahamsen 0 siblings, 0 replies; 7+ messages in thread From: Eric Abrahamsen @ 2020-03-12 19:03 UTC (permalink / raw) To: emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> I would have liked to know what the "something else" was! Or even "Org >> link regexps have been rewritten", something like that. > > I added an obsolescence warning about it in "org-compat.el". It will > still break upstream, since there is no replacement for the variable. I suppose I should have been watching the compiler more closely... >> Looks like commit "Move link-related core functions out of \"org.el\"". >> Nearly a year ago -- I wasn't paying attention! But defining link >> regexps as aliases of other link regexps meant that the regexps matched, >> but the match groups were off: that led to silent failure, and took >> quite a while to debug. I guess I would have preferred a loud failure. > > Most variables were only renamed. It's possible that a few of them > changed match groups, but that was probably not intentional (I cannot > remember). The only intended change was `org-link-bracket-re', which is > documented in ORG-NEWS. It was `org-bracket-link-analytic-regexp', which was made an alias for `org-link-bracket-re', but the groups were different. I just moved straight to using `org-link-any-re'. Anyway, it wasn't a huge problem, and I'm happy to keep up with Org changes, but in this case the silent failure was a bit tricky. Eric ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-03-12 19:04 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-03-11 17:21 removal of org-maybe-keyword-time-regexp Julien Cubizolles 2020-03-11 21:09 ` Nicolas Goaziou 2020-03-11 21:29 ` Eric Abrahamsen 2020-03-11 22:20 ` Nicolas Goaziou 2020-03-11 22:57 ` Eric Abrahamsen 2020-03-12 8:21 ` Nicolas Goaziou 2020-03-12 19:03 ` Eric Abrahamsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.