Re: bi-monthly steps.
On Thu, 12 Mar 2020 14:15:04 -0400, Nick Dokos wrote: "Bi-monthly" is ambiguous: it can mean twice a month or it can mean once every two months and there is no convincing anybody that their use of it is wrong :-) Exactly true. "Bi-weekly" is nearly as ambiguous, but is rescued by an ensuing discussion: "Which two days of the week did you want (the event) to occur?" "Um, ah, I mean every two weeks." "Fine then, let's say that." I think the original question from Christian Hopps presumes the meaning, "Every two months."
Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?
I use C-c C-v C-v quite often to check the final file produced. I use ob-shell with the :shebang of "#!/usr/bin/chibi-scheme", because my code is actually scheme-script, and I need to use :stdin, which isn't supported by ob-scheme and geiser. (And geiser also has some not inconveniences). However, when I expand the block, the shebang line is not added to the top. The top line could also be potentially used for file type detection, and what is also annoying, errors reported by the interpreter are off by 1 (due to the missing first line). -- Yours sincerely, Vladimir Nikishkin
Re: bi-monthly steps.
could use semimonth then :) > On Mar 12, 2020, at 2:15 PM, Nick Dokos wrote: > > "Bi-monthly" is ambiguous: it can mean twice a month or it can mean > once every two months and there is no convincing anybody that their > use of it is wrong :-) > > -- > Nick > > "There are only two hard problems in computer science: cache > invalidation, naming things, and off-by-one errors." -Martin Fowler > >
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: bi-monthly steps.
"Bi-monthly" is ambiguous: it can mean twice a month or it can mean once every two months and there is no convincing anybody that their use of it is wrong :-) -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
bi-monthly steps.
I've the need to display bimonthly clock tables, I was able to add this pretty easy in case the project would find it useful --- org-clock.el2020-03-12 06:52:14.0 -0400 +++ /Users/chopps/org-clock.el 2020-03-12 06:51:43.0 -0400 @@ -2719,6 +2719,7 @@ (pcase step (`day "Daily report: ") (`week "Weekly report starting on: ") +(`bimonth "Bi-Monthly report starting on: ") (`month "Monthly report starting on: ") (`year "Annual report starting on: ") (_ (user-error "Unknown `:step' specification: %S" step @@ -2768,6 +2769,7 @@ (let ((offset (if (= dow week-start) 7 (mod (- week-start dow) 7 (list 0 0 org-extend-today-until (+ d offset) m y))) + (`bimonth (list 0 0 0 (if (< d 16) 16 1) (if (< d 16) m (1+ m)) y)) (`month (list 0 0 0 month-start (1+ m) y)) (`year (list 0 0 org-extend-today-until 1 1 (1+ y))) (table-begin (line-beginning-position 0)) Thanks, Chris. signature.asc Description: PGP signature
Re: Creating table of summarized org-mode result fields in column view "report"
Technically, yes... but it would be vastly less readable to use and enter those properties. So, while I had thought about possibly doing that, it makes more sense to process (from my perspective.). Daryl On Thu, Mar 12, 2020 at 4:39 PM Eric S Fraga wrote: > On Thursday, 12 Mar 2020 at 15:23, Daryl Manning wrote: > > However, I figured this has to be a common enough(ish) thing that people > > need to do that it might already been a code snippet function (or even a > > package) floating around. > > You say you generate these logs using a template. Could you not modify > this template to create the subheading with a PROPERTIES drawer instead > of a log drawer? It would require only adding a leading : to each entry > beyond that. > > Just thinking out loud here... > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-412-ge18415 >
Re: Creating table of summarized org-mode result fields in column view "report"
On Thursday, 12 Mar 2020 at 15:23, Daryl Manning wrote: > However, I figured this has to be a common enough(ish) thing that people > need to do that it might already been a code snippet function (or even a > package) floating around. You say you generate these logs using a template. Could you not modify this template to create the subheading with a PROPERTIES drawer instead of a log drawer? It would require only adding a leading : to each entry beyond that. Just thinking out loud here... -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-412-ge18415
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: Creating table of summarized org-mode result fields in column view "report"
Thanks for the response. Very helpful. I figured out since writing it rom light research on column view and the helpful column view video on the emacs site): 1. Parse the daily files to AST (can do this now via a function) 2. Convert the "yaml-ed" fields to :PROPERTY: "drawer" fields (after looking at the Column video on the emacs website) 3. Dump to a temp buffer with the column definition somewhat like what you outlined ahead of it to render (though was not sure how to pass the fields dynamically, but figured could start with fixed) However, I figured this has to be a common enough(ish) thing that people need to do that it might already been a code snippet function (or even a package) floating around. So, this was more a "does this look like a problem someone has already solved" and where is that package/code kinda question. =] #lazyweb Otherwise, I'll just wander off and attempt coding it myself over le weekend. =] thanks! Daryl. On Thu, Mar 12, 2020 at 2:54 PM Eric S Fraga wrote: > On Thursday, 12 Mar 2020 at 12:46, Daryl Manning wrote: > > Can anyone point me to something similar already? (and is this even > > possible with column view instead of say, turning it into an org-table > > within a buffer. > > This would be straightforward if each of those entries were a > PROPERTY. Then you can specify the properties to display in column view > along with their widths. I do this for my todo list which is all in a > single org file. > > You could define the columns along these lines: > > #+columns: %60ITEM %this %that %50highlights > > to show the contents. > > HTH, > eric > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-412-ge18415 >
Re: Creating table of summarized org-mode result fields in column view "report"
On Thursday, 12 Mar 2020 at 12:46, Daryl Manning wrote: > Can anyone point me to something similar already? (and is this even > possible with column view instead of say, turning it into an org-table > within a buffer. This would be straightforward if each of those entries were a PROPERTY. Then you can specify the properties to display in column view along with their widths. I do this for my todo list which is all in a single org file. You could define the columns along these lines: #+columns: %60ITEM %this %that %50highlights to show the contents. HTH, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-412-ge18415
