Re: org code and error catching
Ihor Radchenko writes: > > Though, I think you didn't change the occurrence that this thread > > started with - `org-eval'. Does changing this one cause problems? > > Tests are passing. > I originally skipped it because it did not look useful from a brief > glance to have full backtraces there, and I was unsure if it is truly > safe. I don't recall either why I originally needed backtraces for it. There was a reason, but I don't remember. > I see no obvious downsides though. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1cb5de621 Thanks, Ihor. Michael.
Re: org code and error catching
Michael Heerdegen writes: > I reviewed it shortly - looks appropriate. Though, I think you didn't change the occurrence that this thread started with - `org-eval'. Does changing this one cause problems? Michael.
Re: org code and error catching
Ihor Radchenko writes: > I changed instances that appear to be safe. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5b4eebfab I reviewed it shortly - looks appropriate. Thank you very much! Michael.
Re: org code and error catching
Ihor Radchenko writes: > As for condition-case-unless-debug, may you create a patch? > But please do not replace everything blindly - I know for sure that at > least some `condition-case' clauses are there on purpose. I nearly never had a closer look at the org-mode code (other than blindly). I would prefer to help differently (like reviewing a patch), honestly, unless there is really no one more appropriate to find. Michael.
Re: org code and error catching
Ihor Radchenko writes: > What are those? > I do not have anything failing on my side. See the attached file. I had been using an up-to-date Emacs master build. Michael. <>
Re: org code and error catching
Ihor Radchenko writes: > In my attempts, the tests started failing for no obvious reason. > Just from changing `condition-case' to `condition-case-unless-debug'. > > Though I did not investigate if it happened for every atomic change. Hmm - mine gave a different result: I cloned the org-mode archive from https://git.savannah.gnu.org/git/emacs/org-mode.git, called "make" and ran the tests as described in the "testing/README". That gave 6 failing tests. Then I blindly replaced every occurrence of `condition-case' with `condition-case-unless-debug' (everywhere but not in the tests), ran "git clean -xf", then "make" again, and ran the tests again. Again 6 failing tests. Not sure if I did something wrong. Michael.
Re: org code and error catching
Ihor Radchenko writes: > This is a good idea, except that `condition-case-unless-debug' has > non-obvious side effects that interfere with ERT (Org testing system). What side effects are these? Thx, Michael.
Re: org-read-date: selecting date with mouse-2 in calendar
Hello again, > selecting a date from within `org-read-date' from the calendar works > with mouse-1, but not with mouse-2 (with latest Emacs master and my > settings loaded at least). > > The code seems to intend that it also works with mouse-2, but it fails. > > Why it doesn't work? Oh, that's because calendar already binds > down-mouse-2 to pop-up a menu (see definition of `calendar-mode-map'). > So when we would add the following line to `org-read-date' (it's obvious > to where and I'm too lazy to create a patch now): > > + (org-defkey map [down-mouse-2] nil) No comments on this (hope it wasn't too confused...)? Should I just commit the fix to the Emacs master branch? TIA, Michael.
Re: org-read-date: selecting date with mouse-2 in calendar
Michael Heerdegen writes: > Nothing is lost since the original popup-menu for the calendar is > still being bound to down-mouse-3 (the more expected key for such a > menu in my opinion, at least 2021). That was not quite correct, however. These are the defining lines: ;; These are referenced in the default calendar-date-echo-text. (define-key map [down-mouse-3] (easy-menu-binding cal-menu-context-mouse-menu)) (define-key map [down-mouse-2] (easy-menu-binding cal-menu-global-mouse-menu)) So the calendar provides a global (mouse-2) and a context menu (mouse-3). Seems both are not really useful for `org-read-date'. Michael.
Re: org-read-date: selecting date with mouse-2 in calendar
Michael Heerdegen writes: > So please consider [...] Oh, and please keep me CC'd, I don't read the list regularly. Thanks, Michael.
org-read-date: selecting date with mouse-2 in calendar
Hello, selecting a date from within `org-read-date' from the calendar works with mouse-1, but not with mouse-2 (with latest Emacs master and my settings loaded at least). The code seems to intend that it also works with mouse-2, but it fails. I don't prefer mouse-2, but it would be good to support it I think, since "clicking" in Emacs is with mouse-2 historically, breaking that might cause inconvenience. Why it doesn't work? Oh, that's because calendar already binds down-mouse-2 to pop-up a menu (see definition of `calendar-mode-map'). So when we would add the following line to `org-read-date' (it's obvious to where and I'm too lazy to create a patch now): + (org-defkey map [down-mouse-2] nil) it works as expected for me. Nothing is lost since the original popup-menu for the calendar is still being bound to down-mouse-3 (the more expected key for such a menu in my opinion, at least 2021). So please consider to add the above line to the defun of `org-read-date'. Regards, Michael.
Re: logrepeat only logging LAST_REPEAT
Ihor Radchenko writes: > You are right. Since this is hard-coded, you may have to use :around > advice to disable org-log-setup: [...] Do you think others may want the same and it could be worth to implement this feature? Michael.
Re: logrepeat only logging LAST_REPEAT
Ihor Radchenko writes: > > Is there a way to get only the :LAST_REPEAT: prop logged, without the > > ever-growing list? > > I guess you can try to play with org-log-done and org-log-repeat > variables. Thanks. But as far as I recall, that's what I already tried and it didn't help. As far as I understand, the logging is implemented in `org-auto-repeat-maybe', and the thing I do not want is caused by the `org-add-log-setup' call, and that is done unconditionally unless `org-log-repeat's value is nil. Which I don't want because this would also disable the "LAST_REPEAT" property setting. Thanks, Michael.
logrepeat only logging LAST_REPEAT
Hello, for some entries I use the logrepeat feature (enabled by setting the LOGGING property of the entry). I get a :LAST_REPEAT: property that I (always) want, and also a complete log I do not (always) want, in the form of a growing list of - State "DONE" from "XYZ" [2021-01-19 Di 12:01] style entries that I often "garbage collect" manually. Is there a way to get only the :LAST_REPEAT: prop logged, without the ever-growing list? If not, please consider as "wishlist" request. TIA, Michael.
Re: org-agenda-get-timestamps and properties
Kyle Meyer writes: > > but not when formatted like this: > > > > ** APPT 10:40 Xyz > > SCHEDULED: <2020-11-08 So +1d> > > :PROPERTIES: > > :ID: 1d313f9a-3044-4c23-9278-422646ec9063 > > :END: > > > > although the latter form is, AFAICT, recommended, and at least it's what > > I get when creating ids automatically with (org-id-get-create). > > ...while this is a valid scheduled heading. Hmm, seems my code has come to the same conclusion and magically started working, without any change, AFAICT. Strange, dunno how, but your answer somehow helped. Quantum physics, probably. I hope it remains so... Thanks, Michael.
org-agenda-get-timestamps and properties
Hi, I have a problem with my appt.el replacement I develop. When debugging, I found that `org-agenda-get-timestamps' does, depending on the position of the SCHEDULED spec, do return a timestamp when an entry is formatted like this: ** APPT 10:40 Xyz :PROPERTIES: :ID: 1d313f9a-3044-4c23-9278-422646ec9063 :END: SCHEDULED: <2020-11-08 So +1d> but not when formatted like this: ** APPT 10:40 Xyz SCHEDULED: <2020-11-08 So +1d> :PROPERTIES: :ID: 1d313f9a-3044-4c23-9278-422646ec9063 :END: although the latter form is, AFAICT, recommended, and at least it's what I get when creating ids automatically with (org-id-get-create). No timestamp, and my appointments don't work (bad). Has anybody any insight into this matter? TIA, Michael.
Re: org-marker vs. org-hd-marker
Kyle Meyer writes: > Going through each of the collection functions at the end of > org-agenda-get-day-entries, it looks like they all set org-marker. > Plus, I can spot places in org-agenda.el that rely on agenda entries > having org-marker (e.g., org-agenda-goto and org-agenda-todo), so I > think that assumption would be safe. Great, thanks for checking, Kyle. Michael.
Re: Headline generation as in diary?
I wrote: > With diary, I can use arbitrary Lisp expressions to generate dates, and > those expressions can also return a string to use as non-nil return > value to generate non-constant headlines including certain numbers for > example. [...] My solution so far: I've set up my `org-capture-templates' so that when I hit T (instead of t) I am prompted for time+headline and optionally a number of days for a reminder, and, for example, when I enter "21:00 Test" and a "2" I get an entry like | ** TODO Special entry: "21:00 Test" | %%(diary-remind |'(and | (dg-it-is "[2020-10-31 Sa]") | "TODO 21:00 Test") |2) `dg-it-is' is a function that tests whether "it is" the given date specified as an inactive org time stamp. The nice thing about this is that org recognizes the stamp and I can click on it with the mouse to change it etc. And I can freely edit the whole expression. The entry gets listed in the agenda correctly (also the reminder) and I get two appt.el appointments (or rather, my substitution for it). Cons: The headline is ignored, I use a dummy headline. I don't have emacs-lisp bindings to edit the expression in the Capture or Org buffer, so if I want something more complicated I probably need to use *scratch* as intermediate step (I tried to use a source block, but then the %%() expression is not recognized any more, and the time stamps are not clickable any more). And for whatever reason, the agenda doesn't fontify the word "TODO". If anyone has ideas for improvements, I'm curious! Regards, Michael.
Re: org-marker vs. org-hd-marker
Kyle Meyer writes: > My reading (which could be very wrong) is that org-hd-marker is always > set to the start of the headline. org-marker, on the other hand, is set > to some position in the entry that depends on who is setting it. Thanks for the insights, Kyle. Do you know whether I can assume that one of those is always present (org-marker probably, since org-hd-marker is not always present) when examining the result of `org-agenda-get-day-entries'? I don't care about the exact location in an entry. > > What does "hd" stand for? > > Headline, I guess. Ah, that would make sense (and also explain why there are no 4k markers ;-) Regards, Michael.
Re: Force creation of org id in template
gusbrs.2...@gmail.com writes: > Untested, but how about adding something like the following to your > template? > > :PROPERTIES: > :ID: %(org-id-new) > :END: I'm not sure. I see that creating an id involves slightly more than adding the property - see the `org-id-add-location' call in `org-id-get'. Calling the higher level `org-id-get' or the like in a %() spec in a template fails however, since when it's called a temp buffer not associated with a file is current. And then I'm also not sure if the above is always secure when something else in the template spec wants to add a (different) property. Do you know? Thanks, Michael.
Force creation of org id in template
Hello, is it possible to tweak `org-capture-templates' entries so that the creation of an org id for an org entry created with `org-capture' is forced? TIA, Michael.
org code and error catching
Hello, I had a hard time to debug some problem with the expansion of some capture template because org catched the error even when I had set `debug-on-error'. Would it be possible to make some functions, e.g. `org-eval' in my case (probably some more?), use `condition-case-unless-debug' instead of `condition-case'? Thanks, Michael.
org-marker vs. org-hd-marker
Hello, what's the difference between org-marker and org-hd-marker markers? What does "hd" stand for? TIA, Michael.
Re: Headline generation as in diary?
Ihor Radchenko writes: > > I didn't know that eval specs support multi-line sexps, but seems that > > works, so I can indeed use this. Thanks for the suggestion. > > Hmm. According to manual, it should support multi-line string. Not sure > about sexps. AFAIR it didn't work in the past. I guess it has been fixed in master not long ago. Michael.
Re: Headline generation as in diary?
Ihor Radchenko writes: > I do not think there is support of multi-line planning everywhere. I see. > You can always use file-local definition at the beginning or end of your > org file. Below is an example of local definition at the end of an org > file. > > # Local Variables: > # eval: (defun your-function () (sexp)) I didn't know that eval specs support multi-line sexps, but seems that works, so I can indeed use this. Thanks for the suggestion. Michael.
Re: Headline generation as in diary?
Robert Pluim writes: > It can? Thatʼs not documented, as far as I can tell. As a user, I read "Diary-style expression entries" in the org manual as including my own defined diary sexps - excluding them would be a surprise that should be documented (no, I don't want that to happen!). Michael.
Re: Headline generation as in diary?
Ihor Radchenko writes: > > When dealing with complicated date rules it can likely happen that a > > diary sexp doesn't fit into one line. > > Diary sexp can be a user-defined function. If your sexp needs to span > multiple lines, it is probably worth defining a function and simply > using <%%(your-function)> as a timestamp. I think this is inconvenient. Ok, only a bit. But it would be nicer if I could specify my dates in only one file. Jumping around in my org file + my emacs init file is what I used to do. Multi-line sexps in time stamps work would just be nice to have. Would it be hard to achieve? I mean, since multi-line %%(...) entries already work... Thanks, Michael.
Re: Headline generation as in diary?
Robert Pluim writes: > I can push my change to org, but Iʼm not a regular org contributor, so > Iʼd prefer to hear from one of the maintainers first. Sorry - I meant, I see no reason to touch the existing code. No need to change anything for what I want. > Michael> This doesn't work: > > Michael> | ** APPT 17:00 Test > Michael> | SCHEDULED: <%%(and (or (diary-date 03 09 2020) > Michael> |(diary-date 04 09 2020)))> > I think thatʼs just a consequence of timestamps not being allowed to > span multiple lines in org, unlike diary. This is bad. Why is that? Can it be changed? When dealing with complicated date rules it can likely happen that a diary sexp doesn't fit into one line. Regards, Michael.
Re: Headline generation as in diary?
Robert Pluim writes: > OK. Thatʼs as far as my org-hacking knowledge goes, so perhaps someone > else here has an idea of the right way to invoke "tell me what heading > Iʼm in, as a string". The situation is actually like this: the empty string issue doesn't happen with time stamps <%%(...)>, this always uses the correct headline. Seems %%() entries are expected to return a string OTOH since the headline seems to be ignored. I guess this is reasonable. Dunno if there is something to change here at all in the code. Ok, the other thing: broken time stamps with line breaks: > You've lost me. Can you show me an example? The difference here is only a line break: This doesn't work: | ** APPT 17:00 Test | SCHEDULED: <%%(and (or (diary-date 03 09 2020) |(diary-date 04 09 2020)))> But this works: | ** APPT 17:00 Test | SCHEDULED: <%%(and (or (diary-date 03 09 2020) (diary-date 04 09 2020)))> Michael.
Re: Headline generation as in diary?
Robert Pluim writes: > How about: > > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index 78fe13303..9049b3a42 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -5772,7 +5772,7 @@ displayed in agenda view." > r (replace-match "" nil nil r))) > (if (string-match "\\S-" r) > (setq txt r) > - (setq txt "SEXP entry returned empty string")) > + (setq txt (org-no-properties (org-get-heading t t t t > (setq txt (org-agenda-format-item extra txt level category tags > 'time)) > (org-add-props txt props 'org-marker marker > 'date date 'todo-state todo-state Thanks for looking at this. Ok - That gives me a headline in the agenda, but a wrong one (more or less, a random headline in the same file, at a seemingly unrelated location). > (Iʼm guessing yet-another-config-variable is unnecessary) I think so toom yes. > >> You can use them in timestamps as well, which is useful for > >> weird time > >> periods > >> > >> ** Just before midnight on a few days 23:00-24:00 > >> <%%(org-block 2020 8 31 2020 9 2)> > >> <%%(org-block 2020 9 10 2020 9 12)> > > Michael> But it seems those time stamps are not allowed to span > Michael> multiple lines > Michael> (at least I don't get it work). Seems org doesn't > Michael> recognize them as > Michael> such? > > Itʼs working fine for me in org-9.3.6. Note that I have my default > agenda view set to a fortnight, and those dates span two different > weeks. I didn't mean time spans. What doesn't work for me are time _stamps_ that span multiple text lines. Thanks, Michael.
Re: Headline generation as in diary?
Robert Pluim writes: > Itʼs triggered by the %%(, I believe, but not in headlines. Yes, I see that in the code. But actually I seem to have the opposite problem: I can't make the original headline appear in the agenda. When the sexp doesn't return a string the agenda will contain a line saying "SEXP entry returned empty string" instead of showing the headline. > You can use them in timestamps as well, which is useful for weird time > periods > > ** Just before midnight on a few days 23:00-24:00 > <%%(org-block 2020 8 31 2020 9 2)> > <%%(org-block 2020 9 10 2020 9 12)> But it seems those time stamps are not allowed to span multiple lines (at least I don't get it work). Seems org doesn't recognize them as such? Michael.
Re: Headline generation as in diary?
Michael Heerdegen writes: > > [1] https://github.com/m-cat/org-recur > > Thanks for the hint, I'll have a look. Nice to have definitely. I want to stick to diary sexp expressions for some complicated dates. I have already extended the diary language to fit my needs to specify the dates of garbage collection here. That looks like this: #+begin_src emacs-lisp (dg-let-date (dg-tomorrow) (dg-except-for* (and (dg-friday-p) (cl-evenp (dg-iso-week))) (cl-some #'dg-holiday-p (dg-the-days-between (dg-days-before 2))) +1)) #+end_src It means: warn me one day before garbage collection happens, and that is: every Friday in any week with even week number, unless it has been a holiday up to two days before that, then they collect one day later. I guess I always want Lisp to specify something like this. Michael.
Re: Headline generation as in diary?
Eric S Fraga writes: > No, not necessarily. I have entries like this: > > %%(diary-anniversary 1981 03 17) Somebody's birthday (%d years) > > and the agenda view shows "Somebody's birthday (19 years)"; the actual > heading for this entry is ignored. Where in an entry do you specify such specifications? > However, I don't know if other diary- functions work the same way. Yes, the interesting part then is: when does org behave like this, and can this behavior be forced? > > Or do I miss something? How to other people deal with things > > like...garbage collection? > > I use the org-recur [1] package for this. Very nice for repeating > events. > Footnotes: > [1] https://github.com/m-cat/org-recur Thanks for the hint, I'll have a look. Michael.
Headline generation as in diary?
Hi, I am mainly using the org agenda for day planning. But there is a functionality I seem to miss I know from diary: With diary, I can use arbitrary Lisp expressions to generate dates, and those expressions can also return a string to use as non-nil return value to generate non-constant headlines including certain numbers for example. I can use that to implement when the next garbage collection will come (rules for that are complicated since there are exceptions etc), add reminders for certain important stuff, etc. I would like to use my org file to specify those things instead of maintaining a second file (the diary file). But AFAIK the dynamically created headline part is tricky: what appears in the agenda is always the org headline as it appears in the file, right? Or do I miss something? How to other people deal with things like...garbage collection? TIA, Michael.
Re: Emacs bug 37890; killing capture buffer
Ihor Radchenko writes: > You can try M-x org-submit-bug-report ;) > Then it becomes clear that you are in the right place already. Thanks! I didn't know about this command - actually I had searched for it but didn't find it because I had searched for something named "report-org-bug" (analogue to `report-emacs-bug'). I think this may happen to other org users not following org-mode development as well - so I just used the command to suggest this name as alias. Regards, Michael.
Bug: About org-submit-bug-report [9.3 (release_9.3 @ /usr/local/share/emacs/27.0.50/lisp/org/)]
Hello, I want to suggest to make `report-org-bug' and alias for the command `org-submit-bug-report'. That's the name I expected (considering "report-emacs-bug"), also some other Emacs packages name their bug reporting command according to this scheme. The additional name would make this important command more discoverable. Second point: When you think it is a trivial task for a common user please consider to add some text to the initial buffer contents of the message buffer created by this command explaining where one can search for existing reports (to avoid duplicates and reports about things that are just pitfalls etc). My buffer included a link to a page explaining how to create a good report but there this information is also missing, although I think it would be a good place. TIA, Michael. Emacs : GNU Emacs 27.0.50 (build 41, x86_64-pc-linux-gnu, GTK+ Version 3.24.13) of 2019-12-20 Package: Org mode version 9.3 (release_9.3 @ /usr/local/share/emacs/27.0.50/lisp/org/)
Re: Emacs bug 37890; killing capture buffer
Samuel Wales writes: > the indirect buffer capture mechanism was to be an improvement on > remember.el, and replaced it. you might still be able to find > remember.el if you prefer the separate file idea. I find it acceptable once it's been made more secure (e.g. by using hooks like I mentioned). But I wonder now why you said there are still problems with final newlines (and you already got a confirmation), while I and other developers say it has been fixed. Do you use the org mode version built in Emacs, and you don't use Emacs master? Thanks, Michael.
Re: Emacs bug 37890; killing capture buffer
Adam Porter writes: > People do care! But everyone here works on Org in their spare time, > and Org is a big project, and things slip through the cracks. I didn't meant to criticize anyone (I have the same problem with my own stuff). Anyway, we got some attention now, thanks for your help! Regards, Michael.
Re: Emacs bug 37890; killing capture buffer
Adam Porter writes: > I guess you're asking me, since I'm the only other person in this > thread--but I'm not an Org maintainer, so my opinion isn't very > important. IMO, the hooks are worth considering, however they should be > done very, very carefully, because bad things can happen when functions > called in kill hooks don't work as expected (e.g. they can make it very > difficult to kill a buffer or the Emacs process, especially for an > average user). Yes, all true. I didn't even check if the code I posted breaks any org commands that kill the buffer. So far it's only meant for demonstration (and my personal usage). Will my request be noticed here, or do you think I should report it to some other place? > > BTW, what about my question whether my original bug report can be > > closed? > > I haven't seen your bug report. Was there discussion about it > previously? No, no discussion at all. As I said, it is Emacs bug #37890, this was my issue: | I want to capture an APPT with `org-capture'. I the pop-up buffer to | edit the item I move the date to the second line and add text after the | date (personal preference). That loses the final newline in | CAPTURE-todo.org. As a result, the headline of the item following the | item to be inserted gets appended to the last line of the text: | | ** APPT Abc |<2019-10-23 Mi> | text... ** APPT 8:30 Important Appointment | | breaking the whole item. The user should somehow be prevented from that | happening. It seems it has been resolved, just without noticing my bug report. If you can confirm that the cited issue has been cared about, I'll close it as done. BTW, what is the canonical place to report org-mode bugs? Emacs bug reports are not (takes a long time until someone even notices) -- I thought this list would be good...or is there a better place? @Adam it's ok if you answer, though I'm a bit disappointed that no one else seems to care so far... Thanks, Michael.
Re: Emacs bug 37890; killing capture buffer
Michael Heerdegen writes: > - kill-buffer-hook in the capture buffer could be used to prevent the > user from killing such a buffer by accident. Or it could be made > configurable what to do (e.g. undo the change with or without user > prompting, ask for what to do, etc.) > > - kill-emacs-hook could be used to register a function that warns when > any capture buffers are left when Emacs is to be killed. That would > make a difference if you have captured more stuff after having > forgotten about a former capture buffer. The user would be guided to > finish what he would otherwise have forgotten. That doesn't seem to be hard to implement: #+begin_src emacs-lisp (add-hook 'org-capture-mode-hook (defun my-org-capture-mode-hook-fun () (add-hook 'kill-buffer-hook (defun my-org-capture-inhibit-accidental-kill () (user-error "Please don't just kill org capture buffers")) nil 'local) (add-hook 'kill-emacs-hook (defun my-org-capture-barf-for-left-capture-buffers () (dolist (b (buffer-list)) (when (with-current-buffer b (bound-and-true-p org-capture-mode)) (user-error "Please care about org capture buffer %s" (buffer-name b (add-hook 'org-capture-prepare-finalize-hook (defun my-org-capture-prepare-finalize-hook-fun () (remove-hook 'kill-buffer-hook 'my-org-capture-inhibit-accidental-kill 'local))) #+end_src Would you consider to do something like this by default? BTW, what about my question whether my original bug report can be closed? TIA, Michael.
Re: Emacs bug 37890; killing capture buffer
Adam Porter writes: > Michael Heerdegen writes: > > > Or (really better IMHO) consider a different implementation where the > > original buffer is not modified until the user explicitly confirms the > > stuff to capture with C-c C-c. > > That would be helpful in some ways, but harmful in others. For example, > consider a capture that is started while in a meeting, on a phone call, > away from one's desk, etc., with some notes in it, clock start time, > etc. (You can find examples of this workflow in, e.g. Bernt Hansen's > Org config.) If Emacs were interrupted (crash, power failure, reboot, > etc), the un-finalized capture would still be present in the auto-save > file and could be recovered when restarting Emacs and finding the file > again. A legitimate objection. > The way Org uses indirect, narrowed buffers for capturing is an > elegant use of Emacs features that helps protect user data from > accidental loss. Let me rethink from the other side: how could the issue I described (globbered org file) be prevented? If you happen to kill the capture buffer or forget about it, is there any indication left that there is a problem? A modified buffer visiting the org file is left, but as soon as you successfully capture something else Org happily saves both edits to the file. So maybe we could prevent the user from doing something wrong? Maybe like this: - kill-buffer-hook in the capture buffer could be used to prevent the user from killing such a buffer by accident. Or it could be made configurable what to do (e.g. undo the change with or without user prompting, ask for what to do, etc.) - kill-emacs-hook could be used to register a function that warns when any capture buffers are left when Emacs is to be killed. That would make a difference if you have captured more stuff after having forgotten about a former capture buffer. The user would be guided to finish what he would otherwise have forgotten. That would improve security even further without getting in the way in the normal workflow. Michael.
Emacs bug 37890; killing capture buffer
Hi, I want to speak about my Emacs bug report 37890 about org-capture. Seems my main point: | I want to capture an APPT with `org-capture'. I the pop-up buffer to | edit the item I move the date to the second line and add text after the | date (personal preference). That loses the final newline in | CAPTURE-todo.org. As a result, the headline of the item following the | item to be inserted gets appended to the last line of the text: | | ** APPT Abc |<2019-10-23 Mi> | text... ** APPT 8:30 Important Appointment | | breaking the whole item. The user should somehow be prevented from that | happening. has been resolved with the latest merge into Emacs master - is that correct? Then I will close that report. The report also included a feature request which I now want to tell here: I often kill the capture buffer instead of hitting C-c C-k. Just by habit. It's wrong and I now it but I guess it happens to others. I guess the capture buffer is just a narrowed indirect buffer copy of the buffer visiting the according org file. Because of this, when you kill the capture buffer, the original buffer reflects the partial and uncomplete entry one tried to add. This may damage your file. But such internals are not known to all, so it would be good if killing the capture buffer, or even just closing the window, would warn the user and offer to undo the partial changes. Or (really better IMHO) consider a different implementation where the original buffer is not modified until the user explicitly confirms the stuff to capture with C-c C-c. TIA, Michael.
Re: [O] Show APPTs every day in Agneda
Neil Jerram writes: > #+BEGIN_EXAMPLE > ** Bank holiday weekend > > <2018-05-05 Sat>--<2018-05-07 Mon> > #+END_EXAMPLE > Sorry, that's no solution for you, but maybe there's a clue in the > detail there? Ha! - indeed. It's obviously not allowed to add spaces like I used to do: <2018-05-05 Sat> -- <2018-05-07 Mon> With <2018-05-05 Sat>--<2018-05-07 Mon> it works like I want. So, thank you very much to pointing me into the right direction. But this doesn't seem to be documented...(question to all)? Thanks, Michael.
Re: [O] Show APPTs every day in Agneda
Neil Jerram writes: > Hi Michael, Hi Neil! > I'm not in front of my computer, to check this, but I think that an > active date range will have this effect, i.e. > > ** Vacation > -- Hmm, no, AFAICT that's what I used to do, and it only shows the appointment at start and end date, not between the two dates. That's with C-c a a btw. I wonder why it seems to work for you... Michael.
[O] Show APPTs every day in Agneda
Hi, I've APPTs like "Vacation" that last 14 days or so. Is there an option/way to show such an APPT for every concerned day, and not only for the border days, so that when I for example want to make a doctor's appointment I see for the respective day that I'm on vacation on that day? TIA, Michael.
[O] bug#18663: 25.0.50; Org agenda broken due to removed fancy-diary-display alias
Hello, I'm not anymore able to view the org agenda. I have been told that this issue has been fixed in the org repo, Commit 4a872ae3... [PATCH] Fix: Emacs 25 fancy diary inclusion in agenda Date: Sat Oct 11 18:16:36 2014 +0200 Dunno when this change will arrive in Emacs and who is responsible for that. Meanwhile users that are affected can fix this by adding the old obsolete alias to their configuration: (define-obsolete-function-alias 'fancy-diary-display 'diary-fancy-display 23.1) Michael.
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
Eli Zaretskii e...@gnu.org writes: [...] I'm not sure this is the same problem as reported by the OP, so it probably should have been reported as a separate bug (merging them later is easy). Ok. I wasn't sure what would be best. - visit a file under version control (I tried a git controlled file here) - M-x vc-annotate - v (i.e. vc-annotate-toggle-annotation-visibility) - M-x linum-mode == all lines but one loose their coloring. Those lines that are still colored loose their line number. nlinum-mode behaves similarly. Fixed in revision 117382 on the emacs-24 branch. Works for me, thanks! Michael.
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
Eli Zaretskii e...@gnu.org writes: Activating both linum-mode and org-indent-mode will cause several graphical glitches in the current line. See http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html That discussion provides no reproducible recipe. FWIW, I think we see something similar or related in helm: https://github.com/emacs-helm/helm/issues/560 Sadly, there's also no recipe for emacs -Q. Michael.
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
Michael Heerdegen michael_heerde...@web.de writes: Activating both linum-mode and org-indent-mode will cause several graphical glitches in the current line. See http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html That discussion provides no reproducible recipe. But I think I found something that is related (before-string overlays vs. text properties) and is reproducible for emacs -Q: - visit a file under version control (I tried a git controlled file here) - M-x vc-annotate - v (i.e. vc-annotate-toggle-annotation-visibility) - M-x linum-mode == all lines but one loose their coloring. Those lines that are still colored loose their line number. nlinum-mode behaves similarly. Michael.
Re: [O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]
Hi Carsten, I believe I have done it in the right place now, please confirm. Confirmed, thanks, that's what I wanted. There's just a little typo in the docstring of `org-unlogged-message': Display a message, but avoid loggin it in the *Messages* buffer. ^ g Regards, Michael.
Re: [O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]
Hello, When I move around in the *Org Agenda* with up and down, the current outline path is displayed in the echo area, which is good. However, what is displayed gets also copied in the *Messages* buffer, which is not helpful, but clutters *Messages* with useless noise. So, IMHO `org-display-outline-path' should still display its stuff in the echo area, but prevent logging in *Messages*. AFAIK, the way to do this is to bind `message-log-max' to nil. Can we please try to make some progress here? I don't want to suggest a patch because I don't know the org code base well, but binding `message-log-max' to nil at one or two location should totally suffice. Who can help? Regards, Michael.
[O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Hello, When I move around in the *Org Agenda* with up and down, the current outline path is displayed in the echo area, which is good. However, what is displayed gets also copied in the *Messages* buffer, which is not helpful, but clutters *Messages* with useless noise. So, IMHO `org-display-outline-path' should still display its stuff in the echo area, but prevent logging in *Messages*. AFAIK, the way to do this is to bind `message-log-max' to nil. I'm not sure if this is the right thing in every case, but if the goal is to just display something for better orientation etc., there is no need for logging. Dunno if there are other functions that could benefit from the same treatment. Regards, Michael. Emacs : GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2012-10-25 on dex, modified by Debian Package: Org-mode version 7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/) current state: == (setq org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-agenda-skip-deadline-prewarning-if-scheduled t org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-reverse-note-order t org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-capture-after-finalize-hook '(#[nil \300\301!\207 [org-agenda-to-appt refresh] 2]) org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers) org-confirm-shell-link-function 'yes-or-no-p org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-agenda-skip-scheduled-if-done t org-agenda-custom-commands '((d todo DELEGATED nil) (c todo DONE|DEFERRED|CANCELLED nil) (w todo WAITING nil) (W agenda #1= ((org-agenda-ndays 21))) (A #A Tasks for today agenda #1# ((org-agenda-skip-function (lambda nil (org-agenda-skip-entry-if (quote notregexp) \\=.*\\[#A\\])) ) (org-agenda-ndays 1) (org-agenda-overriding-header Today's Priority #A tasks: )) ) (u Unsceduled Tasks alltodo #1# ((org-agenda-skip-function (lambda nil (org-agenda-skip-entry-if (quote scheduled) (quote deadline) (quote regexp) [^\n]+) ) ) (org-agenda-overriding-header Unscheduled TODO entries: )) ) ) org-return-follows-link t org-capture-templates '((t Task entry (file+headline my-org-todo-file Tasks) * TODO %?\n SCHEDULED: %t :prepend t) (a APPT entry (file+headline my-org-todo-file Tasks) * APPT %?\n %t :prepend t) (c FromConkeror entry (file+headline my-org-todo-file Tasks) * TODO %?\n :PROPERTIES:\n :created: %U\n :link: %a\n :END:\n %i :prepend t) ) org-after-todo-state-change-hook '(org-clock-out-if-current) org-from-is-user-regexp \\Michael Heerdegen\\ org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '((lambda (rest --cl-rest--) (apply (quote #[(#1=#:G76352 #:G76353 rest #2=#:arguments_76338) \302J@\\207 [#1# #2# apply] 3] ) (quote #:--wrapped-lambda_76337--) (quote #:--menu--) --cl-rest--) ) #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207
[O] bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
Bastien b...@altern.org writes: Hi Michael, Michael Heerdegen michael_heerde...@web.de writes: The org-mode manual under the node The date/time prompt tells: [...] The function understands English month and weekday abbreviations. If you want to use unabbreviated names and/or other languages, configure the variables `parse-time-months' and `parse-time-weekdays'. It doesn't tell how the user can do that. Even worse, `parse-time-months' and `parse-time-weekdays' are not defined as user options and undocumented! After reading the above section in the org manual, users may replace the English names with e.g. German ones in their config. Seems this is not a good idea, as this user question in gnu.emacs.gnus shows: http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9 The thread doesn't tell what is wrong with setting `parse-time-months' and `parse-time-weekdays'. Can you expand a bit more on this? The thread is not completely visible in google groups, dunno why. Please read at gnu.emacs.gnus with a newsreader. The problem was that the user replaced the English names with German names - instead of adding them to the lists. This broke Gnus. Currently, `parse-time-months' and `parse-time-weekdays' are internal variables with no docstring. Seems they are not intended to be changed by the user. Other packages may rely on the fact that the default values aren't changed. If they are supposed to be configured by the user, they should get a documented defcustom. At least, the documentation in the org manual _must_ be improved, so that the user is enabled to do the right thing without breaking anything else. BTW1: maybe a better solution would be to define own variables for this purpose in org, instead of letting users change variables in parse-time.el. Org heavily depends on parse-time.el. Providing a defcustom in Org that is tied to parse-time.el at the same time is not trivial. Why not? You could just write a function `org-parse-time-string' that binds `parse-time-months' and `parse-time-weekdays' accordingly and calls `parse-time-string'. Then you would just need to call this new function from org code. Regards, Michael.
[O] Bug: `org-show-context' doc string [7.5]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Hi, in my version of org-mode, the doc string of `org-show-context' forgets to mention `org-show-entry-below', a variable that also influences the behavior of this function. Emacs : GNU Emacs 23.3.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2011-09-09 on spike.0x539.de, modified by Debian Package: Org-mode version 7.5
[O] Bug: org-export-html-protect-char-alist type def [7.5]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Hello, I use the ELPA built of orgmode. M-x customize-variable org-export-html-protect-char-alist RET gives an error. I guess its custom type definition is illegal: :type '((repeat (cons (string :tag Character) (string :tag HTML equivalent Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.5
