Neil Jerram writes:
> Thanks for explaining that. It's not mentioned in the manual though
> (https://www.gnu.org/software/emacs/manual/html_node/emacs/Regexps.html);
> are you sure that it's supported in Emacs regexps?
>
Itʼs described in the next node:
Hi Nicolas,
On Tue, 5 Mar 2019 at 00:23, Nicolas Goaziou wrote:
[...]
> So, the new challenger is:
>
>
> "\\[\\[\\(\\(?:.\\|\n\\)*?[^\\]\\(\\)*\\)\\]\\(?:\\[\\(\\(?:.\\|\n\\)+?\\)\\]\\)?\\]"
>
> Beautiful.
>
> The commented rx equivalent would be:
>
> (seq "["
> ;; URI part:
Hello,
Neil Jerram writes:
> On Fri, 1 Mar 2019 at 08:14, Nicolas Goaziou wrote:
>> The regexp for bracket links could be, in its simple (!) form:
>>
>> \[\[\(.*?[^\\]\(?:\\\)*\)\]\(?:\[\([^\000]+?\)\]\)?\]
>
> [then a bit later]
>> Small update, in its string form now:
>>
>>
>>
On Fri, 1 Mar 2019 at 08:14, Nicolas Goaziou wrote:
>
> Hello,
>
> Neil Jerram writes:
>
> > Do you mean Windows file names in existing Org files? I.e. the
> > back-compatibility concern?
> >
> > If so, yes, I confess I didn't think at all about back-compatibility,
> > with my suggestion above.
Hello,
stardiviner writes:
> Nicolas Goaziou writes:
>> 3. There will be some backward compatibility issues. We can add
>>a checker in Org Lint to catch most of those. For example, we could
>>look at URI where every percent is followed only by 25, 5B, and 5D.
>
> About this, I'm
Nicolas Goaziou writes:
> Hello,
>
> Neil Jerram writes:
>
>> Do you mean Windows file names in existing Org files? I.e. the
>> back-compatibility concern?
>>
>> If so, yes, I confess I didn't think at all about back-compatibility,
>> with my suggestion above. So perhaps that rules my idea
On 2019-03-01, Nicolas Goaziou wrote:
> Jens Lechtenboerger writes:
>
>> On 2019-03-01, Nicolas Goaziou wrote:
>>
>>> 3. There will be some backward compatibility issues. We can add
>>>a checker in Org Lint to catch most of those. For example, we could
>>>look at URI where every percent
Hello,
Jens Lechtenboerger writes:
> On 2019-03-01, Nicolas Goaziou wrote:
>
>> 3. There will be some backward compatibility issues. We can add
>>a checker in Org Lint to catch most of those. For example, we could
>>look at URI where every percent is followed only by 25, 5B, and 5D.
>
>
Hi there,
I like this proposal.
On 2019-03-01, Nicolas Goaziou wrote:
> 3. There will be some backward compatibility issues. We can add
>a checker in Org Lint to catch most of those. For example, we could
>look at URI where every percent is followed only by 25, 5B, and 5D.
I do not
On Fri, Mar 1, 2019 at 9:15 AM Nicolas Goaziou wrote:
> Thinking a bit more about it, we don't need to escape /all/ square
> brackets, only "]]" and "][" constructs. Therefore, we don't need to
> escape every backslash either.
Brilliant!
Nicolas Goaziou writes:
> The regexp for bracket links could be, in its simple (!) form:
>
> \[\[\(.*?[^\\]\(?:\\\)*\)\]\(?:\[\([^\000]+?\)\]\)?\]
Small update, in its string form now:
"\\[\\[\\([^\000]*?[^\\]\\(\\)*\\)\\]\\(?:\\[\\([^\000]+?\\)\\]\\)?\\]"
Hello,
Neil Jerram writes:
> Do you mean Windows file names in existing Org files? I.e. the
> back-compatibility concern?
>
> If so, yes, I confess I didn't think at all about back-compatibility,
> with my suggestion above. So perhaps that rules my idea out.
>
> If we were starting from
Hello,
Jens Lechtenboerger writes:
> I copied that from the address bar of my browser, probably two years
> ago. Today, I was surprised by a compilation failure.
Link syntax is currently unstable. We fix it on one side and it breaks
elsewhere.
This thread is an attempt to make the link
On Wed, 27 Feb 2019 at 10:49, Nicolas Goaziou wrote:
>
> Hello,
>
> Neil Jerram writes:
>
> > 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
On 2019-02-27, Nicolas Goaziou wrote:
> Hello,
>
> Jens Lechtenboerger writes:
>
>> When exporting the following link to LaTeX, the decoding fails.
>>
>> --8<---cut here---start->8---
>> [[https://en.wikipedia.org/wiki/Red%E2%80%93black_tree][Red-black trees]]
Hello,
Jens Lechtenboerger writes:
> When exporting the following link to LaTeX, the decoding fails.
>
> --8<---cut here---start->8---
> [[https://en.wikipedia.org/wiki/Red%E2%80%93black_tree][Red-black trees]]
> --8<---cut
Hello,
Neil Jerram writes:
> 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
On 2019-02-24, Nicolas Goaziou wrote:
> Recently[1], issues about link escaping have resurfaced. I'd like to
> solve this once and for all.
Good morning,
I updated to Org mode version 9.2.1 (9.2.1-33-g029cf6-elpa @
/home/user/.emacs.d/elpa/org-20190225/).
When exporting the following link to
Nicolas Goaziou writes:
> 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
>
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
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
21 matches
Mail list logo
