Re: [O] Bug: org-refile with active region does not update LOGBOOKs of all entries [9.2.1 (9.2.1-23-g126a37-elpaplus @ /home/eush/.emacs.d/elpa/org-plus-contrib-20190218/)]

2019-02-24 Thread Nicolas Goaziou
Hello,

"Eugene Sharygin"  writes:

> I have `org-log-refile` in my configuration set to `time`, which makes
> `org-refile` add a time stamp to the LOGBOOK drawer at the target
> location.
>
> However, when `org-refile` is called with active region containing
> multiple entries, only LOGBOOK of the first entry is updated.
>
> For example,
>
> * NEW foo
> * NEW bar
>
> after refiling as one active region, looks at the target location like
> this:
>
> * NEW foo
> :LOGBOOK:
> - Refiled on [2019-02-23 Sat 03:41]
> :END:
> * NEW bar
>
> Expected result:
>
> * NEW foo
> :LOGBOOK:
> - Refiled on [2019-02-23 Sat 03:41]
> :END:
> * NEW bar
> :LOGBOOK:
> - Refiled on [2019-02-23 Sat 03:41]
> :END:

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] [RFC] Fixing link encoding once and for all

2019-02-24 Thread Neil Jerram
I'm not sure how much freedom you have here, but I think it would be
both clearer - by avoiding confusion with URL-escaping - and easier to
type, to use an entirely different form of escaping in the Org syntax;
probably just this:

\[ and \] to include a square bracket in a link
\\ to include a backslash

Regards,
Neil

On Sun, 24 Feb 2019 at 01:18, Nicolas Goaziou  wrote:
>
> Hello,
>
> Recently[1], issues about link escaping have resurfaced. I'd like to
> solve this once and for all.
>
> As a reminder, the initial issue is that bracket links, i.e., "[[path]]"
> or "[[path][description]]", cannot contain square brackets, for obvious
> reasons. Therefore, they need to be escaped somehow. For some historical
> reason, the "somehow" settled, for the path part[2], on URL encoding.
> Therefore [ and ] in a link must appear as, respectively, "%5B" and
> "%5D". Of course, the initial link could already contain any of these
> strings, so percent signs also need to be escaped, as "%25". Eventually,
> consecutive spaces are not very handled very gracefully by
> `fill-paragraph' function, so it is also useful, but not mandatory, to
> be able to escape white spaces, with "%20". It can sadly be confusing
> when Org encoding is applied on top an already encoded URI.
>
> To sum it up, `org-link-escape', by default, URL encodes only square
> brackets, percent signs and white spaces. Note that, however,
> `org-link-unescape' is not its reciprocal function, despite its
> docstring. It URL decodes every percent encoded combination.
>
> Anyway, square brackets in a bracket link almost looks like a solved
> problem. Alas, if some links are inserted by helper functions, such as
> `org-insert-link', others could have been typed right into the buffer.
> Therefore, there is usually no way to know if a link is already
> Org-encoded or not. Consequently, there is usually no way to know when
> a link needs to be Org-decoded. This is the root of all evil, or at
> least, all bugs encountered so far. Some links end up being encoded or
> decoded once too many.
>
> To solve this, we must assume that every bracket link is properly
> Org-encoded in a buffer. In other words, when typing, or yanking,
> a bracket link right into a buffer, users are required to use %5B, %5D,
> and %25 in the path part of the link, if necessary. I understand it will
> bite some users, but using `org-insert-link' would mitigate the pain. It
> is also limited to square brackets, which, I assume, is not the type of
> link you usually yank.
>
> With that assumption, the parser can safely Org-decode links
> appropriately, and store paths in their decoded form. Consumers, like
> export back-ends, need not call `org-link-unescape' anymore. In fact,
> the only situation where `org-link-unescape' is still needed is when
> extracting the path part of a bracket link from the buffer, e.g.,
> through regexp matching.
>
> Of course, the manual should mention this assumption, if we agree on it.
>
> Thoughts?
>
> Regards,
>
> Footnotes:
>
> [1] E.g., 
> or .
>
> [2] There is no clear mechanism for the description part.
> `org-insert-link' will replace square brackets with curly ones. We could
> also use entities, but none of them appears as a square bracket. Anyway,
> I'll ignore this issue for the time being.
>
> --
> Nicolas Goaziou
>



