DOC "Org Mode tools": orgparse is missing
Hello, some tool is missing in the documentation here: https://orgmode.org/worg/org-tools/index.html "orgparse" (https://orgparse.readthedocs.io/en/latest/) Also remove "PyOrgParse" which is not maintained anymore and points itself to "orgparse". Kind Christian
Re: Problems with babel reading Japanese paths in Windows
I did and it seems to work fine, I also tested this using plantuml-mode's normal compliation procedure. This seems to specifically be a problem with org-mode and babel's compilation Thanks for your help! On Sat, Mar 12, 2022 at 9:49 PM Ihor Radchenko wrote: > Jonathan Nogueira writes: > > > Hi all, > > > > I've been working with emacs and org on Windows 10.0.19042 and was > recently > > trying to get babel to produce plantuml diagrams. > > > > I've managed to (I think) narrow the issue down to Babel either not being > > able to read/write Japanese paths to shell commands, as when I attempt to > > build the diagrams in folders with only ASCII paths, they build fine, but > > when babel attempts to execute any source code for paths that contain > > Japanese characters, babel gives back the cmd error "The System Cannot > Find > > the Path Specified." > > I do not use Windows, but I recall somewhat relevant discussion on > planuml recently: > https://orgmode.org/list/5d7eba13-b717-a12a-5f89-7d2c94149...@gmail.com > > It seems that plantuml might have some issues with UTF unless you pass > relevant command line args. > > Did you try to run plantuml manually from windows cmd using the > problematic path? > > Best, > Ihor > -- Thanks, Jonathan Nogueira
Re: oc-basic load performance
Actually, this was prompted by this reddit post, where the OP also notes impaired scrolling performance after loading an org file with citations. https://www.reddit.com/r/orgmode/comments/td76wz/org_very_slow_load_with_orgcite_and_a_large/ I encouraged them to post the report here; not really sure why scrolling would be impacted. On Sun, Mar 13, 2022 at 7:28 PM Bruce D'Arcus wrote: > > I've seen a number of people note how slow loading of BibTeX files is in > oc-basic. > > Just wondering: do we know why, and whether there are opportunities to > improve it? > > For comparison, parsebib (which I use in citar) is much faster. > > Bruce
Re: Code blocks and quotes export style
On 14/03/2022 01:39, Juan Manuel Macías wrote:
Supercali@@latex:\-@@fragilistic
Supercali\shy{}fragilistic
Supercali\-fragilistic
should be even better since, besides LaTeX "\-", HTML exporter uses
"" or "" (I would expect more consistent behavior though.)
info "(org) Special Symbols"
https://orgmode.org/manual/Special-Symbols.html [[info:org#Special Symbols]]
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
On 12/03/2022 02:59, Tim Cross wrote:
Ignacio Casso writes:
(let ((org-capture-templates
'(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?"
(org-capture nil "d")))
I put an autoload cookie myself and it doesn't fix it, so it's probably
not that. It's the first time I manage autoload cookies though, so I may
have done something wrong. I only tested that the autoload cookie worked
by checking that before loading org-capture, org-capture-templates
appears in the completion list for C-h v, and I can evaluate it.
While I don't know if this is a bug, it certainly doesn't seem to be
doing the right thing from an 'intuitive' point of view. I would expect
when a variable is bound to a value inside a let and a function is then
called which uses that variable, the initial let bound value should be
used and the result be the same regardless of whether org-capture has or
has not been loaded. It means there is a hidden side-effect here, which
isn't good and probably needs more analysis. If you had set the value
using setq rather than as a let form, it wouldn't be overridden when
org-capture is loaded, so why does it when it is a let binding?
For `defcustom' autoload generates no more than
(defvar org-capture-templates nil "...")
It seems, behavior depends on whether `org-capture-templates' has the
:set attribute. The setter receives nil instead of the let-bound value.
I can not say I understand the tricks with bypassing lexical binding in
`defcustom' and some checks in `custom-declare-variable'. Since emacs-26
something has changed:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6309131349
- ;; Use defvar to set the docstring as well as the special-variable-p flag.
- ;; FIXME: We should reproduce more of `defvar's behavior, such as the warning
- ;; when the var is currently let-bound.
- (if (not (default-boundp symbol))
I am unsure that the setter of `defcustom' should get let-bound value in
the case of autoloading since it might lead to fragile behavior.
I still think that explicit templates argument for `org-capture' is
better than relying on autoloading.
Reading the code I noticed `org-capture-templates-contexts' so I wonder
if it might help for the original use case.
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
> While I don't know if this is a bug, it certainly doesn't seem to be
> doing the right thing from an 'intuitive' point of view. I would expect
> when a variable is bound to a value inside a let and a function is then
> called which uses that variable, the initial let bound value should be
> used and the result be the same regardless of whether org-capture has or
> has not been loaded. It means there is a hidden side-effect here, which
> isn't good and probably needs more analysis. If you had set the value
> using setq rather than as a let form, it wouldn't be overridden when
> org-capture is loaded, so why does it when it is a let binding?
>
I've investigated this a little bit further and this is not specific to
org-capture. For example if you evaluate (let ((org-agenda-files
'("/tmp/foo.org"))) (org-agenda-list)) before org-agenda is laoded, the
let-binding of org-agenda-files is ignored too.
I think the reason is the following:
1) Loading the file defining those autoload functions runs defcustom for
the variable we are using.
2) defcustom calls the function F passed as argument with the :set
keyword (set-default by default) to initialize the variable. That
function receives as argument the variable and a value.
2.1) If the variable was already initialized (e.g., with setq) with a
value V, the value passed to F is V. It it was not, the value passed to
F is the value passed as STANDARD argument to defcustom. So far, so
good.
2.2) If the variable is let-bound with lexical-binding non-nil, there is
an error in Emacs 29, since at the time the variable is let-bound Emacs
does not know it is special and thus it uses lexical binding, but when
defcustom runs it finds out that it is special and therefore it should
have used dynamic binding. In Emacs 27 this check is not done, and the
let-binding is considered lexical, so it has no effect for uses of the
variable while the let body is being executed, unless they appear
textually within that body. In particular, the value passed to F is
again the STANDARD argument of defcustom.
2.2.1) An exception to this is when the variable is autoloaded, since
Emacs can know that it is special by the time is evaluates let.
2.2.2) But in general this means that the programmer should know whether
an autoload function is going to be loaded at that execution
point if he is going to do this.
2.3) If the variable is let-bound with lexical-binding nil, things then
break completely. First, the value passed to F is again the STANDARD
argument of defcustom. This makes sense since F would initialize the
variable globally and the let binding was supposed to be local. But it
means that again the let binding gets shadowed. But it's worse than
that. The initialization of the variable does not work and only has the
same scope as the let-binding, so after the let body is finished, the
variable is void. Furthermore, since the feature in question is already
provided, there is no easy way to leave that state and initialize the
variable again.
This makes me conclude that let-bindings of variables used by autoloaded
functions should be avoided unless we know for sure that the function
will be loaded at that point in execution.
> Might be worth asking a general question on emacs-devel? Stephan or Eli
> can probably provide some clarification here (maybe this is somehow
> related to the changes associated with the lexical binding stuff?)
Yes, I will email them explaining this, since I think the point 2.3 is a
bug. Maybe there is no better way to do this, but I think at least there
should be a warning if a misuse of let + autoload can leave Emacs in
what I think is a broken state.
Possible bug in `org-subtree--get-subtree-options`?
Hello Nicolas,
Today I was debugging something where a subtree export wasn't recognizing
the EXPORT_OPTIONS property set in that subtree.
MWE:
=
* Top level
** Allow broken links, but mark them
:PROPERTIES:
:EXPORT_FILE_NAME: allow-broken-links-but-mark-them
:EXPORT_OPTIONS: broken-links:mark
:END:
=
1. Move cursor to BOL of "** Allow broken links, but mark them" line.
2. M-: (org-export--get-subtree-options)
Output:
(:title (#("Top level" 0 9 (:parent #1
Issue: Point is already on a heading, but it is jumping to the parent
heading and returning that heading's properties.
Debugging through how the export options got parsed in subtree exports, I
reached the `org-export--get-subtree-options' function and this line in
there:
;;
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox.el#n1425
(if (org-at-heading-p) (org-up-heading-safe) (org-back-to-heading t))
It looks like the if condition actions are swapped here.
Should it be:
(if (org-at-heading-p) (org-back-to-heading t) (org-up-heading-safe))
;; If point is in a heading, just go to the BOL (org-back-to-heading t)
;; Otherwise, jump up to a parent-heading if available.
If I evaluate that function after updating that if condition as above and
redo the steps I mentioned above, the output is now what I expect:
(:with-broken-links mark :title (#("Allow broken links, but mark them" 0 33
(:parent #1
I am only surprised that this line has been there at least since 2015.
Thanks!
--
Kaushal Modi
Re: Code blocks and quotes export style
Max Nikulin writes: > should be even better since, besides LaTeX "\-", HTML exporter uses > "" or "" (I would expect more consistent behavior > though.) Hi, Maxim. You're right, I didn't remember that there is a specific entity in Org for the discretionary hyphen. Sometimes I think too much from the LaTeX side... :-) Best regards, Juan Manuel
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Max Nikulin writes:
> On 12/03/2022 02:59, Tim Cross wrote:
>> Ignacio Casso writes:
>
>>>(let ((org-capture-templates
>>> '(("d" "default" entry
>>> (file+headline org-default-notes-file "Tasks")
>>> "* %?"
>>> (org-capture nil "d")))
>>>
>>> I put an autoload cookie myself and it doesn't fix it, so it's probably
>>> not that. It's the first time I manage autoload cookies though, so I may
>>> have done something wrong. I only tested that the autoload cookie worked
>>> by checking that before loading org-capture, org-capture-templates
>>> appears in the completion list for C-h v, and I can evaluate it.
>> While I don't know if this is a bug, it certainly doesn't seem to be
>> doing the right thing from an 'intuitive' point of view. I would expect
>> when a variable is bound to a value inside a let and a function is then
>> called which uses that variable, the initial let bound value should be
>> used and the result be the same regardless of whether org-capture has or
>> has not been loaded. It means there is a hidden side-effect here, which
>> isn't good and probably needs more analysis. If you had set the value
>> using setq rather than as a let form, it wouldn't be overridden when
>> org-capture is loaded, so why does it when it is a let binding?
>
> For `defcustom' autoload generates no more than
>
> (defvar org-capture-templates nil "...")
>
> It seems, behavior depends on whether `org-capture-templates' has the :set
> attribute. The setter receives nil instead of the let-bound value. I can not
> say
> I understand the tricks with bypassing lexical binding in `defcustom' and some
> checks in `custom-declare-variable'. Since emacs-26 something has changed:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6309131349
>> - ;; Use defvar to set the docstring as well as the special-variable-p flag.
>> - ;; FIXME: We should reproduce more of `defvar's behavior, such as the
>> warning
>> - ;; when the var is currently let-bound.
>> - (if (not (default-boundp symbol))
>
> I am unsure that the setter of `defcustom' should get let-bound value in the
> case of autoloading since it might lead to fragile behavior.
>
> I still think that explicit templates argument for `org-capture' is better
> than
> relying on autoloading.
>
Yes, it would seem that something has changed and I suspect it may be
related to the introduction of lexical bindings. Explicit template
arguments for org-capture may or may not be better, I don't know.
However, this behaviour seems like it may be the tip of a much bigger
issue outside of org-mode and potential source of bugs for Emacs.
Bottom line is I don't think any function should behave differently
depending on when autoload runs. It could be because the setter used in
the defcustom is incorrect since the change a while back to use
lexical-binding by default or something else. It looks like the setter
on org-capture-template is used to do some form of conversion on the
template specification to force a new format. Not sure how long that has
been there or whether it is actually still required. Could be that this
setter was added to aid in transition to a new template format which
could/should be removed at some point. Personally, I've never liked
custom setters. I typically avoid the custom interface. However, exotic
custom variable setters can mean that using setq won't work correctly
and you need to use custom-set-variable etc. In fact, I'm seeing a lot
more use of custom-set-variable* in init code recently - something which
was almost never seen 20 years ago.
Regardless, I don't think having the situation where the programmer must
know (guess) whether autoload will/could execute during the evaluation
of code they write is tenable and am beginning to suspect it may be an
Emacs bug OR a subtle bug in org-mode as a result to the transition to
lexical binding as the default. My recommendation would be to come up
with a non-org specific example which reproduces the behaviour and then
ask on emacs-devel, using the example to demonstrate the issue.
> Reading the code I noticed `org-capture-templates-contexts' so I wonder if it
> might help for the original use case.
I thought about that as well. However, from re-reading the OP's posts, I
suspect not. org-capture-templates-contexts seems to be useful when you
want to restrict access to some templates based on context. However,
from reading the OP's posts, I get the impression that what they want is
for templates to be different based on context i.e. they still want the
template associated with 'd', but want its definition to be different.
It is possible org-capture-template-contexts might provide an
alternative solution where you don't need to dynamically modify/add
templates in this manner. For example, you could have all your templates
defined, but only offer those relevant based on context. However, I
guess this would mean having to have different template keys, w
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
I've also investigated the issue a little bit further and wrote and email with my conclusions about the same time Max wrote his. I comment inline about a few of your thoughts: > For `defcustom' autoload generates no more than > > (defvar org-capture-templates nil "...") > > It seems, behavior depends on whether `org-capture-templates' has the :set > attribute. Not really, all defcustoms have a :set attribute, be it passed explicitly as a parameter or the default value, set-default. This issue happens with all autoload functions that use a custom variable: if they are called inside a let form binding that variable and the feature was not loaded yet, the let-binding will have no effect. > The setter receives nil instead of the let-bound value. I can not say > I understand the tricks with bypassing lexical binding in `defcustom' and some > checks in `custom-declare-variable'. Since emacs-26 something has changed: > I am unsure that the setter of `defcustom' should get let-bound value in the > case of autoloading since it might lead to fragile behavior. See my other email where I explain what I think that defcustom of a variable is doing when called inside a let-binding of that variable. >> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6309131349 >>> - ;; Use defvar to set the docstring as well as the special-variable-p >>> flag. >>> - ;; FIXME: We should reproduce more of `defvar's behavior, such as the >>> warning >>> - ;; when the var is currently let-bound. >>> - (if (not (default-boundp symbol)) But the conclusion is that right now it does not work, so I think that warning is needed. > It looks like the setter on org-capture-template is used to do some > form of conversion on the template specification to force a new > format. Not sure how long that has been there or whether it is > actually still required. Could be that this setter was added to aid in > transition to a new template format which could/should be removed at > some point. That is right, it seems it was added for backwards compatibility when a new template format was added. However, it's not actually needed, since org-capture-select-template also calls that function to ensure they are in the new format. It needs to do so in order to allow setting org-capture-templates also with setq, or let-binding org-capture-templates as I do. That's not the problem anyway, as I explained above. > However, this behaviour seems like it may be the tip of a much bigger > issue outside of org-mode and potential source of bugs for Emacs. > Bottom line is I don't think any function should behave differently > depending on when autoload runs > Regardless, I don't think having the situation where the programmer must > know (guess) whether autoload will/could execute during the evaluation > of code they write is tenable and am beginning to suspect it may be an > Emacs bug OR a subtle bug in org-mode as a result to the transition to > lexical binding as the default. My recommendation would be to come up > with a non-org specific example which reproduces the behaviour and then > ask on emacs-devel, using the example to demonstrate the issue. I agree. I'm on it. >> Reading the code I noticed `org-capture-templates-contexts' so I wonder if it >> might help for the original use case. > > I thought about that as well. However, from re-reading the OP's posts, I > suspect not. org-capture-templates-contexts seems to be useful when you > want to restrict access to some templates based on context. However, > from reading the OP's posts, I get the impression that what they want is > for templates to be different based on context i.e. they still want the > template associated with 'd', but want its definition to be different. > > It is possible org-capture-template-contexts might provide an > alternative solution where you don't need to dynamically modify/add > templates in this manner. For example, you could have all your templates > defined, but only offer those relevant based on context. However, I > guess this would mean having to have different template keys, which > might be an issue. If I recall correctly template contexts allow to redefine the template key, so that would not be an issue. And yes, using template contexts could probably be a solution to my use case, as it would be having an org-capture version with template parameter. But don't worry too much about my use case, since a simple (require 'org-capture) is enough to keep doing what I was doing.
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Ignacio Casso writes: >> Regardless, I don't think having the situation where the programmer must >> know (guess) whether autoload will/could execute during the evaluation >> of code they write is tenable and am beginning to suspect it may be an >> Emacs bug OR a subtle bug in org-mode as a result to the transition to >> lexical binding as the default. My recommendation would be to come up >> with a non-org specific example which reproduces the behaviour and then >> ask on emacs-devel, using the example to demonstrate the issue. > > I agree. I'm on it. > Excellent. I will watch with interest to see what feedback you get!
Re: [BUG] error after reading in contents of other file [9.6 (9.6-??-e7ea951 @ /home/user/.emacs.d/.local/straight/build-28.0.50/org/)]
On Sat, Mar 12, 2022 at 7:53 AM Ihor Radchenko wrote: > > Thanks for the report! > Are you still seeing the traceback if you update Org to latest main? > 5da9d6810 in more recent versions should help with some cases when the > error like in your backtrace appears. Yes, I'm still getting the following: Emacs : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-01-15 Package: Org mode version 9.6 (9.6-??-e7ea951ac @ /home/user/.emacs.d/.local/straight/build-28.0.50/org/) Warning (org-element-cache): org-element--cache: Org parser error in FOO-test.org::21. Resetting. The error was: (error "Invalid search bound (wrong side of point)") Backtrace: nil
