Re: [orgmode] Better recurrence for SCHEDULED and DEADLINE
> "IR" == Ihor Radchenko writes: IR> Note that we also have diary style timestamps with arbitrary IR> logic of date selection. The primary problem with those timestamps is that they cannot be marked as DONE and disappear from agendas for the given date. I think that nth-dayofweek-in-month is the only case when I have to use them and it would be nice to have “native” timestamps for that.
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
> "TC" == Tim Cross writes: TC> At any rate, at this point, I suspect this is something best TC> handled in individual configurations rather than attempting to TC> impose a specific interpretation on everyone. If someone needs TC> help to write a simple command to 'toggle' checkbox TC> cancellation, I'm sure asking here will get some assistance. To have it well integrated, at least the following functionality is needed: - To change to and from the canceled state. - To clear all the list items statuses. - Making all the related functionality (blockers, agenda, …) to recognize when a task list with canceled items is finished. - Making it well working with things like org-modern. It’s fair to say the functionality is not suitable for implementation in Org for some reason (too complicated, unclear how to do it properly, almost nobody needs it, …) but let’s not pretend it’s something that can be added to an individual configuration easily. Not that the above couldn’t be implemented privately but the effort would be significant and the hack would be ugly (modifying org-ctrl-c-ctrl-c? uh) and non-portable (different markups by different users). My Org configuration is already cluttered enough and I rather keep living without this functionality than polluting it with additional hacks.
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
> "B" == Bastien writes: B> FWIW, I use this: B> - [X] +This task will probably be canceled+ B> I don't think we should implement a new status for canceled B> tasks. Such a workaround doesn’t work well for lists that are to be re-used next time or cleared when the whole task is repeating and is switched to done. Checkboxes can always be cleared easily using a single rectangular command if there is no automatic mechanism but how to clear the + marks? A typical example would be my checklist for items to take with when traveling. Some of the items are already in my bag, some must be inserted there and some are not needed this time. Using +strike through+ is cumbersome, defining a command for it doesn’t feel good, and there is the problem of clearing the marks when re-using the list next time. Well, I do not store that particular list in a task node so I can use [-] freely but it’s still inconsistent with the actual meaning defined by Org. Not that big deal but it would be nice to have an official way to mark an item as not-applicable / canceled and not blocking finishing the task.
Re: [BUG] LOGBOOK makes property search (in org-agenda) too slow(?)
> "fmd" == fr ml@t-online de writes: fmd> I have just one headline and do a simple property search fmd> (prop1="blah1") for the 'org-agenda', but this takes about 10 fmd> seconds! Org versions from recent years don’t like large logbooks and don’t like large files. For agenda, org-super-agenda & org-ql provide solution, they are generally much faster, don’t suffer from the logbook problem and are also much powerful. For other purposes, it can be more difficult. For example, I had to split my single org-drill file into multiple smaller files when editing and using the file became unusable due to Org slowness in some new Org version. The increasing Org slowness is a limiting factor (and perhaps the only limiting factor) of what can be done with Org. Regards, Milan
Re: How do you manage complex project with Org-mode
> "SG" == Sébastien Gendre writes: SG> But, as a student, I regularly have big and important projects SG> to do for the school. The kind of project who need several days SG> to be done, with deadlines too soon, and if you fail one them SG> the consequences can be disastrous. And generally, I have to SG> many of these project in the same time and not enough time to do SG> all the work. So, I also need to follow the progress of each SG> project to choose which is sufficiently advanced to be stop for SG> the benefit of another less advanced project. SG> And I don't know how to manage this kind of projects with SG> Org-mode. How to do it, without failing a 6 days project because SG> I spent to much time on something else and I have only 3 days SG> left with 3 half-day important appointment I cannot cancel. I SG> can't risk failing a single one of these project by trying. So, SG> when I am in a period with a lot of these projects, I stop using SG> Org-mode and concentrate on doing these project as fast as I SG> can. And because I often have this kind of project, I spend most SG> of the year without being able to use Org-mode. Hi, I’d join the suggestion to keep things simple in the beginning. My task flow is different from yours but in order not to miss really important things, I use the following: - Deadlines, with longer in-advance warnings when needed (e.g. “-3w” in DEADLINE). - I use priority A for and only for stuff that is on risk of really bad consequences if not handled ASAP. And I schedule such stuff to a future date if it doesn’t make sense to work on it now for any reason. As for progress, I’d say that if you don’t know how far are you with your short-term tasks and which of them require attention currently then you might have a problem with your workflow. Maybe you are too overloaded or you don’t split your time among the tasks appropriately. Org mode is a good tool to implement support for different workflows but cannot help if a used workflow doesn’t work very well for you. Again, starting simple with Org mode and paying attention first to how you work and how it could be improved generally might be a good idea (and a life-long process for many of us). Regards, Milan
Re: Build agenda asynchronously
> "TC" == Tim Cross writes: TC> Personally, I took a different route. I keep the number of files TC> which contribute to my agenda to a minimum and have an easy way TC> to update/change that list. I can quickly switch agenda contexts TC> depending on what I'm doing. It’s always advisable to restrict agenda sources to what’s actually relevant. But besides that, all my problems with agenda slowness were resolved once I started to use org-super-agenda (https://github.com/alphapapa/org-super-agenda). It’s both more powerful and much faster than the standard Org agenda. Regards, Milan
Re: Habit error
> "CB" == Colin Baxter writes: CB> Hello, CB> With the latest pull of org-mode I now find habits are not displayed CB> correctly in agenda. The graph bar is missing, with the error CB> org-habit-insert-consistency-graphs: Wrong type argument: CB> number-or-marker-p, nil Hi, I've hit the same error. It was introduced in commit f471768a54d8921ff383516af6a605adc061af30 -- if all-done-dates is nil (i.e. a new habit is introduced), it signals an error. CB> - Begin debugger output -- CB> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) CB> (org-habit-build-graph (737610 1 737613 4 nil ".+") (24292 37530 CB> 669050 863000) (24320 16922 669050 863000) (24329 31898 669050 CB> 863000)) CB> (org-habit-insert-consistency-graphs) CB> (org-agenda-finalize) CB> (org-agenda-list nil) CB> (funcall-interactively org-agenda-list nil) CB> (call-interactively org-agenda-list) CB> (org-agenda nil) CB> (funcall-interactively org-agenda nil) CB> (call-interactively org-agenda nil nil) CB> (command-execute org-agenda) CB> - End debugger output -- CB> The error does not occur with the 'built-in' Org mode version 9.3 for CB> emacs-27. CB> Best wishes, CB> Colin. CB> Colin Baxter CB> URL: http://www.Colin-Baxter.com
Re: [O] org-drill extremely slow with Org 9.2.5
> "CH" == Christian Heinrich > writes: CH> are all your headlines folded? Yes. CH> I found that running "M-x outline-show-all" before the first CH> org- drill call resolves this issue for me with org 9.2 (but not CH> with 9.3). Indeed, cool, thank you for the tip. CH> See also my analysis CH> https://bitbucket.org/eeeickythump/org-drill/issues/48/slow-startup The primary problem seems to be Org regressions. IIRC, with Org 9.3, it's enough to make a file with several thousand folded entries having :ID: properties and the navigation becomes extremely slow. CH> Are you aware of the new org-drill releases by Philipp Lord? CH> https://gitlab.com/phillord/org-drill I wasn't, thank you for the pointer. (However when I tried to install it from MELPA, it installed a new Org with it, making it unusable. Better to install it directly from the archive above.) Thanks, Milan
Re: [O] org-drill extremely slow with Org 9.2.5
> "OK" == Oleh Krehel writes: OK> I noticed org-drill being slow three years ago when I tried to OK> learn it. So I wrote my own package: OK> https://github.com/abo-abo/pamparam/. It's quite fast: it takes OK> 0.6s to sync my 3300 cards from the master Org file. And OK> day-to-day learning operations like building a schedule or OK> fetching a card are instantaneous. The master file is OK> relatively small, since it stores no metadata: less than 1 OK> lines. The metadata is stored per-card, each card is in its own OK> file. The whole thing is backed by Git. All your learning OK> sessions are stored in commits as well. OK> Check it out. It might have less features, but it's really fast OK> and has served me well. Hi Oleh, pamparam looks interesting, however the very first blocker of adoption is that having to type the answers is slower than anything else... And not always feasible. Nevertheless the concepts behind pamparam are interesting. When I grep all the :PROPERTIES: out of my org-drill file, Org can visit and navigate the resulting file completely fine. So the problem is how Org deals with its properties. I can see two options: a) to fix Org property processing b) to change org-drill to off-load metadata to a separate file I'm afraid b) alone wouldn't help, since when I retain just :ID: properties, then the file is unusably slow in Org.
[O] org-drill extremely slow with Org 9.2.5
Hi, after upgrading from Org 9.1 to 9.2, org-drill has become extremely slow. org-drill has never been fast, but now it stops being usable. Everything takes much more time than before -- running `M-x org-drill', both for the first time and again, responding to drill queries, moving over my Org file. My org-drill Org file has over 4,000 entries and almost 50,000 lines. With Org 9.1, it used to be usable after running `M-x org-drill' for the first time in the given Emacs session; after the initial Org processing, I could move over the entries relatively smoothly. But this no longer helps and org-drill itself is much slower too. Is Org 9.2 no longer capable to handle (relatively) large files with a lot of Org properties? Are there any tricks to speed it up? Thanks for any advice, Milan
Re: [O] ANN: org-ql agenda block support
> "AP" == Adam Porter writes: AP> FYI, I just pushed a new feature to org-ql: custom agenda AP> blocks. This allows the use of org-ql queries in custom agenda AP> commands. [...] AP> Please let me know if you have any feedback. Hi Adam, thank you for the feature. I looked at org-ql and org-super-agenda (for the first time) and they look interesting. So interesting that I've decided to convert my agendas to it, with some improvements. It took a lot of effort and was sometimes tricky (although probably not more than standard Org agendas) but the result is nice and worth it. I've sent some feedback to the GitHub issue tracker. On the positive note, org-ql + org-super-agenda is superfast, agenda definitions are much easier to read, they are also relatively easy to write (once one finds out how) and I like the added flexibility. Overall, I like it, it's nice and useful, indeed something like org-agenda-ng. Thank you for your work! Thanks, Milan
Re: [O] org-drill vocabulary and question about properties
> "GB" == Gerhard Butscher writes: GB> As far as I know the inner workings of org-drill are placed in GB> the : PROPERTIES: section of the item. When I use GB> :DRILL_CARD_TYPE: twosided then the item gets questioned some GB> time in german and some time in spanish. But the PROPERTIES are GB> still only once there. If I want to track the learning in both GB> directions separately, I need to make two items for one word, GB> once german-spanish and once spanish-german. Am I right? AFAIK yes.
Re: [O] Customizing todo state for habits
> "CL" == Clarissa Littler writes: CL> the default behavior of habits seems to be to, when completed, CL> to revert the state to the first todo keyword in your listing CL> but I want to have different todo states for different habits CL> depending on the /kind/ of task it is. Rules for repeated tasks apply, as described in Org manual, section Repeated tasks, footnote 1. -- http://www.zamazal.org
Re: [O] Problems with org-drill
> "MW" == Marco Wahl writes: MW> Sven Bretfeld writes: >> I don't know how many of you guys use org-drill as vocabulary >> learning software. I have started some weeks ago to learn >> Norwegian. The concept and flexibility of the extension (contrib) >> are great. But there is a problem (bug?). >> >> During drill-sessions empty cards continue to show up. About >> 30-40% of the questions show an empty screen. These empty screens >> are fully counted as cards in the mini-buffer counter. I use to >> skip those "cards" with "s" but I have the feeling that this >> skips real questions which just are not displayed properly. This >> would mean I'm creating knowledge-gaps in each session. >> >> Editing these cards with "e" doesn't seems to work. It only stops >> the drill-session with the point in the line where I >> started. There seems to be no rule involved in those "empty >> screens" showing up. (But I have the feeling they often occur >> after I give a card score (0-5) differing from the score of the >> last question.) Neither can I see that there are malformed >> entries which could explain the phenomenon. >> >> Does anyone else have this problem and know how to fix it? MW> Yes and you can remove the line MW> (set-window-start nil window-start) MW> from defun org-toggle-latex-fragment in org.el for a fix. I use MW> this fix for a while and have not seen any (unwanted) side MW> effects yet. MW> The real issue may be somewhere else though. Anything new about this problem? I also experience the bug, it's still present and I have to remove the given line on any Org update. :-(
Re: [O] problems with auto-capitalise
Do you use desktop.el? I experienced similar problems with it. I don't remember the details but I've got the following in my Emacs configuration that probably serves as my workaround of the problem: (add-to-list 'desktop-minor-mode-handlers '(auto-capitalize . (lambda (desktop-buffer-locals) (auto-capitalize-mode 1 -- http://www.zamazal.org
Re: [O] Org-drill doesn't work...
> "JK" == Joost Kremers writes:
JK> but org-drill isn't picking up the new entries. i've added a
JK> bunch of new entries to the file and they've all been given an
JK> :ID: property, but they are not being drilled. i'm sure i'm
JK> doing something wrong here, but i can't figure out what...
It may happen if there is some problem with the contents of the entries
("unrecognized" items are silently skipped). I was hit by a similar
problem but once I realized what's wrong, org-drill started to work
perfectly for me.
If you've successfully learned some entries previously, make sure the
new entries are of the same format. If you're not successful, post some
of the ignored entries here.
Re: [O] Org-drill doesn't work...
> "JK" == Joost Kremers writes: JK> however, trying to run org-drill the next day, i got the JK> following message: JK> #+BEGIN_EXAMPLE JK> 0 items reviewed. Session duration 0:00:00. JK> Recall of reviewed items: JK> Excellent (5): 0% | Near miss (2):0% JK> Good (4):0% | Failure (1): 0% JK> Hard (3):0% | Abject failure (0): 0% JK> You successfully recalled 0% of reviewed items (quality > 2) JK> 0/1 items still await review (0 failed, 0 overdue, 0 new, 0 young, 0 old). JK> Tomorrow, 0 more items will become due for review. JK> Session finished. Press a key to continue... JK> #+END_EXAMPLE JK> i wasn't prompted for any new items and the message "tomorrow, 0 JK> more items will become due for review" worries me. JK> also, running org-drill-again gives me the same message. This is all right. You've just learned all the items and there is nothing to learn/repeat now. Nor tomorrow, there is minimum amount of 4 days by default before you are prompted for the same item again (I believe you can customize the interval with org-drill-sm5-initial-interval). In the meantime you can add and train new entries. :-)
Re: [O] [PATCH] Create visibility overlays properly
Any chance to get this patch applied? Or is there anything wrong with it? * org.el (org-set-outline-overlay-data): Use outline-flag-region to make a region invisible. This ensures all necessary actions, especially adding isearch-open-invisible property, are applied. --- lisp/org.el |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index a75f96e..c4196e8 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6599,8 +6599,7 @@ DATA should have been made by `org-outline-overlay-data'." (widen) (show-all) (mapc (lambda (c) - (setq o (make-overlay (car c) (cdr c))) - (overlay-put o 'invisible 'outline)) + (outline-flag-region (car c) (cdr c) t)) data) ;;; Folding of blocks -- 1.7.2.5
[O] [PATCH] Create visibility overlays properly
* org.el (org-set-outline-overlay-data): Use outline-flag-region to make a region invisible. This ensures all necessary actions, especially adding isearch-open-invisible property, are applied. --- lisp/org.el |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index a75f96e..c4196e8 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6599,8 +6599,7 @@ DATA should have been made by `org-outline-overlay-data'." (widen) (show-all) (mapc (lambda (c) - (setq o (make-overlay (car c) (cdr c))) - (overlay-put o 'invisible 'outline)) + (outline-flag-region (car c) (cdr c) t)) data) ;;; Folding of blocks -- 1.7.2.5
[O] org-save-outline-visibility and isearch
After using org-save-outline-visibility the invisible parts of the buffer become invisible to isearch. I have to do something like calling org-global-cycle to restore the buffer to its original state and allow searching in its invisible parts again. The problem seems to be in the functions org-outline-overlay-data and org-set-outline-overlay-data. They save and restore just `invisible' overlays. They should do the same with `isearch-open-invisible' overlays. Or perhaps org-set-outline-overlay-data could simply use outline-flag-region? What do you think?
Re: [O] Largest org file you have + performance
My largest org file is an org-drill file of almost 1 MB size, containing about 32000 lines (most of them are entry properties) and 2000 org-drill entries. It's well useable but tag and property editing is better to be done by hand instead of using org commands and I have to use some folding trick to prevent org-drill performance problems.
[O] Re: [PATCH] European date format
> "ND" == Nick Dokos writes: ND> The problem with the required final trailing dot (if you want to ND> leave out the year) is that it is not obvious - at least to me: ND> the equivalent ISO would be "-03-04" and the equivalent American ND> would be "3/4/" which look horrible - however, I don't know what ND> the general practice is in Europe. The dots are not separators, they mark ordinal numbers. And at least here in Czech Republic the correct typeset form is e.g. "4. 3. 2011" although the compact form "4.3.2011" is often used.
