[DONE] Re: [BUG] The latest org-fold feature breaks link :activate-func property
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> I use extension >> [[https://repo.or.cz/org-link-beautify.git][org-link-beautify]] to display >> text-property beautify content on link. With >> latest org-mode source code on commit "1ed9e4223", I got this error which >> displayed in the >> attachment gif. > > I do not see any error there, except the fact that Org reveals the links > contents. > > Looking at ol.el, it appears that org-next-link does not respect > org-fold-show-context-detail (`link-search'). I fixed this problem on > main. Yes, that's the problem. I pulled that latest commit and confirmed the problem fixed. Thanks for quick response! > > Let me know if you were referring to something else. > > Best, > Ihor -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 signature.asc Description: PGP signature
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
On 4/27/22 09:55, Stefan Monnier wrote: Instead of rounding the times to whole seconds, wouldn't it make more sense to check that the difference is larger than 1s? org-file-newer-than-p is intended to work on filesystems like HFS+ that store just the seconds part of the last-modified time. Since these filesystems take the floor of the system time, taking the floor should be the most-accurate way to work around timestamp truncation issues, where comparing one timestamp that comes from an HFS+ filesystem to another timestamp coming from some other source (which is how org-file-newer-than-p is used). The code won't work as desired on filesystems like FAT where the last-modified time has only 2-second resolution. Ideally Emacs Lisp code would have access to file timestamp resolution but that's not something it has now, so I merely preserved org-file-newer-than-p's assumption that taking the floor is good enough.
Re: [BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too
On Thu, Apr 28, 2022 at 10:44 AM Ihor Radchenko wrote: > I am not going to fix this just yet unless it is critical. It does not > look like this bug is common. It's not time-critical, but it would be good to fix this bug. It's not just the Org link syntax.. any Org markup is fontified inside the src blocks. Here's a screenshot (attached) that shows the bold fortification happen in the src block as well. > This and other fontification issues will be solved by new parser-based > fontification engine I am working on now. If it is planned to be fixed before the next major release of Org, it's OK. Thanks for working on this!
Re: Bug in orgalist mode's advice on indent-according-to-mode
Tim Cross writes: > Eric Abrahamsen writes: > >> In Emacs commit f596f0db82c0b1ff3fe8e8f1d8b07d2fe7504ab6, from Nov 2021, >> the function `indent-according-to-mode' was given an optional >> inhibit-widen argument. That argument being passed causes orgalist's >> advice to fail, as the lambda doesn't accept any additional arguments. >> One way to fix it would be like that: >> >> (unless (advice-member-p 'orgalist-fix-bug:31361 'indent-according-to-mode) >>(advice-add 'indent-according-to-mode >>:around (lambda (old inhibit-widen) >> "Workaround bug#31361." >> (or (orgalist--indent-line) >> (let ((indent-line-function >> (advice--cd*r indent-line-function))) >>(funcall old inhibit-widen >>'((name . orgalist-fix-bug:31361) >> >> Or I suppose a more future-proof approach might be to use a and >> then `apply' instead of `funcall'. >> > > A better solution would probably be to fix this without using > add-advice. While advice can be a useful escape hatch, it really is best > avoided, especially given that it doesn't always play nice with lexical > binding. I note this one is also calling an undocumented internal > function. In principle I quite agree! But orgalist is basically built on top of add-function/advice-add, so I didn't think that was an option. And also assumed that, given what Orgalist is trying to do, there isn't a cleaner solution right now.
Re: [Q] How to get all the properties of the current subtree?
Rodrigo Morales writes: > My question is: How to get all the properties (inherited properties > included) of the current subtree? In the example shown below, I would > expect the following result You would need to collect property names by running org-entry-properties on current heading, it's parent, and so on. You can get parent headings as (org-element-property :parent (org-element-at-point)) in newer Org or using org-up-heading-safe. Then, you can run org-entry-get on the acquired list of property names. Best, Ihor
Re: [BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too
Kaushal Modi writes: > With the default value of the new org-fold-core-style, if I have a > snippet like below: > > #+begin_src toml > [[asdf]] > #+end_src > > The brackets around asdf get hidden. ([[asdf]] is TOML syntax for maps > or array of tables: https://toml.io/en/v1.0.0#array-of-tables) > > If I change org-fold-core-style to overlays, and refresh that Org > buffer, I see the square brackets around asdf in the src block (as > expected). Confirmed. The same problem also did exist in the past, but it was shadowed by re-fontification. I am not going to fix this just yet unless it is critical. It does not look like this bug is common. This and other fontification issues will be solved by new parser-based fontification engine I am working on now. Best, Ihor
Re: [BUG] org-mode #+SETUPFILE not working with properties [9.5.2 (release_9.5.2-378-g98588e @ /home/eros/src/org-mode/lisp/)]
Eros Zaupa writes:
> I would like to move the properties drawer to a separate file and import it
> into the main one. To do so I'm using the `#SETUPFILE` property suggested
> [here][1], but this doesn't seem to work.
Confirmed.
Though I am not 100% sure.
Org is indeed ignoring top-level property drawer when parsing
#+SETUPFILE.
Dear All,
I think that parsing top-level property drawer is simply an omission
from the time we introduced top-level property drawers into syntax.
We may either implement this support or leave things as is and document
the current behaviour.
I would be in favour of implementing top-level drawer support in
SETUPFILE, but there might be alternative opinions. WDYT?
Dear Eros Zaupa,
> ***main.org***
>
> #+SETUPFILE: test.org
>
> #+begin_src sh
> echo ${A}
> #+end_src
>
> #+RESULTS:
>
> ***test.org***
>
> :PROPERTIES:
> :header-args:sh: :var A="this is a"
> :END:
To work around your issue, you can use keyword property syntax:
***test.org***
#+PROPERTY: header-args:sh :var A="this is a"
Best,
Ihor
Re: log-done and org-after-todo-state-change-hook
Florian Lindner writes: > I have an org-todo-keywords like "DONE(d!)" which logs a time stamp > everytime that todo is reached. > > I also use org-after-todo-state-change-hook to copy that node somewhere > else, as soon as it is finished. > > My problem now is that the logging seems to happen after hook, which > made me end up with a original node: > ... > How can make the hook to be executed after the logging of done or some > other way to have the log entry included in the copy? There is currently no hook running after you store note. However, you can add an :after advice to org-store-log-note. Best, Ihor
Re: [BUG] Documentation errata [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
Alessandro Bertulli writes:
> I think this is a typo to be corrected in the Manual. Is this the right
> place to make such a suggestion?
>
> Thanks in advance to all and I apologize if this is not the right way to
> submit an errata.
Thanks for the suggestion! Emailing Org mailing list is the right way to
submit errata and other suggestions/questions.
> this is not actually a bug regarding the code, but the documentation. In
> the Manual, when talking about CDLaTeX mode (specifically at
> https://orgmode.org/manual/CDLaTeX-mode.html), it is said, regarding the
> single quote:
>> Pressing the single-quote followed by another character modifies the
>> symbol before point with an accent or a font.
>
> However, in my setup it's the other way around: first you digit a
> character, and THEN you press the single quote. This is also reflected, for
> what I saw, in the docstring of the function cdlatex-math-modify, which
> says "Modify PREVIOUS char/group/macro with math accent/style." (my
> emphasis).
You were clearly confused by the manual text, so you may certainly be
improved. However, I do not see any error in the text you pointed to.
To make use of org-cdlatex-math-modify (bound to "'") you generally do
the following:
1. Type a math symbol
2. Type ' followed by another character
3. org-cdlatex modifies the symbol from (1) according to the character
you typed in (2).
Example:
1. \alpha
2. ' -
3. \bar{\alpha}
So, as the footnote suggests, you type the single-quote ' followed by
another character - to modify the symbol \alpha before quote.
"Modify PREVIOUS char/group/macro with math accent/style." does not
contradict the above.
If you have a suggestion how to improve the present text in the manual,
feel free to share it.
Best,
Ihor
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Sébastien Miquel writes: > The attached patch adds support for two new babel header arguments: > =:noweb-prefix= and =:noweb-trans=. > > =:noweb-prefix= can be set to =no= to disable the noweb prefix > behaviour, where prefix characters are repeated when expanding a > multiline noweb reference. Thanks for the patch! The idea about :noweb-prefix looks useful. > =:noweb-trans= can be set to =prin1-to-string= to insert a lisp string > representing the content of the referenced src block. > > The goal is to allow one to use, say, a LaTeX src block to represent > some LaTeX snippet to be tangled into a string in some lisp (or other) > code. This isn't possible currently, and one has to manually string > escape the LaTeX code. > ... > I've left undocumented the possibility of setting =:noweb-trans= to > another function. I wonder if anyone can think of some other use. prin1-to-string is too specific and only solves a single use-case. Consider the following example: #+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no :noweb-trans prin1-to-string <> (setq latex-header <>) #+END_SRC There are two noweb references here. Setting source block-wide :noweb-trans is not helpful because the first reference will be incorrectly filtered through prin1-to-string. I'd rather introduce a new syntax to transform the noweb reference inline. Something like #+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no <> (setq latex-header <<(prin1-to-string nw)>>) #+END_SRC > Noweb insertions honor prefix characters that appear before the noweb > -syntax reference. This behavior is illustrated in the following > -example. Because the =<>= noweb reference appears behind the > -SQL comment syntax, each line of the expanded noweb reference is > -commented. With: > +syntax reference. This behavior can be turned off by setting the > +=noweb-prefix= header argument to =no= and is illustrated in the > +following example. Because the =<>= noweb reference appears > +behind the SQL comment syntax, each line of the expanded noweb > +reference is commented. With: This sounds a bit confusing. I would also add an example where it is useful to set :noweb-prefix to no. Best, Ihor
Link display not working for orgroam links as items in enumeration
- [[id:8adf8391-5aa7-40d7-bedf-4a794dc228b2][Galvin (2017) Adverse outcomes in older adults attending emergency departments. a systematic review and meta-analysis of the Identification of Seniors At Risk (ISAR) screening tool]]
Re: [BUG] The latest org-fold feature breaks link :activate-func property
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> I use extension >> [[https://repo.or.cz/org-link-beautify.git][org-link-beautify]] to display >> text-property beautify content on link. With >> latest org-mode source code on commit "1ed9e4223", I got this error which >> displayed in the >> attachment gif. > > I do not see any error there, except the fact that Org reveals the links > contents. > the gif attachment is an animated gif, so you need to view it in a client or other program which will 'run' animated gifs. Even when you do, it doesn't provide much to go on.
Re: [BUG] The latest org-fold feature breaks link :activate-func property
"Christopher M. Miles" writes: > I use extension > [[https://repo.or.cz/org-link-beautify.git][org-link-beautify]] to display > text-property beautify content on link. With > latest org-mode source code on commit "1ed9e4223", I got this error which > displayed in the > attachment gif. I do not see any error there, except the fact that Org reveals the links contents. Looking at ol.el, it appears that org-next-link does not respect org-fold-show-context-detail (`link-search'). I fixed this problem on main. Let me know if you were referring to something else. Best, Ihor
Re: Bug in orgalist mode's advice on indent-according-to-mode
Eric Abrahamsen writes: > In Emacs commit f596f0db82c0b1ff3fe8e8f1d8b07d2fe7504ab6, from Nov 2021, > the function `indent-according-to-mode' was given an optional > inhibit-widen argument. That argument being passed causes orgalist's > advice to fail, as the lambda doesn't accept any additional arguments. > One way to fix it would be like that: > > (unless (advice-member-p 'orgalist-fix-bug:31361 'indent-according-to-mode) >(advice-add 'indent-according-to-mode >:around (lambda (old inhibit-widen) > "Workaround bug#31361." > (or (orgalist--indent-line) > (let ((indent-line-function > (advice--cd*r indent-line-function))) >(funcall old inhibit-widen >'((name . orgalist-fix-bug:31361) > > Or I suppose a more future-proof approach might be to use a and > then `apply' instead of `funcall'. > A better solution would probably be to fix this without using add-advice. While advice can be a useful escape hatch, it really is best avoided, especially given that it doesn't always play nice with lexical binding. I note this one is also calling an undocumented internal function.
