Re: [O] [RFC] Document level property drawer
Hi Adam, Adam Porter writes: > There are a lot of deprecation recommendations in your attached > document: > > > I propose to depricate property-keywords > > I propose to depricate the Options-keyword > > I propose to relabel these keywords as document keywords > > I propose to depricate the #+CATEGORY syntax > > I propose to depricate the #+FILETAGS syntax > > I propose to depricate the #+COLUMNS syntax > > I propose to depricate the #+ARCHIVE syntax > > I propose to depricate the TODO-keywords > > I propose to depricate the priorities-keyword > > I propose to depricate the tags-keyword > > I propose to depricate the link-keyword > > I propose to depricate the constants-keyword > > I propose to depricate the setupfile-keyword > > I propose to depricate the Macro-keyword > > The thoroughness of your investigation is admirable. Thanks! > However, I propose that we don't deprecate any of those. Org has been > around for over a decade now. Such drastic changes would not serve > users well. I think you're right in the fact that Org mode will need to continue to understand them. I'll say again that I wrote the document quite a while ago. It's unedited and initially meant for my eyes only. So "to deprecate" may be perceived to strong and I certainly didn't mean to cut them out straight away. I don't think the diverse use of keywords are good for the future of Org mode though, and I do think there is value in trying to consolidate functionality and possibly promote something that is more clear and easy to understand. Many of the existing keywords have a corresponding property-syntax. For those I think it would be good to start promoting using properties instead of keywords (as I've written over and over again :) ). Other keywords affect the Org mode configuration for the current buffer. They are basically shortcuts to customization for the current buffer. Which led me to proposing a settings drawer. It may be that it initially is enough to just update the documentation with a chapter about keywords and categorizing them in some groups based on intended purpose. I do however still like the idea of collecting those keywords in a drawer instead of having them spread out in the document. > Note that I'm taking your use of the word "deprecate" to mean what > it's expected to mean in this context: that the software developers > recommend against using it, with the intention to eventually remove > support for the feature. We shouldn't be removing any such features > from Org. > > Not only would it not serve users well, but it would make the software > much more complicated. As it stands, finding, e.g. a #+CATEGORY: > keyword and getting its value is as simple as: > > (save-excursion > (goto-char (point-min)) > (when (re-search-forward (rx bol "#+CATEGORY:" (1+ blank) >(group (1+ nonl))) >nil t) > (match-string 1))) > > Hiding those keywords in drawers means that either: > > a) Eligible drawers must be located, and then the desired > property must be searched for inside of them. > > b) Possibly valid properties must be located, and each one must be > confirmed to be inside an eligible drawer. > > What benefit would this added complexity serve? To put the keywords > in one place in the document? There are already multiple ways to > achieve that. I don't agree here. Keywords today break the outline and have no positional requirements. Both a property and a settings drawer would have a fixed position to make it easy to locate, both programmatically, visually and by search. > I can't emphasize enough how important stability and consistency is > for Org and its file formats right now. As I've said, there are new > implementations in development, which have the potential to bring a > lot of publicity and new users to Org. For example, this one was > mentioned on a Hacker News post a few days ago: There is always a balance between stability, backwards compatibility and progression. I agree that backwards compatibility and stability is important. But I also argue that progression is important. Good if Org mode is gaining traction! But that doesn't mean we can't improve it further, for it to gain even more traction! And in the larger scheme of things, Org mode still is tiny. So let's not oversell ourselves here. It's almost like a catch 22. But the largest hinderance for Org mode to grow further is probably its ties with Emacs, the very thing that makes Org mode into the powerhouse it is! > https://github.com/mickael-kerjean/filestash > > In the same HN post were examples of implementations for Vim and > VSCode. Already, especially in the VSCode ones, there were apparent > incompatibilities in their implementations of the Org file format. I've been a promoter of separating the Org mode syntax from Emacs for a long time. I think I've written about it on this list previously as well. So I know what you mean.
Re: [RFC] Document level property drawer
Hi,
> One issue for me is the positioning of the level 0 property drawer.
> Having the requirement for that drawer starting in the very first
> line is too strong for me. I guess one would at least like to have
> the option to add some configuration with the ‘-*-...-*-’ construct
> which currently only works in the first line.
Hmm, that should work right now. 0..n comment lines are supposed to be
allowed anyways. I can debug that a bit later to see if something has
gone amiss.
> Further I think one would also like to place #+: configuration lines
> there in particular the #+title: line. What about allowing lines
> starting with character # above the level 0 property drawer? And put
> a newly created level 0 property drawer below the first line in the
> file that does not start with #?
The first patch allowed both coments ("# "-lines) and keyword lines
(#+...:) as well. But I removed keyword lines for now to start with a
bit more strict definition, per request from Nicolas. I think the
parser will be happy if there is as little information abouve the
drawer as possible, since it will have to retrace itself from the
first line of the buffer every time it needs to verify that the drawer
actually is the "proper" property drawer. If that makes sense. So the
more restrictive we can allow us to be, the better the performance and
the easier it will be to understand where the drawer goes. And less
complexity.
Happy to get more feedback on that decision though!
Thanks! Gustav
Re: [O] Bug: org-read-date ignores hours?
While fooling around with capture templates, I have also noticed this: (progn (setq org-popup-calendar-for-date-prompt t) (read-date t))) When prompted, if you type something like "13:00" - it returns correct, expected datetime. But, if you do: (progn (setq org-popup-calendar-for-date-prompt nil) (read-date t))) And again, type some time value in the prompt - it returns date with no time. This seems to be a bug. On Thu, Oct 24, 2019 at 1:41 AM Marco Wahl wrote: > Hi Ag, > > > When I use (org-read-date t) and type something like "+2m" it works as > expected, but for > > some reason if I type something like "+2h" it returns datetime with no > > changes. Expected - two hours in the future. Am I missing something? > > AFAICS your expectation is not implemented. See function > org-read-date-get-relative. > > +1 for someone trying to implement this idea. > > > HTH, > -- > Marco > -- Regards, Ag.
Re: [O] Bug: org-map-entries infinite loop for org file with tags [9.2.6 (9.2.6-elpa @ /home/ian/.emacs.d/elpa/org-9.2.6/)]
This worked fine for me with org 9.2.3 and 9.2.6 with emacs 26.1.
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Thu, Oct 24, 2019 at 8:02 AM ian martins wrote:
> Running org-map-entries on an org file with tags results in an infinite
> loop.
>
> Example function using org-map-entries:
>
> (defun org-map-entries-test ()
> (interactive)
> (org-map-entries '(lambda () (message "%s" (org-entry-properties
> (point) 'standard
> (message "done"))
>
> Example org file:
>
> * one
> * two
> * three
> :noexport:
>
> expected result: visit each headline once then print "done"
> actual result: visits headlines in an infinite loop and never prints "done"
>
> It fails with: Org mode version 9.2.6 (9.2.6-elpa @
> /home/ian/.emacs.d/elpa/org-9.2.6/)
> It works with: Org-mode version 8.2.10 (release_8.2.10 @
> /usr/share/emacs/24.5/lisp/org/)
> It also works if the org file has no tags.
>
>
> Emacs : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
> of 2017-09-20 on lcy01-07, modified by Debian
> Package: Org mode version 9.2.6 (9.2.6-elpa @
> /home/ian/.emacs.d/elpa/org-9.2.6/)
>
> current state:
> ==
> (setq
> org-table-export-default-format "orgtbl-to-csv"
> org-hide-leading-stars 'hidestars
> org-tab-first-hook '(org-babel-hide-result-toggle-maybe
> org-babel-header-arg-expand)
> org-speed-command-hook '(org-speed-command-activate
> org-babel-speed-command-activate)
> org-occur-hook '(org-first-headline-recenter)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-log-done t
> org-confirm-shell-link-function 'yes-or-no-p
> org-startup-folded 'content
> org-from-is-user-regexp "\\"
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-babel-pre-tangle-hook '(save-buffer)
> org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook org-show-all append
> local]
>5 "\n\n(fn)"]
> #[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook
> org-babel-show-result-all append local]
>5 "\n\n(fn)"]
> org-babel-result-hide-spec org-babel-hide-all-hashes)
> org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
> org-archive-hook '(org-attach-archive-delete-maybe)
> org-cycle-hook '(org-cycle-hide-archived-subtrees
> org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-babel-tangle-lang-exts '(("python" . "py") ("java" . "java")
> ("emacs-lisp" . "el") ("elisp" . "el"))
> org-confirm-elisp-link-function 'yes-or-no-p
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-link-parameters '(("id" :follow org-id-open)
>("eww" :follow eww :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") ("doi" :follow org--open-doi-link)
>("elisp" :follow org--open-elisp-link)
>("file" :complete org-file-complete-link)
>("ftp" :follow
> (lambda (path) (browse-url (concat "ftp:" path
>("help" :follow org--open-help-link)
>("http" :follow
> (lambda (path) (browse-url (concat "http:" path
>("https" :follow
> (lambda (path) (browse-url
Re: [O] Exporting noweb-ref's without disabling org-babel processing
Hi Chuck, Thanks for your answer - I didn't know about that behavior of #+CALL, and I'm sure it will be useful sometime. However, this is not exactly what I was getting at. Here's what I want: 1. First of all, my code needs to tangle correctly - for this I use :noweb and :noweb-ref in some of the chunks, to structure things better. org-babel-tangle produces a working source file. 2. Upon export, most source blocks should export as-they-are. However, when I use :noweb or :noweb-ref, I want two things: a) Noweb chunk names should not be expanded upon export - e.g. <> should be exported like that b) Chunks with :noweb-ref should be identified by their chunk name in the exported code, e.g. prepended by "<>=" in the line before the chunk name. 3. As part of the explanation in my org file, I have some other source blocks (e.g. Ditaa) which are not part of the tangle output, but rather I use to produce diagrams or other stuff. For these, I need ":exports results" behavior. And here's my current status: 1. Works, basic org-babel functionality, no issues :) 2.a. Works by setting ":noweb no-export", no problems. 2.b. Works by modifying my exporter to include the necessary text in the exported output. *However*, the exporter can only access the :noweb-ref header argument if the =org-export-use-babel= variable is set to =nil=. Otherwise, it seems that all org-babel related headers (including :noweb, :noweb-ref and :exports) are removed from the block before it gets passed to the exporter functions. 3. Only works if =org-export-use-babel= is set to =t=, since otherwise org-babel (who does the selection of what gets exported based on :exports) never gets called. Basically, my problem is the contradiction between (2.b) and (3) above, with respect to the org-export-use-babel variable. What I would like to know is if there is a way to keep the :noweb and :noweb-ref header arguments in the block, even after org-babel processes them. For (2.b), I also experimented with setting =org-babel-exp-code-template=, unfortunately I encountered two problems: 1. =org-fill-template= sorts keys by length, which meant that when "%noweb-ref" appears in the template, it always gets interpreted as "%noweb" followed by the string "-ref". 2. I only want the value of :noweb-ref to be output when the parameter is specified, but =org-fill-template= doesn't handle that sort of logic - the header argument is always expanded in the template, even when its value might be missing or "no". So, I'm still looking for a good solution to my problem. In the meantime, I can generate my Ditaa diagrams separately and just include the output in my org file, which is not tragic but not the most elegant :) Hope this further clarifies things! Best, --Diego On Wed, Oct 23, 2019 at 6:51 PM Berry, Charles wrote: > Diego, > > I am not sure I understand. Here is my interpretation: > > You wish to have `:exports both' behavior in your org export. > > You want noweb references in the exported code to render as > angle-bracketed chunk names, such as <> rather than being expanded > in place. > > If that is what you want, you can use the feature of CALL keywords that > resets the header arguments for the src block it calls to obtain different > behavior with the same code. For example: > > #+begin_src org > ,#+name: template-chunk > ,#+begin_src emacs-lisp :noweb no > (concat c b a > <> > ) > ,#+end_src > > ,#+CALL: template-chunk() :noweb yes :var a="A" b="B" c="C" > > ,#+begin_src emacs_lisp :noweb-ref super-duper-code > (concat a b c) > ,#+end_src > #+end_src > > exports as > > --8<---cut here---start->8--- > , > | (concat c b a > | <> > | ) > ` > > , > | CBAABC > ` > > > , > | (concat a b c) > ` > --8<---cut here---end--->8--- > > HTH, > > Chuck > > > On Oct 22, 2019, at 1:29 PM, Diego Zamboni wrote: > > > > Hi, > > > > I'm working on a Leanpub Markua exporter (not quite complete yet but > already usable, if you are interested: > https://github.com/zzamboni/ox-leanpub/tree/book-and-markua) > > > > I would like to include the value of :noweb-ref for code blocks in > exported output, like noweb originally did, e.g. something like this: > > > > #begin_src emacs_lisp :noweb-ref super-duper-code > > ... > > #end_src > > > > to produce something like this in the export: > > > > <>= > > ... > > > > After much poking around, I figured that the :noweb and :noweb-ref > header args are removed by org-babel *before* the src block makes it to the > exporter. I also discovered that by setting org-export-use-babel to nil I > could disable this behavior, which means that my exporter can access the > :noweb-ref argument by parsing the :parameters property (see > https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-markua.el#L388 > ). > > > > This was good for my original purpose, but I just realized that this > also
[O] Bug: org-map-entries infinite loop for org file with tags [9.2.6 (9.2.6-elpa @ /home/ian/.emacs.d/elpa/org-9.2.6/)]
Running org-map-entries on an org file with tags results in an infinite
loop.
Example function using org-map-entries:
(defun org-map-entries-test ()
(interactive)
(org-map-entries '(lambda () (message "%s" (org-entry-properties
(point) 'standard
(message "done"))
Example org file:
* one
* two
* three
:noexport:
expected result: visit each headline once then print "done"
actual result: visits headlines in an infinite loop and never prints "done"
It fails with: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)
It works with: Org-mode version 8.2.10 (release_8.2.10 @
/usr/share/emacs/24.5/lisp/org/)
It also works if the org file has no tags.
Emacs : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2017-09-20 on lcy01-07, modified by Debian
Package: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)
current state:
==
(setq
org-table-export-default-format "orgtbl-to-csv"
org-hide-leading-stars 'hidestars
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-log-done t
org-confirm-shell-link-function 'yes-or-no-p
org-startup-folded 'content
org-from-is-user-regexp "\\"
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5 "\n\n(fn)"]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local]
5 "\n\n(fn)"]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-babel-tangle-lang-exts '(("python" . "py") ("java" . "java")
("emacs-lisp" . "el") ("elisp" . "el"))
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("id" :follow org-id-open)
("eww" :follow eww :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") ("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
("help" :follow org--open-help-link)
("http" :follow
(lambda (path) (browse-url (concat "http:" path
("https" :follow
(lambda (path) (browse-url (concat "https:" path
("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path)))
)
("news" :follow
(lambda (path) (browse-url (concat "news:; path
("shell" :follow org--open-shell-link))
org-babel-load-languages '((java . t) (python . t) (emacs-lisp . t)
(calc . t) (org . t) (screen . t) (dot . t)
(plantuml . t) (gnuplot . t))
Re: [O] org-fast-todo-selection window behaviour?
Hi Matt, :) Have you tried (setq org-use-fast-todo-selection 'expert) It is the least jarring implementation, and it is the setting I use. Carsten On Wed, Oct 23, 2019 at 8:10 PM Matt Price wrote: > Ah well. I find the new way jarring, but it doesn't seem to bother anyone > else, and as it's a one-line (2 character!) change for me I think I can > carry the diff in my init file for now. In any case it's a small issue I > think.An honour to find myself in disagreement with the org-founder! > > On Mon, Oct 21, 2019 at 5:47 AM Carsten Dominik wrote: > >> Hi Matt, >> >> I made this change, because I found the previous way jarring. The window >> with the selection information showed up in different places depending on >> what the current window setup is. With the new implementation, the info >> window is always in the same predictable place. After the selection is >> done, the old window setup is restored to exactly what it was >> >> Carsten >> >> On Sun, Oct 20, 2019 at 8:46 PM Matt Price wrote: >> >>> I've recently noticed a slightly frustrating behavour on the part of >>> org-todo that I think is new and maybe was introduced in mid-August with >>> >>> f1c030bed54737319aeb1d592e3340d6a48cea3a >>> >>> In a split frame,calling org-todo with org-use-fast-todo-selection >>> enabled, ~C-c C-t~ now calls ~delete-other-windows~ before popping up the >>> org-todo keywords window. Is this necessary? I find this behaviour >>> visually confusing and distracting, and a slowdown to my workflow. Would >>> it make sense to introduce some kind of defcustom for this? For now I'm >>> just commenting out line 10614 of org.el, but if others want to be able to >>> customize the behaviour I will submit a patch. >>> >>> Maybe there's a reason delete-other-window is necessary, but i don't see >>> it in the commit message nor immediately in the other parts of this >>> otherwise very well-documented commit >>> >>> Thanks! >>> >>>
[O] Title in an PlantUML generated file
At the moment I am using PlantUML to generate eps diagrams. When opening them in Evince it says: noTitle. Is there a way to get a title so Evince has useful information in its window title? -- Cecil Westerhof
Re: [O] Bug: org-read-date ignores hours?
Hi Ag, > When I use (org-read-date t) and type something like "+2m" it works as > expected, but for > some reason if I type something like "+2h" it returns datetime with no > changes. Expected - two hours in the future. Am I missing something? AFAICS your expectation is not implemented. See function org-read-date-get-relative. +1 for someone trying to implement this idea. HTH, -- Marco
[O] Suggestion: Bulleted List inside Columns?
Hi there, First time poster, please be gentle and don't bite my head off if I'm doing something wrong. I just posted last night on Reddit about this and was told that Org-Mode can't do this (which quite surprised me). Having come from OmniOutliner for Mac, there's a very useful native function which automatically allows you to make indented lists in columns (which can be collapsed, expanded just like bullet lists in org-mode). This is really useful for making long lists with different categories and still wanting to keep them all in column views for organization purposes. I was told that column-view can sort of do this, but it's really not what I need. I'd have to set up the columns beforehand, it's not intuitive, it's not really simple and on the fly (though I can see how it's useful for many other things). It's basically not *really* the same thing that I'm thinking of, which I can see at least. I'm wondering: Does this interest anyone? I hope I'm emailing the right place and I'm not certain if I'm breaking any rules about where or how to post about this. I also hope I'm being clear enough - I can elucidate more if needed, or post pictures/a write-up of some sort on my blog with a link if people need some sort of comparison. Please let me know? Also, I've been using Org-Mode since about end of January/February since I was introduced to Spacemacs and then Emacs, which got me to stay with Spacemacs and then Emacs (and now both for various purposes), so I just want to thank everyone for all the amazing work! So, thank you! Nat Harari.
Re: [O] Feature Proposal: Titled Paragraphs
Am 23.10.19 um 16:18 schrieb Dominik Schrempf: > I agree with this proposal. At some point I already asked if the following > structure is possible: > > #+begin_example > * Title > ** Section I > Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit > tempor > tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis > eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis > parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. > Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. > Nam vestibulum accumsan nisl. > > Another paragraph that is not related to Section I, but doesn't deserve a > section title. Another paragraph that is not related to Section I, but doesn't > deserve a section title. Another paragraph that is not related to Section I, > but > doesn't deserve a section title. Another paragraph that is not related to > Section I, but doesn't deserve a section title. > #+end_example > > With titled paragraphs, this document structure could be achieved. Only if you are very restrictive about it, as you hit a fundamental problem of org markup here, a problem it shares with (La)TeX, HTML, all printed books I'm aware of, and a lot of other formats. Org and (La)TeX only markup the start of a section, not its end. Thus it would be difficult to tell your construct apart from other kind of structures. Contrary to your view, in the (La)TeX-world \paragraph is usually seen as just another hierarchical level of document structuring. It is a heading (with a weird default of not standing on a line of its own), and it does NOT solely belong to the one paragraph it starts. In fact, with your view, (La)TeX's \subparagraph macro would not make any sense at all. That means, adding \paragraph in your sense will break document structure the moment you also have nesting deeper than 3 (or 4 for book-like formats). Julius
