Re: [FR] Should we preserve point when calling `org-open-at-point' (C-c C-o) on a heading (was: [BUG] Point position with org-open-at-point on a heading [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/
Hi Ihor, On Sat, 23 Sept 2023 at 05:32, Ihor Radchenko wrote: > > I see no particular reason. > Thanks for the reply. > +1. > But maybe others have objections. And for the support. :-) Best, Gustavo.
Re: [BUG] org-element-context doesn't recognize link inside property drawer [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]
Hi Ihor, On Sat, 23 Sept 2023 at 05:28, Ihor Radchenko wrote: > > Gustavo Barros writes: > > > When a link is placed as a property value, `org-element-context' does > > not recognize it as a link. > > It is expected and intentional: > https://list.orgmode.org/orgmode/877d8llha9@nicolasgoaziou.fr/. > > > In particular, the "link" element is not present, as would be the case > > if the exact same link were not inside the property drawer. On the > > other hand, the link is active (fontified, works, etc.). Thus, > > `org-element.el` and `ol.el` seem to disagree as to what that part of > > the buffer actually is. > > This is intentional. org-agenda and fontification deliberately recognize > links in more contexts compared to org-element and export. Same for > timestamps. For example, see `org-at-timestamp-p'. > > For ol.el, the links are open inside property drawer for convenience. > Below is a code responsible for this case from `org-open-at-point': > >;; No valid link at point. For convenience, look if something >;; looks like a link under point in some specific places. >((memq type '(comment comment-block node-property keyword)) > (call-interactively #'org-open-at-point-global)) I didn't know that. Thanks for the detailed answer. Best, Gustavo.
Re: [BUG] org-element-context doesn't recognize link inside property drawer [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]
On Fri, 22 Sept 2023 at 15:11, Gustavo Barros wrote: Sorry, some poor copy-paste from my part on the original report. The following... > (Setting `eval-expression-print-level' and > `eval-expression-print-length' to nil). ... was meant to come after: > Placing point on the link and calling `(org-element-context)' returns: It doesn't make sense where it was placed.
[BUG] Point position with org-open-at-point on a heading [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]
Hi All,
When point is on a heading, `org-open-at-point' offers to open links
in the subtree. This is a very useful feature, and I use it a lot.
However, in this case, `org-open-at-point' not only opens the link,
but also moves point to said link. Perhaps there's some reason why
point is not preserved in this case. But for me at least, this is not
what I'd expect, and I find it somewhat disrupting, especially when
I'm working on a folded tree (defeats speed keys, etc.).
A simple test file to reproduce the described behavior:
#+begin_src org
,* Heading
Foo.
https://orgmode.org/
Bar.
#+end_src
How about adding a `save-excursion' for this case inside `org-open-at-point'?
Best regards,
Gustavo.
Emacs : GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
of 2023-07-30
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/local/share/emacs/29.1/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change
org-cycle-display-inline-images)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-fold-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-persist-directory "/tmp/org-persist-IhBaHK"
org-fold-core-isearch-open-function 'org-fold--isearch-reveal
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link :insert-description
org-info-description-as-command)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("doi" :follow org-link-doi-open :export
org-link-doi-export)
("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302 Q \"\207"
["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("mailto" :follow
#[514 "\301\300\302 Q \"\207"
["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("https" :follow
#[514 "\301\300\302 Q \"\207"
["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("http" :follow
#[514 "\301\300\302 Q \"\207"
["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("ftp" :follow
#[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"]
[BUG] org-element-context doesn't recognize link inside property drawer [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]
Hi All,
When a link is placed as a property value, `org-element-context' does
not recognize it as a link.
(Setting `eval-expression-print-level' and
`eval-expression-print-length' to nil).
Consider the following document:
#+begin_src org
,* Heading
:PROPERTIES:
:LINK: [[https://orgmode.org/][Org mode for Emacs]]
:END:
#+end_src
Placing point on the link and calling `(org-element-context)' returns:
#+begin_src emacs-lisp
(node-property
(:key "LINK"
:value "[[https://orgmode.org/][Org mode for Emacs]]"
:begin 24
:end 76
:post-blank 0
:post-affiliated 24
:mode node-property
:granularity element
:cached t
:parent
(property-drawer
(:begin 11
:end 82
:contents-begin 24
:contents-end 76
:post-blank 0
:post-affiliated 11
:mode planning
:granularity element
:cached t
:parent
(section
(:begin 11
:end 82
:contents-begin 11
:contents-end 82
:robust-begin 11
:robust-end 80
:post-blank 0
:post-affiliated 11
:mode section
:granularity element
:cached t
:parent
(headline
(:raw-value "Heading"
:begin 1
:end 82
:pre-blank 0
:contents-begin 11
:contents-end 82
:robust-begin nil
:robust-end nil
:level 1
:priority nil
:tags nil
:todo-keyword nil
:todo-type nil
:post-blank 0
:footnote-section-p nil
:archivedp nil
:commentedp nil
:post-affiliated 1
:LINK "[[https://orgmode.org/][Org mode for Emacs]]"
:title "Heading"
:mode first-section
:granularity element
:cached t
:parent
(org-data
(:begin 1
:contents-begin 1
:contents-end 82
:end 82
:robust-begin 3
:robust-end 80
:post-blank 0
:post-affiliated 1
:path "~/test.org"
:mode org-data
:CATEGORY "test"
:cached t))
#+end_src
In particular, the "link" element is not present, as would be the case
if the exact same link were not inside the property drawer. On the
other hand, the link is active (fontified, works, etc.). Thus,
`org-element.el` and `ol.el` seem to disagree as to what that part of
the buffer actually is.
Best regards,
Gustavo.
Emacs : GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
of 2023-07-30
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/local/share/emacs/29.1/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change
org-cycle-display-inline-images)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-fold-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-persist-directory "/tmp/org-persist-DRjSU9"
org-fold-core-isearch-open-function 'org-fold--isearch-reveal
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
[BUG] org-todo on region fails to log changed state [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/29.1/lisp/org/)]
Hi All,
When setting Org to track TODO state changes, calling `org-todo' on an
active region comprising multiple headings, the state changes only
logged for the last heading.
To reproduce with `emacs -Q', visit the file:
#+begin_src org
,#+todo: TODO(t) | DONE(d!)
,* TODO Task 1
,* TODO Task 2
,* TODO Task 3
#+end_src
Select a region including all three tasks, call `org-todo' with "C-c
C-t", and mark them as DONE. The state changes are only logged for
Task 3. Whereas, if you call `org-todo' on each task individually,
the state change is logged, as expected.
Best regards,
Gustavo.
Emacs : GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
of 2023-07-30
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/local/share/emacs/29.1/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change
org-cycle-display-inline-images)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-fold-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-persist-directory "/tmp/org-persist-FCOctd"
org-fold-core-isearch-open-function 'org-fold--isearch-reveal
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow
:complete org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow org-eww-open
:store org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link
:insert-description org-info-description-as-command)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("doi" :follow org-link-doi-open :export
org-link-doi-export) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302 Q \"\207" ["news" browse-url ":"] 6
"\n\n(fn URL ARG)"])
("mailto" :follow
#[514 "\301\300\302 Q \"\207" ["mailto" browse-url ":"] 6
"\n\n(fn URL ARG)"])
("https" :follow
#[514 "\301\300\302 Q \"\207" ["https" browse-url ":"] 6
"\n\n(fn URL ARG)"])
("http" :follow
#[514 "\301\300\302 Q \"\207" ["http" browse-url ":"] 6
"\n\n(fn URL ARG)"])
("ftp" :follow #[514 "\301\300\302 Q \"\207" ["ftp"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("help" :follow org-link--open-help :store org-link--store-help)
("file" :complete org-link-complete-file) ("elisp"
:follow org-link--open-elisp))
org-metaup-hook '(org-babel-load-in-session-maybe)
)
Re: How to disable org-persist in a given file?
On Wed, 3 May 2023 at 07:55, Ihor Radchenko wrote: > This was actually just an omission in `org-persist-gc'. > Now fixed on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e11073d17 Thank you! > But do not create so much sense of urgency here. As I explained, this is > not something that much critical to fix ASAP. Fair, I won't anymore. Best, Gustavo.
Re: How to disable org-persist in a given file?
On Tue, 2 May 2023 at 17:54, Ihor Radchenko wrote: > I think `recentf-save-file' for example is no different. And > org-id-locations-file. And custom-file, if you happen to save safe > buffer-local variables by answering "!" in Emacs prompt. And many many > other places. Those two are easy to avoid, if one wishes. But granted, there are plenty of places, some keeping file names, some worse. Still, this is arguably something to avoid. > I do not think that file name, even from encrypted volume, is something > we need to worry about. Granted too. What I'm worried about is being able to disable the feature. Besides, why store it in the index if the persist file does not exist? > I even suspect that, for example, browser cache often contains all kinds > of secrets, like files associated with web pages were you logged in. And > they can be read by anyone familiar with the layout! (like > https://www.nirsoft.net/utils/chrome_cache_view.html) I really hope that's not Org's benchmark. ;-) > That said, do not worry about this issue being forgotten. But it is not > easy to design cleanly. I am thinking about it. > Of course, if you have good ideas or patches, they are welcome. Thank you! Best, Gustavo.
Re: How to disable org-persist in a given file?
On Tue, 25 Apr 2023 at 07:52, Gustavo Barros wrote: > My view is that there really should be a way of doing it. Because this > has relevant security implications. And because users should be able > to have control of their data in the first place. And then if one such > a feature, necessarily requiring persistence (as opposed to the > convenience of "just" speeding things up), a user-error could be > signaled saying "sorry, can't do that because you disabled > persistence". And the two cases you mentioned seem quite the exception > to me. Of course, I'm speaking here about writing information about / > of the org file itself to an external file, naturally internet > downloads must go somewhere and that should be easy. The thing is Org > is used for a lot of things. You can rest assured I have no intention > of exporting my encrypted files alongside some remote content. But I > do wish to be able to make sure my passwords are safe. For the record, even ".org.gpg" files generate an entry in the cache index. (True, not the `:persist-file' itself though). My ~/.cache/org-persist/index contains: (:container ((elisp org-element--headline-cache) (elisp org-element--cache)) :persist-file "c8/fd2b62-45cc-41c8-8571-d944c76b1f15" :associated (:hash "7fd2d95e0f9239939598e7a9b8d5a273" :file "/path/to/myfile.org.gpg" :inode 41551881) :expiry 30) Please, please, be reasonable about this. Please, do not store information about known encrypted files in other places. Please, allow users to disable the feature cleanly and safely for arbitrary files if they choose to. Best, Gustavo.
Re: How to disable org-persist in a given file?
On Tue, 25 Apr 2023 at 07:21, Ihor Radchenko wrote: > > I don't understand that. Isn't persistence about keeping data across > > Emacs sessions? > > Not only. We also use org-persist to cache downloaded images from > internet and, in future, to cache image previews (currently, they just > sit in `org-preview-latex-image-directory'). These scenarios make use of > org-persist during a single Emacs session, not just across several > sessions. I see. But, for uses where the data is only required during a session, does the cache have to be written to an external file? But I think I get why write it for the previews, and obviously, for downloads too. I'm not sure this should be called "persistence" though. > Even if we allow completely disabling persistence for certain files, > previews, and internet downloads should happen _somewhere_ in file system > and might inevitably cause leakage. But what is the way around? My view is that there really should be a way of doing it. Because this has relevant security implications. And because users should be able to have control of their data in the first place. And then if one such a feature, necessarily requiring persistence (as opposed to the convenience of "just" speeding things up), a user-error could be signaled saying "sorry, can't do that because you disabled persistence". And the two cases you mentioned seem quite the exception to me. Of course, I'm speaking here about writing information about / of the org file itself to an external file, naturally internet downloads must go somewhere and that should be easy. The thing is Org is used for a lot of things. You can rest assured I have no intention of exporting my encrypted files alongside some remote content. But I do wish to be able to make sure my passwords are safe.
Re: How to disable org-persist in a given file?
On Sun, 23 Apr 2023 at 11:19, Ruijie Yu wrote: > Side track: remember that you have `always' and `ignore' in your > collection of functions. :) Somehow I wasn't aware of `always'. Thanks! Gustavo.
Re: How to disable org-persist in a given file?
On Sun, 23 Apr 2023 at 10:51, Ihor Radchenko wrote: > We can try (string-match mounted-file-systems default-directory). > Will it work with your setup? Wouldn't that exclude a lot of legitimate use cases? Personally, I don't see an issue in this scenario of mine for Org to handle. It's an exception I must handle. > We cannot just disable persistence completely. > For example, remote image export relies on persistence to be working > _during_ Emacs session. > > What about file/directory-local variable that will redirect where to > save cache? I don't understand that. Isn't persistence about keeping data across Emacs sessions? Redirecting the cache is useful too. But, imho, there should be a way to disable persistence altogether for sensitive data (or, at least, any storage of data in other files, since I don't get what you mean by persistence during a session). If `org-persist-before-write-hook' does this, as I understand it does, adding a function there which just returns the value of a variable defaulting to nil and safe-local if booleanp, would be enough, wouldn't it? Or what am I missing? > I think we can add a section near "Code Evaluation and Security Issues". That would be appreciated, thank you. Best, Gustavo.
Re: How to disable org-persist in a given file?
Hi Ihor, On Sun, 23 Apr 2023 at 07:55, Ihor Radchenko wrote: > Thanks for letting us know about this scenario! Yes, but there's little Emacs/Org can do there, I think. Once the volume is mounted, there's no way to tell it is meant to be treated as an encrypted file. With time I'm learning that non-standard setups, while they may seem attractive at first, come and bite you sooner or later. Not necessarily because they are technically flawed, but because it breaks people's expectations. I do have some unusual partitioning scheme, and sometimes it becomes an uphill battle to avoid leakages. On Emacs alone, I have to take special care of backups, bookmarks (that's now fixed on 29), trash, and now cache. > You can use `org-persist-before-write-hook' to disable writing > selectively. Thanks! That's the one. Though it would be nice if a variable existed for the purpose. `(add-hook 'org-persist-before-write-hook (lambda ( _args) t) nil t)' is not our average file local variable. :) > You can refer to the comment in org-persist.el for explanation about the > core concepts about CONTAINER and ASSOCIATED terms. > > Let us know if you have difficulties understanding the commentary or if > you think that things can be improved. I took a closer look at it now, and I think it is clear. But I do have a suggestion. I've seen the use of `org-persist' by `org-element' by default announced in the news file. But I think this would deserve an entry in the manual (as far as I can tell, currently there isn't one, but I'm running built-in on 29, so I might be out of date), letting people know it is enabled by default, and how to opt out, if they want to. As my scenario above shows, there's little hope of being able to cover "all cases", and people must take care of that for themselves within reason. All Org can do is let people know, and on security related issues, better be outspoken than shy. And thank you very much for this nice feature! Best, Gustavo.
How to disable org-persist in a given file?
Hi All, this is more of a question really. I moved recently to the new pretest version of Emacs and thus got the 9.6 version of Org. And after that I started to notice some saving by `org-persist' going on, and indeed I have a new associated "~/.cache/org-persist/" directory. However, I do have some Org files which contain sensitive data. I'd like to be able to disable persistence in those files. Now, some of them are ".org.gpg" files, and I've seen the sources of `org-persist' and noticed persistence is inhibited for them. But I also do have some encrypted loop devices which, once opened, have a "plain" .org file there. I've greped the sources, and I see that `org-element' is making use of `org-persist'. I've also seen the release notes, and that `org-element' makes available `org-element-cache-persistent'. However, taking a look at `org-persist's API, I couldn't find any obvious handle to disable persistence there. Everything I've seen presumes I have knowledge of registered "containers", which I don't. Is currently `org-element' the only part of Org using persistence by default? Is there some way to inhibit `org-persist' altogether in a given file? (As opposed to just inhibiting `org-element' use of it with `org-element-cache-persistent'). Best regards, Gustavo.
Re: [BUG] org-latex-packages-alist type specification [9.6.3 (release_9.6.3-2-gf2949d @ /usr/local/share/emacs/29.0.90/lisp/org/)]
On Sat, 22 Apr 2023 at 10:27, Ihor Radchenko wrote: > > Ruijie Yu writes: > > > Subject: [PATCH] * lisp/org.el org-latex-packages-alist: fixed type > > definition > > Applied, onto bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=14dccff8b Thank you all!
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
On Thu, 13 Apr 2023 at 12:47, Ihor Radchenko wrote: > I suspect that it might be Emacs problem. Ok, you win, done: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62847 Best, Gustavo.
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi Ihor, On Thu, 13 Apr 2023 at 12:10, Ihor Radchenko wrote: > Basically, we need to bring Emacs devs in. Because I have no clue what > is going on. And reporting to Emacs bug tracker is the way to involve > Emacs devs. I get that. But please look at it from my perspective too. This is a reiteration of a previous report. Now you are asking me to make a third one, which would have to start from scratch. Also, if Emacs devs are requested to chime in by Org devs it is different from "just another user's report". Besides, I don't even understand why you say this is an Emacs problem, so I'd be at a loss at even trying to explain what the general problem is. Best, Gustavo.
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi Ihor, On Thu, 13 Apr 2023 at 11:52, Ihor Radchenko wrote: > I inspected `mode-name'. > I tried harder, and I was able to reproduce using literally emacs -Q. Thanks, and I'm glad to know I'm not crazy then. > It looks like Emacs bug then. I suspect some funny staff going on during > compilation. > May you report it to Emacs bug tracker, linking to this bug report? Mhm, I don't know why you say it is an Emacs bug. From my side, it only affects Org Agenda. So I've reported it to Org. Besides, it would be a legitimate place to report this even if it was a more general issue. Best regards, Gustavo.
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi Ihor, On Thu, 13 Apr 2023 at 11:24, Ihor Radchenko wrote: > > Gustavo Barros writes: > > > For the record, I'm trying the new Emacs pretest with Org 9.6.3 and > > the `mode-name` is still has the propertized space and, in some > > situations (e.g. `org-tags-view`) the blank gap in the mode line still > > creeps in for me. > > I still cannot reproduce on bugfix. thanks for checking this again. When you say you can't reproduce you mean that you get no blank gaps in the mode line, or that, if you inspect `mode-name`, the space is not propertized? (Just tested the latter and I do find it propertized even in `emacs -Q`). Best, Gustavo.
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi All, On Sat, 22 Oct 2022 at 07:51, Gustavo Barros wrote: > > On Sat, 22 Oct 2022 at 04:14, Ihor Radchenko wrote: > > > I am unable to reproduce with the latest Org. > > thanks for checking this report. > I've retested things here and, though I can still reproduce it with > Org 9.5.5, I can confirm the issue is gone on 9.6-pre with the latest > commit on master. > Lucky us! :-) For the record, I'm trying the new Emacs pretest with Org 9.6.3 and the `mode-name` is still has the propertized space and, in some situations (e.g. `org-tags-view`) the blank gap in the mode line still creeps in for me. Best regards, Gustavo.
[BUG] org-latex-packages-alist type specification [9.6.3 (release_9.6.3-2-gf2949d @ /usr/local/share/emacs/29.0.90/lisp/org/)]
Hi All,
I'm testing here the new pretest for Emacs 29, and I noticed a small
problem in the type specification of the `org-latex-packages-alist'
defcustom.
The docstring states that each element of the alist is composed of up
to four elements, but the type specification comprises just the first
three.
So, if you use the new `setopt' to set it, and the variable includes
something like `("AUTO" "babel" t ("pdflatex"))', you get a
warning somewhat like:
#+begin_example
Warning (emacs): Value ‘(("final" "microtype" nil) ("" "soul" t) (""
"booktabs" nil) ("AUTO" "babel" t ("pdflatex")) ("autostyle"
"csquotes" nil) "\\MakeAutoQuote{“}{”}" ("" "enumitem" nil)
"\\setlistdepth{8}" "\\renewlist{itemize}{itemize}{8}"
"\\setlist[itemize,1,5]{label=\\textbullet}"
"\\setlist[itemize,2,6]{label=$\\circ$}"
"\\setlist[itemize,3,7]{label=\\textasteriskcentered}"
"\\setlist[itemize,4,8]{label={\\normalfont\\bfseries
\\textendash}}")’ does not match type (repeat (choice (list :tag
options/package pair (string :tag options) (string :tag package)
(boolean :tag Snippet)) (string :tag A line of LaTeX)))
#+end_example
Some testing here shows the offending entry is the one with the fourth
element, that of `babel'.
Best regards,
Gustavo.
Emacs : GNU Emacs 29.0.90 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
of 2023-04-10
Package: Org mode version 9.6.3 (release_9.6.3-2-gf2949d @
/usr/local/share/emacs/29.0.90/lisp/org/)
Re: [FR] Don't hardcode checker functions prefix in org-lint
Hi All, On Tue, 10 Nov 2020 at 17:22, Gustavo Barros wrote: > This is a small feature request for `org-lint' not to hardcode the > checker functions' prefix, as it currently does. > > [...] > > However, `org-lint' hardcodes the prefix of the checker functions to its > own prefix, so that to define my own personal checker functions I have > to step on `org-lint's namespace, and use "org-lint-" as a prefix, to > get things working. The hardcoding occurs in > `org-lint--generate-reports', when each checker is called with: I'm trying out the new pretest and I was glad to find out that the function property for `org-lint-checker` has been exposed in the `cl-defstruct` at `org-lint.el`. I have no idea if this request had anything to do with it. But, regardless, to whoever did it, thank you! Best regards, Gustavo.
Re: Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi Ihor, On Mon, 24 Oct 2022 at 01:21, Ihor Radchenko wrote: > I am unable to reproduce your recipe on the latest Org main. Indeed, I can confirm! True, the empty line between the headings still goes missing, but there's no longer structural change which was the real problem. And, sorry for the noise. I had assumed that for such an old one the latest release was good enough approximation, it turned out it wasn't. > Note that we have several capture-related fixed on main but not on > stable Org 9.5.5. I was tempted to call the "lucky us" card again, but twice in a row makes it unlikely. It seems that what's really going on is folks working hard for the upcoming release, which is much appreciated. :-) Thank you all! And particularly to whoever got this one fixed. Best regards, Gustavo.
Re: [BUG] org-link-descriptive not honored as file-local-variable [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Mon, 24 Oct 2022 at 01:52, Ihor Radchenko wrote: > This is because setting things up for links is a part of Org loading > process. And file-local variables are only loaded after major mode by > Emacs. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003 Ah, I had presumed this one would be a load order issue, and indeed it is a general one. Agreed that this report should stay on standby until it's been decided what to do in general terms. And thank you for raising the issue in the Emacs list. Good discussion, btw. Best regards, Gustavo.
Re: Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi All, On Sun, 28 Jul 2019 at 16:34, Gustavo Barros wrote: > When the capture template ends with a newline character and the capture > process is canceled, the following heading gets demoted. And it > shouldn’t. a respectful bump on this one. I can still reproduce this with Emacs 28.2 and Org 9.5.5. Best regards, Gustavo.
Re: [BUG] org-link-descriptive not honored as file-local-variable [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All, On Fri, 29 Oct 2021 at 15:53, Gustavo Barros wrote: > Currently, trying to set `org-link-descriptive' as file-local-variable > is not honored by Org, and doing so, leads to one of mismatched states > between `org-link-descriptive' and the invisibility specs. a respectful bump. Despite the changes made to `org-link-descriptive` by Kyle in a related thread (https://list.orgmode.org/87im4ypu9v@kyleam.com/), the failing recipe in this report can still be reproduced in Org 9.5.5 and Emacs 28.2. Best regards, Gustavo.
Re: Bug: fill-paragraph in Org buffer [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi All, On Mon, 26 Oct 2020 at 14:11, Gustavo Barros wrote: > Calling `fill-paragraph' in an Org buffer may leak paragraph boundaries, > and even heading boundaries, and break document structure. Just an update on this one. I can no longer reproduce it with Emacs 28.2 and Org 9.5.5. Fixed. Best regards, Gustavo.
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi Ihor, On Sat, 22 Oct 2022 at 04:14, Ihor Radchenko wrote: > I am unable to reproduce with the latest Org. thanks for checking this report. I've retested things here and, though I can still reproduce it with Org 9.5.5, I can confirm the issue is gone on 9.6-pre with the latest commit on master. Lucky us! :-) Best regards, Gustavo.
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Mon, 18 Jul 2022 at 14:28, Ihor Radchenko wrote: I feel that you are overcomplicating things a bit. Well, the most important objective of the analysis was to try to figure out if the `todayp' condition was too strict or not. Since your suggested fix implies removing it as well, I take I have you convinced? ;) What if we simply change all the agenda lines if and only if their date in agenda is earlier or equal to the next scheduled time (after repeater is triggered)? I think this is a good condition, better than the one I had devised (considering the span of the agenda and the repetition frequency). As far as I can tell, it will also require parsing the planning info of the entry and consider the relevant cases, but perhaps you are seeing more than I can. And I presume you refer only to repeating tasks, so that the rest of the current conditional (except `todayp') would remain in place. The only case I can think of which might trip a little this condition is a date range, but "date range with repeater" seems corner enough for us not to sweat much over it. One thing to consider is the timing of things and how it affects the conditional. You said "earlier or equal to the next scheduled time (after repeater is triggered)". We are looking at things in `org-agenda-todo' after `org-todo' has done its job, in other words, after the repeater has "stepped". `org-agenda-headline-snapshot-before-repeat' is stored in `org-todo' because there would be no longer any way to retrieve it at this point, but we don't store anything else, as far as I can tell. So, at this point, the current scheduled (dedlined, etc.) time would be "the next/first instance which is *not* done", and hence wouldn't it be "earlier, but not equal, to the next scheduled time"? Another thing for which you might have something in mind, but I don't see how to handle it is that `org-agenda-change-all-lines' can receive the `just-this' argument and that decides whether just the current line gets changed or if all entries with the same marker are looped over. So it's either "this" or "all". Perhaps the version of the conditional you suggested will require change in `org-agenda-change-all-lines' so that it can change "some, according to a given predicate". In sum, all in all, the conditional you suggested sounds very good to me, and a clear improvement relative to the current state of things. And regardless of anything else, it seems we agree that `todayp' is too strict and removing it would be the low hanging fruit in all this. Best, Gustavo.
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Tue, 12 Jul 2022 at 10:46, Ihor Radchenko wrote: Thanks for the detailed analysis! I thank you again for your continued interest in this little report. I dug through the old commits and found where this behaviour has been introduced: Commit 0bbf3a9bd message details the current behaviour and its caveats: Ah! this definetely clears up the intended purpose of the condition. Great dig! As you can see, the todayp condition is avoiding issues with weekly agenda when the same habit is displayed multiple times. The problem you observed is also noted and left unresolved. Ideas how to deal with the described are welcome! I can try to think this trough with you, if you'd like. Since I'm the reporter and bumper, it is fair that I start and try to build a base for it. The TL;DR for what follows is that I think `todayp' is ultimately the "wrong" condition to apply, but is a good *proxy*. Perhaps there's a chance to get to a more correct condition, but I'm not sure. But, even if not, I'd like to argue that the "occurrence at point" may be a better proxy, which would be the condition applied (as far as I can tell, which see) if the `todayp' condition were dropped. The long version: First a preliminary observation. I think the case "noted and left unresolved" in the commit message is somewhat different than the one reported here. Related, of course, but different. Let's consider a hypothetical agenda with the following characteristics: a weekly agenda starting on Monday (fixed), today is Tuesday. Unless stated otherwise, this is the scenario for the examples that follow. A daily repeating task, scheduled for today will appear in the agenda from Tuesday to Sunday. If we move point to the occurrence of that task on, say, Thursday, and mark it done then, we would have the case described in the commit message. I'm not sure it is "unlikely", but we could argue that this is "dubious user input". Now consider the case of a weekly repeating task scheduled for Thursday. This is the case reported here. And I think marking this entry done "ahead of schedule" is arguably more legitimate user input. For once, this entry only appears once in the given agenda view, there is no option to use any other. That said, let's try to be systematic. There are a number of reasons an entry may appear multiple times in an agenda view: A1) The entry is scheduled in a past date, and this past date is also visible in the agenda view. In the example agenda a task scheduled for Monday would appear both Monday, and today, Tuesday. A2) The entry has a deadline in a future date, this future date is visible in the agenda view, and the deadline warning settings are enough to be shown today as well. A task with a deadline for Thursday would appear today, Tuesday, and Thursday. B) The entry is scheduled (deadlined?) to a range of dates. For example, a task scheduled to a range from Thursday to Saturday this week would appear four times in the agenda view, once for the regular schedule and thrice for the range "(N/3)". C) The entry has a repeater whose frequency is higher than the span of the agenda view. A daily task on a weekly view, a weekly task on a monthly view, etc. Of course, a given entry may appear in the agenda multiple times for multiple of these reasons. That's all I can think of. Do you see any other cases? This is a critical question, because the soundness of the argument depends on this list being exhaustive. Anyway, pending on that, let me go on. Now, this bug only affects repeating tasks, because the problem arises only for them because their state in the underlying buffer does not correspond to the "todo change the user has just applied". Indeed, `org-agenda-headline-snapshot-before-repeat' is correspondingly just stored for them, as the name implies. Furthermore, reasons A1, A2 and B, are not specific to repeating tasks, though they affect them too, of course. Reason C is the only one specific to repeating tasks, and is really the only reason I think grants for the case considered in the commit message: Because the same line may be present in other lines in the same weekly agenda, we cannot simply update all lines related to this entry. Indeed, a non-repeating task which appears multiple times in the agenda view (A1, A2, or B), when marked done, is visually changed as such in all occurrences. The same does not happen for a repeating entry because, well, "there might be C (as well?)...". That's the nature of the problem, as far as I can see. And a real one at that. I don't know enough of the agenda machinery to know if among the metadata stored as text properties we would be able to distinguish "C" from the other reasons for a given occurrence of a given entry. It is probably fair to presume it is not possible to distinguish, otherwise Carsten might have leveraged that information. That given, `todayp'
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All, On Fri, 29 Oct 2021 at 21:40, Ihor Radchenko wrote: Gustavo Barros writes: The glitch is that some repeated tasks, when marked done in the Agenda, show no visual feedback that the action has taken place, as usual, and if you refresh the Agenda, they just vanish, which demonstrates the action had indeed taken place in the agenda file, just not shown in the Agenda buffer itself. And, as far as I can tell, this happens to repeated tasks, scheduled in future. For tasks scheduled for today or in the past, they appear to be done as expected. Confirmed Best, Ihor This is a respectful bump on this one. But not to bump empty handed, I did some investigation on this, and I think I know why the problem happens. At `org-agenda-todo' when a task is a repeating one, the value of `org-agenda-headline-snapshot-before-repeat' stored at `org-todo' may or may not replace `newhead' depending on some conditions, which are: #+begin_src emacs-lisp (when (and org-agenda-headline-snapshot-before-repeat (not (equal org-agenda-headline-snapshot-before-repeat newhead)) todayp) (setq newhead org-agenda-headline-snapshot-before-repeat just-one t)) #+end_src So that `newhead' is set to `org-agenda-headline-snapshot-before-repeat' only if `todayp' is non-nil. And, indeed, this seems to be the condition which results in the missing visual feedback reported here. I've tried without it, and it works. (I'm currently using built-in 9.5.2, but I think there's no change in the function to current release 9.5.4 and also, light testing with the latter suggests no change in the reported issue). What I'm not sure is why this condition is there in the first place. That's the only place where the let-bound `todayp' is used in the function, so I may be missing why it exists and the purpose of this condition. But one side-effect of it is that, if you happen to do a repeating task ahead of schedule, you won't see the change of todo state in the agenda. Best regards, Gustavo.
[BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi All,
I'm trying out the pre-release this week, and in thus doing, I met a
particularly strange issue related to Org Agenda's `mode-name'. And one
space in particular, the one that is added before
`org-agenda-current-span'. The `mode-name' for the Agenda is set by
`org-agenda-set-mode-name', and inside it we find:
#+begin_src emacs-lisp
" "
'(:eval (org-agenda-span-name org-agenda-current-span))
#+end_src
Now, this space somehow gets propertized.
A recipe for it. Start `emacs -Q'. Set things up:
#+begin_src emacs-lisp
(setq org-agenda-files '("~/agenda.org"))
(setq eval-expression-print-level nil)
(setq eval-expression-print-length nil)
#+end_src
Let's say =agenda.org= contains:
#+begin_src org
,* TODO Task
SCHEDULED: <2022-02-28 Mon>
#+end_src
Call `M-x org-agenda RET a'. Now examine `mode-name' with `M-:
mode-name RET' to get:
#+begin_src emacs-lisp
("Org-Agenda" "" #(" " 0 1 (todo-state #("TODO" 0 4 (fontified nil
org-category "agenda")) org-habit-p nil priority 1099 warntime nil
ts-date 738214 date (2 28 2022) type "scheduled" org-hd-marker #(moves after insertion) at 1 in agenda.org> org-marker #after insertion) at 24 in agenda.org> face org-scheduled-today
undone-face org-scheduled-today help-echo "mouse-2 or RET jump to Org
file ~/agenda.org" mouse-face highlight done-face org-agenda-done
org-complex-heading-regexp "^\\(\\*+\\)\\(?: +\\(DONE\\|TODO\\)\\)?\\(?:
+\\(\\[#.\\]\\)\\)?\\(?: +\\(.*?\\)\\)??\\(?:[
]+\\(:[[:alnum:]_@#%:]+:\\)\\)?[ ]*$" org-todo-regexp
"\\(DONE\\|TODO\\)" org-not-done-regexp "\\(TODO\\)" dotime time format
(((org-prefix-has-time t) (org-prefix-has-tag nil)
(org-prefix-category-length 12) (org-prefix-has-effort nil)
(org-prefix-has-breadcrumbs nil)) (format " %s %s%s%s" (format "%s" (if
(member category-icon '("" nil)) "" (concat category-icon ""
(get-text-property 0 'extra-space category-icon (format "%-12s" (if
(member category '("" nil)) "" (concat category ":" (get-text-property 0
'extra-space category (if (member time '("" nil)) "" (format "%-12s"
(concat time ""))) (format "%s" (if (member extra '("" nil)) "" (concat
extra " " (get-text-property 0 'extra-space extra)) extra
"Scheduled: " time "" level " " txt #("TODO Task" 0 9 (fontified nil
org-category "agenda" org-heading t)) breadcrumbs nil duration nil
time-of-day nil org-priority-lowest 67 org-priority-highest 65 tags nil
org-category "agenda")) (:eval (org-agenda-span-name
org-agenda-current-span)) "" "" "" " Ddl" " Grid" "" "" "" "" "" "" ""
"" "")
#+end_src
So, it appears that the Org Agenda buffer's properties are somehow
getting to that particular space in `mode-name'. It completely beats me
how it is so but, alas, it is there.
This is a problem because, depending on what the content of your agenda
is, this might result in this space getting some visually distinctive
property. In my case, I get a blank gap in the mode-line at this point.
I couldn't generate a simple ECM that gets this effect. But, at this
point, it should be clear it can happen, given these properties are
there.
This was all tested with the latest pre-release tarball, and the Org
built-in there. (I did not get the mode-line gap with 27.2 and the
latest Org release for the same agendas).
Btw, since we are talking about this particular space in `mode-name', I
always had some qualms with the fact that it is unconditionally added
there, so that we get a double space for Agendas for which `(:eval
(org-agenda-span-name org-agenda-current-span))' results in an empty
string (e.g. a simple todo agenda). Couldn't this space be added there
conditionally there? It is likely trivial to handle it directly in
`org-agenda-span-name' (I know it also used in `org-agenda-list', but an
optional argument could make the distinction). WDYT?
Best regards,
Gustavo.
Emacs : GNU Emacs 28.0.91 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2022-02-26
Package: Org mode version 9.5.2 (release_9.5.2-3-geb9f34 @
/usr/local/share/emacs/28.0.91/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-agenda-files '("~/agenda.org")
org-export-before-parsing-hook '(org-attach-expand-links)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function
[BUG] org-link-descriptive not honored as file-local-variable [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All,
Currently, trying to set `org-link-descriptive' as file-local-variable
is not honored by Org, and doing so, leads to one of mismatched states
between `org-link-descriptive' and the invisibility specs.
An ECM for it. Start ~emacs -Q~ and setup current Org:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.5")
#+end_src
Visit =document.org= containing:
#+begin_src org
[[https://orgmode.org/][Org mode for Emacs]]
# Local Variables:
# org-link-descriptive: nil
# End:
#+end_src
The default value of `org-link-descriptive' is t, and after visiting
this file, the local variable is indeed set (inspect it, and it tells
you it is nil). However, the links are still "descriptive", and
`buffer-invisibility-spec' does contain `(org-link)'. Indeed, if at
that point, you try `org-toggle-link-display', it will fail the first
time, but work the second one.
Possibly related threads:
https://list.orgmode.org/87pmzdhl4b@kenko.localhost.com/
https://list.orgmode.org/orgmode/87lfeqzm3a@gmail.com/
Best regards,
Gustavo.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: Org mode version 9.5 (9.5-g0a86ad @
/home/gustavo/.emacs.d/elpa/org-9.5/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-reveal-start-hook '(org-decrypt-entry)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("doi" :follow org-link-doi-open :export
org-link-doi-export) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow
#[514 "\301\300\302Q\"\207" ["mailto" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("https" :follow
#[514 "\301\300\302Q\"\207" ["https" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("http" :follow
#[514 "\301\300\302Q\"\207" ["http" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow
#[514 "\301\300\302Q\"\207" ["ftp" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("help" :follow org-link--open-help :store
org-link--store-help)
("file" :complete org-link-complete-file)
("elisp" :follow org-link--open-elisp))
org-link-elisp-confirm-function 'yes-or-no-p
)
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Fri, 29 Oct 2021 at 21:40, Ihor Radchenko wrote: Confirmed Thanks for checking and marking. Best, Gustavo.
[BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All,
I've been meeting a small glitch on the Agenda, which had been eluding
me for some time, as it "sometimes works, sometimes doesn't", and I
wasn't being able to recognize the rule for it. So I started keeping
track of it a while, and I was thus able to come up with a ECM. I'm not
sure the "rule" is the one I came up with, since it was based on
inference, but I hope the ECM is reproducible.
The glitch is that some repeated tasks, when marked done in the Agenda,
show no visual feedback that the action has taken place, as usual, and
if you refresh the Agenda, they just vanish, which demonstrates the
action had indeed taken place in the agenda file, just not shown in the
Agenda buffer itself. And, as far as I can tell, this happens to
repeated tasks, scheduled in future. For tasks scheduled for today or
in the past, they appear to be done as expected.
The ECM runs as follows. Start ~emacs -Q~ and setup current Org and the
agenda files:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.5")
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
Where =~/test/agenda.org= contains:
#+begin_src org
,* TODO Foo (scheduled for yesterday)
SCHEDULED: <2021-10-28 Thu +1w>
,* TODO Bar (scheduled for today)
SCHEDULED: <2021-10-29 Fri +1w>
,* TODO Baz (scheduled for tomorrow)
SCHEDULED: <2021-10-30 Sat +1w>
#+end_src
And note the dates relative to today are critical for the ECM to
demonstrate what it intends to. So, if you try this out another day,
shift the schedules as appropriate.
Now, run ~M-x org-agenda~, then "a" to get to the default agenda. And
mark each of these tasks done with "t".
"Foo" and "Bar" appear as "DONE", as usual and expected. "Baz" does
not.
Refresh the agenda, and see they are indeed all gone from this week's
view (hence marked done in the actual file). And indeed, with "f" we
see they are there next week.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: Org mode version 9.5 (9.5-g0a86ad @
/home/gustavo/.emacs.d/elpa/org-9.5/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-agenda-files '("~/test/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("doi" :follow org-link-doi-open :export
org-link-doi-export) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url
":"] 6 "\n\n(fn URL ARG)"])
Re: [BUG] org-return does not honor delete-selection-mode [9.4.6 (release_9.4.6-551-gf70e36 @ /home/gustavo/.emacs.d/lib/org-mode/lisp/)]
Hi Bastien, On Mon, 27 Sep 2021 at 14:50, Bastien wrote: `org-return' currently does not honor `delete-selection-mode'. This should be fixed now, thanks a lot. Thank you! Best, Gustavo.
Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi Bastien, On Sat, 25 Sep 2021 at 17:25, Bastien wrote: Ihor Radchenko writes: And yet another update fixing a typo in previous patch. Applied, thanks! Thank you! Ihor, thank you for the patch! And thanks to all who chimed in. Best, Gustavo.
Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi Ihor, On Sat, 10 Jul 2021 at 10:48, Ihor Radchenko wrote: The breakage was introduced in commit c67037: [c670379adfbdc4883d3cfa230289fd2829993265] Fix `org-agenda-todo' undo behavior when logging (not adding note) The fix is attached. Thank you very much! Best, Gustavo.
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
On Sun, 27 Jun 2021 at 03:31, Bhavin Gandhi wrote: You are right, I actually did a bisect last week and found that change has introduced this behavior. I should have posted that immediately, it would have saved some of your time. No problem. Thanks for confirming you reached the same conclusion. Best, Gustavo.
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi All, On Sat, 26 Jun 2021 at 00:13, Jeff Kowalski wrote: While I don't have a fix for the root issue, I did have a chance to create a lint for LOGBOOK duplicates, as you suggested. Since Jeff put some effort, I went for some too. :-) I did some digging and, as far as I can tell, the commit which introduces the bug is "c670379ad Fix `org-agenda-todo' undo behavior when logging (not adding note)". I tested the ECM initially reported, and I don't find the behavior in commit `b2be3dd0e', but I do find it in `59edcc27c', and what happened in `master' between the two is `c670379ad'. Not a fix, but this should narrow the search down. Best regards, Gustavo.
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi Jeff, On Sat, 26 Jun 2021 at 00:13, Jeff Kowalski wrote: While I don't have a fix for the root issue, I did have a chance to create a lint for LOGBOOK duplicates, as you suggested. It can be found here: Looks good! Thank you very much. Best regards, Gustavo.
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi Jeff, On Wed, 16 Jun 2021 at 23:22, Jeff Kowalski wrote: I can confirm the same is happening here for me with Org mode version 9.4.6 (9.4.6-4-g093c94-elpa @ /home/jeff/.emacs.d/elpa/org-20210607/) on GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2021-06-16 The duplicate LOGBOOK entries also seem to be messing up the graphical display of habit records in the agenda. Deleting the duplicates returns the habit display to expected output. I'd be happy to share details of that symptom, but the root cause seems to clearly be the duplicates in the LOGBOOK Thanks for confirming and for the habits info. So that's what was happening with my consistency graphs. I had indeed been noticing they felt "off", but I eventually reverted to 9.4.4 because of the duplicate entries and forgot about it. It seems then that this got solved for me not by the reverting itself but by me removing the duplicate entries in the LOGBOOK. Would clocking reports be affected too? (I'm not personally an user of clocking, so I don't really know). Perhaps a "lint" for LOGBOOK duplicates would be a good idea alongside with the fix, so that people could go about fixing their data with a little more convenience? Best regards, Gustavo.
Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi Bhavin, On Mon, 14 Jun 2021 at 15:01, Bhavin Gandhi wrote: On Mon, 14 Jun 2021 at 19:10, Gustavo Barros wrote: The marking of repeated tasks as "done" is currently resulting in duplicate entries in the "LOGBOOK" drawer, which is not expected. I don't know exactly when this came to be, but it does not happen in the current built-in version (9.4.4), while it does in the latest release (9.4.6). I was able to reproduce this, and here are my findings as well as a reproducible configuration with only a few settings. Thank you for taking the time to try this out and for confirming you are able to reproduce the issue. (I'm marking this bug confirmed. I'd normally refrain from "self confirming" but, since Bhavin was able to reproduce and I consider this one to be particularly relevant, I made an exception.) Best regards, Gustavo.
Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]
Hi All,
The marking of repeated tasks as "done" is currently resulting in
duplicate entries in the "LOGBOOK" drawer, which is not expected. I
don't know exactly when this came to be, but it does not happen in the
current built-in version (9.4.4), while it does in the latest release
(9.4.6).
An ECM to reproduce the issue is the following.
Start 'emacs -Q' and do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.4.6")
(setq org-log-into-drawer t)
(setq org-log-done 'time)
(setq org-todo-keywords
'((sequence "TODO(t)" "SOMEDAY(s)" "|" "DONE(d!)")
(sequence "NEXT(n)" "WAIT(w@/!)" "|" "CANCELED(c@/!)")))
#+end_src
Visit file =test.org= with contents:
#+begin_src org
,* TODO Foo
SCHEDULED: <2021-06-13 Sun +1d>
#+end_src
Now call "C-c C-t" (`org-todo'), and call the key "d" for "DONE", as per
the above settings. The resulting buffer is:
#+begin_src org
,* TODO Foo
SCHEDULED: <2021-06-15 Tue +1d>
:PROPERTIES:
:LAST_REPEAT: [2021-06-14 Mon 10:27]
:END:
:LOGBOOK:
- State "DONE" from "TODO" [2021-06-14 Mon 10:27]
- State "DONE" from "TODO" [2021-06-14 Mon 10:27]
:END:
#+end_src
Best regards,
Gustavo.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: Org mode version 9.4.6 (9.4.6-gab9f2a @
/home/gustavo/.emacs.d/elpa/org-9.4.6/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-log-done 'time
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO(t)" "SOMEDAY(s)" "|" "DONE(d!)")
(sequence "NEXT(n)" "WAIT(w@/!)" "|"
"CANCELED(c@/!)"))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export
org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs") ("shell" :follow
org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207"
["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("mailto" :follow
#[514 "\301\300\302Q\"\207"
["mailto" browse-url ":"] 6 "\n\n(fn URL
ARG)"]
)
("https" :follow
[BUG] org-return does not honor delete-selection-mode [9.4.6 (release_9.4.6-551-gf70e36 @ /home/gustavo/.emacs.d/lib/org-mode/lisp/)]
Hi All,
`org-return' currently does not honor `delete-selection-mode'. An ECM to
reproduce it is the following.
Start `emacs -Q' and do some setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/lib/org-mode/lisp")
;; Org repo at commit f70e36252
(load-library "org")
(org-version); => "9.4.6"
(delete-selection-mode 1)
(org-mode)
#+end_src
Now select a region and type "RET". The newline is indeed inserted, but
the selected region is not deleted, as would be expected. To compare,
select some region again and type "a".
I don't know when this came to be, but the above ECM was tested on the
current master. The issue is also present for me in the built-in version
of Emacs 27.2, Org 9.4.4.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: Org mode version 9.4.6 (release_9.4.6-551-gf70e36 @
/home/gustavo/.emacs.d/lib/org-mode/lisp/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '((closure
(org--rds reftex-docstruct-symbol
org-element-greater-elements org-clock-history
org-agenda-current-date org-with-time org-defdecode
org-def
org-read-date-inactive org-ans2 org-ans1
org-columns-current-fmt-compiled
org-clock-current-task
org-clock-effort org-agenda-skip-function
org-agenda-skip-comment-trees
org-agenda-archives-mode
org-end-time-was-given org-time-was-given
org-log-note-extra org-log-note-purpose
org-log-post-message org-last-inserted-timestamp
org-last-changed-timestamp
org-entry-property-inherited-from
org-blocked-by-checkboxes
org-state org-agenda-headline-snapshot-before-repeat
org-agenda-start-on-weekday
org-agenda-buffer-tmp-name
org-priority-regexp org-mode-abbrev-table
org-mode-syntax-table buffer-face-mode-face
org-tbl-menu
org-org-menu org-struct-menu org-entities
org-last-state
org-id-track-globally org-clock-start-time
texmathp-why
remember-data-file
org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist calc-embedded-open-mode
calc-embedded-open-formula
calc-embedded-close-formula
align-mode-rules-list org-emphasis-alist
org-emphasis-regexp-components
org-export-registered-backends org-modules
org-babel-load-languages org-id-overriding-file-name
org-indent-indentation-per-level
org-element-paragraph-separate
org-inlinetask-min-level t)
nil
(add-hook 'change-major-mode-hook 'org-show-all
'append
'local)
)
(closure
(org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no
org-babel-tangle-uncomment-comments
org-src-preserve-indentation org-src-lang-modes
org-edit-src-content-indentation
org-babel-library-of-babel
t)
nil
(add-hook 'change-major-mode-hook
#'org-babel-show-result-all 'append 'local)
)
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function '(closure
(org-id-locations
org-agenda-search-view-always-boolean
org-agenda-overriding-header t)
(entry) (cdr (assq :title
entry)))
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
On Mon, 24 May 2021 at 13:34, Bhavin Gandhi wrote: Yes, I have attached an updated patch. Looks good to me. Thank you! We are indeed aligned. The only additional thing I discovered was the reason `org-refile--get-location' works despite having double slashes. That was new for me. Great! Thanks for clearing that up too. Best, Gustavo.
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi Bhavin, On Sun, 23 May 2021 at 15:05, Bhavin Gandhi wrote: Finally after spending a couple of hours, I was able to understand the code of org-refile-get-location \o/. The detailed bug report helped me to understand the issue. I'm attaching a patch here which should fix the problem, it has other details as well. I have tested a few basic scenarios as mentioned in the report. Thank you very much for working on this patch. I couldn't offer it myself (out of my legal bounds) and had gone as far as I was allowed to here, so I'm happy you took it from there. The patch looks good to me, and corresponds to my analysis of the problem and suggested fix. I have only one minor nitpick: you could go with a simple `let' there, instead of a `let*', since we only have one let-bound variable there anyway. About: [...] it has other details as well. As far as I could see, we are very much aligned on the problem and fix. But perhaps I'm missing something, could you elaborate on that? Thanks again. Best, Gustavo.
Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi Bastien, On Thu, 06 May 2021 at 08:53, Bastien wrote: I fixed this in the maint branch, please let me know if you notice any weirdness. It's looking good here now. Thanks again. Best, Gustavo.
Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi Bastien, On Mon, 03 May 2021 at 19:26, Bastien wrote: well, clearly my mind is dull right now - I pushed another better fix, but please report any better solution if you have one. Thank you. No, not really, I just happened to spot an offending case of the previous commit. Unfortunately, I don't have a silver bullet here. Gustavo.
Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi Bastien, On Mon, 03 May 2021 at 17:31, Bastien wrote: Hi Gustavo, Gustavo Barros writes: since some time I've been facing a small annoyance in the agenda, as when I move point in my weekly agenda to a day which is not the first one display and then hit "f" (`org-agenda-later') the agenda buffer is scrolled up, hiding the top of the buffer, even though there is no lack of space in the frame to fit the whole window. Fixed in maint, thanks. Thank you for looking into this. But I think the commit, though indeed avoids the reported undue scrolling, brings other undesired side effects. Usually, `org-agenda-later' will carry over the current day of the week to the next week. If we call it on Thursday, point will be placed on the same week day of the next week. Just calling `(set-window-start nil 1)' there breaks this regularity. It is easy to generate a case where this happens. Just squeeze the height of your window on a "populated" agenda, and choose a day for which that day next week won't fit in the window if position 1 is shown, and call it from there. Perhaps doing so before the call to `org-agenda-find-same-or-today-or-agenda' would be a possibility? (untested) Best, Gustavo.
Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi Bastien,
On Sun, 02 May 2021 at 03:54, Bastien wrote:
Hi Gustavo,
Gustavo Barros writes:
I just tested the fix and, indeed,
`org-insert-heading-respect-content' no longer breaks the structure
of
the first heading. However, if I may add a nitpick, the value of
`org-blank-before-new-entry' does not seem to be honored in this
case.
For default values, a distance of one blank line is ensured to the
next heading.
My understanding is that `org-blank-before-new-entry' will ensure
there is a blank line before the new entry, which is what I see.
Let me know if there is something I miss here. Thanks!
Indeed, that's why I said I'm not sure `org-blank-before-new-entry' is
the culprit here. Still, there is a difference of behavior in that
regard if point is before or after the fist heading. An ECM to
reproduce it is the following.
From the situation ("|" represents point position), call `C-RET':
#+begin_src org
,#+title: Title
|
,* Foo
,* Bar
,* Baz
#+end_src
The result is:
#+begin_src org
,#+title: Title
,* |
,* Foo
,* Bar
,* Baz
#+end_src
Now move point to:
#+begin_src org
,#+title: Title
,*
,* Foo
,* Bar
|
,* Baz
#+end_src
And call `C-RET'. The result is:
#+begin_src org
,#+title: Title
,*
,* Foo
,* Bar
,* |
,* Baz
#+end_src
Not quite sure what is the cause, and also not absolutely sure what
would be expected behavior. Since, if we now place point at:
#+begin_src org
,#+title: Title
,*
,* Foo
|
,* Bar
,*
,* Baz
#+end_src
And call `C-RET', we get:
#+begin_src org
,#+title: Title
,*
,* Foo
,* |
,* Bar
,*
,* Baz
#+end_src
My guess, and this is just a hunch, is that the default value of
`org-blank-before-new-entry', which by default is `auto' for `heading'
is somehow backward looking, and hence has somewhat of a hard time in
making the said "intelligent decision" as to how many blank lines to
include. Particularly before the first heading.
Indeed, I can understand the last case in that perspective, since the
first heading we inserted has no blank line to "Foo", so that when
inserting a new heading between "Foo" and "Bar" if we look right above
"no blank line" is the rule to infer. And, if that first heading is
removed, inserting a new one there, will behave just as it does between
"Bar" and "Baz".
This was all tested with `emacs -Q', version 27.2, and Org commit
3e497bec3. No variables changed, thus out-of-the-box experience.
Anyway, as mentioned, "nitpick" level stuff, since you asked for
testing.
Best regards,
Gustavo.
Re: Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi Bastien, On Sun, 02 May 2021 at 03:30, Bastien wrote: Gustavo Barros writes: This way it would be possible to toggle the markers selectively, as it is done with the links. I'm not sure this is granted, but one reasonable hypothesis why `org-link' was used there in the first place is that some degree of selective toggling of the markers was somehow demanded. Yes, this came to my mind too, but I will refrain from adding this new toggling capability for emphasis markers until people convince us it has to be implemented. I'm fine with that. I have no particular opinion on the matter, I was really just speculating why that might have ended there in the first place. That said, nothing to add here, except: thanks again. Gustavo.
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Bastien, On Sun, 02 May 2021 at 03:29, Bastien wrote: Indeed, I have some code ready for this in an updated version of the patch. So the change won't be that "breaking" but let's still assess whether it will break many configurations. Looks good to me. Thank you. Gustavo.
Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi Bastien, On Sat, 01 May 2021 at 13:02, Bastien wrote: Hi Gustavo, Gustavo Barros writes: I just found a misbehaving of `org-insert-heading-respect-content': when it's called before the first heading in the buffer, it breaks the structure of that fist heading by inserting a new heading on the line the previous heading existed. Fixed with commit fb3030188 in the maint branch, thanks a lot. Please test it and report any problem you may encounter. Thank you very much. I just tested the fix and, indeed, `org-insert-heading-respect-content' no longer breaks the structure of the first heading. However, if I may add a nitpick, the value of `org-blank-before-new-entry' does not seem to be honored in this case. For default values, a distance of one blank line is ensured to the next heading. In the report's ECM, after the fix, the new heading is inserted immediately before it. (I'm not sure it is really `org-blank-before-new-entry' which is at play here, but the behavior is not the same before the first heading than it is after it, with respect to blank lines). Best, Gustavo.
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Bastien, On Sat, 01 May 2021 at 13:24, Bastien wrote: Hi Gustavo, Gustavo Barros writes: I don't know if there is a strong reason to hard-code the set of keys in `org-speed-commands-default'. But, if there isn't, could you consider (somehow) exposing the whole set of `org-speed-commands' to user customization? Well, no, I don't see a strong reason to hard-code the set of speedy keys. See the attached patch, which proposes to use just one option `org-speed-commands'. This would be a breaking change, but I don't think we do otherwise. Would this suit your needs? What do you think about the change? Thank you for seeing to this. Yes, the patch corresponds pretty much to what I had in mind. That's the way I'd go there too. And it's not about my needs here, I can verify it is safe to override the defconst and do so (as indeed I do). I was thinking more of that kind of user which would be uncertain if they could, and might eventually refrain from using a nice feature for framing it an "expert kind of stuff". A possible way to mitigate breakage here can be at hand, since we ended up with a third name (a proper one, btw). You could mark `org-speed-commands-user' as obsolete but keep it, for the due time as usual, and append it to `org-speed-commands' somehow (no need to distinguish them in `org-speed-command-help' though). Those who had overriden `org-speed-commands-default' are on their own, of course, as they shouldn't have done that in the first place. ;-) Best regards, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, On Sat, 01 May 2021 at 17:28, Bastien wrote: Hi Gustavo, Gustavo Barros writes: The Org line commands -- `org-beginning-of-line', `org-end-of-line', and `org-kill-line' -- all take due care for the presence of `visual-line-mode' to do the right thing if it is turned on. However, when `visual-line-mode' is indeed on, the bindings on `visual-line-mode-map' shadow Org's bindings, so that we actually get `beginning-of-visual-line', `end-of-visual-line', and `kill-visual-line' for the usual keybindings, instead of the much nicer specialized Org commands. Fixed in the maint branch with commit ccd513a3c, thanks! Thank you! Gustavo.
Re: Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi Bastien, On Sat, 01 May 2021 at 13:42, Bastien wrote: Hi Gustavo, Gustavo Barros writes: when using `org-hide-emphasis-markers', making links visible with `org-toggle-link-display' also unhides the emphasis markers. I believe this to be unexpected behavior (it certainly is to me), but I might be wrong here, given that the emphasis markers are explicitly set to a `org-link' invisible property (which see). thanks for reporting this, I've committed 842ab092a in maint which should fix it. Thank you for looking into this, and for the fix. I hope the change does not break anyone's code: perhaps some people use custom code to hide/show emphasis markers based on the org-link invisible property specs. In any case, I don't think `org-toggle-link-display' should display emphasis markers. I'm not sure either. Perhaps that was the reason why `org-link' was used as the invisibility property there in the first place. If you think that is a concern, perhaps adding something as `org-emph' to the invisibility specs and using it there instead of leaving the markers in the default group might be a good idea. This way it would be possible to toggle the markers selectively, as it is done with the links. I'm not sure this is granted, but one reasonable hypothesis why `org-link' was used there in the first place is that some degree of selective toggling of the markers was somehow demanded. Best, Gustavo.
Re: A small idea to simplify (further) time input in the date/time prompt
Hi Bastien, On Sat, 01 May 2021 at 12:40, Bastien wrote: Hi Gustavo, sorry for the slow reply. I applied this patch in master with commit e8562a332. Thanks! Thank you very much! Looking forward to enjoy this one. Best, Gustavo.
Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
On Tue, 27 Apr 2021 at 04:29, Bastien wrote: Ihor Radchenko writes: Maybe you can use (eq (org-element-type (car (org-element-lineage element))) 'drawer) Indeed, thanks for the tip! Committed as 26d1d29cf. Bastien and Ihor, thank you! Gustavo.
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
I'd like to kindly bump this report.
It is an issue which has been around for some time. The report provides
a clear reproduction recipe, which stardiviner was able to reproduce,
and still affects current "org-plus-contrib-20210208". The report also
provides a hopefully convincing code analysis of the affected function
`org-refile-get-location' and a suggested fix (I just don't send a
patch, because I can't provide CA).
Best regards,
Gustavo.
On Mon, 21 Sep 2020 at 15:34, Gustavo Barros
wrote:
Hi All,
some time ago, I've reported an issue regarding duplicity of the
default
candidate in `org-refile'
(https://orgmode.org/list/87lftw1k2n@gmail.com/). The problem was
that,
when using `org-refile-use-outline-path' an "extra" slash was appended
at the
end of every path, but candidates were stored in `org-refile-history'
without
that extra slash. Bastien took care of that and indeed changed things
so as
to pass the elements to `org-refile-history' with the trailing slash
as
appropriate.
At the time, I reported a difference of behavior between
`completing-read-default' and `ivy-completing-read' after the
mentioned
commit by Bastien. But the issue did not appear for Bastien, which
does not
use Ivy, and I also was not able to diagnose the problem properly. I
felt I
didn't have enough to offer as to insist, so I resorted to an old hack
of
mine. But the new release this week (thank you very much!, btw) has
bitten me
again on this, so I went back to some digging, and hopefully I can do
a better
job this time in diagnosing the problem and suggesting a fix.
An ECM to reproduce the issue as it currently stands is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
(add-to-list 'load-path "~/.emacs.d/elpa/ivy-20200826.955")
;; Those are the latest Org weekly build (Org 9.4) and the current up
to
date
;; Ivy at Melpa
(setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
(require 'ivy)
(ivy-mode)
;; Bear with me, the problem is not with Ivy, I'll demonstrate that.
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,* Top heading 1
,* Top heading 2
,** Entry 1
,** Entry 2
#+end_src
- Go to heading "Entry 1", refile it to "Top heading 1"
- Go to heading "Entry 2", and call `org-refile'
- Observe the available candidates, and notice "test.org/Top heading
1/" is
there twice, once as the default candidate, with a *double*
trailing slash,
and also on the paths list, with a single trailing slash.
I've tried to pin down what is going on here and my understanding is
that
Bastien's fix on that previous thread did indeed correct the problem
of the
missing trailing slash in `org-refile-history' and this indeed
corresponds
correctly to the state of the completion "collection" (the let bound
`tbl'
variable in `org-refile-get-location'), as it should. But there
remained a
couple of instances in `org-refile-get-location' which added the
trailing
slash considering `org-refile-history' didn't have them, so that when
this is
done, we get a double trailing slash.
The two instances are: 1) when the completion function is actually
called:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (concat (car org-refile-history)
extra
#+end_src
2) And three lines bellow, on the let binding:
#+begin_src emacs-lisp
(let* ((last-refile-loc (car org-refile-history))
(last-refile-loc-path (concat last-refile-loc extra)))
...)
#+end_src
In both instances, we are getting the `car' of `org-refile-history'
which now
already has `extra' (that is, the trailing slash) and adding it again.
My suggested fix is to remove these `extra's in duplicity, they are
remnants
of when `org-refile-history' didn't have them already. That is:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (car org-refile-history
#+end_src
And:
#+begin_src emacs-lisp
(let* ((last-refile-loc (car org-refile-history))
(last-refile-loc-path last-refile-loc))
...)
#+end_src
Of course, the second opens some opportunity to simplify the code that
follows
considering `last-refile-loc-path' and `last-refile-loc' are now
identical.
Why I think this is the problem and the correct way to fix it:
1) If you add inspection points at the appropriate locations for the
sexps
=(concat (car org-refile-history) extra)= and =(concat last-refile-loc
extra)=
you will find the double trailing slash there, and
Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
Hi Juan, On Mon, 25 Jan 2021 at 14:46, Juan Manuel Macías wrote: By the way... I have written some code to export the citations using make4ht. It's just a proof of concept, and not too elegant I'm afraid. But I wanted to explore a bit more the use of make4ht in this context. Nice! I also think make4ht has potential for this purpose. tex4ht/make4ht is usually a somewhat delicate tool for a general LaTeX document (powerful, but complex), but the typical output of citation and bibliography is text with emphasis/bold etc, and perhaps a list, if we interpret the bibliography environment strictly. This is much simpler (again, typically) than an arbitrary document, to the point I believe it could be streamlined reliably for this subset of the document. The idea is to write the citations in Org as mere bibLaTeX commands, but between !!- ... -!! (a provisional regexp, for convenience, and to see if it works). It can be tested in this Org file, which includes the code (you have to give a value to the variables `bib' and `preamble'): https://gitlab.com/-/snippets/2066135 I understand using the regexp to separate the problems, provisionally, as you said. If it evolves, you might wish to go with the current state of things in the wip-cite branch or, I reiterate the suggestion, look at latex-preview, which allows you to specify the commands of interest, if I recall correctly. I hope you find your way trough the approach. If you do, please let me know. Or, if you wish to discuss a particular issue, feel free to write me directly. Best regards, Gustavo.
Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
Hi Juan, On Sun, 24 Jan 2021 at 16:20, Juan Manuel Macías wrote: I agree with what you comment here and in your previous message. In fact, I'm afraid this (humble) approach of mine is focused only on creating a mere list of references in HTML from a bib file, keeping the same bibliography styles that I have customized in bibLaTeX, but not on everything related to citations throughout the text and on the consistency between citations and bibliographies. I would say that my method is not a good starting point to implement a solution. [...] In my case, anyway, I had been using the TeX ecosystem almost exclusively for my work in typesetting and editorial design (I do not use DTP software, which is not intended to create books but magazines and newspapers), and Org Mode for writing and notes. But in recent years I have come to realize that a workflow based also on Org and Org-Publish is tremendously productive for me to manage the typesetting of a book, especially a complex book. Let's say now I also use Org as a high-level interface for LaTeX. I'm currently working on the /Hispanic Dictionary of Classical Tradition/ (/Diccionario Hispánico de la Tradición Clásica/), a volume of multiple authorship and about 1200 pages. The method I raised in this thread has to do with this scenario, where each dictionary entry is accompanied by a bibliography. As the dictionary will have an online secondary version, I wanted to keep the same bibliography style that I had defined for bibLaTeX. I have not had the problem of the citations here, since the entries do not contain citations (bibliographies only). Otherwise, I think an emergency solution could be to export from Org to *.tex, and then generate the HTML from there using make4ht and another preamble /ad hoc/, better than using a mixed csl/bibLaTeX method which, as you say, can result in many inconsistencies. Well, I think your approach should work quite well for your use case, and certainly a number of others. It is just a matter of being aware of the limitations of the tool. That given, it is great. Of course, I was also curious how you had figured things from a more general perspective. The essential problem, of course, is that our customization is LaTeXcentric: it resides in LaTeX/bibLaTeX and not in Org. [...] I think it is more than just being "LaTeXcentric". Depending on requirements, there is really no choice. We don't hear this often, but the fact is that Org does not support citation and bibliography by itself. A lot of things "work", and in many requirements scenarios that seems to be enough, but what does work relies on outsourcing that task to other tools. As far as I know, there are only two ways out of an Org document with citation and bibliography: LaTeX (and its related tools: bibtex, biblatex, biber, etc), and pandoc (which uses CSL to process these features). The first option is extremely featureful, but restricts us to .pdf output. The only sufficiently general option with multi output is then pandoc, which in turn bypasses the whole Org export infrastructure, implying its own trade-offs because of that. Besides, there is no real link between the LaTeX infrastructure and pandoc/CSL, so that if you want to reach "best results in LaTeX, and acceptable results in other formats", you are bound to live with differences in output for citation/references across formats and to remain under the restrictions of the least featureful backend. Long ago I tended to be more in favor of the idea that a single source-text should produce multiple identical or interchangeable formats. I really still believe it with enthusiasm and I have not completely lost faith in such a utopia ;-) I'd also would love to see that. ;-) And I do think Org is, by far, the best placed tool to fill this place. But I also think citations and bibliography are a big bottleneck in that regard. Of course, there is a long ongoing effort in that area, in the `wip-cite' branch, and the related `org-citeproc' package. I'm still in the hope this will get merged in future not too distant, as it would change things in that regard. Not in the sense of "magically solving all of these problems", but in providing a convened base upon which people can than invest their time and effort, and try to figure each case out, with time. Best regards, Gustavo.
Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
On Sun, 24 Jan 2021 at 08:37, Gustavo Barros wrote: It should handle two limitations of your procedure, which are: getting the bibliography with the entries actually cited in the document and citation callouts. The first one is easy to handle in your current approach by means of any of the multiple alternatives to generate a bib file with only the cited entries. The second one, much harder, as far as I can see. Thinking this through: there is actually a third challenge to the approach, which is ensuring the relation of the citation callouts and the bibliography is correct. For example, if using a numeric or alpha style, how to be sure the labels are the same in the citation and the bibliography. Even in other styles, such as author-year, if disambiguation rules come into play (e.g. (Smith 1987a, Smith 1987b)), how to be sure the same rules are being applied by pandoc/CSL (on the citations) and biblatex (in the bibliography). As far as I can tell, this will hang on sorting, something which biblatex is known to be more capable than other tools, so that I would expect differences (at least potentially). Styles such as verbose or author-title would probably be safe, I guess. Have you given some thought about this? If so, how are you handling the case? Best, Gustavo.
Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
Hi Juan, that's very interesting. Thanks for sharing. On Sat, 23 Jan 2021 at 12:03, Juan Manuel Macías wrote: > When I export to LaTeX an Org document that contains a bibliography, I > use bibLaTeX with a very custom style (i.e. quite a few lines of code > related to bibLaTeX in the preamble). I wanted to apply all that > bibLaTeX setting and styles when exporting to HTML too, so I came up > with this method, using make4ht. I share it here, in case it is useful > to someone. > > The idea is to compile with make4ht (see: > https://www.ctan.org/pkg/make4ht) a simple file with *only* the > bibliography, and "embed" the HTML output in the Org document. You need > to create in the working directory a tex file, which will serve as a > minimal preamble and which also includes all code related to bibLaTeX. > We can name it preamble.tex, and it would start like this: Indeed, when one actually needs biblatex-biber to process their bibliography, using Org is really hard. I have some history with this problem, as I initially approached Emacs (once upon a time) trying to use Org as a single source and multiple outputs (mainly pdf and odt). However, as you, I rely on heavily customized styles, which simply won't work with pandoc/CSL, so I got stuck. I eventually stayed in Emacs and use Org for a number of things, but for my more formal writing use AUCTeX + RefTeX, which is great too (alas, no odt..., at least not easily). For a long time I fancied trying something about it, pretty much in the same lines as you are doing here. My idea was to use `preview-latex' for this, which I still think is promising and, as far as I understand, pretty much automates what you are doing, which is to generate a stripped document, with a proper preamble, and run it on a piece of your actual document. It is used by AUCTeX and LyX (Org too, I presume) to generate images, but I don't see why it could not be streamlined to generate a dvi which could then be fed to tex4ht and friends, just as you do too. I thought that this procedure could, in principle, be used to export to other formats, but also to Org itself, generating either a second version of the source document with the citations and bibliography already processed as text (sort of a 'org-biblatex-citeproc'), or as a preview, such as the ones for math. Depending on how far you are willing to take your setup, this might be one path. It should handle two limitations of your procedure, which are: getting the bibliography with the entries actually cited in the document and citation callouts. The first one is easy to handle in your current approach by means of any of the multiple alternatives to generate a bib file with only the cited entries. The second one, much harder, as far as I can see. To my dismay, my own style customizations for biblatex are mainly aimed at citations (primary/archival sources for Economic History). But it was quite interesting to see your approach here. So, again, thank you. Best, Gustavo.
Re: org-refile and ivy
Hi Eric, On Fri, 22 Jan 2021 at 15:49, Eric S Fraga wrote: > Dear all org mode list readers, > > I have been trying to get to grips with org-refile. For some reason, > the completion mechanism (I use ivy generally but I have no idea what > org-refile actually tries to do/use) only shows me the current file name > if I have org-refile-targets set to nil. It doesn't show any top level > headlines to choose from which is what I would expect from the > documentation. Hitting RET to select the completion target given (file > name only) refiles to the end of the file which is not what I want. > > This is with org updated fairly recently but not quite up to > date. However, I've had this problem for a long time and don't use > org-refile as a result. > > Any suggestions welcome. I use org-refile with ivy, so I might share. If I recall correctly, the only thing that does not play well between the two is `org-outline-path-complete-in-steps`. My basic setup is the following: #+begin_src emacs-lisp (setq org-refile-targets '((org-agenda-files :maxlevel . 6) ;; 'nil' means consider headings of the current buffer (nil :maxlevel . 6))) (setq org-refile-use-outline-path 'file) (setq org-outline-path-complete-in-steps nil) #+end_src That should get you started. I personally like org-refile for its quickness, so I do some extra work to filter out candidates of this list and keeping only the frequent targets (with `org-refile-target-verify-function'). And if something atypical arises, I just go with kill-yank. Note however, on the relation of org-refile and ivy: https://orgmode.org/list/87tuvrj7ww@gmail.com/ HTH, Gustavo.
Re: underline with line breaks doesn't work
Hi Enrique,
On Fri, 01 Jan 2021 at 05:22, "Blair, Erik" wrote:
> I would like to use \ul from the soul package in Org mode for underlining with
> line breaks (and *not* underlining spaces). It’s not working well. It fails
> like \underline (spaces get underlined, and lines don’t break and run off the
> page). My LaTeX export doesn’t work if I insert \ul{abc} into the org file,
> but I can insert \ulem{abc} or \underline{abc}, as well as the typical _abc_.
>
> More information: I’m actually trying to define a new command using logic in
> the LaTeX header. This way, I can make notes with key words. I can toggle a
> Boolean variable, and it makes key words show up; or, it underlines the words,
> which are also hidden by \phantom. Also, we would like to avoid underlining
> spaces because it cues the reader to know how many words are missing.
>
> I note this previous discussion:
>https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00376.html
>
> It seems like the issue that was fixed at one point and \ul should work, but
> maybe it’s not now. Or, maybe I don’t have the experience to know how to apply
> the solution to my Emacs/Org mode on my computer.
`soul' was considered as a default for underline and strike-through in
that thread, but some people reported problems with Chinese characters,
so that eventually it was replaced by `ulem'. In other words, `soul' is
not loaded by default by Org when exporting to LaTeX, `ulem' is.
Much later, I've argued in that same thread in favor of `soulutf8' as
a better default:
https://orgmode.org/list/8736iobefh@gmail.com/
https://orgmode.org/list/871ry8bdo8@gmail.com/
But my necrobumping seems to have missed the opportunity at that point.
Regarding your particular situation, you just tell us "it's not work
well / doesn't work" which is not much to go about. And also not much
about any Org export configurations you might have in your init.
Anyway, the only guess I have with what you provided is that you are
missing to load `soul' altogether. If that's the case, adding the
following to your document should do:
#+latex_header: \usepackage{soulutf8}
That is, it should be enough for you to use it in your `\keyTest' or to
use `\ul' directly. For Org to export `_abc_' as `\ul{abc}' you'd also
need to configure `org-latex-text-markup-alist`.
Note, however, that the `soul' underline will underline spaces. But
that's an issue on the LaTeX side, and has nothing to do with Org. For
this to work as you expect, you will either have to go fancy in your
underlining (for which there is plenty of examples in
tex.stackexchange) or, which is probably the easiest, provide that this
is handled appropriately in your conditional for `\keyTest'.
HTH,
Gustavo.
[FR] Generalize org-reftex-citation
Hi All, It's been some time since included in my todos to cook something to insert citations in Org using RefTeX's infrastructure. As I set this morning to do so, I found out it already existed: `org-reftex-citation'. Alas, it is not enough for me (and certainly also others), because it uses a simple regexp search for "#+BIBLIOGRAPHY:", thus only being able to find the .bib file with that specific form of declaration. In particular, it does not support biblatex (as far as I can tell). Before I found out the function existed, I had a general idea of letting RefTeX work in the exported .tex file. It turns out it is easy to adapt `org-reftex-citation' to do precisely that. And in so doing, being thus able to do anything RefTeX is able to support in its native environment, on top of anything Org is able to export. The only disadvantage I see, and which I consider minor, is that the .tex file has to exist. My take on this neat little idea so far is: #+begin_src emacs-lisp (defvar gb/org--rds nil) (defun gb/org-reftex-citation () "Use `reftex-citation' to insert a citation into the buffer. The bibliography sources for the base Org file are found by RefTeX itself parsing the corresponding exported \".tex\" file, which is required to exist. Those are passed to `reftex-citation' to insert a citation into the base Org buffer." (interactive) (unless (derived-mode-p 'org-mode) (user-error "Not an Org buffer")) (let ((tex-file (org-export-output-file-name ".tex"))) (if (file-readable-p tex-file) (find-file-noselect tex-file) (user-error "TeX file not available, export first to %S" tex-file)) (let ((reftex-docstruct-symbol 'gb/org--rds) gb/org--rds) (with-current-buffer (get-file-buffer tex-file) (reftex-access-scan-info nil) (setq gb/org--rds (symbol-value reftex-docstruct-symbol))) (call-interactively 'reftex-citation #+end_src Still lightly tested, but looks good with what I tried out. So, I thought it was a good idea to send this to the list as suggestion / feature request. Best regards, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
On Tue, 22 Dec 2020 at 17:24, Gustavo Barros wrote: Damn! Sorry for the noise. It *doesn't* work, and disables Org's own remappings, of course. Just as I sent I realized I had something else enabled which was doing the actual job (my previous take on this thread). Back on the deadlock. Sorry again. But, in the meantime I did find this: https://stackoverflow.com/a/13102821 I reproduce Stefan's answer verbatim, so it's kept for reference in the list regardless of the external link: #+begin_src emacs-lisp (add-hook '-hook (lambda () (let ((oldmap (cdr (assoc ' minor-mode-map-alist))) (newmap (make-sparse-keymap))) (set-keymap-parent newmap oldmap) (define-key newmap [] nil) (make-local-variable 'minor-mode-overriding-map-alist) (push `( . ,newmap) minor-mode-overriding-map-alist #+end_src Best regards, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
On Tue, 22 Dec 2020 at 17:18, Gustavo Barros wrote: Anyway, what I came up is a slight variation from Marco's approach, which may be just general enough to be employed by Org. #+begin_src emacs-lisp (add-hook 'visual-line-mode-hook #'my/visual-line-mode-hook-for-org) (defun my/visual-line-mode-hook-for-org () (when (and (derived-mode-p 'org-mode) visual-line-mode) ;; Ensure 'visual-line-mode' does not shadow Org's line commands. (local-set-key [remap move-beginning-of-line] nil) (local-set-key [remap move-end-of-line] nil) (local-set-key [remap kill-line] nil))) #+end_src I've lightly tested this here and it seems to be working. WDYT? Damn! Sorry for the noise. It *doesn't* work, and disables Org's own remappings, of course. Just as I sent I realized I had something else enabled which was doing the actual job (my previous take on this thread). Back on the deadlock. Sorry again. Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, Hi Marco, On Fri, 04 Sep 2020 at 14:37, Bastien wrote: Hi Gustavo, Gustavo Barros writes: I do think my other workaround is worth pondering to be included, so that this would work out-of-the-box. Do you see any particular drawbacks of setting these bindings directly (that is, not by remapping) in `org-mode-map'? You mean by adding something like (org-defkey org-mode-map (kbd "C-a") #'org-beginning-of-line) in org-keys.el? I'm pretty sure such "hard" remapping breaks an Emacs convention--I'll ask emacs-devel, because that would indeed fix the problem you are reporting. Thanks for insisting, I've been playing with 'mwim.el' today, and came up with something that might be interesting. Btw, Bastien, I've seen the message you've sent to emacs-devel about this. Thank you. A pity it doesn't seem to have drawn much attention. Anyway, what I came up is a slight variation from Marco's approach, which may be just general enough to be employed by Org. #+begin_src emacs-lisp (add-hook 'visual-line-mode-hook #'my/visual-line-mode-hook-for-org) (defun my/visual-line-mode-hook-for-org () (when (and (derived-mode-p 'org-mode) visual-line-mode) ;; Ensure 'visual-line-mode' does not shadow Org's line commands. (local-set-key [remap move-beginning-of-line] nil) (local-set-key [remap move-end-of-line] nil) (local-set-key [remap kill-line] nil))) #+end_src I've lightly tested this here and it seems to be working. WDYT? Best regards, Gustavo.
Re: did behaviour of RET change again?
Hi All, On Sun, 20 Dec 2020 at 18:25, Bastien wrote: > > Also, I'm thinking of using headline-data as the new default for the > org-adapt-indentation option. WDYT? > > I know Kevin as a good overview of the whole topic, maybe he can also > advise about what should be done here. I cannot but raise a friendly flag here. I've reported the following behavior I've found for `headline-data' some time ago: https://orgmode.org/list/87r1qukjjs@gmail.com/ Nicholas Savage did try and could not reproduce. Last time I've tried it, not long ago, I still found the behavior. I would thus suggest that at least some more people try it and check their end before going that route. I'll be happy if it's just me. That said, I do think `headline-data' is a great default value for `org-adapt-indentation', despite the fuss that is bound to ensue for *any* change there. Best regards, Gustavo.
Bug: org-link-descriptive and org-toggle-link-display [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi All,
there is a scope mismatch in `org-toggle-link-display' between text
(visibility) properties and the setting of `org-link-descriptive'. The
text properties are set for the buffer with either
`remove-from-invisibility-spec' or `add-to-invisibility-spec', but the
value of `org-link-descriptive` is set globally with `(setq
org-link-descriptive (not org-link-descriptive))'. It is not a big
deal, but it does lead to a glitch in `org-toggle-link-display'.
It is easy to generate an ECM to trigger the glitch:
- Start `emacs -Q'
- Load the latest:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201123")
#+end_src
- Open two Org buffers "*Buffer 1*" with contents:
#+begin_src org
[[https://orgmode.org/][Org mode for Emacs]]
#+end_src
- And "*Buffer 2*" with contents:
#+begin_src org
[[https://orgmode.org/worg/][Hello Worg, the Org-Mode Community!]]
#+end_src
- It's probably easier to visualize if you have both windows in view in
a split frame, but it should not change the result whatever you do.
- The initial state, as per defaults, is that links are invisible in
both buffers.
- Go to "*Buffer 1*" and `M-x org-toggle-link-display', and links are
made visible in that buffer, but not in "*Buffer 2*".
- Now, go to "*Buffer 2*" and call `M-x org-toggle-link-display' there.
It doesn't work. Call it again. Now it does.
What's happening is that, when we call `org-toggle-link-display' in
"*Buffer 1*" we set `org-link-descriptive' to nil globally, so that when
we move to "*Buffer 2*", Org thinks the links are visible, and when we
call `org-toggle-link-display' then, Org will try to "re-hide" the links
that are already invisible, with no apparent effect. But, in doing so,
it also sets `org-link-descriptive' to t again, also globally. And so a
second call will work.
I don't know if it's better to make `org-link-descriptive' buffer-local,
or to simply use `setq-local' in `org-toggle-link-display'. Either way,
it is a low hanging one.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-44-g5272d9-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-link-descriptive nil
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow
Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi All,
when using `org-hide-emphasis-markers', making links visible with
`org-toggle-link-display' also unhides the emphasis markers. I believe
this to be unexpected behavior (it certainly is to me), but I might be
wrong here, given that the emphasis markers are explicitly set to a
`org-link' invisible property (which see).
An ECM to reproduce the issue is:
- Start `emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201123")
(setq org-hide-emphasis-markers t)
#+end_src
- Open an Org buffer with contents:
#+begin_src org
[[https://orgmode.org/][Org mode for Emacs]]
,*bold*
#+end_src
given the settings, both the link and emphasis markers should be
invisible.
- Call `M-x org-toggle-link-display', see that both the link and the
emphasis markers are made visible. Toggle it again, and both are
invisible.
As far as I dug, the reason for this behavior lies in
`org-do-emphasis-faces' which indeed uses the `org-link' invisible
property to hide the links (at the very end of the function):
#+begin_src emacs-lisp
(when (and org-hide-emphasis-markers
(not (org-at-comment-p)))
(add-text-properties (match-end 4) (match-beginning 5)
'(invisible org-link))
(add-text-properties (match-beginning 3) (match-end 3)
'(invisible org-link)))
#+end_src
So that `org-toggle-link-display' cannot really distinguish an emphasis
marker from an actual link when it removes `org-link' from the
invisibility-spec.
I don't know why this is done this way in `org-do-emphasis-faces', so I
might be missing something, but it does lead to this peculiar behavior
of `org-toggle-link-display'.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-44-g5272d9-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-hide-emphasis-markers t
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs")
Re: Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
On Tue, 17 Nov 2020 at 02:54, Kyle Meyer wrote: Gustavo Barros writes: Hi All, The toggling of Archives mode in the agenda, the one which includes archive files, called with "v A", can be turned on, but turning it off with "v A" does not currently work. An ECM to reproduce the issue is: Thanks for the report and reproducer. Should be fixed by 104d92199. Wow, that was fast! Thank you very much, Kyle.
Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
Hi All,
The toggling of Archives mode in the agenda, the one which includes
archive files, called with "v A", can be turned on, but turning it off
with "v A" does not currently work.
An ECM to reproduce the issue is:
- Start `emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201116")
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
- We have two files in =~/test/=: =agenda.org= and =agenda.org_archive=,
which is, as you presume, the default archive file of the first one.
The contents of =agenda.org= are:
#+begin_src org
,* TODO Task
SCHEDULED: <2020-11-16 Mon>
,* TODO Archived tree
:ARCHIVE:
SCHEDULED: <2020-11-16 Mon>
#+end_src
- And those of =agenda.org_archive= are:
#+begin_src org
#-*- mode: org -*-
Archived entries from file /home/gustavo/test/agenda.org
,* TODO Archived task
SCHEDULED: <2020-11-16 Mon>
:PROPERTIES:
:ARCHIVE_TIME: 2020-11-16 Mon 11:52
:ARCHIVE_FILE: ~/test/agenda.org
:ARCHIVE_TODO: TODO
:ARCHIVE_CATEGORY: agenda
:END:
#+end_src
Which was actually produced by archiving this task from =agenda.org=.
- From this setup, lets call `org-agenda': "M-x org-agenda RET a".
- At this point, the agenda only shows "Task", which is as expected.
Call "v a" to also show "Archived tree", locally archived by tagging.
Call "v a" again to disable it, and it goes away as expected.
- Call "v A" (uppercase "A"), to enable display of archived tasks
including those of archive files. "Archived task" is also shown, as
expected. So far, so good.
- Now call "v A" again to toggle (off) the display of archived tasks.
The minibuffer echoes the message "Trees with :ARCHIVE: tag and all
active archive files are included", and the archived items are still
shown. Considering the manual describes the binding "v A" as "Toggle
Archives mode. Include all archive files as well.", this is not
expected behavior.
- Using "v a" to toggle it off does work as expected though, even when
we enabled `org-agenda-archives-mode' with "v A".
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-41-g9bb930-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/test/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
Re: Changed list indentation behavior: how to revert?
Hi Tim, Hi All, On Mon, 16 Nov 2020 at 18:15, Tim Cross wrote: > Tim Cross writes: > >> >> Thanks for clarifying this Kyle. >> >> So essentially, this change has been made to make org-mode consistent >> with the rest of emacs which enabled electric-indent by default in Emacs >> 24. this is a good thing. Org should be consistent with other modes. Any >> differences are likely to be the source of confusion and bug reports. >> >> I am a little confused about the purpose of org-adapt-indentation >> though. According to the org news file, to get back the old behaviour, >> it says to explicity disable electric-indent mode using org-mode-hook. >> There is no mention of org-adapt-indentation. >> >> Is this just an artefact from before and in effect, we have two methods >> to disable the indentation behaviour? Is there anything functionally >> different between disabling electric-indent by calling >> electric-indent-local-mode -1 or setting org-adapt-indent to nil or is >> the result functionally equivalent? >> > > Following up to my own question. The two are NOT functionally equivalent > in that org-adapt-indentation supports other values than t or nil. You > can use this variable to tweak how the adaptive indentation works. While > setting it to nil may be equivalent to turning of electric-indent mode, > it can be used to adjust how adaptive indentation works as well. > > Tim > > -- > Tim Cross I think I might chime in again, as perhaps I have a point to add, and Tim's formulation here is a good hook for that. Setting `org-adapt-indentation' to nil is not equivalent to disabling `electric-indent-mode' not because there are more values than t or nil for the first, but because they are conceptually different. `org-adapt-indentation' controls how the indentation should be done by Org, `electric-indent-mode' just applies this setting when you hit RET. If you have `electric-indent-mode' off, but `org-adapt-indentation' set to t, type a heading hit RET, than TAB, you will get the same indentation up to the heading stars level. But the point of interest here, is not this difference by itself, but in some of its implications, and why so many people were unaware of `org-adapt-indentation'. I think this is the case because, with `electric-indent-mode' off, it is easy to slip through the right indentation, and get to believe things are working as expected, when they are actually just doing so by coincidence. Suppose you are in the status quo before 9.4, that is `org-adapt-indentation' set to its default value of true, and `electric-indent-mode' off, and you start to type a little document. If you type it always hitting TAB after RET, you will get: #+begin_src org ,** Foo First line Second line #+end_src (Indentation appears off, but that's just the escape comma). If, instead, you just type RET, you get what many people surprised by the change in this thread expect: #+begin_src org ,** Foo First line Second line #+end_src Now, the point is that, if you just miss the TAB on the first line, even if you hit TAB to indent on the subsequent ones, they will still not indent and be kept on the left margin. So things *appear* to be working as expected, but they are not. What is happening here is that *because indentation is broken in the first line* it goes amiss in the following ones. One might argue that, if it appears to work on all accounts, it is actually working. But if you have this situation, you will then be subject to all sorts of strange things. Suppose we are in the situation of the last block, and demote the heading: #+begin_src org ,*** Foo First line Second line #+end_src Surprise! the content of the heading was moved to the right by one space which is neither indented as it should, nor at the left margin as "expected". Now you try to "fix" this "incorrect" dragging of the content, by selecting the subtree and calling `org-indent-region'. #+begin_src org ,*** Foo First line Second line #+end_src Surprise! it's even "worse". So you then undo twice, and type the star directly to "correct" it (how else?). Try to expand an org-tempo template and get surprised that you can't get a non-indented expansion right after the heading, but you can do it after some content (from a real case at https://emacs.stackexchange.com/q/55413/18951). I haven't tried further, but I wouldn't be surprised if similar "strange" behaviors would also affect killing-yanking subtrees, refiling, etc. So, keeping `org-adapt-indentation' to t, but "solving" the inconvenience by disabling `electric-indent-mode' is not a solution, because this will just hide (keep hiding?) from you the fact that you are editing a document which is different from what Org is actually expecting according to the indentation settings, and this will result in inconsistencies of behavior at a number of points. We should probably thank `electric-indent-mode' for making people more aware of this user option, and correct this setting
Re: Changed list indentation behavior: how to revert?
Hi Jean, On Sun, 15 Nov 2020 at 09:09, Jean Louis wrote: That is useful. I'm glad to hear that. You (plural) could probably also get some juice from looking into, and incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. I do, thank you for reminder. Us in plural are sometimes teachers or mentors who educate other people who are supposed to edit Org files in most simple manner, and those people will never be able to write to this list to find out which option where, not even to know about indentation things. When default is introduced then all people following an educator has to turn off default. They will not even know why. One default introduced can cause butterfly effect. Also a fellow teacher here. As you, I'm trying to transmit this information to you and others, because I find it useful. Nobody needs to use `M-RET', `C-RET' and `C-j'. General design of user interface should not conquer their habits unless substantial amount of users have demanded it so. And how exactly would maintainers know that? Do you claim to be speaking on their (substantial amount of users) behalf? For me is now better to simple adjust: org-indent-region variable just as you said. Please, don't confuse. I said you should *not* use (the command) `org-indent-region' if you were systematically manually overriding indentation defaults. I recommended to set the user option `org-adapt-indentation' to nil, which seems to be the desired value for most of the manifestations on this thread. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Hi All, On Sun, 15 Nov 2020 at 13:37, Greg Minshall wrote: > hi, all. > > David Rogers wrote: > >> Am I crazy to say that your last example of unwanted behavior is >> easier for me to read and understand? (and to me the common >> indenting is a hopeless mess?) > > yes, in fact, the "new" way sort of has the buffer indentation match > that of the outline structure of the file (specified by asterisks). > there's a lot to be said for that. (though, obviously, it's not what > everyone would want.) > > if the new mode stays as the standard, maybe we'd want to capture an > asterisk typed immediately after a newline that would (by default), put > that line-beginning asterisk back in column one? > > otherwise, this is what one gets (without remembering to do a C-j > instead of ): > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - > which is maybe not optimal? > > in most non-org modes (including in Org Src... buffers, and in org files > when writing org-mode lists), i'm a big fan of electric indent mode. > > maybe an org-specific setting, "org-file-indent-follows-structure"? if > true, it means the user wants to have a "raw" org document laid out > according to the outline structure of the document. if false, it means > one, in general, wants the org file laid out with left-alignment (or, > right, in right-to-left) languages (not including embedded lists, and > whatever else i might be ignoring). > > cheers, Greg I'm quite surprised by the reaction to this issue, because `electric-indent-mode' *does not change Org's indentation settings*, it just applies them alongside RET. Which makes me think that those who've been so bitten by it where actually manually overriding (their own) settings in this area by never applying indentation. If that's your case, you'd probably be very surprised of running `org-indent-region' in your documents (don't do it, I don't want to break them). In particular, one "surprising" result of the "new behavior" is that of indentation after a heading. That was already and continues to be controlled by the user option `org-adapt-indentation'. If you don't want your content to be indented after a heading, set it to nil. And `electric-indent-mode' should do what you expect in this regard. I'm not sure if thus overriding your own (or Org's, if you prefer) indentation settings by selectively applying indentation is a sane approach, so perhaps `electric-indent-mode' may help you discipline your editing to your benefit. And make you more conscious of Org indentation. Especially because indentation is not a "free variable" in Org, it is a syntactical aspect of an Org document and, conspicuously, is critical to the definition of a heading and of plain lists. An example from Greg: > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - That's because the first one is indeed a heading, and the second is not, it is a plain list item. By definition a heading must start at the left margin. You (plural) could probably also get some juice from looking into, and incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. Of course, with that said, if you really don't like `electric-indent-mode' for Org, you can disable it as described in the Org News, previously linked to in this thread. There is ground to prefer this, particularly for the list case, mentioned by Karl in the original message of this thread. But `electric-indent-mode' does not induce a new pattern of indentation for Org, it just applies your settings in this area, whose defaults have not changed of recent, as far as I recall. Finally, the "change" was not brought about by Org, but by Emacs. Org just (belatedly) tagged along. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
On Fri, 13 Nov 2020 at 18:47, Jean Louis wrote: * Gustavo Barros [2020-11-14 00:12]: I have seen discussion with very little reasoning. You are changing default for many users and large subset of those users will not read the NEWS. And now you are discovering that there are people who get messed up with it. Is it really useful? So far I remember the electric-indent-mode did work in Org mode without this anti-enhancement. [...] Introducing default that changes habits and gives more work to present users is not useful. Did you consider number of users who would now maybe need to introduce local variable just to turn that off? Sorry that I do not find this case reasonable. Oh, my! I'm not even the person you should be ranting to. I'm just an user, and someone who follows this list, and was trying to be helpful. But, as such, I do get what motivated maintainers to make the change from the linked threads. And I also got from them and the News the information needed to adjust for the change, in case I'd want to. Perhaps we read differently. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Hi Karl, On Fri, 13 Nov 2020 at 18:30, Karl Voit wrote: > Hi! > > I'm on Org mode maint git repo, currently v9.3.6. > > I recently upgraded from an older git commit version. > > Since the upgrade I do have a different behavior: > > - Consider this list itemX > A 1 > 2 > > When I press RET at the "X" above, I end up at position "1". With > another RET, cursor ends up at "2". I'd love to get back the > previous behavior where RET at "X" always ended up at "A". > > Unfortunately, there are tons of org*indent* variables out there. > I'd appreciate it very much if somebody knows what variable I need > to modify to get back to the previous behavior. > > Thanks! I'll answer, because I feel somewhat responsible for your upgrade. ;-) Since recently Org is set to respect Emacs' `eletric-indent-mode'. If I'm not mistaken, it made to the 9.4 release, I presume that's what you are getting. You can find the Org News entry, and how to get the previous behavior back in: https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323 A couple of threads that might help understand the change and the reasoning behind it: https://orgmode.org/list/877dxpazbo.fsf...@gmail.com/ https://orgmode.org/list/878sfbycip@iki.fi/ HTH, Gustavo.
Re: [FR] Don't hardcode checker functions prefix in org-lint
Hi All, On Tue, 10 Nov 2020 at 17:22, Gustavo Barros wrote: This is a small feature request for `org-lint' not to hardcode the checker functions' prefix, as it currently does. I've been playing with and testing this further, and I found an uncovered corner in my initial suggestion: the revert-buffer behavior in the report buffer. It is still simple to handle it, but requires a couple of extra steps: set the prefix variable as a buffer local variable in the report buffer in `org-lint--display-reports' and let-bind this value before moving to the linted buffer in `org-lint--generate-reports'. As an extra sugar, but non essential, it would also be nice to be able to set the report buffer's name. In sum, the suggestion/request then entails: #+begin_src emacs-lisp (defvar-local org-lint--checkers-prefix nil) (defvar-local org-lint--report-buffer-name nil) (defun org-lint--generate-reports (buffer checkers) (let ((checkers-prefix (or org-lint--checkers-prefix "org-lint"))) (with-current-buffer buffer ;; [...] (funcall (intern (format "%s-%s" checkers-prefix (org-lint-checker-name c))) ast) ;; [...] ))) (defun org-lint--display-reports (source checkers) ;; changed let-binding <-- (let ((buffer (get-buffer-create (or org-lint--report-buffer-name "*Org Lint*" (with-current-buffer buffer (org-lint--report-mode) (setf org-lint--source-buffer source) (setf org-lint--local-checkers checkers) ;; added variable setting <-- (setf org-lint--checkers-prefix org-lint--checkers-prefix) (org-lint--refresh-reports) (tabulated-list-print) (add-hook 'tabulated-list-revert-hook #'org-lint--refresh-reports nil t)) (pop-to-buffer buffer))) #+end_src That's about it. With it, I get a fully functional Lint report for personal lints with something like: #+begin_src emacs-lisp (defun my/org-lint ( arg) (interactive "P") (let ((org-lint--checkers my/org-lint-checkers) (org-lint--checkers-prefix "my/org-lint") (org-lint--report-buffer-name "*My Org Lint*")) (funcall-interactively 'org-lint arg))) #+end_src Best regards, Gustavo.
[FR] Don't hardcode checker functions prefix in org-lint
Hi All, This is a small feature request for `org-lint' not to hardcode the checker functions' prefix, as it currently does. `org-lint' is a small gem in Org, specially to those fat-fingered folks such as myself, to the point that it's been some time since I've been fancying using it to check some of my own personal conventions and structures, beyond Org syntax. It is not difficult to do so, and it is enough to define some appropriate checker functions and a personal `my-org-lints' let binding `org-lint--checkers' to my own set of checkers. It's pretty neat. However, `org-lint' hardcodes the prefix of the checker functions to its own prefix, so that to define my own personal checker functions I have to step on `org-lint's namespace, and use "org-lint-" as a prefix, to get things working. The hardcoding occurs in `org-lint--generate-reports', when each checker is called with: #+begin_src emacs-lisp (funcall (intern (format "org-lint-%s" (org-lint-checker-name c))) ast) #+end_src It would be really useful, and simple enough, if a variable was defined, such as: #+begin_src emacs-lisp (defvar org-lint-checker-prefix "org-lint") #+end_src and the call used this variable instead of hardcoding its value: #+begin_src emacs-lisp (funcall (intern (format "%s-%s" org-lint-checker-prefix (org-lint-checker-name c))) ast) #+end_src This would allow to define the mentioned `my-org-lints' function let binding `org-lint--checkers' and `org-lint-checker-prefix' to appropriate values. So that an user's checker functions could have names with other prefixes. As far as my grasp of `org-lint' goes (still learning), that would be enough for users to enjoy its infrastructure for personal lints without having to invade org-lint's namespace. If you think it's a good idea, I'd certainly appreciate it to be included. Thank you. Best regards, Gustavo.
Re: org-sort-entries sorting by top-level with first entry at bob
Hi Samuel, On Fri, 30 Oct 2020 at 17:43, Samuel Wales wrote: i always have everyting under a top level, so taht files are trees not forests and org can work treeishly even at toplevel. This would be a workaround, not a solution. Is it a formal requirement of Org that files must be kept in this form? but to not use the mark, typically you supply point-min and point-max to some function. `org-sort-entries' does not take beg/end as arguments, it uses the active region, as reported. Regards, Gustavo.
org-sort-entries sorting by top-level with first entry at bob
Hi All, `org-sort-entries' provides no easy way to sort by top-level when the first entry is at the beginning of buffer. This is true for both interactive and non-interactive uses of the function, but a little more inconvenient in the latter case. Indeed, `org-sort-entries', when deciding what to sort, first tests for `org-region-active-p', then `org-at-heading-p' (or if after a heading), failing those tests, it falls back to top-level sorting. However, if the first heading is at the beginning of buffer and we want to sort by top-level, we'll never get to the fall back case, because `org-at-heading-p' will return non-nil, and the children of the first entry will be sorted instead. Not an ECM, just an use case with the situation at hand. Consider a buffer with contents: #+begin_src org ,* B Foo ,** B Baz ,** A Foo ,* A Bar #+end_src How to sort by top-level? The currently existing alternative is to `mark-whole-buffer', and let `org-sort-entries' sort by region. While this is reasonable in the interactive case, it is less so if `org-sort-entries' is being called in code. Using `mark-whole-buffer' in your code will grant you a nice compiler warning and pretending you don't use it by doing the same thing yourself is explicitly advised against in its docstring: "it is usually a mistake for a Lisp function to use any subroutine that uses or sets the mark". Behind the scenes, Org is using `use-region-p', which means the region must not only exist but transient-mark-mode must be on and the mark must be active. It can be made to work, of course, but it is clearly less than ideal. Either way, currently the only way to ensure that sorting is done by top-level when you don't know whether there is something before the first heading (including possible narrowing) is to rely on the region case. What to do with it is somewhat tricky, though. My first thought was to test if we are actually looking at a heading regexp, and sort on the heading's level in this case. But, on second thought, I believe this is not a good idea, because it will conflict with current and expected behavior for speed-keys, in particular. Perhaps test if point is at beginning of buffer, and handle this case specially? Best regards, Gustavo.
Documentation suggestion: Mention async-bytecomp-package-mode in the installation section of the manual
Hi All, I've seen time and again folks get bitten by trying to install Org with `package.el' while having Org loaded. The latest, but certainly not the first and not the last: https://www.reddit.com/r/orgmode/comments/jicj1k/how_to_use_org_version_from_orgpluscontrib/ This is well known, and indeed the manual states "important" in bold to say that "You need to do this in a session where no ‘.org’ file has been visited, i.e., where no Org built-in function have been loaded." But it is not always easy to ensure that, even when you know what you are doing. And certainly not trivial to users less acquainted with the package system and how library loading works, etc. However, there is a very easy way to ensure that installation/byte-compilation is done in a clean environment in package `async', namely `async-bytecomp-package-mode'. From my experience, I have a simple: (use-package async-bytecomp :ensure async :defer t :custom (async-bytecomp-allowed-packages 'all) (async-bytecomp-package-mode t)) in my init file. My `initial-major-mode' is `org-mode' and I've never had an installation problem, even though I update `org-plus-contrib' carelessly at will on a live session. `async' is by John Wiegley, and available both at ELPA and MELPA. Wouldn't it be worth mentioning it in the manual and/or in the site/Worg? Best regards, Gustavo.
Re: Force creation of org id in template
On Mon, 26 Oct 2020 at 19:40, Gustavo Barros wrote: > On Mon, 26 Oct 2020 at 22:33, Michael Heerdegen > wrote: > >> I'm not sure. I see that creating an id involves slightly more than >> adding the property - see the `org-id-add-location' call in >> `org-id-get'. Calling the higher level `org-id-get' or the like in a >> %() spec in a template fails however, since when it's called a temp >> buffer not associated with a file is current. >> >> And then I'm also not sure if the above is always secure when something >> else in the template spec wants to add a (different) property. Do you >> know? > > Not really. `org-id' usually "just works" for me, so I never had to dig > anything deeper there. But, as far as I recall, this is meant to add > the new ID on the IDs file. Considering your capture template is likely > to be on your agenda files, this is probably not going to be of > concern (meaning here these files will eventually be scanned and the ID > found). But, if it is, you could then go with `%(org-id-get nil t)`, > right? It does seem to be more appropriate either way, I agree. > > I have stored here in my init file a message from the list describing > the procedure Org uses to try to find an ID, you might find it useful: > https://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg01195.html > > Regarding the second issue, of course, you should end up with a single > properties drawer, and the template should ensure that. Indeed, `%(org-id-get nil t)` fails. But the following works: (defun org-id-get-new-id () (interactive) (let ((id (org-id-get nil t))) id)) To my surprise, I had to make it interactive. Perhaps that's what made the previous try fail. Best, Gustavo.
Re: Force creation of org id in template
On Mon, 26 Oct 2020 at 22:33, Michael Heerdegen wrote: > I'm not sure. I see that creating an id involves slightly more than > adding the property - see the `org-id-add-location' call in > `org-id-get'. Calling the higher level `org-id-get' or the like in a > %() spec in a template fails however, since when it's called a temp > buffer not associated with a file is current. > > And then I'm also not sure if the above is always secure when something > else in the template spec wants to add a (different) property. Do you > know? Not really. `org-id' usually "just works" for me, so I never had to dig anything deeper there. But, as far as I recall, this is meant to add the new ID on the IDs file. Considering your capture template is likely to be on your agenda files, this is probably not going to be of concern (meaning here these files will eventually be scanned and the ID found). But, if it is, you could then go with `%(org-id-get nil t)`, right? It does seem to be more appropriate either way, I agree. I have stored here in my init file a message from the list describing the procedure Org uses to try to find an ID, you might find it useful: https://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg01195.html Regarding the second issue, of course, you should end up with a single properties drawer, and the template should ensure that. Best, Gustavo.
Bug: fill-paragraph in Org buffer [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi All,
Calling `fill-paragraph' in an Org buffer may leak paragraph boundaries,
and even heading boundaries, and break document structure.
I'm aware, of course, of `org-fill-paragraph'. Indeed, `org-mode' both
sets `fill-paragraph' function to `org-fill-paragraph' and remaps the
`fill-paragraph' binding to `org-fill-paragraph'. If I understand
correctly, this is technically redundant, but (a guess) probably the
remapping is kept for backwards compatibility reasons.
I don't know why this happens. As far as I get, `fill-paragraph' should
be calling `fill-paragraph-function', so I'd expect both to do the same
thing. But currently they don't.
Why would anyone call `fill-paragraph' instead of `org-fill-paragraph'?
Well, if you have some paragraph filling tweak you like, you might. For
example, one such instance is that widespread "fill-or-unfill" function,
which I think started with Artur Malabarba, and was eventually packaged
by Steve Purcell in https://github.com/purcell/unfill (180k+ downloads
at MELPA).
Either way, even when the binding for `fill-paragraph' is remapped to
`org-fill-paragraph' it should be at least safe (I think...) to call
`fill-paragraph' directly in an Org buffer, even when it might arguably
be better to call `org-fill-paragraph'.
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201019")
#+end_src
- Visit file =test.org= with contents:
#+begin_src org
,* Foo
- Boo
- Baz
,* Bar
:PROPERTIES:
:CATEGORY: home
:CUSTOM_ID: Bar
:END:
#+end_src
- Place point in the "Baz" list item under heading "Foo", and call `M-x
org-fill-paragraph'. As expected, the buffer is unchanged.
- Now call `M-x fill-paragraph'. The result is:
- The result is:
#+begin_src org
,* Foo
- Boo
- Baz
,* Bar
:PROPERTIES:
:CATEGORY: home :CUSTOM_ID: Bar
:END:
#+end_src
where `fill-paragraph' "filled" the contents of the properties drawer of
the following heading, despite three whole blank lines and a heading
along the way.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-19-gb1de0c-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi All,
I just found a misbehaving of `org-insert-heading-respect-content': when
it's called before the first heading in the buffer, it breaks the
structure of that fist heading by inserting a new heading on the line
the previous heading existed.
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201019")
#+end_src
- Visit file =test.org= with contents:
#+begin_src org
,#+title: Title
,* Foo
#+end_src
- Place point between the title and the "Foo" heading, and call
`org-insert-heading-respect-content' with "C-RET".
- The result is:
#+begin_src org
,#+title: Title
,* !* Foo
#+end_src
where "!" represents point position.
Which clearly does not "respect content" of the following heading.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-19-gb1de0c-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow
#[514 "\301\300\302Q\"\207" ["mailto" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("https" :follow
#[514 "\301\300\302Q\"\207" ["https" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("http" :follow
#[514 "\301\300\302Q\"\207" ["http" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow
#[514 "\301\300\302Q\"\207" ["ftp" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("help" :follow org-link--open-help) ("file"
:complete org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi"
Re: A small idea to simplify (further) time input in the date/time prompt
Hi All, Hi Bastien, if I may kindly bump this patch for review. Best regards, Gustavo. On Wed, 03 Jun 2020 at 10:14, Gustavo Barros wrote: Hi Bastien, On Tue, Jun 02 2020, Bastien wrote: Hi Gustavo, I like this idea, thanks for proposing it. We are in feature freeze for core features, so we have time to work on this for Org 9.5. [...] Would you agree? Would you like to work on this change? Well, I did give it a shot. And, as it turns out, this might be manageable within my limitations. A preliminary patch is attached, for comments. I took here the stance of following the same treatment which is given to am/pm times, and of using the letter "h" as sole main identifier. In particular, standard "HH:MM" times take precedence, as is the case for am/pm times. And duration specification with numbers only are presumed to be hours, which was already the case, the patch does not introduce any changes here. The input will match for this format for "number h 2-digit-number", where either the hour or the minutes, but not both, can be omitted and, if so, is presumed to be zero. 24h format is also presumed. With it, some example inputs/outputs for time in the date/time prompt: | input | output | |---+-| | 9h| 09:00 | | h45 | 00:45 | | 21h | 21:00 | | 9h-10h| 09:00-10:00 | | 9h--10h30 | 09:00-10:30 | | 18h30+h30 | 18:30-19:00 | | 18h30+1 | 18:30-19:30 | | 18h30+1h | 18:30-19:30 | And some sanity checks: | input | output | Observation | |---+--+---| | 10:00 9h | 10:00| by design, as for am/pm times | | 10am 9h | 10:00| expected from coming after am/pm handling | | 10:00-11h | 10:00-11:00 | | | 10h-11:00 | no match | am/pm also does not match here | | +9h | no match | | | -9h | no match | | | h | no match | | | 10h+h | no match | | | h5| no match | | | 10h70 | no match | | | 29h | 2020-06-04 Thu 05:00 | makes sense, same as for 29:00 | | 30h | no match | as per the regexp | WDYT? Best, Gustavo.
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi stardiviner, On Wed, 23 Sep 2020 at 11:17, stardiviner wrote: I have same issue when using Ivy. But can't reproduce this by disabled ivy-mode. And only happened when I refiled once, then the target will has two slash like this: #+begin_example Tasks/kk// (file.org) Tasks/hello/ (file.org) #+end_example Thank you for checking this and for confirming you also observe this behavior with Ivy. Regarding when ivy-mode is off, as I argued in the original report, the problem is indeed *not visible* when using `completing-read-default', the double trailing slash is nevertheless there if you inspect the value being passed as default value to the completing-read-function. The tests included with ivy-mode turned off were meant to emphasize things are expected to work with the suggested fix also in this case, in other words, that this is not "just a fix for ivy-mode", which is not the problem here. Best, Gustavo.
Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi Nick, On Mon, 21 Sep 2020 at 19:06, "Nicholas Savage" wrote: > I tried reproducing this, but I am having difficulties. "Baz" and the " - > State" stayed correctly aligned as I would have expected them, and not as you > have shown them. > > I am on emacs 28.0.50 though so maybe that has made the difference, with org > compiled from master as of a day or two ago. > > Nick > thank you for looking into it. You mentioned that you could not reproduce the second issue, but could you reproduce the first? (That is, the note being inserted at the margin rather than indented with the drawer). Anyway, indeed the Emacs and Org versions might be making a difference. Let's see if anyone else can reproduce. Gustavo.
Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
since some time I've been facing a small annoyance in the agenda, as
when I move point in my weekly agenda to a day which is not the first
one display and then hit "f" (`org-agenda-later') the agenda buffer is
scrolled up, hiding the top of the buffer, even though there is no lack
of space in the frame to fit the whole window.
This is not something that started after the most recent release, I had
been observing this previously. But I thought I might have missed some
fix, and waited to see if the issue was still up after the release came.
And it is. I'd say since a couple of weeks, but it is easy to be
tricked by memory in these cases, and it might be more.
I did some bisecting to be able to come up with a proper ECM, and it
turned out to boil down to the interaction between my
`scroll-conservatively' setting, and a combination in
`org-agenda-custom-commands' of two agendas with different time spans
(one weekly, the other daily).
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
;; Latest Org weekly build (Org 9.4)
(setq scroll-conservatively 1)
;; Not essential to reproduce, but included just to emphasize there is
no lack
;; of space to trigger the scrolling.
(setq org-agenda-window-setup 'only-window)
(setq org-agenda-custom-commands
'(("w" "Agenda"
((agenda ""
((org-agenda-overriding-header "Agenda (Week)")))
(agenda ""
((org-agenda-overriding-header "Habits (Day)")
(org-agenda-span 'day)))
#+end_src
Now, open this agenda with "M-x org-agenda RET w", move point to a day
further down the first agenda block (e.g. today is Monday, go to
Saturday). Call `org-agenda-later' ("f") and observe the buffer was
scrolled up so that the day of the week you were before is now made the
first line of the buffer, and the previous ones are hidden.
As these kinds of scrolling settings interactions might be somewhat
tricky to reproduce, I attach a couple of screenshots of the resulting
situation before and after calling `org-agenda-later' as described in
the ECM.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-agenda-window-setup 'only-window
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store
Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
the new release brought the interesting value `headline-data' to the
option `org-adapt-indentation'. However it introduces some issues
regarding the indentation of log entries in the `LOGBOOK' drawer, which
I describe below.
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
;; This is the latest Org weekly build (Org 9.4)
(setq org-adapt-indentation 'headline-data)
(setq org-log-into-drawer t)
(setq org-todo-keywords '((sequence "TODO(t)" "DONE(d@)")))
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,** Foo
#+end_src
- Change the todo state of "Foo" to "DONE" and add a corresponding note
with "C-c C-t d Baz C-c C-c".
- After expanding the `LOGBOOK' drawer we find:
#+begin_src org
,** DONE Foo
:LOGBOOK:
- State "DONE" from [2020-09-21 Mon 16:19] \\
Baz
:END:
#+end_src
In which we find that the drawer itself is honoring the setting in
`org-adapt-indentation' whereas the content of the drawer is not. And
it is expected that it did.
- After that, move point to the headline and demote it with ""
and examine the buffer again to find:
#+begin_src org
,*** DONE Foo
:LOGBOOK:
- State "DONE" from [2020-09-21 Mon 16:19] \\
Baz
:END:
#+end_src
We now see the demotion did bring the content of `LOGBOOK' to align
with the headline, but in doing so, broke the plain list structure of
the note, removing the indent of "Baz", which is also not expected.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-adapt-indentation 'headline-data
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO(t)" "DONE(d@)"))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs")
("shell"
Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
some time ago, I've reported an issue regarding duplicity of the default
candidate in `org-refile'
(https://orgmode.org/list/87lftw1k2n@gmail.com/). The problem was
that, when using `org-refile-use-outline-path' an "extra" slash was
appended at the end of every path, but candidates were stored in
`org-refile-history' without that extra slash. Bastien took care of
that and indeed changed things so as to pass the elements to
`org-refile-history' with the trailing slash as appropriate.
At the time, I reported a difference of behavior between
`completing-read-default' and `ivy-completing-read' after the mentioned
commit by Bastien. But the issue did not appear for Bastien, which does
not use Ivy, and I also was not able to diagnose the problem properly.
I felt I didn't have enough to offer as to insist, so I resorted to an
old hack of mine. But the new release this week (thank you very much!,
btw) has bitten me again on this, so I went back to some digging, and
hopefully I can do a better job this time in diagnosing the problem and
suggesting a fix.
An ECM to reproduce the issue as it currently stands is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
(add-to-list 'load-path "~/.emacs.d/elpa/ivy-20200826.955")
;; Those are the latest Org weekly build (Org 9.4) and the current up
to date
;; Ivy at Melpa
(setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
(require 'ivy)
(ivy-mode)
;; Bear with me, the problem is not with Ivy, I'll demonstrate that.
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,* Top heading 1
,* Top heading 2
,** Entry 1
,** Entry 2
#+end_src
- Go to heading "Entry 1", refile it to "Top heading 1"
- Go to heading "Entry 2", and call `org-refile'
- Observe the available candidates, and notice "test.org/Top heading 1/"
is there twice, once as the default candidate, with a *double*
trailing slash, and also on the paths list, with a single trailing
slash.
I've tried to pin down what is going on here and my understanding is
that Bastien's fix on that previous thread did indeed correct the
problem of the missing trailing slash in `org-refile-history' and this
indeed corresponds correctly to the state of the completion "collection"
(the let bound `tbl' variable in `org-refile-get-location'), as it
should. But there remained a couple of instances in
`org-refile-get-location' which added the trailing slash considering
`org-refile-history' didn't have them, so that when this is done, we get
a double trailing slash.
The two instances are: 1) when the completion function is actually
called:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (concat (car org-refile-history)
extra
#+end_src
2) And three lines bellow, on the let binding:
#+begin_src emacs-lisp
(let* ((last-refile-loc (car org-refile-history))
(last-refile-loc-path (concat last-refile-loc extra)))
...)
#+end_src
In both instances, we are getting the `car' of `org-refile-history'
which now already has `extra' (that is, the trailing slash) and adding
it again.
My suggested fix is to remove these `extra's in duplicity, they are
remnants of when `org-refile-history' didn't have them already. That
is:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (car org-refile-history
#+end_src
And:
#+begin_src emacs-lisp
(let* ((last-refile-loc (car org-refile-history))
(last-refile-loc-path last-refile-loc))
...)
#+end_src
Of course, the second opens some opportunity to simplify the code that
follows considering `last-refile-loc-path' and `last-refile-loc' are now
identical.
Why I think this is the problem and the correct way to fix it:
1) If you add inspection points at the appropriate locations for the
sexps =(concat (car org-refile-history) extra)= and =(concat
last-refile-loc extra)= you will find the double trailing slash there,
and it shouldn't be there.
2) The visual manifestation of this double trailing slash in the default
candidate with `ivy-mode' is there therefore independently of
`ivy-mode`. Indeed, `ivy-mode' basically sets
`completing-read-function' to `ivy-completing-read', which in turn calls
its main API function `ivy-read'. `ivy-completing-read' just passes
along the `def' argument without manipulating it. As far as I can see,
`ivy-read' also does not change it before calling
`read-from-minibuffer'.
Why `completing-read-default' does not show this second trailing slash
of the `def' argument it received is another matter. But it's there...
3) I've tested this
Re: "text mode" org mode
Hi Emanuel, On Tue, 15 Sep 2020 at 14:27, Emanuel Berg via "General discussions about Org-mode." wrote: > Can I tell Org mode to don't change editing back and > forth, also don't collapse items in and out, i.e. > virtually text mode, only I still want the font lock > and to be able to use the mode to set keys, the > functions to compile into a PDF, and so forth. > > TIA That's probably not something most Org users would do, but I think you'd get close to what you want with: (add-hook 'org-mode-hook 'visible-mode) HTH. Best, Gustavo.
Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi Bastien, On Thu, 10 Sep 2020 at 02:34, Bastien wrote: Hi Gustavo, Gustavo Barros writes: As of recently, repeating tasks are no longer showing up in the agenda for future dates. Below a minimal example of the issue: Just confirming this issue, to make sure we don't forget it. Thank you for keeping track of this. But this issue is currently not affecting us any longer. If I recall correctly, the problem had emerged after a fix to another issue. Kyle was able to identify the commit, and the discussion then converged to revert that commit, thus restoring the behavior which prompted this report of mine, until a fix for the other issue which did not cause this could be found. Some of the relevant messages are: - Kyle's message stating the commit was reverted, with the corresponding commit numbers: https://orgmode.org/list/87o8rx1cmf@kyleam.com/ - The issue whose fix caused this regression is mentioned at: https://orgmode.org/list/87o8tim83q@kyleam.com/ I think (not sure) that that issue is still pending. Best, Gustavo.
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Bastien, On Fri, 04 Sep 2020 at 14:45, Bastien wrote: Hi Gustavo, I don't know if there is a strong reason to hard-code the set of keys in `org-speed-commands-default'. But, if there isn't, could you consider (somehow) exposing the whole set of `org-speed-commands' to user customization? Yes, I think the two variables should be merged into a single `org-speed-commands' option. Unless someone strongly objects, I will do after Org 9.4. Thanks for the suggestion, Thank you for considering this suggestion. I'm sure many people here have some fat-fingered "friend" who will rejoice to use the speed-keys with more tranquility. ;-) Best, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, On Fri, 04 Sep 2020 at 14:37, Bastien wrote: You mean by adding something like (org-defkey org-mode-map (kbd "C-a") #'org-beginning-of-line) in org-keys.el? I'm pretty sure such "hard" remapping breaks an Emacs convention--I'll ask emacs-devel, because that would indeed fix the problem you are reporting. Thanks for insisting, Yes, that is what I mean. I understand this kind of hard remapping would not be conventional, and is not the best solution. But, in this case, it is not Org, but visual-line-mode which is going a bit too far. Org takes care of the presence of visual-line-mode, but the opposite does not occur. Anyway, since you are asking emacs-devel, perhaps ask too if it would be possible for a major mode to set, something like `beginning-of-line-function' etc, which visual-line-mode, or even the original functions it substitutes, could then honor, as is done with `fill-paragraph-function', for example. Something of the sort might be the proper solution. "Hard" rebinding is what Org can currently do on its side, as far as I can tell. Best, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, On Fri, 04 Sep 2020 at 17:20, Bastien wrote: > Hi Marco, > > Marco Wahl writes: > >> (add-hook 'visual-line-mode-hook >> (lambda () (when (derived-mode-p 'org-mode) >>(local-set-key (kbd "C-a") #'org-beginning-of-line) >>(local-set-key (kbd "C-e") #'org-end-of-line) >>(local-set-key (kbd "C-k") #'org-kill-line > > Nice -- I've added this to https://orgmode.org/worg/org-hacks.html I do think my other workaround is worth pondering to be included, so that this would work out-of-the-box. Do you see any particular drawbacks of setting these bindings directly (that is, not by remapping) in `org-mode-map'? Best, Gustavo.
