Bug in orgalist mode's advice on indent-according-to-mode
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'. Eric
Re: [BUG] The latest org-fold feature breaks link :activate-func property
"Christopher M. Miles" writes: > [[PGP Signed Part:Undecided]] > > 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. That animated gif is not terribly helpful. A backtrace would likely provide something more concrete to work with. As this is something which is triggered by an external package not part of org mode, you probably need to report it to the maintainer of that package.
Re: [BUG] buffer displays incorrectly after capture
Skip Collins writes: > On Wed, Apr 27, 2022 at 4:48 AM Ihor Radchenko wrote: >> Fixed in 2d6f26c05 on main. And no, it was not that easy to fix. >> Captured headlines may or may not need to be unfolded. > > Thanks. I confirm that behavior is correct for folded level 1 > headlines. But the problem still exists at level 2 and deeper: > ... > 9. Observe that the new level 2 headline still does not appear, but a > misplaced folding ellipsis does appear at the end: > * foo... > ** bar > more text > ... This is not a bug. You will routinely see constructs like this when you jump to a deeply nested headline in real Org files. Only level 1 headlines are always kept visible by convention (and some people even argue that this convention should be dropped e.g. in sparse trees). To deal with such situations, see org-reveal (possibly with prefix arguments). Best, Ihor
log-done and org-after-todo-state-change-hook
Hello, 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: DONE letzter note :LOGBOOK: - State "DONE" from "TODO" [2022-04-27 Mi 21:42] :END: [2022-04-27 Mi] which is copied to ** DONE letzter note [2022-04-27 Mi] 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? Thanks! Florian
Re: [the culprit]
>>> "JK" == John Kitchin writes: > This seems like something that could (should?) go in a personal config, as > a custom function, or advice. > You could, for example do something like this (lightly tested) > #+BEGIN_SRC emacs-lisp > (defun my-put (property value here) > (interactive (list nil nil current-prefix-arg)) > (if (null here) > (org-set-property property value) > (let* ((property (or property (org-read-property-name))) > (value (or value (org-read-property-value property > (save-excursion > (beginning-of-line) > (search-forward ":") > (backward-char) > (insert (format ":%s: %s\n" property value)) > #+END_SRC I tested it, and for my org files this is slightly better: #+BEGIN_SRC emacs-lisp (defun my-put (property value here) (interactive (list nil nil current-prefix-arg)) (if (null here) (org-set-property property value) (let* ((property (or property (org-read-property-name))) (value (or value (org-read-property-value property (save-excursion (beginning-of-line) (search-forward ":") (backward-char) (insert (format ":%s: %s\n" property value)) (indent-for-tab-command nil) #+END_SRC But this might be just me. In any case I think this functionality is very helpful. Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
Re: Name the different types of links in an org file
c.bu...@posteo.jp writes: > Hello, > > I just want to find the correct terms of the different types of links > an org file can have. This is not only about orgmode but orgroam > (version 1 and 2) also. > > 1. Hyperlinks > Example: [[https://foo.bar][Link description]] > This links can also point to files on the local filesystem etc > See the following chapter in the manual: (info "(org)Hyperlinks") and in particular, the sections on "Inernal" and "External" links, but note that the hyperlink system is extensible - you define your own link types and behavior: (info "(org)Adding Hyperlink Types") -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
> - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) > - (cl-subseq time 0 2) > + (not (time-less-p (org-time-convert-to-integer > + (nth 5 (file-attributes file))) > + (org-time-convert-to-integer time) Instead of rounding the times to whole seconds, wouldn't it make more sense to check that the difference is larger than 1s? Stefan
Re: [tip] Org speed commands improved
Juan Manuel Macías [2022-04-26 Tue 14:00] wrote: > Org speed commands are a major productivity boost and I love them. > Lately it has occurred to me to make some modifications with the > following configuration, which I share here in case someone wants to try > it. The idea is that Org speed commands are activated anywhere in the > header (not just at the beginning of the line) *or* when point is at the > very beginning of the buffer. This, in my opinion, improves the > navigation speed: Very nice idea; I'll give it a try, thanks! -- Daniel Fleischer
Re: [BUG] buffer displays incorrectly after capture
On Wed, Apr 27, 2022 at 4:48 AM Ihor Radchenko wrote: > Fixed in 2d6f26c05 on main. And no, it was not that easy to fix. > Captured headlines may or may not need to be unfolded. Thanks. I confirm that behavior is correct for folded level 1 headlines. But the problem still exists at level 2 and deeper: 1. Open emacs with an empty file: emacs test.org 2. From emacs, enable auto-revert-mode: M-x auto-revert-mode 3. From a shell, add text to the file: echo "* foo\nsome text\n** bar\nmore text\n" >>test.org 4. From emacs, cycle global visibility twice, so that the second level headline is visible but folded: S-TAB S-TAB 5. Observe the two folded headlines: * foo... ** bar... 6. From the shell, add another level 2 headline at the end of the file: echo "** baz\n" >>test.org 7. Observe that the new level 2 headline is not displayed as expected: * foo... ** bar... 8. From emacs, move the cursor onto the "** bar" headline and cycle visibility: TAB 9. Observe that the new level 2 headline still does not appear, but a misplaced folding ellipsis does appear at the end: * foo... ** bar more text ... 10. Cycle global visibility twice: S-TAB S-TAB 11. Observe the correct display of all headlines: * foo... ** bar... ** baz
[BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too
Hello, 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). Org mode version 9.5.3 (release_9.5.3-458-g1ed9e4) -- Kaushal Modi
Name the different types of links in an org file
Hello, I just want to find the correct terms of the different types of links an org file can have. This is not only about orgmode but orgroam (version 1 and 2) also. Currently I know and "understand" this types of links. 1. Hyperlinks Example: [[https://foo.bar][Link description]] This links can also point to files on the local filesystem etc 2. Org-roam ID-Links (version 2) Example: [[ID:123456789][Link description]] 3. Old Org-roam (version 1) links I have never seen them in real world but I assume this are usual to-local-file-links as described in point 1. 4. Roam Links I also have seen links like this [[roam:Foobar][Foobar]] or [[roam:Foobar]] I know them as "placeholders" or dead-links when want to insert a link to an orgroam node that does not exist yet. In my workflow deadlinks like this are like reminders for me that I should create a node. But I am not sure what type of link this is in other situations. Am I right here? Did I miss something? Please feel free to correct the names of the link types and correct my explanation. Kind Christian
[BUG] org-mode #+SETUPFILE not working with properties [9.5.2 (release_9.5.2-378-g98588e @ /home/eros/src/org-mode/lisp/)]
Given this file
:PROPERTIES:
:header-args:sh: :var A="this is a"
:END:
#+begin_src sh
echo ${A}
#+end_src
#+RESULTS:
: this is a
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.
***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:
[1]: https://emacs.stackexchange.com/a/59059/36590
Emacs : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.17.6)
of 2022-04-04
Package: Org mode version 9.5.2 (release_9.5.2-378-g98588e @
/home/eros/src/org-mode/lisp/)
Re: Cursor stays TODO creation
> Ihor Radchenko writes: > Colin Baxter writes: >> With the latest org-mode, if I set a TODO keyword then after its >> creation the cursor stays to the left of "T". In the past it >> would move one space beyond the "O". Is this a new feature? If it >> is then it's a nuisance. > Thanks for reporting! Fixed in 1ed9e4223. Great, I can confirm that it's fixed for me. Thank you. Best wishes, Colin Baxter.
Re: [the culprit]
>>> "JK" == John Kitchin writes: > This seems like something that could (should?) go in a personal config, as > a custom function, or advice. > You could, for example do something like this (lightly tested) > #+BEGIN_SRC emacs-lisp > (defun my-put (property value here) > (interactive (list nil nil current-prefix-arg)) > (if (null here) > (org-set-property property value) > (let* ((property (or property (org-read-property-name))) > (value (or value (org-read-property-value property > (save-excursion > (beginning-of-line) > (search-forward ":") > (backward-char) > (insert (format ":%s: %s\n" property value)) > #+END_SRC Thanks very much. I will test it and report back as soon as possible. smime.p7s Description: S/MIME cryptographic signature
Re: Cursor stays TODO creation
Colin Baxter writes: > With the latest org-mode, if I set a TODO keyword then after its creation > the cursor stays to the left of "T". In the past it would move one space > beyond the "O". Is this a new feature? If it is then it's a nuisance. Thanks for reporting! Fixed in 1ed9e4223. This is not a new feature but a result of major change in folding machinery. If you see other changes from usual behaviour, please report them. Things should not behave differently compared to earlier, except what is listed in "Users experiencing performance issues can use new folding backend" (ORG-NEWS). Best, Ihor
Cursor stays TODO creation
Hello, With the latest org-mode, if I set a TODO keyword then after its creation the cursor stays to the left of "T". In the past it would move one space beyond the "O". Is this a new feature? If it is then it's a nuisance. Best wishes, Colin Baxter.
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
I quietly followed the conversation. Thank you for the advice. On Wed, Apr 27, 2022 at 9:06 AM Ignacio Casso wrote: > > Ihor Radchenko writes: > > > Ignacio Casso writes: > > > >>> A better approach could be using org-link-expand-abbrev. It is an API > >>> function and should be forward-compatible. > >> > >> Do you mean something like this? > >> > >> (defun org-open-at-point-global () > >> ... > >> (cond ((org-in-regexp org-link-any-re) > >> (org-link-open-from-string > >> (org-link-expand-abbrev (match-string-no-properties 0 > >> ...)) > >> > >> Right now that is not enough because `org-link-expand-abbrev' only works > >> for links without square brackets, like "abbrev:suffix", and > >> `org-link-any-re' matches links with square brackets, like > >> "[[abbrev:suffix]]". That could be easily worked around in > >> `org-open-at-point-global' but maybe it would be better to change > >> `org-link-expand-abbrev' to work with both forms. > > > > Fair point. Then, the most future-proof way would be calling > > org-element-link-parser. It should take care about abbrev expansion and > > other edge cases. Then, you just need to use :raw-link property of the > > parsed link element. > > > > Best, > > Ihor > > And then we come full circle, since that is what is being done already > but in a temporal buffer (so without access to > `org-link-abbrev-alist-local'), and your original concerns in your first > reply apply: doing it inside `org-open-at-point' would duplicate a lot > of code. > > So I guess the issue is not as orthogonal as I though with the one of > the parser and it would be complicated to fix it properly, as you said > in your first email. If no one else has reported this problem or replied > to this thread, I guess that probably the best thing to do is fixing > this in my own config and move on for now: > > I'll copy here the advice that fixes it, in case anyone needs to add it > to their config too: > > (defun my-advice (orig-fun args) > (let ((org-link-abbrev-alist > (append org-link-abbrev-alist org-link-abbrev-alist-local))) > (apply orig-fun args))) > > (advice-add 'org-open-at-point-global :around 'my-advice) > > Best regards, and thanks for taking a look at this, > > --Ignacio > >
Re: [PATCH] Add missing `provide' in ob-octave test
Nick Dokos writes:
> `make test' has been failing for me with this error:
>
> ,
> | Error: error ("Loading file
> | /home/nick/src/emacs/org/org-mode/testing/lisp/test-ob-octave.el
> | failed to provide feature ‘test-ob-octave’")
> `
>
> The attached patch provides a fix.
Thanks! Applied to main as 98a771cc3.
Best,
Ihor
Re: [PATCH] Fix examples of clock tables in the manual
Nick Dokos writes: >> Note that you may need to add TINYCHANGE cookie as you appear to not >> have the copyright assignment with FSF. >> > > I'm in there (under "Nicholas Dokos"). I should have searched by surname :facepalm: >> Also, your current patch does not apply onto main: >> Applying: Fix examples of clock tables in the manual error: corrupt patch at line 10 >> > > Mailer mangled it - let me try attaching. > > Hope this is better. Thanks! Thanks! Applied to main as e359b01a6. Best, Ihor
Re: [PATCH] update ob-scheme to latest changes in geiser package
Tim Van den Langenbergh writes: > I have taken the liberty of reformatting the patch you created for ob-scheme. > You can find it enclosed. Thanks! Since Felipe has no objections, your patch should be good to apply. > If it is fine with you and the org-mode maintainers it can be applied as-is, > particularly since it is a tiny change. > I have also added some additional information to the commit message, such as > when the `geiser-eval-region/wait' function was introduced. Could you kindly add the geiser version info as a comment inside code? Commit message is an unlikely place to be checked regularly and be noticed as geiser is updated in future. Comments are generally preferred over commit messages: https://orgmode.org/worg/org-contribute.html#commit-messages -> -> https://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE >> - Explaining the rationale for a design choice is best done in comments >> in the source code. However, sometimes it is useful to describe just >> the rationale for a change; that can be done in the commit message >> between the summary line and the file entries. Best, Ihor
Re: [BUG] buffer displays incorrectly after capture
Skip Collins writes: > I think this is a real bug. Am I wrong? Seems like it should be easy to fix. Fixed in 2d6f26c05 on main. And no, it was not that easy to fix. Captured headlines may or may not need to be unfolded. Best, Ihor
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
Thanks for reporting that. Fixed in Emacs master via the attached. For the more general issue I'm planning to add a builtin boolean variable current-time-list soon, that is t for (HIGH LOW MICROSEC PICOSEC) format, nil for (TICKS . HZ) format.From 3abb3681b57d7c8ca7fa808addb0a10b6b109cab Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 27 Apr 2022 00:29:26 -0700 Subject: [PATCH] Use org-time-convert-to-integer instead of by hand MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org/org-macs.el (org-file-newer-than-p): Don’t assume list-format timestamps, by using org-time-convert-to-integer instead of doing it by hand. --- lisp/org/org-macs.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org/org-macs.el b/lisp/org/org-macs.el index b10725bd52..92591b5bb7 100644 --- a/lisp/org/org-macs.el +++ b/lisp/org/org-macs.el @@ -257,15 +257,16 @@ org-fit-window-to-buffer (defun org-file-newer-than-p (file time) "Non-nil if FILE is newer than TIME. -FILE is a filename, as a string, TIME is a list of integers, as +FILE is a filename, as a string, TIME is a Lisp time value, as returned by, e.g., `current-time'." (and (file-exists-p file) ;; Only compare times up to whole seconds as some file-systems ;; (e.g. HFS+) do not retain any finer granularity. As ;; a consequence, make sure we return non-nil when the two ;; times are equal. - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) - (cl-subseq time 0 2) + (not (time-less-p (org-time-convert-to-integer + (nth 5 (file-attributes file))) + (org-time-convert-to-integer time) (defun org-compile-file (source process ext err-msg log-buf spec) "Compile a SOURCE file using PROCESS. -- 2.32.0
Re: [tip] Org speed commands improved
Hi Ihor, Ihor Radchenko writes: > If you are going this far with speed commands, you might as well switch > to modal editing. What you are describing is basically a modal command > map with ability to switch to insert map. I'm not a fan of modal editing, rather the opposite. But in this particular case I have found that I spend very little time editing the raw content of the headers, once I set it. I spend more time editing the 'meta-content': TODO states, properties, tags, refile, attached folders, etc. And that with the speed commands can be achieved in a very agile way, so that a small dose of controlled modal editing and reduced only to the header, maybe it's worth it :-) If the speed commands were also activated in the content of the sections, here we would have a real modal editing, and that (in my case) would not be comfortable. Best regards, Juan Manuel
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >>> A better approach could be using org-link-expand-abbrev. It is an API >>> function and should be forward-compatible. >> >> Do you mean something like this? >> >> (defun org-open-at-point-global () >> ... >> (cond ((org-in-regexp org-link-any-re) >> (org-link-open-from-string >> (org-link-expand-abbrev (match-string-no-properties 0 >> ...)) >> >> Right now that is not enough because `org-link-expand-abbrev' only works >> for links without square brackets, like "abbrev:suffix", and >> `org-link-any-re' matches links with square brackets, like >> "[[abbrev:suffix]]". That could be easily worked around in >> `org-open-at-point-global' but maybe it would be better to change >> `org-link-expand-abbrev' to work with both forms. > > Fair point. Then, the most future-proof way would be calling > org-element-link-parser. It should take care about abbrev expansion and > other edge cases. Then, you just need to use :raw-link property of the > parsed link element. > > Best, > Ihor And then we come full circle, since that is what is being done already but in a temporal buffer (so without access to `org-link-abbrev-alist-local'), and your original concerns in your first reply apply: doing it inside `org-open-at-point' would duplicate a lot of code. So I guess the issue is not as orthogonal as I though with the one of the parser and it would be complicated to fix it properly, as you said in your first email. If no one else has reported this problem or replied to this thread, I guess that probably the best thing to do is fixing this in my own config and move on for now: I'll copy here the advice that fixes it, in case anyone needs to add it to their config too: (defun my-advice (orig-fun args) (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) (apply orig-fun args))) (advice-add 'org-open-at-point-global :around 'my-advice) Best regards, and thanks for taking a look at this, --Ignacio
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
The change also breaks org-file-newer-than-p function that triggered the debugger while loading my init that uses org babel. I was able to use the example of the patch that Paul Eggert provided earlier for the desktop-save to add the time-convert to “fix” org-file-newer-than-p as shown below. Not positive that I needed to change it in both places, but it works for me now on macOS Monterey. modified lisp/org/org-macs.el @@ -264,8 +264,8 @@ org-file-newer-than-p ;; (e.g. HFS+) do not retain any finer granularity. As ;; a consequence, make sure we return non-nil when the two ;; times are equal. - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) -(cl-subseq time 0 2) + (not (time-less-p (cl-subseq (time-convert (nth 5 (file-attributes file)) 'list) 0 2) +(cl-subseq (time-convert time 'list) 0 2)
