Re: [BUG] after update to 9.5, starting org mode results in cache error messages [9.5 (9.5-gd4e192 @ c:/Users/scott/.emacs.d/straight/build/org/)]
Scott Otterson writes: > I just updated to org v 9.5, and now, when I open an org file, I get a > cache error message (between the '=' lines below). Before 9.5, I didn't > have this problem. Thanks for reporting! We are enabling org-element-cache by default. That's where the warnings are coming from. > The element is: "(paragraph (:begin 549781 :end 549835 :contents-begin > ... > The real element is: "(paragraph (:begin 549660 :end 549835 This backtrace is really strange. I have seen some advised functions in your config. Do you happen to advice built-in org-mode functions, especially from org-element? Also, if you observe this warning often, can you set org-element--cache-self-verify to 'backtrace and report the detailed backtrace next time you see the warning? Best, Ihor
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
On Sat, Oct 30, 2021 at 10:46 PM Ihor Radchenko wrote: > > Aaron Jensen writes: > > >> Do you always see "Current command: nil"? If you do, do you have any > >> minor modes that change text in Org buffers? > > > > I don't know, but I'll keep an eye out for the next time it happens. > > If possible, can you also upgrade to latest main? I just pushed a patch > providing additional backtrace to the warning. Hopefully, it can reveal > more details. Will do > > And this to change the behavior of org-indent: > > > > (aj-defadvice aj--org-indent--compute-prefixes-hanging-bullets () > > :override #'org-indent--compute-prefixes > > "Compute prefix strings with hanging header bullets." > > ... > > The was a problem related to org-indent recently [1]. If your Org is > older than b135b8c7, there is a small chance that the warning might be > fixed after update. > > [1] https://list.orgmode.org/878ryev6q2.fsf@localhost/T/#t It wasn't when I just checked, but I updated packages today so it's possible that I was behind on this. I'll let you know if I see it again. The second error I reported was on the latest main. > > As for minor modes, yes: > > > > https://github.com/awth13/org-appear > > ... > > And prettify-symbols-mode: > > I also use org-appear and prettify-symbols-mode. Hopefully not an issue. > > > https://github.com/integral-dw/org-superstar-mode > > Not sure here. It would be helpful if you try to disable > org-superstar-mode and see if it helps, I'll leave it on for a bit longer to see what still repros. If it happens again, I'll try disabling it. > > Warning (emacs): org-element--cache: Added org-data parent to > > non-headline element > > This is a bad one. I was really hoping that I fixed it. Can you set > org-element--cache-self-verify to 'backtrace before loading Emacs and > post the full backtrace if you see this warning again? Done, I'll report back. Thanks, Aaron
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Aaron Jensen writes: > I just got this warning: > > Warning (emacs): org-element--cache: Added org-data parent to > non-headline element This is a bad one. I was really hoping that I fixed it. Can you set org-element--cache-self-verify to 'backtrace before loading Emacs and post the full backtrace if you see this warning again? Best, Ihor
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Aaron Jensen writes: >> Do you always see "Current command: nil"? If you do, do you have any >> minor modes that change text in Org buffers? > > I don't know, but I'll keep an eye out for the next time it happens. If possible, can you also upgrade to latest main? I just pushed a patch providing additional backtrace to the warning. Hopefully, it can reveal more details. > And this to change the behavior of org-indent: > > (aj-defadvice aj--org-indent--compute-prefixes-hanging-bullets () > :override #'org-indent--compute-prefixes > "Compute prefix strings with hanging header bullets." > ... The was a problem related to org-indent recently [1]. If your Org is older than b135b8c7, there is a small chance that the warning might be fixed after update. [1] https://list.orgmode.org/878ryev6q2.fsf@localhost/T/#t > As for minor modes, yes: > > https://github.com/awth13/org-appear > ... > And prettify-symbols-mode: I also use org-appear and prettify-symbols-mode. Hopefully not an issue. > https://github.com/integral-dw/org-superstar-mode Not sure here. It would be helpful if you try to disable org-superstar-mode and see if it helps, > I think that's it (and yes, that's a lot, heh). That's not a lot ;) Best, Ihor
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
On Sat, Oct 30, 2021 at 12:45 PM Aaron Jensen wrote: > > On Sat, Oct 30, 2021 at 11:37 AM Ihor Radchenko wrote: > > > > Aaron Jensen writes: > > > > > I don't have a consistent repro, but I am seeing this error often. At > > > different times it is in different files and lists different nodes. > > > > Thanks for reporting! > > > > > Warning (emacs): org-element--cache: Unregistered buffer modifications > > > detected. Resetting. > > > If this warning appears regularly, please report it to Org mode mailing > > > list (M-x org-submit-bug-report). > > > The buffer is: 20211025-journal > > > Current command: nil Disable showing Disable logging > > > > Do you always see "Current command: nil"? If you do, do you have any > > minor modes that change text in Org buffers? I just got this warning: Warning (emacs): org-element--cache: Added org-data parent to non-headline element: (item (:bullet "- " :begin 1935 :end 1982 :contents-begin 1937 :contents-end 1982 :checkbox nil :counter nil :structure ((1935 0 "- " nil nil nil 1982) (1982 0 "- " nil nil nil 2032)) :pre-blank 0 :post-blank 0 :post-affiliated 1935 :tag nil :mode item :granularity element :cached t :parent (plain-list (:type unordered :begin 1935 :end 2032 :contents-begin 1935 :contents-end 2032 :structure ((1935 0 "- " nil nil nil 1982) (1982 0 "- " nil nil nil 2032)) :post-blank 0 :post-affiliated 1935 :mode planning :granularity element :cached nil :parent (section (:begin 1935 :end 2032 :contents-begin 1935 :contents-end 2032 :robust-begin 1935 :robust-end 2030 :post-blank 0 :post-affiliated 1935 :mode section :granularity element :cached nil :parent (headline (:raw-value "[2021-10-15 Fri]" :begin 1915 :end 2032 :pre-blank 1 :contents-begin 1935 :contents-end 2032 :robust-begin 1937 :robust-end 2030 :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 1915 :title "[2021-10-15 Fri]" :mode nil :granularity headline :cached nil :parent (org-data (:begin 1 :contents-begin 1 :contents-end 2030 :end 2030 :robust-begin 67 :robust-end 2028 :post-blank 0 :post-affiliated 1 :path "" :mode org-data :ID "09182EC8-8E37-4ABA-8E20-768D9A4CD34B" :CATEGORY "" :granularity headline) nil) :org-element--cache-sync-key (4 . 1913))) :org-element--cache-sync-key (4 . 1932))) :org-element--cache-sync-key (4 . 1933))) :org-element--cache-sync-key (4 . 1934))) Aaron
Re: [BUG] Elisp error when exporting citation [9.5 (release_9.5-104-g2b1fc6 @ /home/quintus/.emacs.d/org-mode/lisp/)]
Am Samstag, dem 30. Oktober 2021 schrieb Marvin Gülker:
> trying to export the following org-document results in an Elisp error:
>
> #+TITLE: Test
> #+AUTHOR: Testauthor
> #+LANGUAGE: de
> #+bibliography: /tmp/mwe/mwe.bib
> #+cite_export: csl /tmp/mwe/juristische-schulung.csl
>
> Test [cite:raubenheimer1996dongle p. 76; /Dreier/, in: @ds2018urhg § 69d
> Rn. 10]
It turns out my cite command lacks an @ before `raubenheimer1996dongle'.
With the @ it does not error. I leave it to the org maintainers to
decide whether the resulting error should be more human-readable or not.
However, if exported to LaTeX the italic on the name `Dreier' comes out
wrong:
{ Dreier}, in: Dreier/Schulze
The braces are included literally in the PDF, with the first brace being
italicised. Exporting to HTML applies the italic correctly.
-quintus
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland | kont...@guelker.eu| O<
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
On Sat, Oct 30, 2021 at 11:37 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > I don't have a consistent repro, but I am seeing this error often. At
> > different times it is in different files and lists different nodes.
>
> Thanks for reporting!
>
> > Warning (emacs): org-element--cache: Unregistered buffer modifications
> > detected. Resetting.
> > If this warning appears regularly, please report it to Org mode mailing
> > list (M-x org-submit-bug-report).
> > The buffer is: 20211025-journal
> > Current command: nil Disable showing Disable logging
>
> Do you always see "Current command: nil"? If you do, do you have any
> minor modes that change text in Org buffers?
I don't know, but I'll keep an eye out for the next time it happens.
As for minor modes, yes:
https://github.com/awth13/org-appear
https://github.com/integral-dw/org-superstar-mode
And prettify-symbols-mode:
(push '("[ ]" . "☐") prettify-symbols-alist)
(push '("[X]" . "☑") prettify-symbols-alist)
(push '("[-]" . "❍") prettify-symbols-alist)
(prettify-symbols-mode)
And this to change the behavior of org-indent:
(aj-defadvice aj--org-indent--compute-prefixes-hanging-bullets ()
:override #'org-indent--compute-prefixes
"Compute prefix strings with hanging header bullets."
(setq org-indent--heading-line-prefixes
(make-vector org-indent--deepest-level nil))
(setq org-indent--inlinetask-line-prefixes
(make-vector org-indent--deepest-level nil))
(setq org-indent--text-line-prefixes
(make-vector org-indent--deepest-level nil))
(let* ((indent 2))
(dotimes (n org-indent--deepest-level)
(aset org-indent--heading-line-prefixes n
(make-string (- indent 2) ?\s))
(aset org-indent--inlinetask-line-prefixes n
(make-string indent ?\s))
(aset org-indent--text-line-prefixes n
(make-string indent ?\s)
I think that's it (and yes, that's a lot, heh).
Thanks,
Aaron
Re: tangle option to not write a file with same contents?
Max, thanks for the reply. > In the meanwhile I realized that check for modification by user should > be performed *before* tangle, and hash to detect changes is > appropriate for such purpose. I think, a copy of tangled file just to > detect modification will cause some tension from users. i guess you mean org's current "cache" stuff? > Comparison of earlier and current tangle results should be done at the > end, so implementation should be independent. There is no point to use > hash, size + byte to byte comparison is fast and reliable. that makes sense. cheers, Greg
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Aaron Jensen writes: > I don't have a consistent repro, but I am seeing this error often. At > different times it is in different files and lists different nodes. Thanks for reporting! > Warning (emacs): org-element--cache: Unregistered buffer modifications > detected. Resetting. > If this warning appears regularly, please report it to Org mode mailing list > (M-x org-submit-bug-report). > The buffer is: 20211025-journal > Current command: nil Disable showing Disable logging Do you always see "Current command: nil"? If you do, do you have any minor modes that change text in Org buffers? Best, Ihor
Re: Org default is Left-to-right
Daniel Fleischer writes: > Ihor Radchenko writes: >> See https://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00285.html > > OK, so 10 years ago on Emacs 24 it might have caused some slowdown on > large Org files. It wasn't clear if these people needed RTL or not, > because I set it to nil as soon as I open my Org files. I guess I'll > use a hook in my config. You asked why Org does not use default. That was the reason. Unfortunately, the original test file is not available anymore, so we cannot easily test if the slowdown is still there. I tried to create a large file in Persian, but I cannot see any difference in performance when bidi-paragraph-direction is nil or 'left-to-right. However, I was able to see a difference using the attached file when moving through an artificially created very long line in the second heading. In my testing, setting bidi-paragraph-direction to nil *improves* the performance. > You could also turn it back to nil and see if people complain, as part > of 9.6. So, my datapoint indicates that changing bidi-paragraph-direction back to nil could make sense. However, I am not using right-to-left text daily in my system. Testing from people who do use right-to-left languages would be appreciated. Best, Ihor Text credit: https://ganjoor.net/khayyam/robaee/ test-bidi.org Description: Lotus Organizer
[BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
I don't have a consistent repro, but I am seeing this error often. At
different times it is in different files and lists different nodes.
Warning (emacs): org-element--cache: Unregistered buffer modifications
detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing list
(M-x org-submit-bug-report).
The buffer is: 20211025-journal
Current command: nil Disable showing Disable logging
Emacs : GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.1.0, NS
appkit-2113.00 Version 12.0.1 (Build 21A559))
of 2021-10-29
Package: Org mode version 9.5 (9.5-g49e2f6 @
/Users/myuser/.emacs.d/straight/29/straight/build/org/)
current state:
==
(setq
org-roam-db-location "/Users/myuser/.emacs.d/var/org-roam.db"
org-mac-grab-devonthink-app-p nil
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "xxx"
org-hide-emphasis-markers t
org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-download-file-format-function 'org-download-file-format-default
org-roam-mode-hook '(evil-motion-state)
org-agenda-custom-commands '((" " "Agenda"
((agenda "" ((org-agenda-span 'day)))
(tags "refile"
((org-agenda-overriding-header "Tasks to
Refile")
(org-tags-match-list-sublevels nil))
)
(tags-todo "-refile/!"
((org-agenda-overriding-header "Tasks")
(org-agenda-skip-function
'(org-agenda-skip-entry-if 'deadline
'scheduled)
)
)
)
(tags "-refile/"
((org-agenda-overriding-header
"Tasks to Archive")
(org-agenda-skip-function
'aj/skip-non-archivable-tasks)
(org-tags-match-list-sublevels nil))
)
)
)
)
org-agenda-skip-scheduled-if-done t
org-agenda-files '("")
org-journal-dir ""
org-journal-date-format "%a, %-d %b %Y"
org-capture-templates '(...
)
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-refile-targets '((nil :maxlevel . 9) (aj/refile-target-files :maxlevel .
3))
org-export-before-parsing-hook '(org-attach-expand-links)
org-default-notes-file "notes.org"
org-roam-find-file-hook '(org-roam-buffer--setup-redisplay-h
org-roam--register-completion-functions-h
org-roam--replace-roam-links-on-save-h
org-roam-open-id-with-org-roam-db-h
org-roam-db-autosync--setup-update-on-save-h)
org-refile-use-outline-path 'file
org-publish-timestamp-directory "/Users/myuser/.emacs.d/var/org/timestamps/"
org-archive-hook '(org-attach-archive-delete-maybe)
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-ascii-format-drawer-function #[771 ".\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-mac-grab-Outlook-app-p nil
org-catch-invisible-edits 'show
org-mac-grab-Addressbook-app-p nil
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '(aj--org-download org-tempo-setup aj--add-recalc-table-hook
evil-org-mode aj--org-line-spacing
#[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
aj/org-prettify-symbols org-superstar-mode org-indent-mode
orgonomic-mode org-appear-mode org-eldoc-load
electric-pair-local-mode aj--disable-line-numbers
flyspell-mode)
org-babel-load-languages '((shell . t))
org-src-window-setup 'current-window
org-id-locations-file
Re: tangle option to not write a file with same contents?
On 30/10/2021 00:58, Greg Minshall wrote: Some hash-based build systems are mentioned in that thread. Since that time more more similar tools have appeared, e.g. buck, reimplementations of DJB's redo https://cr.yp.to/redo.html i think different people will settle on different build tools. Greg, I see your point and often I am not happy to change established workflow as well. Partially a reason is that it requires some efforts. This particular issue should be handled in Org code. (Unfortunately it requires some efforts as well.) On the other hand, it may be treated in a more general way by external hash build tool. Actually I have no suggestion concerning particular build system. E.g. buck is too heavy (python+java), and my experience is not purely positive. It seems `compare-buffer-substrings` has more logic than just byte to byte comparison. Is it to handle alternatives for unicode character alternatives? For tangled buffer it should be size that is checked first... you are right, it definitely makes sense to look first at size. (which is what, e.g., rsync(1) does.) also, probably i needn't have mentioned `compare-buffer-substrings` -- i was really just trying to suggest "simple" (which maybe i anti-did?). I think, `compare-buffer-substrings' is a good starting point. It is ready to use and I am not aware of obvious problems with it. (Can it happen that change of file encoding would be discarded since buffers are equal?) I just was curious whether the function performs size check. It does, but comparison is not identity test, so it is at the end of the function. In the meanwhile I realized that check for modification by user should be performed *before* tangle, and hash to detect changes is appropriate for such purpose. I think, a copy of tangled file just to detect modification will cause some tension from users. Comparison of earlier and current tangle results should be done at the end, so implementation should be independent. There is no point to use hash, size + byte to byte comparison is fast and reliable. A subtle point partially discussed earlier is overwriting content of existing file vs. tangling to temporary file and atomic replacement. In most cases the latter is preferred. However if target file is open for debugging in an editor, content should be written to the existing file (preserving inode). It allows to preserve unsaved changes if the editor notifies user that file is modified.
Re: Org default is Left-to-right
Ihor Radchenko writes: > See https://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00285.html OK, so 10 years ago on Emacs 24 it might have caused some slowdown on large Org files. It wasn't clear if these people needed RTL or not, because I set it to nil as soon as I open my Org files. I guess I'll use a hook in my config. You could also turn it back to nil and see if people complain, as part of 9.6. -- Daniel Fleischer
Re: Sub-figures in Org Mode
Hi Jason, sorry for the late reply. Jason Ross writes: > I'm looking at declaring a "figure" block the way you are, but > `org-element-map'ing over the links inside the block and processing them > with the "normal" link-handling machinery. That way, image options work > the same way in a subfigure as they do normally. I really like your idea, and it's more consistent with the Org syntax, since (as you say) the images behave like images and it is not necessary to enter the options via marks within the link description, which is somewhat hacky. I think your idea could also be adapted to LaTeX (and HTML) backends... Best regards, Juan Manuel
Re: Introducing Org-transclusion
Noboru Ota writes: > This is my first post to Org mailing list. Welcome ;) > Is this type of add-on packages worth considering for inclusion into > Org? I am asking this question without knowing the practice of how > these things are considered in this mailing list; apologies if I am > missing the context. The feedback I have received includes requests for > me to put this discussion forward in this mailing list, so some people > find it useful if Org-transclusion were part of Org. You have my +100500 to have this package as part of Org :D The package may allow several interesting things in Org: 1. An alternative way to structure headings Currently, we have a rigid headline structures in Org and alternative tag-based approaches like Org Roam. Headline transclusion will allow same subtree under several headings (aka file system symlinks). 2. A much faster tangle system. If we can directly transclude and sync contents of source blocks with actual programming language buffer, C-c ' can trivially support flycheck-mode and provide a more IDE-like experience while still benefiting from literate programming style. 3. Visible #+INCLUDE directives. I recall multiple requests to be able to see the INCLUDEd files right inside source Org buffer. 4. Dynamic Org files like agenda views, but made of transcuded headlines. Such files can be kept in Org mode with all its features. Transculation has been requested many times by different users. Some relevant links: - https://emacs.stackexchange.com/questions/51814/embed-org-task-list-from-other-subtree - https://www.reddit.com/r/emacs/comments/dz5xeb/is_there_a_way_to_include_an_org_file_in_another/ - https://www.reddit.com/r/emacs/comments/flxqei/cloningmirroring_a_region_to_some_other_location/fl22ele/ - https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00141.html - https://emacs.stackexchange.com/questions/57608/split-code-across-multiple-src-blocks - https://lists.gnu.org/archive/html/help-gnu-emacs/2020-06/msg00151.html - https://reddit.com/r/emacs/comments/debean/possible_to_embed_another_org_file_or_entry_in_an/]] Other attempted implementations: - https://github.com/legalnonsense/org-clones - https://github.com/magnars/multifiles.el - https://github.com/vspinu/lentic - https://github.com/whacked/transclusion-minor-mode Best, Ihor
Re: Org default is Left-to-right
Daniel Fleischer writes: > nil is Emacs default. I don't understand why Org chooses to align > everything to the left, disregarding any RTL language. Org works great > with RTL and even with mixed languages, as many people can attest. See https://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00285.html Best, Ihor
Org default is Left-to-right
Hi, in org.el , when defining the mode there's the code (setq bidi-paragraph-direction 'left-to-right) which makes everything left-to-right instead of 'nil which smartly aligns paragraphs either LTR or RTL according to the language of that paragraph. nil is Emacs default. I don't understand why Org chooses to align everything to the left, disregarding any RTL language. Org works great with RTL and even with mixed languages, as many people can attest. Can we consider dropping this line? LTR people wouldn't notice any difference but RTL people will appreciate it without needing to override it using a hook or toggling it with some elisp code (like I did). Thanks, -- Daniel Fleischer
Re: Introducing Org-transclusion
Hi Noboru, Noboru Ota writes: > I would like to introduce an add-on package I have been developing for > about one year and ask for discussion / advice. > > The package is named "Org-transclusion", and is available on GitHub at > https://github.com/nobiot/org-transclusion. Simply put, it lets you > insert a copy of text content via a file link or ID link within an Org > file. The GitHub repository contains links short video presentations > and documentation in detail. I installed your package a few months ago and I have to say that it works quite well, although I have not had, at the moment, the opportunity to make intensive use of it. What I can say is that the concept seems very interesting to me. Very nice package. Best regards, Juan Manuel
Introducing Org-transclusion
Hi everyone, This is my first post to Org mailing list. I would like to introduce an add-on package I have been developing for about one year and ask for discussion / advice. The package is named "Org-transclusion", and is available on GitHub at https://github.com/nobiot/org-transclusion. Simply put, it lets you insert a copy of text content via a file link or ID link within an Org file. The GitHub repository contains links short video presentations and documentation in detail. Judging from feedback from users, it is used for academic writing such as PhD dissertation, technical writing with source code embedded as transclusions, and note taking. I am not a programmer by trade; I originally developed it to help me write a book. It's a very thin volume on a business topic, which has nothing to do with Emacs or Org mode. Is this type of add-on packages worth considering for inclusion into Org? I am asking this question without knowing the practice of how these things are considered in this mailing list; apologies if I am missing the context. The feedback I have received includes requests for me to put this discussion forward in this mailing list, so some people find it useful if Org-transclusion were part of Org. I am in the process of assigning the copyright to FSF (my email request has not been responded to, so I might need to do it again). I would be also fine to put Org-transclusion on GNU ELPA (or NonGNU ELPA) and see it to mature before this discussion can be had. Of course, I would also understand if there is an outright decision to not consider my request at this point in time. I will appreciate your comments and discussions. Thank you. Noboru
Re: Bug: Bad behavior of refill-mode at end of org-mode file [9.4.4 (9.4.4-11-g9e8215-elpa @ /home/joh/.emacs.d/elpa/org-20210118/)]
Johannes Mueller writes: > When using refill-mode in combination with org-mode adding a new section or a > list item at the end of the buffer, obviously because refill-mode steps in and > deletes the line break before the headline marker or the list marker. I would say that it is a bug in refill-mode. Org mode correctly sets `fill-paragraph-function', but refill-mode does not respect it. Best, Ihor
[BUG] Elisp error when exporting citation [9.5 (release_9.5-104-g2b1fc6 @ /home/quintus/.emacs.d/org-mode/lisp/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Dear all,
trying to export the following org-document results in an Elisp error:
#+TITLE: Test
#+AUTHOR: Testauthor
#+LANGUAGE: de
#+bibliography: /tmp/mwe/mwe.bib
#+cite_export: csl /tmp/mwe/juristische-schulung.csl
Test [cite:raubenheimer1996dongle p. 76; /Dreier/, in: @ds2018urhg § 69d
Rn. 10]
In case you wonder why there's a name in the prefix for @ds2018urhg:
another speciality of German judicial citations. We have a special kind
of literature called commentaries. In these, a specific law's articles
are explained one by one, where different authors comment on different
articles. In the above example, Mr. Dreier comments § 69d of the German
Copyright Act (UrhG). Still, the entire commentary is to be cited as one
work. Each footnote is prefixed with the (typically italicised) name of
the person commenting the specific article, resulting in the above cite
command.
The exported footnote should have looked like this:
Raubenheimer, CR 1996, 69, 76; Dreier, in: Dreier/Schulze (Hrsg.), UrhG, 6.
Aufl. 2018
This is mwe.bib:
@Article{raubenheimer1996dongle,
author = {Andreas Raubenheimer},
title= {Beseitigung/Umgehung eines technischen Programmschutzes
nach UrhG und UWG},
journaltitle = {Computer und Recht},
shortjournal = {CR},
year = {1996},
pages = {69-79},
langid= {german}}
@commentary{ds2018urhg,
title = "Urheberrechtsgesetz",
shorttitle = "UrhG",
editor = "Thomas Dreier and Gernot Schulze",
edition = "6",
year = "2018",
publisher = "C.H. Beck",
location = "München"
}
juristische-schulung.csl is
https://github.com/citation-style-language/styles/raw/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl
I use Org mode version 9.5 (release_9.5-104-g2b1fc6 @
/home/quintus/.emacs.d/org-mode/lisp/).
Citeproc.el is at 34e66583d95a8d80fb5b9f2960f3382ca0e6d3ab.
The following error is produced when exporting to HTML (C-c C-e h o):
Debugger entered--Lisp error: (wrong-type-argument plistp (prefix .
#("Dreier, in:" 3 9 (:parent (italic (:begin 179 :end 187
:contents-begin 180 :contents-end 186 :post-blank 0 :parent (citation-reference
(:key "ds2018urhg" :begin 178 :end 217 :post-blank 0 :prefix ... :suffix ...
:parent ...))) #("Dreier" 0 6 (:parent #7 13 18 (:parent
(citation-reference (:key "ds2018urhg" :begin 178 :end 217 :post-blank 0
:prefix (#(" " 0 1 ...) (italic ... ...) #(", in: " 0 6 ...)) :suffix (#(" §
69d Rn. 10" 0 13 ...)) :parent (citation (:style nil :begin 143 :post-blank 0
:end 218 :prefix ... :contents-begin 178 :contents-end 217 :parent ...)
#7)))
plist-put((prefix . #("Dreier, in:" 3 9 (:parent (italic (:begin
179 :end 187 :contents-begin 180 :contents-end 186 :post-blank 0 :parent
(citation-reference (:key "ds2018urhg" :begin 178 :end 217 :post-blank 0
:prefix ... :suffix ... :parent ...))) #("Dreier" 0 6 (:parent #5 13 18
(:parent (citation-reference (:key "ds2018urhg" :begin 178 :end 217 :post-blank
0 :prefix (#(" " 0 1 ...) (italic ... ...) #(", in: " 0 6 ...)) :suffix (#(" §
69d Rn. 10" 0 13 ...)) :parent (citation (:style nil :begin 143 :post-blank 0
:end 218 :prefix ... :contents-begin 178 :contents-end 217 :parent ...)
#5)) :prefix (#("raubenheimer1996dongle p. 76" 0 28 (:parent (citation
(:style nil :begin 143 :post-blank 0 :end 218 :prefix (#4) :contents-begin 178
:contents-end 217 :parent (paragraph (:begin 138 :end 219 :contents-begin 138
:contents-end 219 :post-blank 0 :post-affiliated 138 :parent ...) #("Test " 0 5
...) #7 #("\n" 0 1 ...))) (citation-reference (:key "ds2018urhg" :begin 178
:end 217 :post-blank 0 :prefix (... ... ...) :suffix (...) :parent #7)))
(setcar (cdr element) (plist-put (nth 1 element) property value))
(if (stringp element) (org-add-props element nil property value) (setcar
(cdr element) (plist-put (nth 1 element) property value)) element)
org-element-put-property(((id . "ds2018urhg") (prefix . #("Dreier,
in:" 3 9 (:parent (italic (:begin 179 :end 187 :contents-begin 180
:contents-end 186 :post-blank 0 :parent (citation-reference ...)) #("Dreier" 0
6 (:parent #7 13 18 (:parent (citation-reference (:key "ds2018urhg" :begin
178 :end 217 :post-blank 0 :prefix (... ... ...) :suffix (...) :parent
(citation ... #7)) (suffix) (locator . #("69d Rn. 10" 0 10 (:parent
(citation-reference (:key "ds2018urhg" :begin 178 :end 217 :post-blank 0
:prefix (... ... ...) :suffix (...) :parent (citation ... #9)) (label .
"section") (location . #(" § 69d Rn. 10" 0 13 (:parent (citation-reference
(:key
