Re: [O] [PATCH] Use regexp-opt in org-set-tag-faces
Hello,
Anders Johansson writes:
> I just noticed a place where it would be appropriate to use regexp-opt
> instead of doing:
> (concat ":\\(" (mapconcat 'car value "\\|") "\\):"
>
> regexp-opt promises to be more efficient.
Applied. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Error in compact guide
Hello, John Weeks writes: > Hi! Tiny error in release 9.2 of compact org-mode guide, page 23; C-c M-x > is the binding given for org-copy instead of C-c M-w (it's correct in the > "full" manual). Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] org-habit: allow overriding org-scheduled-past-days and always including time of day
Hello, John Lee writes: > Hi, sorry Nicolas I totally missed your review comments! No problem. > Trying hard to make up a reason for utility of the current behaviour: > let's say your habits tend to be weekly and have an optimum time and > weekday, but if you miss them it's just "as soon as possible". But if > anybody actually does see their habits that way, that would seem > likely to vary by habit. So I'd be surprised if the current behaviour > was very useful. > > Shall I make it the default, then? I think so. > Thank you. Right now I have one other change I'd like to submit which > is also tiny, do I need to start the assignment process? If both changes do not add up to around 15 non-trivial locs, that's fine. >> > +(defcustom org-habit-scheduled-past-days nil >> > + "Non-nil means the value of this variable will be used instead >> > +of org-scheduled-past-days, for habits only. >> >> First line needs to be a full sentence. Also, > > To me it looks like a full sentence? What I meant is the first line should contain only full sentences. Yours spans over two lines. > Should it be something like this below (based on looking at other docstrings)? > > "Value to use instead of `org-scheduled-past-days', for habits only. > > If nil, `org-scheduled-past-days' is used." That's better, indeed. > I think "as a mean of" is not correct English (I'm a native speaker in > the UK). Of course, you're right. Sorry for the noise. > Presumably I should use the version from the highest current git tag "plus > one", i.e. 9.3? > > :package-version '(Org . "9.3") That's correct. Regards, -- Nicolas Goaziou
Re: [O] org-habit: allow overriding org-scheduled-past-days and always including time of day
On Sun, 18 Nov 2018, at 23:40, Nicolas Goaziou wrote: > Hello, Hi, sorry Nicolas I totally missed your review comments! > John Lee writes: For context since it's months ago now: > > My own workflow around this is similar to GTD, so I'm using SCHEDULED > > as basically a way to get TODO items to show up after the scheduled > > date, not to show up in the calendar except as a reminder that I have > > new TODOs. For that reason I set org-scheduled-past-days to a low > > value (3 right now). I also set org-agenda-todo-ignore-scheduled to > > 'future and org-agenda-tags-todo-honor-ignore-options to t (not > > directly relevant here except as context). For habits that causes > > habits not to show up sometimes because of the short > > org-scheduled-past-days, which isn't appropriate for my habits: if > > I say .+5d, I still want to see the habit there if it's due, even if > > it's been 4 days since the last done date (which is more than the > > 3 days of org-scheduled-past-days). This motivates > > `org-habit-scheduled-past-days'. > > It sounds reasonable. > > > Similarly, since I want to do some of my habits at a particular time > > of day, org-agenda's omitting of the time of day from the scheduled > > timestamp if this is a "repeat" (i.e. I missed doing the habit) is > > unhelpful for habits, because now I have to scan though a long-ish > > list of habits (5 or 10 right now!) and think "is now the right time, > > should I have done that already?" for every habit in the list, rather > > than just eyeballing it to see which ones are around now in time. This > > motivates `org-habit-always-show-time'. > > It sounds good too. However, I wonder if that shouldn't be the default. > Hiding the time for a missed scheduled item hadn't the habits in mind > (see http://lists.gnu.org/archive/html/emacs-orgmode/2016-11/msg00539.html). > > To put it differently, is there any workflow wanting to hide the time > for habits in this case? I don't know. There's always somebody :-) Perhaps nobody has filed an issue before because some people find the current behaviour useful -- but perhaps it's only because nobody uses times for habits, maybe because of this very issue. Trying hard to make up a reason for utility of the current behaviour: let's say your habits tend to be weekly and have an optimum time and weekday, but if you miss them it's just "as soon as possible". But if anybody actually does see their habits that way, that would seem likely to vary by habit. So I'd be surprised if the current behaviour was very useful. Shall I make it the default, then? > > I have not yet submitted the FSF copyright assignment form but am > > prepared to do so. > > This can go as a TINYCHANGE (you need to put that string at the end of > the commit messages). > > However, if you plan to be able to provide more code to Org, I suggest > starting the copyright assignment nonetheless. Thank you. Right now I have one other change I'd like to submit which is also tiny, do I need to start the assignment process? > > +(defcustom org-habit-scheduled-past-days nil > > + "Non-nil means the value of this variable will be used instead > > +of org-scheduled-past-days, for habits only. > > First line needs to be a full sentence. Also, To me it looks like a full sentence? Should it be something like this below (based on looking at other docstrings)? "Value to use instead of `org-scheduled-past-days', for habits only. If nil, `org-scheduled-past-days' is used." > > +TODO items on a particular date, rather than as a means of > > +creating calendar-based reminders." > > as a mean of... I think "as a mean of" is not correct English (I'm a native speaker in the UK). > > + :group 'org-habit > > + :type 'integer) > > You need to add :package-version and :safe keywords. Presumably I should use the version from the highest current git tag "plus one", i.e. 9.3? :package-version '(Org . "9.3") Thanks for your comments
[O] Error in compact guide
Hi! Tiny error in release 9.2 of compact org-mode guide, page 23; C-c M-x is the binding given for org-copy instead of C-c M-w (it's correct in the "full" manual).
Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)
Uwe Koloska writes: > Maybe the variable 'org-extend-today-until' can help. Indeed, thank you!
Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)
Marcin Borkowski writes: > You do realize you are not the first one to have that problem, don't > you? Have you seen `org-agenda-todo-yesterday'? Thank you! Sounds like it'll combo nicely with `org-extend-today-until` pointed out by Uwe, to slowly make checking tasks the day before less and less convenient and push the sleep schedule the right way. >> Anyway, thank you for org-mode, that allows me to be mildly annoyed at >> things I wouldn't even have considered might become an issue someday >> with programs I used before! > > Not sure whether this is a compliment, but I like it:-). It's definitely meant to be! :)
Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)
Am 02.02.19 um 01:29 schrieb Leo Gaspard: > I have a few tasks marked as `:STYLE: habit`. And I relatively often > finish one of those daily habits after midnight. > > Yet, I'd like to count it as having been finished the day before, so > that day switch time happens while I sleep. Maybe the variable 'org-extend-today-until' can help.
Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)
Am 02.02.19 um 01:29 schrieb Leo Gaspard: > I have a few tasks marked as `:STYLE: habit`. And I relatively often > finish one of those daily habits after midnight. > > Yet, I'd like to count it as having been finished the day before, so > that day switch time happens while I sleep. Maybe the variable 'org-extend-today-until' can help.
Re: [O] latest org-mode ignores visibility property selectively
On Tue, 29 Jan 2019 at 17:39, Michael Maurer wrote: > > I'm currently using org-mode version 9.1.14, where everything > seemingly works fine. > > The problem is, when I upgrade to the latest version via the packaging > system, one particular headline no longer folds and hides its > children, although the visiblity properties are identical to other > headlines, and the way its children are structured as well. > > On startup the custom property gets ignored, it's not folded, and all > its children are visible. I've upgraded to the latest emacs version, > to see if that makes a difference, but the problem persists. Not sure > where or how I should start to track this problem down. > > Here's the offending headline. > > * DONE 2017 [462/462] abc,cde, efg, hij, klm > :PROPERTIES: > :VISIBILITY: folded > :END: > ** DONE Dezember [34/34] abc, eds > :PROPERTIES: > :VISIBILITY: folded > :END: >CLOSED: [2017-12-31 So 00:19] >- CLOSING NOTE [2017-12-31 So 00:19] Ok, I figured it out. If the top headline has a "visibility: folded" property, and one of its children has that property as well, the parents property gets disabled, for some reason. Guess it's a bug?
[O] Format of links to Info node and Info index
Hi all I noticed that the link format with only single colons for the Info node like info:org:Feedback stopped to work. Now I am confused about the difference of info:org#Feedback that is documented as a link to an info _node_ in [[info:org#External Links]] but never used in org-manual.org versus info:org::Feedback that is not documented in org-manual.org but used for all Info links there, like for example in the section info:org::Activation for the link to Key Binding Conventions. Currently both link formats can also be used for links to Info _index_, for example info:org::table.el and info:org#table.el Should there be a different link format for Info node versus Info index or not? Who would prefer (my favorite) | =info:org::External links= | Info node, preferred format | | =info:org#External links= | (alternative format) | | =info:org#table.el=| Info index, preferred format | | =info:org::table.el= | (alternative format) | or who would prefer | =info:org::External links= | Info node link | | =info:org#table.el=| Info index link | or who would prefer something else? Michael
