[BUG] A commented line breaks line numbering [9.6-pre (release_9.5.5-1058-g6ef33b @ /home/thblt/.emacs.d/lib/org/lisp/)]

Hello, With org 9.6-pre, a commented out line breaks list numbering (even with `org-list-repair`), and effectively breaks a list in two distinct lists in exporters. Eg: 1. Item 1 2. Item 2 # 3. Commented out item 3 1. Reset counter? At "Reset counter?", HTML export opens a new there,

Re: Different exporters behave differently re exporter-specific lines

> I doubt it. There are 3 paragraphs, even for LaTeX, since there are > empty lines. I believe there may have been a communication issue somewhere, since you cite my message with extra \n --- there are no empty lines in my original message. For reference, here's the exact input I've used:

Re: Discrepancy between documentation and implementation regarding comments

Robert Pluim writes: > end of line *is* a whitespace character, but Iʼm not going to argue > that. Iʼm going to argue that this doesnʼt cover the case of a '#' at > EOB without a newline, hence saying 'zero or more' would be better. But zero-or-more would mean that this line: #Alpha Is a

Different exporters behave differently re exporter-specific lines

I'm not sure how this feature is called, but in Org you can restrict a line to a given exporter by prepending it with, eg, #+latex: There's a bug with some exporters f treat these lines as paragraph breaks, some don't. For example, the following input: Hello #+latex: \TeX{} World #+html: Wide

Re: Discrepancy between documentation and implementation regarding comments

Nicolas Goaziou writes: > See (with a nice > typo...) Thanks Nicolas, just a small detail though: unless this is a planned (breaking) change, I believe the description you linked should read: A “comment line” starts with *zero or more

Discrepancy between documentation and implementation regarding comments

Hello, According to Org-Mode documentation[1], > Lines starting with zero or more whitespace characters followed by one > ‘#’ and a whitespace are treated as comments and, as such, are not > exported. The actual implementation differs on a subtle detail: Org-Mode will treat a line where the

Re: [O] org-crypt broken on Ubuntu 18.04

> What's an ECM? French for Exemple complet minimal = Minimal Working Example (MWE)[1] [1]: https://en.wikipedia.org/wiki/Minimal_Working_Example -- Thibault

[O] Bug: imenu fails with non-continuous structure [9.1.13 (release_9.1.13 @ /home/thblt/.emacs.d/lib/org/lisp/)]

Steps to reproduce, from emacs -q: 1. (setq org-imenu-depth 10) 2. Create the following document: #+begin_src org #+TITLE: Test * Level 1 ** Level 2 *** Level 3 Level 4 Level 8 #+end_src Notice the break on the structure: levels 5, 6 and 7 are missing. 3. M-x imenu, select

Re: [O] Bug: org-indent-mode with visual-line-mode breaks C-a and C-e

I can confirm the issue appears with those two commands. I forwarded this report to the Emacs bug tracker. Regards, Nicolas Goaziou writes: > Hello, > > Thibault Polge <thiba...@thb.lt> writes: > >> With visual-line-mode and org-indent-mode activated, C-a and C-e >&g

[O] Bug: org-indent-mode with visual-line-mode breaks C-a and C-e

* Summary With visual-line-mode and org-indent-mode activated, C-a and C-e misbehaves on indented text blocks. C-a and C-e sometimes start jumping over lines (ie, go backwards or forward one extra line) and sometimes even reverses direction (C-e goes backward). I can reproduce this from emacs

[O] Bug: save-some-buffers saves org-edit-special buffers to separate files [9.0.4 (9.0.4-elpa @ /home/thblt/.emacs.d/elpa25/org-20170124/)]

When calling (save-some-buffers t) while a code block is being edited with org-edit-special, the org-edit-special buffer is saved to the disk to a new, separate file with a name like: dotemacs.org[*Org Src dotemacs.org[ emacs-lisp ]*] I can reproduce this from emacs -Q with org 9.0.4 from org