Re: [O] Getting text at position?
Mike Gauland writes: > I'd like to be able to be able to get the text associated with a given > heading (based on the current point, for example). > > Can anyone point me to an example for doing this in the approved manner > (assuming there is one), or to functions to help with this? Don't trust me to give you an approved manner, but a couple of options: * If you just care about headlines and assuming you want all associated content, including the headline text itself, perhaps calling org-copy-subtree non-interactively will suffice. If that doesn't behave how you want, looking at org-copy-subtree's source could still give you an idea of how to do what you want in elisp. * You could use the org-element API to get the information and likely could easily tweak something like below to suit your needs. (and (ignore-errors (org-back-to-heading t)) (let ((el (org-element-at-point))) (buffer-substring (org-element-property :begin el) (org-element-property :end el -- Kyle
[O] Getting text at position?
I'd like to be able to be able to get the text associated with a given heading (based on the current point, for example). Can anyone point me to an example for doing this in the approved manner (assuming there is one), or to functions to help with this? Kind regards, Mike
[O] Bug: Bulk adding tags in agenda does not respect radio groups
I have a radio group of 3 tags defined in org-tag-alist: now. next, later. This tag group works correctly when editing the tags directly in the original org files or when the tags are edited individually in the agenda using ':'. When editing tags via the agenda's bulk editing command, however, adding a tag from that radio group does not remove any pre-existing tags from that group. For example, say an item is already tagged "now", and the tag "next" is added to it via bulk editing. The expected result is that the tag "next" is added and the tag "now" is removed. Instead, the result is ":now:next:", as the pre-existing tag is not removed. I have version 9.2.3 - Mark Kerr
Re: [O] Bug: org-list-make-subtree produces incorrect level [9.2.3 (9.2.3-20-g31873e-elpaplus @ /home/felix/.emacs.d/elpa/org-plus-contrib-20190527/)]
Hello, Felix Wiemuth writes: > In some situations, org-list-make-subtree does not create the tree at > the desired level. For example, in the following case, when executing > the command on the first list element, the resulting level is 3 instead > of 2: > > * L1 > - List Item > ** L2 > > The result is: > > * L1 > *** List Item > ** L2 > > Expected result (as in most situations): > > * L1 > ** List Item > ** L2 > > The last item (L2) is necessary for this to happen, whether the list has > multiple items or > subitems does not matter. The identation of the list item does not > matter either. > > The same happens in deeper levels: > > * L1 > ** L2a > ** L2b >- List Item > *** L3 > > It seems that the resulting tree is always put one level deeper than a > (deeper) heading following without a newline. Maybe this was intended > but it feels unintuitive to me. > > * L1 > - List Item > *** L3 > > results in > > * L1 > List Item > *** L3 > > but > > * L1 > - List Item > > *** L3 > > results in > > * L1 > ** List Item > > *** L3 > > I think I also observed a case where the resulting level was 2 instead > of 4, so the other way round, but unfortunately I cannot reproduce it. I think this is now fixed in master. Thank you. Regards, -- Nicolas Goaziou
[O] bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?
Nicolas Floquet writes: > Le jeudi 16 mai 2019 à 17:16 +0200, Nicolas Floquet a écrit : >> The problem is not solved on emacs 26.2. > > I have just humbly made a little commit wich is not the best solution, > take in consideration that I am not a programmer… I can not currently > do better ! :-) > https://code.orgmode.org/nflqt/org-mode/commit/11206b40781b9f04912cb1c538a6b936c8dadc21 > I set that mirror up last year around when the bug report was submitted. I see in 50aca8422b [0] on the org-mode repo @ngz removed references to the GitHub repo from lisp/ox-html.el, as I believe there was some talk to use Emacs’s htmlfontify instead of htmlize. But I’m not aware of any progress on that front. Further, references to the GitHub repo still remain in lisp/ox-org.el, lisp/org-agenda.el, and lisp/org-manual.org; the first two of which were addressed by @nflqt’s commit above. [0]: https://code.orgmode.org/bzg/org-mode/commit/50aca8422b0afd4a2173ac93225fa9b39a94d8dd @ngz, until such time as htmlfontify fully replaces org-mode’s uses of htmlize, what do you think about (partially) reverting your 50aca8422b and instead of linking to the htmlize repo on GitHub or no link at all, link to https://code.orgmode.org/mirrors/emacs-htmlize instead? > > >> Thank you for all the work done. > > Again. Best, amin
Re: [O] [ANN] org-conflict add-on: timing conflicts detector and resolver for Org agenda
Hi, I'm surprised that noone answered yet. This package is great! You're addressing one of the large shortcomings of org-mode's planning features: org has information about several planning details (estimation, duration, holidays, start date, deadline, …) and still doesn't use any of that to offer help to the user in very simple cases. Like for instance, I would expect org-mode to say „you shouldn't have >20 tasks scheduled for the same day, because at a default duration of 1 h, you'll find that there aren't enough working hours to do them“. Or if you have a 10-hour task and a 12-hour task in the same day, it should trigger some warning. Or scheduling a work task during a holiday. Or conflicts. Or work which is scheduled after a deadline. Or 10 tasks scheduled one after the other without taking into account that humans need to take breaks from time to time. Or schedules based on out-of-date information like overrun deadlines or overrun budgets. I want the freedom to be able to do all those mistakes but I'd also appreciate some help from org-mode or any other tool… Scheduling algorithms are very hard. Repetitions, time zones, summer time changes, … As for org-conflict itself: I like how it has not only the part about detecting conflicts, but also an interface to see conflicting items, propose a solution and try to find the right time; that's many steps ahead. I would be fine with just being able to *detect* conflicts, but I see how detecting+resolving can be useful to many people. I like how you included the part about having breathing time or „coffee breaks“ between tasks. This is all very user-friendly. I'm not sure about the entry point; that is, how to invoke the conflict resolution step. From the documentation and from using it, it seems that you must actively say „right now I'd like to write a date to see whether it would conflict with anything“; this is a use case I never have thought of or needed previously. My needs have rather been: 1) „right now I'd like to schedule a task“ (hopefully at a date which doesn't create conflicts). That means, I'd prefer if the conflict resolution happened as part of the normal C-c C-s scheduling process, instead of an optional step that you must remember to invoke with C-c C-c. Reschedulings (including rescheduling after a repetition) should be subject to the same checks. Even if this means having to wait more. I think you could provide some code or instructions about how to make automatic checks after C-c C-s (maybe only if the specified date includes a duration) 2) from time to time I wish I could check not only 1 timestamp, but *all* my existing appointments (mainly the future ones) for conflicts. This means comparing each one against each other! (including repetitions) or producing a timeline and checking for overlaps. This is very hard, I know! And the interactive part (seeing proposed resolutions) is heavy because there are infinite possible resolutions. This turns very fast into an optimization problem An issue that makes org-conflict less helpful than it could is that it only works for agenda appointments that have a duration. You implemented a default duration for the *new* event (the one just inputted) and then compare this event against all existing agenda events *that have a duration*. But I think that *all* agenda events should have a default duration too (because in real life, no task takes 0 minutes). So the new event should be compared against all future timestamps, not only those with a duration. This is slower, I know. Actually, a better way to implement this would be: let's forget about durations and just take the day, not the hour. If you want to schedule an event at day X, and there's already another event at day X (no duration specified), let's call this a conflict and prevent scheduling a second one. If you don't want to consider it a conflict (because you really plan to do both things the same day) then you should be required to choose a time for the existing event, and then another time (non-conflicting) for the new event. This experiment may help in teaching the user to do better planning, i.e. if you want to do many things the same day, choose at which times. I tried to implement some programs to do similar things, and to get some useful information from my org agenda (which is a mess because of too many tasks). Like for instance, I take a list of tasks, „enhance them“ with scheduling information like a default duration and a deadline, and then I add the human requirements that org doesn't know about: for instance complaining if there are more than 24 h of work in a day (actually I delay them to the next day), or adding pauses for lunch or for sleep (this will also shift everything forwards). This is all more complex than expected and in the end I'm doing the processing outside org; actually I prefer to use a very simple list (1. x, 2. yy, 3. , …) in an org file to do my planning, and ignore org-mode task
Re: [O] Capture with date prompt defaults to yesterday
On Fri, 7 Jun 2019 at 22:31, Nicolas Goaziou wrote: > Hello, > > Neil Jerram writes: > > > Nicolas, I hope you don't mind me sending a 'ping' for this, as it looks > > like it might have got lost. Please do let me know what you think. > > I'm not sure this is a right fix. Doesn't it force default times to noon > instead of midnight? I think default times should be midnight. > Yes, it does make the default time noon. But AFAICS the time of day doesn't actually matter in any of the Org source code where the result of org-get-cursor-date is used. Have I missed a case where it does matter? However, in the attached patch I've revised that so that the default time of day is :00am, i.e. it's the earliest time that Org treats as being that date. WDYT? Alternatively, we could refactor the code around where org-get-cursor-date is used to make it more explicit when the time of day doesn't matter, and look further if there are any cases where it does. Best wishes, Neil From 48b342bbd8c97bf24214b57e04d6d59108320ba0 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Tue, 28 May 2019 21:01:17 +0100 Subject: [PATCH] Make capture's idea of the current day more intuitive --- lisp/org.el | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c6861dc9a..6af97b348 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18936,7 +18936,9 @@ Returns the number of empty lines passed." This works in the calendar and in the agenda, anywhere else it just returns the current time. If WITH-TIME is non-nil, returns the time of the event at point (in -the agenda) or the current time of the day." +the agenda) or the current time of the day; otherwise returns the +earliest time on the cursor date that Org treats as that date +(bearing in mind `org-extend-today-until')." (let (date day defd tp hod mod) (when with-time (setq tp (get-text-property (point) 'time)) @@ -18949,13 +18951,13 @@ the agenda) or the current time of the day." (cond ((eq major-mode 'calendar-mode) (setq date (calendar-cursor-to-date) - defd (encode-time 0 (or mod 0) (or hod 0) + defd (encode-time 0 (or mod 0) (or hod org-extend-today-until) (nth 1 date) (nth 0 date) (nth 2 date ((eq major-mode 'org-agenda-mode) (setq day (get-text-property (point) 'day)) (when day (setq date (calendar-gregorian-from-absolute day) - defd (encode-time 0 (or mod 0) (or hod 0) + defd (encode-time 0 (or mod 0) (or hod org-extend-today-until) (nth 1 date) (nth 0 date) (nth 2 date)) (or defd (current-time -- 2.17.1