Re: [O] [Patch] Org-tools addendum

2019-02-24 Thread Nicolas Goaziou
Hello,

"Andrea D'Amore"  writes:

> On Tue, 26 Jun 2018 at 11:55, Nicolas Goaziou  wrote:
>> Hello,
>> "Andrea D'Amore"  writes:
>> > I'm submitting a small patch to add orga and pandoc to the list of
>> > org-tools.
>>
>> Thank you. Would you mind using "git format-patch" to get a proper
>> commit message and send it again?
>
> Sorry for the extreme delay, I'm attaching the patch printed out by
> git-format-patch.
>
> I had a little embarrassment writing a ChangeLog entry for such a
> small diff, the first line was already saying it all…
>
> Please still directly reply to me if need be.

Applied. I changed "org-mode", "Org-Mode" and "org" to "Org".

Thank you!

Regards,

-- 
Nicolas Goaziou



Re: [O] [Patch] Org-tools addendum

2019-02-24 Thread Andrea D'Amore
On Tue, 26 Jun 2018 at 11:55, Nicolas Goaziou  wrote:
> Hello,
> "Andrea D'Amore"  writes:
> > I'm submitting a small patch to add orga and pandoc to the list of
> > org-tools.
>
> Thank you. Would you mind using "git format-patch" to get a proper
> commit message and send it again?

Sorry for the extreme delay, I'm attaching the patch printed out by
git-format-patch.

I had a little embarrassment writing a ChangeLog entry for such a
small diff, the first line was already saying it all…

Please still directly reply to me if need be.


Best regards

-- 
Andrea
From c73b2afcf11a1041dc2893e1e69868316820e351 Mon Sep 17 00:00:00 2001
From: Andrea D'Amore 
Date: Sun, 24 Feb 2019 16:20:58 +0100
Subject: [PATCH] index.org: Mention Orga and Pandoc in the tool page

* index.org (Org-mode parsers): add link to homepage and brief description for
Orga, an ES parsers for org, and Pandoc, the multi-purpose converter.

TINYCHANGE
---
 org-tools/index.org | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/org-tools/index.org b/org-tools/index.org
index 53a01963..3b6a5035 100644
--- a/org-tools/index.org
+++ b/org-tools/index.org
@@ -111,6 +111,17 @@ org-js is a javascript parser and converter for org-mode
 For a working example of an interactive editor, see
 http://mooz.github.com/org-js/editor/.
 
+** [[https://github.com//xiaoxinghu/orgajs][orga]] by Xiaoxing Hu
+
+Orga is a flexible org-mode syntax parser. It parses org content into
+AST (Abstract Syntax Tree).
+
+** [[https://pandoc.org][pandoc]]
+
+Pandoc is the Swiss-army knife to convert files from one markup format
+into another, it can convert documents from many source format,
+including Org-Mode, to many other.
+
 * Specific purpose tools
 
 ** orgmode for drupal
-- 
2.17.1



[O] [PATCH] Let radio target works well with Chinese

2019-02-24 Thread Feng Shu
>From bbf085c61f8b7e9b80077b401cd275b420b4ddca Mon Sep 17 00:00:00 2001
From: Feng Shu 
Date: Sun, 24 Feb 2019 17:52:51 +0800
Subject: [PATCH] Let radio target works well with Chinese
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org.el (org-update-radio-target-regexp): Let radio target works well with Chinese.

There is no need to force split words with the help
of space for Chinese, this change let the below
example works well.

<<<天空>>>

我爱天空和大地

---
 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 9f33c9e60..ea68aacfc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6052,8 +6052,8 @@ by a #."
 Also refresh fontification if needed."
   (interactive)
   (let ((old-regexp org-target-link-regexp)
-	(before-re "\\(?:^\\|[^[:alnum:]]\\)\\(")
-	(after-re "\\)\\(?:$\\|[^[:alnum:]]\\)")
+	(before-re "\\(?:^\\|[^[:alnum:]]\\|\\cc\\)\\(")
+	(after-re "\\)\\(?:$\\|[^[:alnum:]]\\|\\cc\\)")
 	(targets
 	 (org-with-wide-buffer
 	  (goto-char (point-min))
-- 
2.20.1



--