Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Christophe Schockaert writes: > (my wish would be to have a robust way to handle multilines formating, > but that’s on another topic going on ^^) > > I don’t know what’s the usual process : can’t we file an issue to track > it, and write down the options we have, then decide the outcome of it > (either development, or documenting options and ideas) ? Just drop an email with appropriate subject. > Regarding the checkbox state, I wanted to have the impression of > maintainers, but I felt that choosing the character would not be easy to > handle not only for development, but even for reading documents from > different sources (custom TODO states have a meaning that we can infer, > but a single letter seems harder). > > As an after thought, about the "[C]" proposal, I wonder if it would not > be better to have a symbol, as "[X]" is not used for the letter, but for > the cross, same for the "space" and the "dash" which express "halfway > through". I didn’t have any idea the other day, but meanwhile, I have > come first with "[~]" which sounds like a wave and thus is not firm, and > is also a bitwise NOT in some programming languages. Or, thinking about > the "NOT", I thought about "[!]" which is a NOT (not done) and also > quite expressive. The only thing is that it is quite catching attention, > like if we need to pay attention for something that was probably not > that important since we cancelled it :) I could not find many other > options, as I feel we need to stick to ASCII for a solution. > > > WDYT ? I think that choosing a character is of a secondary importance. It can be easily adjusted once we have a working code. Getting the working code is much harder though. Someone™ will need to submit a patch first. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
andrés ramírez writes: > Ihor> Then, can you provide the updated profiler report again? Please > use the latest > Ihor> development version of Org + (setq org-element--cache-self-verify > nil) > > See the attached file. Please try again on the latest main. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Use lexical-scoping in tests
>> OK, here's a better version. As you can see, it's not nearly as simple. > > Applied onto main + commits addressing all but one FIXME (the one about > `find-file' in org-test.el). Great, thanks, Stefan
Re: [PATCH] ol.el: Always prompt for description in `org-insert-link'
Max Nikulin writes: > I have an idea how to fix the code to bypass the description prompt if > path is completed by description discarding identical path and > description, but I prefer to drop the confusing variable and not depend > on the means how the link was selected from the list of stored items. > > Have I missed something and unconditional prompt to edit link > description may be undesired in some cases? AFAIU, this particular behaviour is undocumented. If it is used by some other code, let's make tests for it, document, and fix in a better, more explicit way. I am unaware about the code using this link==description behaviour. Applied onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=69b36beac790bad95fdd9ce4a7bcfbbb46d39c64 https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6d8d7fba61652434764c9906df69db373ff4f7f6 Bastien, Could you please check the ongoing changes in this area (storing/inserting links)? The code in this area is old, confusing, and not fully documented. I'm afraid that we may break something in the process of refactoring. If you see some dangerous changes, please let us know. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Use lexical-scoping in tests
Stefan Monnier writes: >> The fix is in preparation, but obviously I had tested my patch >> incorrectly (i.e. I probably compiled and tested another code than the >> one I had patched). > > OK, here's a better version. As you can see, it's not nearly as simple. Applied onto main + commits addressing all but one FIXME (the one about `find-file' in org-test.el). https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1a5e3f931c9bbefaefafd4cdcc5f0dfcd1c97769 https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=17b51973bd17f26b4dfa0a5d5f198c7e1c8461dd https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6074a22bcb25593bd7644b2695d38f8b41200463 https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e3348ccc03b0aa3e8f8b3d0837b91f8285fe161a -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Use lexical-scoping in tests
>> +;; FIXME: `s' is a symbol, so (car-safe s) is always nil. >> +;;(when (eq 'autoload (car-safe s)) >> +;; (unintern s obarray)) >> + > > If I understand correctly, the intended version of this code is supposed > to be > > (when (autoloadp (symbol-function s)) > (unintern s obarray)) > > the idea being "unloading" all the built-in org-related staff. > However, make test will be failing then with byte-compiler error. > I feel that the idea of the code is reasonable, but some detail of how > autoloads work in Emacs is missed. I don't see why you'd need to remove the existing autoloads: they don't specify which directory the file will come from, so if the file still exists in the new Org, the (old) autoload will load from the new Org, as needed. I mean it's OK to remove those autoloads, but really, those are usually harmless and they are the least of your problems. I think the things we'd want/need to "remove" are those things which *aren't* autoloads. Also `unintern` is a fairly powerful operation which can come with undesirable side-effects, so I'd rather replace it with something less risky like `fmakunbound`. >> + ;; FIXME: For the rare cases where we do need to mess with windows, >> + ;; we should let `body' take care of displaying this buffer! >> (setq buffer (find-file file)) > > Could you please elaborate about this fixme? `find-file` displays the buffer in a window. In most uses of this code we don't care whether the buffer is displayed or not, so we should probably use `find-file-noselect` instead. [ As a rule of thumb, most uses of `find-file` (and `switch-to-buffer`) in ELisp code are the result of a misunderstanding from the coder who just uses the commands he's familiar with as a user. But in Elisp, you generally want to use `find-file-noselect` (and `set-buffer`, or maybe `pop-to-buffer`) instead. ] I didn't make the change, tho, because some parts of the tests do care about which buffer is displayed in which window, apparently, so it would take more work. Stefan
Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output
No worries! Thanks for your patient help. Ihor Radchenko writes: > Ihor Radchenko writes: > >> Joseph Turner writes: >> >>> You're right! Thank you for catching my mistake. I'll send another patch. >> >> Did you have a chance to work on the patch? > > Oops. Missed that you've sent a patch in another thread. Sorry for the noise.
Re: Reinstalling compat fixed everything breaking
Charles Philip Chan writes: > I am seeing the same problem. However, it did not resolve for me after > upgrading > the compat library to the current git version. I am still getting: > > , > | Warning (emacs): Org version mismatch. Make sure that correct ‘load-path’ > is > | set early in init.el This warning usually appears when a built-in Org > version is > | loaded prior to the more recent Org version. > ` > > during "make install". I never had this problem before. Should be fixed on latest main. This looks similar to https://orgmode.org/list/cdf0bc7d-3ed1-e1ce-84bb-239575a9c...@oracle.com -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Use lexical-scoping in tests
Stefan Monnier writes: >> The fix is in preparation, but obviously I had tested my patch >> incorrectly (i.e. I probably compiled and tested another code than the >> one I had patched). > > OK, here's a better version. As you can see, it's not nearly as simple. Thanks! This new version passes all the tests on my side. However, I have a few questions about FIXME items. > + ;; FIXME: `s' is a symbol, so (car-safe s) is always nil. > + ;;(when (eq 'autoload (car-safe s)) > + ;; (unintern s obarray)) > + If I understand correctly, the intended version of this code is supposed to be (when (autoloadp (symbol-function s)) (unintern s obarray)) the idea being "unloading" all the built-in org-related staff. However, make test will be failing then with byte-compiler error. I feel that the idea of the code is reasonable, but some detail of how autoloads work in Emacs is missed. > +;; FIXME: For the rare cases where we do need to mess with windows, > + ;; we should let `body' take care of displaying this buffer! > (setq buffer (find-file file)) Could you please elaborate about this fixme? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
On 2022-09-14 14:43, Ihor Radchenko wrote: Karl Voit writes: So, to me the main use case to have an explicit cancel, is when I have a long list, and to remember that I stated it as "cancelled". If we go that way, having no other nice idea at the moment, I quite like the [C] which is explicit although language specific. ... if it is possible with the current implementation, we could introduce an official convention that any single (upper case?) character between the brackets is interpreted as a non-open checkbox. So any user is able to choose her character of choice even language-dependent. I do not like the idea of pre-defining a meaning of an arbitrary single character. This will leave too less flexibility for future. As for cancelled state, it makes sense to add it. I have seen cancelled state in other outliners. However, adding a new checkbox state will involve changing Org syntax (https://orgmode.org/worg/dev/org-syntax.html#Items). Also, list implementation in Org is not particularly modular---someone will need to go across the code and make sure that new checkbox state is not going to break anything. The manual will also need to be updated. To conclude, if there is sufficient interest, I do not see why not. But it will be an involved change in Org code someone will need to perform. As for me, I am interested in having a way to manage cancels. I have always managed it with workarounds up to now, so it would be nice to have a clean way for it. However, this is low priority to me regarding the effort to provide. Also, since the suggestion from Daniel, I can consider it as a viable option for my use case, to keep lists simple and use the strikethrough would improve my readability. This would allow several behaviors for counting the checkboxes as we please : * TODO [2/2] Several checkboxes - [X] This one is done - [X] +This once is cancelled as done+ - +[ ] This one is forgotten completely+ (my wish would be to have a robust way to handle multilines formating, but that’s on another topic going on ^^) I don’t know what’s the usual process : can’t we file an issue to track it, and write down the options we have, then decide the outcome of it (either development, or documenting options and ideas) ? Regarding the checkbox state, I wanted to have the impression of maintainers, but I felt that choosing the character would not be easy to handle not only for development, but even for reading documents from different sources (custom TODO states have a meaning that we can infer, but a single letter seems harder). As an after thought, about the "[C]" proposal, I wonder if it would not be better to have a symbol, as "[X]" is not used for the letter, but for the cross, same for the "space" and the "dash" which express "halfway through". I didn’t have any idea the other day, but meanwhile, I have come first with "[~]" which sounds like a wave and thus is not firm, and is also a bitwise NOT in some programming languages. Or, thinking about the "NOT", I thought about "[!]" which is a NOT (not done) and also quite expressive. The only thing is that it is quite catching attention, like if we need to pay attention for something that was probably not that important since we cancelled it :) I could not find many other options, as I feel we need to stick to ASCII for a solution. WDYT ? Christophe -- ---> https://www.citadels.earth Once it's perfectly aimed, the flying arrow goes straight to its target. Thus, don't worry when things go right. There will be enough time to worry about if they go wrong. Then, it's time to fire a new arrow towards another direction. Don't sink. Adapt yourself ! The archer has to shoot accurately and quickly. [Words of Erenthar, the bowman ranger] <---
Re: Do not show a TODO item in the global TODO list until certain date?
Hello,
Ihor Radchenko writes:
> Also, I am doing something similar in my personal config using
> SHOWFROMDATE property. See
> https://github.com/yantar92/emacs-config/blob/master/config.org#properties
> for inspiration.
I tried the following but without success... my Emacs Lisp lack of
knowledge is showing here...
I copied your code from
https://github.com/yantar92/emacs-config/blob/master/config.org#properties
into my .emacs and eval-ed it.
,
| (add-to-list 'org-default-properties "SHOWFROMDATE")
| (bind-key "C-c C-f" #'org-command-set-SHOWFROMDATE-property org-mode-map)
| (bind-key "C-c C-f" #'org-command-set-SHOWFROMDATE-property
org-agenda-mode-map)
| (add-to-list 'org-agenda-bulk-custom-functions '(?F
org-command-set-SHOWFROMDATE-property))
|
| (defun org-command-set-SHOWFROMDATE-property (&optional arg)
| "Command to set :SHOWFROMDATE property for the org entry at point.
|If NOT-IN-AGENDA is not nil, do not check whether we are in agenda
now."
| (interactive "P")
| (if (equal major-mode 'org-agenda-mode)
| (progn
| (org-agenda-check-no-diary)
| (let* ((marker (or (org-get-at-bol 'org-marker)
| (org-agenda-error)))
| (buffer (marker-buffer marker))
| (pos (marker-position marker))
| (inhibit-read-only t)
| ts)
| (org-with-remote-undo buffer
| (with-current-buffer buffer
| (widen)
| (goto-char pos)
| ;; (org-fold-show-context 'agenda)
| (funcall-interactively 'org-command-set-SHOWFROMDATE-property arg)
| (setq ts (org-entry-get (point) "SHOWFROMDATE")))
| (org-agenda-show-new-time marker ts " P"
| (let ((property "SHOWFROMDATE"))
| (if (equal arg '(4))
| (org-entry-delete (point) property)
| (let ((value (org-read-property-value property))
| (fn (cdr (assoc-string property org-properties-postprocess-alist
t
| (setq org-last-set-property property)
| (setq org-last-set-property-value (concat property ": " value))
| ;; Possibly postprocess the inserted value:
| (when fn (setq value (funcall fn value)))
| (unless (equal (org-entry-get nil property) value)
| (org-entry-put nil property value)))
|
| (defun org-set-SHOWFROMDATE-property (PROMPT &rest args)
| "Read :SHOWFROMDATE: property."
| (org-read-date nil nil nil PROMPT))
|
| (add-to-list 'org-property-set-functions-alist '("SHOWFROMDATE" .
org-set-SHOWFROMDATE-property))
|
| (defun org-agenda-skip-before-SHOWFROMDATE-property ()
| "Skip agenda item if :SHOWFROMDATE: property is set and the day is before
it"
| (when-let* ((showfromdate (if (bound-and-true-p org-ql--current-element)
| (org-element-property :SHOWFROMDATE
(org-element-lineage org-ql--current-element '(headline) t))
| (org-entry-get (point) "SHOWFROMDATE")))
| (showfromdate (unless (seq-empty-p showfromdate) (ts-parse-org
showfromdate)))
| (currenttime (ts-now)))
| (ts< currenttime showfromdate)))
`
Then, I defined a test custom command:
,
| (setq org-agenda-custom-commands
| '(("h" "Agenda and tasks"
|((agenda "" ((org-agenda-skip-function
'org-agenda-skip-before-SHOWFROMDATE-property)))
| (alltodo "" ((org-agenda-skip-function
'org-agenda-skip-before-SHOWFROMDATE-property)))
`
together with a test TODO item:
,
| ** TODO test :personal:
|
|:PROPERTIES:
|:SHOWFROMDATE: 2022-10-16
|:END:
`
But the "test" still shows in the TODO list. Am I missing something
basic here?
Thanks for your help. Cheers,
--
Ángel de Vicente
Research Software Engineer (Supercomputing and BigData)
Instituto de Astrofísica de Canarias (https://www.iac.es/en)
Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output
Ihor Radchenko writes: > Joseph Turner writes: > >> You're right! Thank you for catching my mistake. I'll send another patch. > > Did you have a chance to work on the patch? Oops. Missed that you've sent a patch in another thread. Sorry for the noise. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output
Joseph Turner writes: > You're right! Thank you for catching my mistake. I'll send another patch. Did you have a chance to work on the patch? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
[PATCH 5] New: auto display inline images under subtree when `org-cycle'.
Sorry for this hard work on this patch. And thanks for your carefully
code reviewing. I have not contribute to org-mode for a long time,
already forgot most guidelines. Regards
Ihor Radchenko writes:
> "Christopher M. Miles" writes:
>
>>> Also, this change should be documented in etc/NEWS and also in
>>> "12.7 Images" section of the manual.
>>
>> Done. (the manual, you mean org-manual.org right? I found too many
>> documents under doc/ folder, confused for a while)
>
> I meant doc/org-manual.org
> Note doc/Documentation_Standards.org for the conventions we use in the
> manual. Your patch does not follow those conventions (double space
> between sentences).
Done
>
>> P.S: I merged two commits into one for clear.
>
> Let's not do it. They are two distinct changes and I will have
> significant comments regarding subtree cycling. (I had plans to
> implement cycling at point for images, and we may as well take this
> chance to create some generic infrastructure for showing/hiding the
> inline images).
>
> For now, lets sort out the ORG-IMAGE-ACTUAL-WIDTH property and get it
> merges. Then, we can move ahead to the subtree cycling feature.
>
Ok, I will submit the first patch of new property at first. If you're
going to implement this cycling inline image display feature,
that's great!
>> * lisp/org.el (org-display-inline-image--width): support subtree-level
> ^S
>
>> +If you want to override global variable ~org-image-actual-width~ of
>> +inline image display width, you can specify property
>> +"=ORG-IMAGE-ACTUAL-WIDTH=" in subtree level. It will only affect
>> +inline images under the specified subtree.
>
> Could you also add a paragraph describing what org-image-actual-width
> does?
Done in doc/org-manual.org
>
>> +*** New default property =ORG-IMAGE-ACTUAL-WIDTH= for overriding global
>> ~org-image-actual-width~
>
> I think that people may be confused by "default property" here. Just say
> "new property".
Done
>
>> +The subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" can override the
>> +global variable ~org-image-actual-width~ settings for inline images
>> +width under current property specified subtree.
>
> It is not necessarily subtree-level. You can as well set it in
> document-wide property drawer. Just say "The new property ...
> overrides ...".
Done
From 1bc3224220ec71292e08ebc6b25e0064f7243f2e Mon Sep 17 00:00:00 2001
From: stardiviner
Date: Thu, 15 Sep 2022 17:25:13 +0800
Subject: [PATCH] org.el: Support subtree-level org-image-actual-width
overriding
* lisp/org.el (org-display-inline-image--width): Support new property
"ORG-IMAGE-ACTUAL-WIDTH" overriding global variable
`org-image-actual-width'.
---
doc/org-manual.org | 21 +++
etc/ORG-NEWS | 4 +++
lisp/org.el| 89 --
3 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index a37b8390c..2d2b93694 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11314,6 +11314,27 @@ command:
startup by configuring the variable
~org-startup-with-inline-images~[fn:119].
+ #+vindex: org-image-actual-width
+ Control the display size of inline images.
+ The value can be bellowing formats:
+ - When non-nil, use the actual width of images when inlining them.
+ - When set to a number, use imagemagick (when available) to set the
+image's width to this value.
+ - When set to a number in a list, try to get the width from any
+=#+ATTR.*= keyword if it matches a width specification like:
+#+ATTR_HTML: :width 300px
+and fall back on that number if none is found.
+ - When set to nil, try to get the width from an =#+ATTR.*= keyword
+and fall back on the original width if none is found.
+ - When set to any other non-nil value, always use the image width.
+
+ This requires Emacs >= 24.1, built with imagemagick support.
+
+ #+cindex: @samp{NOBLOCKING}, property
+ If you want to override the global variable ~org-image-actual-width~
+ of inline image display width, you can specify property
+ "=ORG-IMAGE-ACTUAL-WIDTH=".
+
** Captions
:PROPERTIES:
:DESCRIPTION: Describe tables, images...
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index a7f32671e..f30809973 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -296,6 +296,10 @@ headings in HTML export.
Use the header argument =:var x=code-block[]= or
: #+CALL: fn(x=code-block[])
to pass the contents of a named code block as a string argument.
+*** New property =ORG-IMAGE-ACTUAL-WIDTH= for overriding global ~org-image-actual-width~
+
+The new property "=ORG-IMAGE-ACTUAL-WIDTH=" can override the global
+variable ~org-image-actual-width~ value for inline images display width.
** New options
*** New custom settings =org-icalendar-scheduled-summary-prefix= and =org-icalendar-deadline-summary-prefix=
diff --git a/lisp/org.el b/lisp/org.el
index 6e6c437d5..d2d66038d 100644
--- a/lisp/org.el
+++ b/lis
Re: [PATCH 4] New: auto display inline images under subtree when `org-cycle'.
"Christopher M. Miles" writes: >> Also, this change should be documented in etc/NEWS and also in >> "12.7 Images" section of the manual. > > Done. (the manual, you mean org-manual.org right? I found too many > documents under doc/ folder, confused for a while) I meant doc/org-manual.org Note doc/Documentation_Standards.org for the conventions we use in the manual. Your patch does not follow those conventions (double space between sentences). > P.S: I merged two commits into one for clear. Let's not do it. They are two distinct changes and I will have significant comments regarding subtree cycling. (I had plans to implement cycling at point for images, and we may as well take this chance to create some generic infrastructure for showing/hiding the inline images). For now, lets sort out the ORG-IMAGE-ACTUAL-WIDTH property and get it merges. Then, we can move ahead to the subtree cycling feature. > * lisp/org.el (org-display-inline-image--width): support subtree-level ^S > +If you want to override global variable ~org-image-actual-width~ of > +inline image display width, you can specify property > +"=ORG-IMAGE-ACTUAL-WIDTH=" in subtree level. It will only affect > +inline images under the specified subtree. Could you also add a paragraph describing what org-image-actual-width does? > +*** New default property =ORG-IMAGE-ACTUAL-WIDTH= for overriding global > ~org-image-actual-width~ I think that people may be confused by "default property" here. Just say "new property". > +The subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" can override the > +global variable ~org-image-actual-width~ settings for inline images > +width under current property specified subtree. It is not necessarily subtree-level. You can as well set it in document-wide property drawer. Just say "The new property ... overrides ...". -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
bug#45915: 28.2; delete-char deletes two letters
I confirmed that delete-char still deletes two letters on emacs-version: 28.2, org-version: 9.5.5. I found out (org-table-align) in (org-table-copy-down) makes this situation. Can someone take a look (org-table-align)? TIA #+begin_src emacs-lisp (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| 1 |")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-f C-f")) (message "I will call #'org-table-copy-down.") (sit-for 2) (call-interactively #'org-table-copy-down) (sit-for 2) (message "I will hit .") (sit-for 2) (execute-kbd-macro (kbd "")) (message "Two letters were deleted unexpectedly.")) ;;; (call-interactively 'emacs-bug-reproduce-45915) #+end_src
Re: [BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]
Sorry for the late reply. Ignacio Casso writes: > I was going to write one, but I have found further inconsistencies and > incomplete documentation and I think we should clearly define first how > we want dependencies to behave. According to the Org Mode documentation > and the docstrings of `org-enforce-todo-dependencies' and > `org-block-todo-from-children-or-siblings-or-parent', tasks are blocked > when: > > 1. The task has undone children tasks. > > 2. A task has a parent with the property :ORDERED:, and there > are undone sibling tasks prior to the current task > > 3. The parent of the task is blocked because it has siblings that should > be done first, or is child of a blocked grandparent TODO entry." > > But they are actually blocked when: > > 1. The task has undone DESCENDANT tasks (i.e., undone children of > children also block) > > 2. A task has a parent with the property :ORDERED:, and there > are sibling tasks prior to the current task which are undone OR > HAVE UNDONE DESCENDANTS > > 3. The parent of the task is blocked because it has siblings that should > be done first, or is child of a blocked grandparent TODO entry. BUT > THE TASK IS NOT BLOCKED E.G., IF ITS GRANDPARENT IS BLOCKED AND IS > PARENT IS DONE OR HAS NO TODO STATE. This is indeed inconsistent. I suspect that the main reason is an omission in the code when a single re-search-forward is used to check if there are undone descendant tasks. If not and the code deliberately checks things not mentioned in the manual, we may need to look further and dig into the mailing list/git logs. > So my other issues are: > > - Remarks in upper case in points 1 and 2 should be clarified in the > documentation and docstrings, if that is actually the desired > behaviour and not a bug. Otherwise, they should be fixed. I can do > that in the same patch. I think that they are mostly clarified in "5.2.7 TODO dependencies" section of the manual, except slightly confusing passage about subtasks: 5.2.7 TODO dependencies :: The structure of Org files—hierarchy and lists—makes it easy to define TODO dependencies. Usually, a parent TODO task should not be marked as done until all TODO subtasks, or children tasks, are marked as done. Sometimes there is a logical sequence to (sub)tasks, so that one subtask cannot be acted upon before all siblings above it have been marked as done. If you customize the variable ‘org-enforce-todo-dependencies’, Org blocks entries from changing state to DONE while they have TODO children that are not DONE. Furthermore, if an entry has a property ‘ORDERED’, each of its TODO children is blocked until all earlier siblings are marked as done. Here is an example: -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: error org export to pdf when latex letter class has been added to org-latex-classes
Hi,
for what it may help...
my emacs version:
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0)
of 2022-09-12
Adding
#+OPTIONS: toc:nil
to your MWE
I have this small file to export to latex:
```
(require 'org)
(require 'ox-latex)
(eval-after-load "org"
(progn
;; Add KOMA script based books
(add-to-list 'org-latex-classes
'("letter"
"\\documentclass{letter}"))
(setq org-latex-pdf-process '("latexmk -bibtex -f %f")
org-babel-python-command "python3")))
```
And I use it as:
```
emacs -Q --batch test.org -l org-export.el -f org-latex-export-to-pdf
```
And I see no errors...
Maybe you could try from here and start stripping things further from it to
narrow the problem
Hope it helps...
/PedroAAranda
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
