Hi!
I've updated to org-mode 9.0.7 but the problem remains. With this org-mode
buffer
[[info:emacs#Directory%20variables][info:Directory variables]]
org-element-parse-buffer give the following (indented):
(org-data
nil
(section
(:begin 1 :end 92 :contents-begin 1 :contents-end 92 :post-
Hi,
Thanks a lot for the quick fix!
I am not sure I understand the check
(when (or (not (string-match-p "[0-9]" value))
(and (string-match-p "[1-9]" value)
(= 0 (string-to-number value
before the error message. Wouldn't it be good enough t
On Sunday, 21 May 2017 at 13:37, Nicolas Goaziou wrote:
> If there are no objection nor additional suggestions, I will push it to
> master in a couple of days.
Looks good to me! Thanks.
--
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.7-468-g2b44a1.dirty
signature.asc
Description
On Mon, May 22, 2017, 1:58 AM Nicolas Goaziou
wrote:
> Even though it is surprising, this is not an issue. The thing is macros
> are expanded at the very beginning of the export process, even before
> the document is parsed. At this point, the example above is properly
> expanded to
>
> 7463.
>
Hello,
Erik Sjöstrand writes:
> I've updated to org-mode 9.0.7 but the problem remains. With this org-mode
> buffer
>
> [[info:emacs#Directory%20variables][info:Directory variables]]
>
> org-element-parse-buffer give the following (indented):
>
> (org-data
> nil
> (section
> (:begin 1 :e
Hello,
Kaushal Modi writes:
> It just so happened that autofilling ended up with a number followed by a
> period at the BOL. So I couldn't have planned inserting a zero-width space
> before the dot.
This shouldn't happen. "1." is defined as paragraph separator (see
`org-element-paragraph-separa
Hi,
turning on column view might change the buffer, because it
sometimes stores computed values in properties. Is this really
intended? At least I could not find this behavior described in
the documentation.
For instance, in the following buffer
* a
:PROPERTIES:
:XX:
Hello,
Hendrik Tews writes:
> I am not sure I understand the check
>
>(when (or (not (string-match-p "[0-9]" value))
> (and (string-match-p "[1-9]" value)
> (= 0 (string-to-number value
>
> before the error message. Wouldn't it be good enough to
Hello,
Hendrik Tews writes:
> turning on column view might change the buffer, because it
> sometimes stores computed values in properties. Is this really
> intended?
It is. But it only happens if the property already exists in the
summarized node.
> At least I could not find this behavior desc
Nicolas Goaziou writes:
> The intent of the check is to warn the user that a columns contains
> invalid values. Applying `string-to-number' unconditionally could give
> strange results for example, with {mean,%.2f}.
I do see your point here. I don't use mean, but it is probably
good to warn user
On Mon, May 22, 2017 at 7:47 AM Nicolas Goaziou
wrote:
> This shouldn't happen. "1." is defined as paragraph separator (see
> `org-element-paragraph-separate' and `org-element--set-regexps) so
> auto-fill cannot break a line before this construct.
>
That's good to know and comforting :) Thanks f
Hello,
Oskar Kvist writes:
> I have a buffer with the 3 lines below. Notice that the long lines
> contains no newlines. I selected (with the mark) the whole last line,
> the one starting with "2.", and ran `fill-region`. It worked, and the
> line was filled. Then I tried to do the same with the
Kaushal Modi writes:
> I just tried this out and it works:
>
> diff --git a/lisp/org-element.el b/lisp/org-element.el
> index c60a56ead..4f4fc1e2c 100644
> --- a/lisp/org-element.el
> +++ b/lisp/org-element.el
> @@ -181,7 +181,9 @@ specially in `org-element--object-lex'.")
>(?\) ")") (?.
This prevents false n-macro matches.. added \\b after "{{{n".
diff --git a/lisp/org-element.el b/lisp/org-element.el
index c60a56ead..2bee85ede 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -181,7 +181,9 @@ specially in `org-element--object-lex'.")
(?\) ")") (?. "\\.") (_ "[
* Karl Voit wrote:
>
> Org-mode from maint Git repository overruled via following lines
> right at the top of my ~/.emacs.d/init.el:
>| (add-to-list 'load-path "~/.emacs.d/contrib/org-mode/lisp")
>| (add-to-list 'load-path "~/.emacs.d/contrib/org-mode/contrib/lisp" t)
>
> When I start emacs, I got
Hendrik Tews writes:
> I believe it makes a lot of sense to have
>
> :PROPERTIES:
> :Effort: TODO
> :END:
The linter will complain about it. Effort is a special property.
> and the old behavior of treating TODO as 0 in such cases seems
> perfect to me.
>
> I believe you should also permit
On Mon, May 22, 2017 at 9:13 AM Nicolas Goaziou
wrote:
> This is a wrong approach. A macro doesn't separate paragraphs, but
> belongs to them. IOW, you get the desired side-effect, but break
> underlying syntax.
>
I agree
A better way to solve this would to add a function to
> `fill-nobreak-pre
Hello,
林镇国 writes:
> When I insert a link to my note, such as“这是一个[[link][链接]]啦~”，
> the text after the link, "啦~", will be formatting as link style.
FWIW, I cannot reproduce it, i.e., only "链接" appears with a link face.
Regards,
--
Nicolas Goaziou
18 matches
Mail list logo
