> "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'
> "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
> "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,
> "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.
> "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
> "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
> "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.
> "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
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
> "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
> "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
> "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
> "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
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
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
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% |
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 +--
* 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
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
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
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
21 matches
Mail list logo