Re: Bug or not a bug? dot expansion in ob-shell
Hi, Nick Dokos writes: >> That said, we have three solutions: >> >> 1. Stick to a strict reading of Org and bash manuals: the absence of a >>:results header means "return the value, i.e. the exit status". >> >> 2. Deviate from this strict reading, introduce an exception for *all* >>shell blocks: no :results header means "return output" and you need >>to use :results value to get the exit status (your proposal). >> >> 3. Deviate from this strict reading and introduce an option that says: >>"Don't deviate from the Org's and bash manuals for all src blocks". >> >> Obviously, nobody wants the first solution. > > I'm not convinced of that: personally, I would be happy with the first > solution and maybe others would be too. > > My longer term suggestion (which, I realize, does not help to close > *this* case any time soon): > > I think that the global default setting `:results value' is wrong Strongly agree with Nick on both points here. I prefer option 1 over options 2 and 3, I think it is the more consistent and simple behavior. I also think ":results value" is a problematic default. Anecdotally, I use Org-Babel as a computational notebook similar to Jupyter or Rmarkdown, and set ":session :results output" for nearly all my org-babel blocks. Of course, there are many ways in which org-babel can be used, and for some uses, ":results value" is the better default. But for other use cases, including shell blocks, ":results output" is the more intuitive default. And I think this is really the problem here. The result of a shell block is surprising to the new user, because the user probably wants ":results output", but ":results value" is the default. I'm not sure of the solution to this problem, but I don't think it's to change the meaning of ":results value".
Re: Survey: changing a few default settings for Org 9.4
Yes! Thank you Bastien! On Wed, Feb 19, 2020 at 10:26 AM Bastien wrote: > > Also, my question is still open: is there any strong reason to provide, > > out of the box, two template mechanisms in Org? This is genuine > > question. > > No, there is no good reason for two template mechanism, and if we can > rely on org-insert-structure-template only, while still being able to > complete <* at the beginning of the line, that'd be perfect to me. > I definitely agree with this. I voted (slightly late) for having org-tempo in org-modules--not out of any love of org-tempo itself, but more because it feels to me like an extremely natural way to create blocks. The tab key is extremely easy to hit, and having a fully formed block created by typing a short string of characters makes the tab-completion lizard-part of my brain happy in a way that key chord combos simply don't. I think this is partly because I personally can't do key chords at the same rate I can type a string of characters--even if they require technically the same number of keystrokes. Like, I can type a 10 character command *significantly* faster than I can hit a number of different combinations of keys that also happen to be 10 keypresses. I just personally find it really nice! On Fri, Feb 21, 2020 at 12:37 PM Diego Zamboni wrote: > Thanks Bastien for all your work! > > --Diego > > > On Fri, Feb 21, 2020 at 4:50 PM Bastien wrote: > >> Hi all, >> >> here are the results of the survey, with *47* voters: >> >> - 26+2 : org-loop-over-headlines-in-active-region => t >> - 25+2 : org-agenda-loop-over-headlines-in-active-region => t >> - 28+3 : org-fontify-done-headline => t >> - 17+4 : org-hide-emphasis-markers => t >> - 10+6 : org-hide-macro-markers => t >> - 15+5 : org-refile-use-cache => t >> - 23+6 : org-special-ctrl-k => t >> - 20+6 : org-allow-promoting-top-level-subtree => t >> - 22+5 : Add org-tempo to org-modules >> >> I've changed the values of these options in master: >> >> - 35+2 : org-src-tab-acts-natively => t >> - 28+3 : org-fontify-done-headline => t >> - 26+2 : org-loop-over-headlines-in-active-region => t >> - 25+2 : org-agenda-loop-over-headlines-in-active-region => t >> >> I've *not* changed the values of these options: >> >> - 23+6 : org-special-ctrl-k => t >> - 22+5 : Add org-tempo to org-modules >> - 20+6 : org-allow-promoting-top-level-subtree => t >> - 17+4 : org-hide-emphasis-markers => t >> - 10+6 : org-hide-macro-markers => t >> - 15+5 : org-refile-use-cache => t >> >> The reason for not changing the default of org-special-ctrl-k is that >> 23 < 47/2. Also, I think it was a mistake to propose this: even the >> org-special- prefix should have warned me. The org-special-* options >> should be nil by default, and while org-special-ctrl-k may be useful, >> it is as useful as org-special-ctrl-a/e, which sticks to nil too. >> >> The reason for not adding org-tempo to org-modules is, on top of the >> poll being 22 < 47/2, that the current discussion on the list leaves >> room for improvements that may lead to move org-tempo from Org's core >> anyway. >> >> The reason for not changing the four other options is that they did >> not get enough votes. >> >> I've push the change for the three options in current master. >> >> Thanks again for participating to the poll and to the discussions! >> >> Best, >> >> -- >> Bastien >> >>
Re: Bug or not a bug? dot expansion in ob-shell
Hi Bastien, I think all this is reasonable. I have some inline comments and a suggestion at the end. Bastien writes: > Hi Nick, > > I didn't conduct the survey in 2013, you can find the results here: > https://orgmode.org/worg/org-configs/org-customization-survey.html > > I understand why you (and Tim and Derek) think an option is too much. > > But let's separate two problems: one is that Org have many options, > some perhaps unneeded (or only here because of bad design decisions we > made in the past), causing a technical debt, another one being "How to > handle shell's notion of "return value" in ob-shell.el? > > The first problem is real: patches are always welcome in this area but > this is the kind of problem that requires a big picture and a strong > push, incremental fixes are difficult here. > But if we can avoid making the problem worse, we should do that. Messes like this are created, not born. > The second problem is real too, and while being cautious about not > making the first problem worse, the solution should be independant. > > That said, we have three solutions: > > 1. Stick to a strict reading of Org and bash manuals: the absence of a >:results header means "return the value, i.e. the exit status". > > 2. Deviate from this strict reading, introduce an exception for *all* >shell blocks: no :results header means "return output" and you need >to use :results value to get the exit status (your proposal). > > 3. Deviate from this strict reading and introduce an option that says: >"Don't deviate from the Org's and bash manuals for all src blocks". > > Obviously, nobody wants the first solution. I'm not convinced of that: personally, I would be happy with the first solution and maybe others would be too. I would add a :results output header explicitly where needed and be on my way. Of course, it would break workflows where the output is expected and that might be a problem for some. I agree that the option takes care of this problem. > > Part of me agrees with your second solution: after all, we had to wait > until Vladimir's "echo ." trick to find out there was a problem. > > Part of me think that (1) deviation from the normal behavior should be > carefully advertized and (2) by design, the normal behavior should not > require tweaking options manually for each block. An option fulfills > both these needs: allowing to get the normal behavior by default and > advertizing the "deviation". I somewhat object to the use of the word "normal" in this paragraph: I think you mean "current" in the first and last instances. I disagree with (2): see my suggestion below. And IMO, the option makes it so that most users don't have to change anything. That is a good think in general (it is the reason that the option exists), but it hides the deviation rather than advertising it, because unless somebody follows this discussion, they don't know that there *is* a deviation. > > Right now I'm not convinced we should get rid of this option. > > But I'm convinced we should take the decision we no consideration of > the first (biggest) problem of Org having *perhaps* too many options. > > Case still open. My longer term suggestion (which, I realize, does not help to close *this* case any time soon): I think that the global default setting `:results value' is wrong: it works fine for "functional" code blocks (ones where a function is defined and then called with some parameters to make sure it produces the correct value - the function can be written in any language: I don't mean to restrict it to functional languages); it does not work well for the "scripting" cases (ones where the code block is a sequence of calls, each of which might or might not produce output - but it's the whole output that matters, not the individual calls). In the longer run, I think the possibility of *forcing* users to choose which one they want, should be entertained. Thanks and regards! -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Survey: changing a few default settings for Org 9.4
Thanks Bastien for all your work! --Diego On Fri, Feb 21, 2020 at 4:50 PM Bastien wrote: > Hi all, > > here are the results of the survey, with *47* voters: > > - 26+2 : org-loop-over-headlines-in-active-region => t > - 25+2 : org-agenda-loop-over-headlines-in-active-region => t > - 28+3 : org-fontify-done-headline => t > - 17+4 : org-hide-emphasis-markers => t > - 10+6 : org-hide-macro-markers => t > - 15+5 : org-refile-use-cache => t > - 23+6 : org-special-ctrl-k => t > - 20+6 : org-allow-promoting-top-level-subtree => t > - 22+5 : Add org-tempo to org-modules > > I've changed the values of these options in master: > > - 35+2 : org-src-tab-acts-natively => t > - 28+3 : org-fontify-done-headline => t > - 26+2 : org-loop-over-headlines-in-active-region => t > - 25+2 : org-agenda-loop-over-headlines-in-active-region => t > > I've *not* changed the values of these options: > > - 23+6 : org-special-ctrl-k => t > - 22+5 : Add org-tempo to org-modules > - 20+6 : org-allow-promoting-top-level-subtree => t > - 17+4 : org-hide-emphasis-markers => t > - 10+6 : org-hide-macro-markers => t > - 15+5 : org-refile-use-cache => t > > The reason for not changing the default of org-special-ctrl-k is that > 23 < 47/2. Also, I think it was a mistake to propose this: even the > org-special- prefix should have warned me. The org-special-* options > should be nil by default, and while org-special-ctrl-k may be useful, > it is as useful as org-special-ctrl-a/e, which sticks to nil too. > > The reason for not adding org-tempo to org-modules is, on top of the > poll being 22 < 47/2, that the current discussion on the list leaves > room for improvements that may lead to move org-tempo from Org's core > anyway. > > The reason for not changing the four other options is that they did > not get enough votes. > > I've push the change for the three options in current master. > > Thanks again for participating to the poll and to the discussions! > > Best, > > -- > Bastien > >
Re: testing org-bbdb-anniversaries
Hi Nicolas. Nicolas> Sadly, yes. Like most diary-related stuff, it expects the Nicolas> `date' variable to be globally bound. Perhaps something about it on the help? --8<---cut here---start->8--- (defun org-bbdb-anniversaries () "Extract anniversaries from BBDB for display in the agenda In case of calling programatically. Like most diary-related stuff, it expects the `date' variable to be globally bound." (require 'bbdb) . ) --8<---cut here---end--->8--- Nicolas> Something like Nicolas> (let ((date '(2 29 2020))) (org-bbdb-anniversaries)) It helped. Thanks. BR
Re: testing org-bbdb-anniversaries
Hello, rrandr...@gmail.com (Andrés Ramírez) writes: > I eval 'org-bbdb-anniversaries' that lead me to > > --8<---cut here---start->8--- > Debugger entered--Lisp error: (void-variable date) > (car date) [...] > above is intended behaviour? Sadly, yes. Like most diary-related stuff, it expects the `date' variable to be globally bound. > I would like to to check an specific date on bbdb-records 2020-02-29 > and that date should return me a result that would confirm me > org-bbdb-anniversaries is loading my entries on agenda, otherwise a > warning message should appear on emacs startup. > > Which is the right way of checking org-bbdb-anniversaries is loading my > entries? Something like (let ((date '(2 29 2020))) (org-bbdb-anniversaries)) should do. Regards, -- Nicolas Goaziou
testing org-bbdb-anniversaries
Hi. Emacs 26.3, org 9.1.9 My bbdb anniversary entries are not being shown on my agenda. I would like to add warning on emacs startup when bbdb records are not being showed. I eval 'org-bbdb-anniversaries' that lead me to --8<---cut here---start->8--- Debugger entered--Lisp error: (void-variable date) (car date) (let* ((m (car date)) (d (nth 1 date)) (y (nth 2 date)) (annivs (gethash (list m d) org-bbdb-anniv-hash)) (text nil) rec recs) (if (and (= m 3) (= d 1) (not (null (gethash (list 2 29) org-bbdb-anniv-hash))) (not (calendar-leap-year-p y))) (progn (setq recs (gethash (list 2 29) org-bbdb-anniv-hash)) (while (setq rec (car-safe (prog1 recs (setq recs ... (setq annivs (cons rec annivs) (if annivs (progn (while (setq rec (car-safe (prog1 annivs (setq annivs ... (if rec (progn (let* (... ... ... ... ... ...) (org-add-props tmp nil ... name) (if text ... ...))) text) org-bbdb-anniversaries() eval((org-bbdb-anniversaries) nil) elisp--eval-last-sexp(nil) eval-last-sexp(nil) funcall-interactively(eval-last-sexp nil) call-interactively(eval-last-sexp nil nil) command-execute(eval-last-sexp) --8<---cut here---end--->8--- above is intended behaviour? I would like to to check an specific date on bbdb-records 2020-02-29 and that date should return me a result that would confirm me org-bbdb-anniversaries is loading my entries on agenda, otherwise a warning message should appear on emacs startup. Which is the right way of checking org-bbdb-anniversaries is loading my entries? BR
Re: Survey: changing a few default settings for Org 9.4
Hi all, here are the results of the survey, with *47* voters: - 26+2 : org-loop-over-headlines-in-active-region => t - 25+2 : org-agenda-loop-over-headlines-in-active-region => t - 28+3 : org-fontify-done-headline => t - 17+4 : org-hide-emphasis-markers => t - 10+6 : org-hide-macro-markers => t - 15+5 : org-refile-use-cache => t - 23+6 : org-special-ctrl-k => t - 20+6 : org-allow-promoting-top-level-subtree => t - 22+5 : Add org-tempo to org-modules I've changed the values of these options in master: - 35+2 : org-src-tab-acts-natively => t - 28+3 : org-fontify-done-headline => t - 26+2 : org-loop-over-headlines-in-active-region => t - 25+2 : org-agenda-loop-over-headlines-in-active-region => t I've *not* changed the values of these options: - 23+6 : org-special-ctrl-k => t - 22+5 : Add org-tempo to org-modules - 20+6 : org-allow-promoting-top-level-subtree => t - 17+4 : org-hide-emphasis-markers => t - 10+6 : org-hide-macro-markers => t - 15+5 : org-refile-use-cache => t The reason for not changing the default of org-special-ctrl-k is that 23 < 47/2. Also, I think it was a mistake to propose this: even the org-special- prefix should have warned me. The org-special-* options should be nil by default, and while org-special-ctrl-k may be useful, it is as useful as org-special-ctrl-a/e, which sticks to nil too. The reason for not adding org-tempo to org-modules is, on top of the poll being 22 < 47/2, that the current discussion on the list leaves room for improvements that may lead to move org-tempo from Org's core anyway. The reason for not changing the four other options is that they did not get enough votes. I've push the change for the three options in current master. Thanks again for participating to the poll and to the discussions! Best, -- Bastien
Re: [PATCH] Skip entries with no ID when updating ID locations
A note related to duplicate IDs, the messages only shows one of the duplicate, so it is not easy to know which one to change. This have implication when creating links to headline using their IDs. And does the current algorithm for finding duplicates check their reference through the "org db"? Regards, Roland. Bastien writes: > Hi Eric, > > Eric Abrahamsen writes: > >> Would the attached patch be acceptable? It's no big deal, just skips >> entries with no ID property when updating all ID locations. I couldn't >> figure out why I had several thousand "Duplicate ID "nil"" warnings in >> the *Messages* buffer after updating ID locations. > > A welcome enhancement - applied, thanks! -- Luke, use the FOSS Sent from Emacs
Re: Feature request: shared radio targets with archive files
Hi Bastien, * Bastien wrote: > > Karl Voit writes: > >> Can somebody estimate on the effort and potential negative >> implications (performance, caching issues, ...) when this feature >> would be extended, so that radio targets of foo.org also work[2] in >> foo.org_archive and vice versa? > > Radio targets only work within the same file. > > Just like HTML anchor links: voila. > > Allowing a radio target to be reached outside the current file would > lead to blur the distinction between radio targets and... links. Oh, what a bummer. > That said, you can write your own function, taking inspiration from > org-link--search-radio-target and adding it to org-open-link-functions, > where your function searches the target outside of the current buffer. > > Not sure, of course, whether this is trivial or not :) Hehe. OK, it was worth the (short) discussion. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Bonjour Bastien, * Bastien wrote: > > Karl Voit writes: > >> With disabled org-depend, it is working and finishes in ~5 minutes. With >> enabled org-depend it (sometimes) end up in an error as described. > > Do you need org-depend when exporting? Well: in all cases where I defined a dependency of task B to a task A, with disabled org-depend I end up seeing task B on the agenda although I can not do it at the moment. So as long as I don't use dependencies, it does not matter. However, I'm organizing a lecture in the summer term using a very large and complicated yankpad/yasnippet template for the whole term that is using many dependencies for approx. 70 todos. With disabled org-depend, I end up seeing all 70 todos although I may be able to work on two or three of them at any moment in time. > If not, I simply suggest to turn org-depend off... or to let-bind > `org-trigger-hook' and `org-blocker-hook' to nil in your function. > > Probably org-depend does a lot of moving back and forth in files to > check for IDs, and that may explain the time spend by this command > when you export many files. This sounds reasonable. I'm fine with - let's say - +50% 1-day agenda duration and I'm fine with even an hour of 60d agenda export to ics with enabled org-depend. The show-stopper is, when org-depend does run in an error after hours of exporting without a result. This way, I'm losing my Org->Android/Radicale workflow or my dependencies. The longer this thread gets, the more I have to accept that I might be the only one using dependencies in Org mode. I'm puzzled here because I do think that dependencies are such a natural thing to want and use. (I also have several ideas to improve usability of them to minimize manual effort when defining dependencies.) So maybe I have to invest a weekend or so to bisect the issue. My gut feeling tells me that I won't like the output somehow. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Bug or not a bug? dot expansion in ob-shell
Hi Nick, I didn't conduct the survey in 2013, you can find the results here: https://orgmode.org/worg/org-configs/org-customization-survey.html I understand why you (and Tim and Derek) think an option is too much. But let's separate two problems: one is that Org have many options, some perhaps unneeded (or only here because of bad design decisions we made in the past), causing a technical debt, another one being "How to handle shell's notion of "return value" in ob-shell.el? The first problem is real: patches are always welcome in this area but this is the kind of problem that requires a big picture and a strong push, incremental fixes are difficult here. The second problem is real too, and while being cautious about not making the first problem worse, the solution should be independant. That said, we have three solutions: 1. Stick to a strict reading of Org and bash manuals: the absence of a :results header means "return the value, i.e. the exit status". 2. Deviate from this strict reading, introduce an exception for *all* shell blocks: no :results header means "return output" and you need to use :results value to get the exit status (your proposal). 3. Deviate from this strict reading and introduce an option that says: "Don't deviate from the Org's and bash manuals for all src blocks". Obviously, nobody wants the first solution. Part of me agrees with your second solution: after all, we had to wait until Vladimir's "echo ." trick to find out there was a problem. Part of me think that (1) deviation from the normal behavior should be carefully advertized and (2) by design, the normal behavior should not require tweaking options manually for each block. An option fulfills both these needs: allowing to get the normal behavior by default and advertizing the "deviation". Right now I'm not convinced we should get rid of this option. But I'm convinced we should take the decision we no consideration of the first (biggest) problem of Org having *perhaps* too many options. Case still open. -- Bastien
