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
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
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
* 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
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'.")
(?\) ")") (?. "\\.") (_ "[
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'.")
>(?\) ")") (?.
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
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
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
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
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
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,
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
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
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.
>
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
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
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-
18 matches
Mail list logo
