Re: Bug: :match filter fails on columnview dblock when :maxlevel present [9.4.6 (9.4.6-gab9f2a @ /Users/pabfr/.emacs.d/elpa/org-9.4.6/)]
> On 12 Jul 2021, at 15:22, Pablo Perez wrote: > > * Scrum Summary >#+BEGIN: columnview :hlines 3 :id "47B8AC9D-2556-4F6E-AAE1-775731314596" > :indent t :maxlevel 4 :match "Sprint4" I’ve noticed in the past that :maxlevel prevents “match” from functioning properly. Have you tried to remove “maxlevel”? /Kris signature.asc Description: OpenPGP digital signature
Re: a repeater doesn't increment
What I'm trying to do is more complex than that. * Reorder pills ** TODO order hctz, lisinipril, metformin, provacol, claritin, Co-q10, Deadline: <8-2-2021 +4w> ** TODO order Colase Deadline: <10-13-2021 +14w> ** TODO order Turmerick Deadline: <8-30-2021 +8w> On Thu, 22 Jul 2021, Nick Dokos wrote: > Jude DaShiell writes: > > > Does enough material exist on werg tutorials that document how to get a > > repeater operational? That or maybe I don't understand repeaters. Had > > the repeater I tried to use worked correctly it would have advanced the > > original date by 4 weeks when that date got copied down to another cell. > > I selected the whole line including both verticals and perhaps this works > > when only a time stamp is copied. > > > > I may be misunderstanding, but are you trying to fill a column in a table > with dates that are four weeks apart? If so, repeaters have nothing to do > with it (AFAIK). You need `org-table-copy-increment' to be set to 28. > > --8<---cut here---start->8--- > > | date | foo | > |--+-| > | <2021-07-22 Thu> | | > | <2021-08-19 Thu> | | > | <2021-09-16 Thu> | | > | <2021-10-14 Thu> | | > | <2021-11-11 Thu> | | > | <2021-12-09 Thu> | | > > > * Code > > #+begin_src elisp > (setq-local org-table-copy-increment 28) > > #+end_src > > #+RESULTS: > : 28 > > --8<---cut here---end--->8--- > > Then keep pressing `S-RET' to get the next date. > > > > > > On Tue, 20 Jul 2021, Jude DaShiell wrote: > > > >> I am likely doing this wrong but will describe what has been done. > >> I put an agenda time stamp into a field in test.org and add +4w to the end > >> of the time stamp inside the >. > >> I get on the left of the field column on the vertical character and type > >> control-space to set mark. > >> I move to the end of the field on the > sign and type space and another > >> vertical to close the column entry for that field. > >> Next I do control-c+x+v and am told strings are copied to the kill ring. > >> Next I move down one line and type control-y to yank those strings out of > >> the kill buffer and paste them on that line. > >> When this is done, I expected the time stamp to increment by 4 weeks. > >> What happened was the same information got copied down and it didn't > >> increment. > >> What am I doing wrong? > >> > >> > >> > > > > > >
Re: org-agenda-do-date-earlier does not work on today
my description of the problem is misleading. if you are in the previously scheduled section, and move to today by shift right (this requires a variable setting possibly), then moving to yesterday toggles moving to today and moving to yesterday. what i expected was, moving increasingly into the past, by one day, per invocation of the command. On 7/22/21, Samuel Wales wrote: > i used to be able to do org-agenda-do-date-earlier (shift left) to put > an item that is scheduled for today into the previously scheduled > tasks. however, that is a no-op, at least recently, in recent maint. > > has anything changed? > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
org-agenda-do-date-earlier does not work on today
i used to be able to do org-agenda-do-date-earlier (shift left) to put an item that is scheduled for today into the previously scheduled tasks. however, that is a no-op, at least recently, in recent maint. has anything changed? -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: a repeater doesn't increment
Jude DaShiell writes: > Does enough material exist on werg tutorials that document how to get a > repeater operational? That or maybe I don't understand repeaters. Had > the repeater I tried to use worked correctly it would have advanced the > original date by 4 weeks when that date got copied down to another cell. > I selected the whole line including both verticals and perhaps this works > when only a time stamp is copied. > I may be misunderstanding, but are you trying to fill a column in a table with dates that are four weeks apart? If so, repeaters have nothing to do with it (AFAIK). You need `org-table-copy-increment' to be set to 28. --8<---cut here---start->8--- | date | foo | |--+-| | <2021-07-22 Thu> | | | <2021-08-19 Thu> | | | <2021-09-16 Thu> | | | <2021-10-14 Thu> | | | <2021-11-11 Thu> | | | <2021-12-09 Thu> | | * Code #+begin_src elisp (setq-local org-table-copy-increment 28) #+end_src #+RESULTS: : 28 --8<---cut here---end--->8--- Then keep pressing `S-RET' to get the next date. > > On Tue, 20 Jul 2021, Jude DaShiell wrote: > >> I am likely doing this wrong but will describe what has been done. >> I put an agenda time stamp into a field in test.org and add +4w to the end >> of the time stamp inside the >. >> I get on the left of the field column on the vertical character and type >> control-space to set mark. >> I move to the end of the field on the > sign and type space and another >> vertical to close the column entry for that field. >> Next I do control-c+x+v and am told strings are copied to the kill ring. >> Next I move down one line and type control-y to yank those strings out of >> the kill buffer and paste them on that line. >> When this is done, I expected the time stamp to increment by 4 weeks. >> What happened was the same information got copied down and it didn't >> increment. >> What am I doing wrong? >> >> >> > > -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Update Schedule for orgmode
Yes, 9.5. I'm curious about the timeline too. On Wed, Jul 21, 2021, 8:36 AM Denis Maier wrote: > Hi, > I'm helping a scholar at my institution with his emacs/org-mode > installation. As he'll would like to have automatic citations I > suggested he should try the new org-cite features, but he does not > really want to run the dev version. Is it already predictable when 9.5 > will be released? IIUC, the new citation features will be part of 9.5, > right? > Best, > Denis > >
Re: [org-cite] issues with org-cite-make-insert-processor select-style
Matt - that's not really the problem. In general, these core org-cite functions (org-cite-make-insert-processor and org-cite-register-processor) must be loaded after anything they refer to; e.g. placed at the end of the package file. But if they aren't, the resulting error message is really confusing, and emacs shouldn't break. On Thu, Jul 22, 2021 at 9:27 AM Matt Price wrote: > > Bruce, are you loading this code with use-package? If so, and if I'm reading > this right, you can perhaps add the missing functions to the > > :commands > > directive for org-mode? IIUC that should ensure that they are available to > your package, as long as you have an > :after (org oc) > line in the package's use-package directive. > > On Thu, Jul 22, 2021 at 6:31 AM Bruce D'Arcus wrote: >> >> The problem was load order I guess; putting this of the file fixes it. >> >> So when org-citemake-insert-processor is first loaded, it looks for >> the two functions, which haven't been loaded yet. >> >> I still think a) the error message could say that (that the functions >> aren't found or some such), and b) that it shouldn't break starting >> Emacs. >> >> On Thu, Jul 22, 2021 at 4:27 AM Bruce D'Arcus wrote: >> >> > If I comment out those lines and use the oc-basic style selector >> > instead to start emacs, and from there reactivate this function and >> > compile and reload the code from the buffer, THEN it works without >> > error. >>
Re: [org-cite] issues with org-cite-make-insert-processor select-style
Bruce, are you loading this code with use-package? If so, and if I'm reading this right, you can perhaps add the missing functions to the :commands directive for org-mode? IIUC that should ensure that they are available to your package, as long as you have an :after (org oc) line in the package's use-package directive. On Thu, Jul 22, 2021 at 6:31 AM Bruce D'Arcus wrote: > The problem was load order I guess; putting this of the file fixes it. > > So when org-citemake-insert-processor is first loaded, it looks for > the two functions, which haven't been loaded yet. > > I still think a) the error message could say that (that the functions > aren't found or some such), and b) that it shouldn't break starting > Emacs. > > On Thu, Jul 22, 2021 at 4:27 AM Bruce D'Arcus wrote: > > > If I comment out those lines and use the oc-basic style selector > > instead to start emacs, and from there reactivate this function and > > compile and reload the code from the buffer, THEN it works without > > error. > >
Re: a repeater doesn't increment
Hi, thanks this approach should work fine! On Thu, 22 Jul 2021, Henrik Frisk wrote: > Hi! > > Den tors 22 juli 2021 03:49Jude DaShiell skrev: > > > Does enough material exist on werg tutorials that document how to get a > > repeater operational? That or maybe I don't understand repeaters. Had > > the repeater I tried to use worked correctly it would have advanced the > > original date by 4 weeks when that date got copied down to another cell. > > I selected the whole line including both verticals and perhaps this works > > when only a time stamp is copied. > > > > Check out this explanation: > > https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/ > > I find it helpful and most of the time i prefer to use the > org-clone-subtree-with-time-shift function as it gives me more control. In > general, the date notation (+1w) is intended for the agenda wiew. > > Hope it helps, > /Henrik >
Re: [org-cite] issues with org-cite-make-insert-processor select-style
The problem was load order I guess; putting this of the file fixes it. So when org-citemake-insert-processor is first loaded, it looks for the two functions, which haven't been loaded yet. I still think a) the error message could say that (that the functions aren't found or some such), and b) that it shouldn't break starting Emacs. On Thu, Jul 22, 2021 at 4:27 AM Bruce D'Arcus wrote: > If I comment out those lines and use the oc-basic style selector > instead to start emacs, and from there reactivate this function and > compile and reload the code from the buffer, THEN it works without > error.
Re: Subject: Bug: Org-Clock-Out in indirect buffer error after refile [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Hi Bhavin, Thanks for your prompt response. I have followed those steps and that is the same behaviour I get. The expected behaviour is for it to clock out of the subtree, instead of giving the "Clock start time is gone" error. Regards, - Eddie Drury On Wed, 21 Jul 2021 at 02:00, Bhavin Gandhi wrote: > Hello Eddie > > On Mon, 19 Jul 2021 at 16:15, Eddie Drury wrote: > > > > When I am working in an indirect buffer and am currently clocked into a > subheading. If I refile this subheading and then run org-clock-out, I get > the error "Clock start time is gone". > > I'm not sure if this is intended behaviour or a bug, but I was able to > reproduce this with the following steps on the latest master. Can you > confirm if you are doing something similar as well? > > Content of test.org > > #+begin_src org > * Read Org mode list > ** Triage bugs > > * Read Emacs bugs list > > #+end_src > > 1. Now go to the "Read Org mode list" entry and run, >org-tree-to-indirect-buffer (C-c C-x b). > 2. Switch to the indirect buffer. > 3. Go to the "Triage bugs" entry, and run org-clock-in (C-c C-x C-i). > 4. Refile the "Triage bugs" entry to "Read Emacs bugs list" with >org-refile (C-c C-w) > 5. Switch to test.org buffer, and go to the "Triage bugs" entry, and run >org-clock-out (C-c C-x C-o) > 6. This will show "Clock start time is gone" > > > When not working in an indirect buffer, Org Mode is able to track this > subtree and clock out of it, which is the expected behaviour. > > Yes, I found that it is able to track the refile. > > -- > Regards, > Bhavin Gandhi (bhavin192) | https://geeksocket.in >
Re: a repeater doesn't increment
Hi! Den tors 22 juli 2021 03:49Jude DaShiell skrev: > Does enough material exist on werg tutorials that document how to get a > repeater operational? That or maybe I don't understand repeaters. Had > the repeater I tried to use worked correctly it would have advanced the > original date by 4 weeks when that date got copied down to another cell. > I selected the whole line including both verticals and perhaps this works > when only a time stamp is copied. > Check out this explanation: https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/ I find it helpful and most of the time i prefer to use the org-clone-subtree-with-time-shift function as it gives me more control. In general, the date notation (+1w) is intended for the agenda wiew. Hope it helps, /Henrik
Re: [org-cite] issues with org-cite-make-insert-processor select-style
Another odd thing.
If I comment out those lines and use the oc-basic style selector
instead to start emacs, and from there reactivate this function and
compile and reload the code from the buffer, THEN it works without
error.
On Wed, Jul 21, 2021 at 10:17 PM Bruce D'Arcus wrote:
>
> BTW, here's the info from the debugger:
>
> Debugger entered--Lisp error: (error "Wrong argument type(s)")
> error("Wrong argument type(s)")
> org-cite-make-insert-processor(bibtex-actions-org-cite-insert
> bibtex-actions-org-cite-select-style)
> (org-cite-register-processor 'bibtex-actions-org-cite
> :insert (org-cite-make-insert-processor
> #'bibtex-actions-org-cite-insert
> #'bibtex-actions-org-cite-select-style)
> :follow #'bibtex-actions-org-cite-follow)
> load-with-code-conversion("/home/bruce/.config/emacs/.local/straight/build-28..."
> "/home/bruce/.config/emacs/.local/straight/build-28..." nil t)
> require(bibtex-actions-org-cite nil nil)
>
> On Wed, Jul 21, 2021 at 11:14 AM Bruce D'Arcus wrote:
> >
> > I have run into a problem in implementing a "select-style" function
> > for an org-cite-insert-processor.
> >
> > The WIP code is here:
> >
> > https://github.com/bdarcus/bibtex-actions/pull/182
> >
> > It was running correctly yesterday morning, but now it doesn't.
> >
> > I have two related issues:
> >
> > 1. I think, but am not sure, I may have run into a bug in
> > org-cite-make-insert-processor, as the function I am using for the
> > select-style parameter runs correctly outside of the insert processor,
> > and returns the same results as the "org-cite-basic--complete-style"
> > function. But when I uncomment the parameter to use it on the org-cite
> > insert processor, it not only doesn't work correctly, but Emacs won't
> > even load fully.
> >
> > 2. The error I get "wrong type" is so general it literally took me
> > hours to realize it was coming from this function; I was looking
> > elsewhere for the issue.
> >
> > So if I'm right about a bug, obviously it would be great if that could be
> > fixed.
> >
> > But better error handling and reporting would also be really great.
> >
> > Bruce
> >
> > PS - I"m still learning elisp, and so am not super knowledgeable about
> > debugging in general. If anyone has any tips on that, that could help
> > me narrow down the source of the error, that would be much
> > appreciated.
