Re: [O] [bug] #+constants line has to be at column 0
Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Agreed, please go ahead, Done. Thanks! -- Bastien
Re: [O] [bug] #+constants line has to be at column 0
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bastien b...@gnu.org writes: This is the same behavior than all #+ directives except these four: #+TITLE: #+AUTHOR: #+DATE: #+EMAIL: Fontification should tell you in all cases. Most user-defined keywords ignore indentation (e.g., #+LATEX_HEADER:, #+MACRO: ...). I think we should remove this historical limitation, as there is no reason to keep it any longer. The benefit is that such a change will be backward compatible. Nicolas, thanks for this. Works very well now. The fontification doesn't as I guess org-fontify-meta-lines-and-blocks-1 hasn't been updated. I suggest adding +constants: to the first cond entry in this function? Thanks again, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org release_8.2.5h-709-g99f1ff
Re: [O] [bug] #+constants line has to be at column 0
Hi Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: The fontification doesn't as I guess org-fontify-meta-lines-and-blocks-1 hasn't been updated. I suggest adding +constants: to the first cond entry in this function? this is now fixed in master -- *sorry* for not crediting you in the commit message, my memory thought Alan reported this. -- Bastien
Re: [O] [bug] #+constants line has to be at column 0
Bastien b...@gnu.org writes: Hi Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: The fontification doesn't as I guess org-fontify-meta-lines-and-blocks-1 hasn't been updated. I suggest adding +constants: to the first cond entry in this function? this is now fixed in master -- *sorry* for not crediting you in the commit message, my memory thought Alan reported this. Works perfectly! Thanks. No worries re: credit. It's not something that matters. Org itself is thanks enough. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org release_8.2.5h-709-g99f1ff
Re: [O] [bug] #+constants line has to be at column 0
Hi Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: Unlike some other #+ directives, the #+constants: one has to be at column 0 or else it is not understood/parsed by org. This is the same behavior than all #+ directives except these four: #+TITLE: #+AUTHOR: #+DATE: #+EMAIL: Fontification should tell you in all cases. HTH, -- Bastien
Re: [O] [bug] #+constants line has to be at column 0
Hello, Bastien b...@gnu.org writes: This is the same behavior than all #+ directives except these four: #+TITLE: #+AUTHOR: #+DATE: #+EMAIL: Fontification should tell you in all cases. Most user-defined keywords ignore indentation (e.g., #+LATEX_HEADER:, #+MACRO: ...). I think we should remove this historical limitation, as there is no reason to keep it any longer. The benefit is that such a change will be backward compatible. Regards, -- Nicolas Goaziou
Re: [O] [bug] #+constants line has to be at column 0
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: I think we should remove this historical limitation, as there is no reason to keep it any longer. The benefit is that such a change will be backward compatible. Agreed, please go ahead, -- Bastien
Re: [O] [bug] #+constants line has to be at column 0
Bastien b...@gnu.org writes: Agreed, please go ahead, Done. Regards, -- Nicolas Goaziou
[O] [bug] #+constants line has to be at column 0
Hello, Unlike some other #+ directives, the #+constants: one has to be at column 0 or else it is not understood/parsed by org. This has consequences for lists. See attached example. #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga * Table constants Assume that I have a list: 1. and in this list, one of the entries is a table 2. This is the table #+constants: param=-5 | | X | Y | | ! | x | y | |---+---+| | # | 1 | -4 | | # | 2 | -3 | | # | 3 | -2 | #+TBLFM: $3=$x+$param 1. The constants line cannot be indented as it is not understood if it is. 2. This means that the list has been interrupted. Obviously, I can move the constants line elsewhere and/or use the $ directive within the table but I thought that this was an inconsistency in the parsing of org files? Maybe not? Org up to date and verified with emacs -Q. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org release_8.2.5h-687-g9d39aa
