Re: removal of org-maybe-keyword-time-regexp
Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen 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
Re: removal of org-maybe-keyword-time-regexp
Hello, Eric Abrahamsen 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
Re: removal of org-maybe-keyword-time-regexp
On 03/11/20 23:20 PM, Nicolas Goaziou wrote: > Hello, > > Eric Abrahamsen 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
Re: removal of org-maybe-keyword-time-regexp
Hello, Eric Abrahamsen 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
Re: removal of org-maybe-keyword-time-regexp
Nicolas Goaziou writes: > Hello, > > Julien Cubizolles 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.
Re: removal of org-maybe-keyword-time-regexp
Hello, Julien Cubizolles 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
