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

[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

[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

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 +--

Re: [O] Org-drill doesn't work...

JK == Joost Kremers joostkrem...@fastmail.fm 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% |

Re: [O] Org-drill doesn't work...

JK == Joost Kremers joostkrem...@fastmail.fm 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

[O] Re: [PATCH] European date format

ND == Nick Dokos nicholas.do...@hp.com 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

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

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

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

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

[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

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

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

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.

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

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

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,

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.

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

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'