>> I am not sure if "Org *10*.0" is a good general example. It is probably
>> one of those cases when users want fine control over emphasis and must
>> use zero width space.
>
> This is simply the first example that crossed my mind. My point is that
> changing the regexp substantially may not be
Hello,
Ihor Radchenko writes:
> Commit messages are also important, especially years later. I updated
> the commit message in the attached new version of the patch.
Note I'm not saying commit messages are not important. I just won't
spend energy on the wording there.
>> Thinking about it a bit
On 21/11/2021 17:01, Ihor Radchenko wrote:
Max Nikulin writes:
My draft version is attached. Ihor, thank you for inspiration. Feel free
to improve it. I hope, it makes problem more apparent to user who tries
to customize markers. Have I missed some undesired side effects?
Unfortunately with
Max Nikulin writes:
> My draft version is attached. Ihor, thank you for inspiration. Feel free
> to improve it. I hope, it makes problem more apparent to user who tries
> to customize markers. Have I missed some undesired side effects?
Your version looks a lot better. Thanks!
> Unfortunately
Nicolas Goaziou writes:
> Thanks for the update, and apologies in advance for being bold, as
> I have some additional comments about it.
Constructive critics and suggestions are always welcome. And we do not
have pressing deadlines here :)
>> * doc/org-manual.org (Emphasis and Monospace): Advic
Hello,
Ihor Radchenko writes:
> I updated the patch. If you have no objections on the new wording, I
> will push it to main.
Thanks for the update, and apologies in advance for being bold, as
I have some additional comments about it.
> * doc/org-manual.org (Emphasis and Monospace): Advice user
On 16/11/2021 14:43, Ihor Radchenko wrote:
Max Nikulin writes:
Better docs and some restriction on defcustom values were discussed earlier:
https://list.orgmode.org/87k0oyd3pw@nicolasgoaziou.fr/
Nicolas Goaziou. Re: Using backticks for the inline code delimeter? Mon,
19 Apr 2021 11:27:07 +0
On 18/11/2021 05:44, Samuel Wales wrote:
i think i found it useful, long ago, when it was ok/tolerated to
change the var, and probably still, to /"do this"/ and /this,/.
D. Knuth in "The TeXbook" put punctuation outside of emphasized text,
however he mentioned that accordingly to old manuals s
Nicolas Goaziou writes:
>> +Sometimes, Org mode has difficulties recognising markup. It usually
>> +happens when markup marker symbols are present inside verbatim or code
>> +blocks:
>
> I disagree with the wording. Org mode has no difficulties recognizing
> markup nor does it parses text incorr
Hello,
Ihor Radchenko writes:
> * doc/org-manual.org (Emphasis and Monospace): Advice users to insert
> zero width space when Org does not parse emphasized text correctly.
> ---
[...]
> +Sometimes, Org mode has difficulties recognising markup. It usually
> +happens when markup marker symbols
Nicolas Goaziou writes:
> You can use a zero-width space to help Org sorting out the ambiguity,
> for example (| denotes the zero-width space):
>
> /|A link [[https://orgmode.org/?oops=true][Org Mode]]
>
> /A code ~user|/?my-user-variable~ with slash/
Makes sense. Maybe we should also mentio
Hello,
Ihor Radchenko writes:
> However, it is not clear then how to handle situations like
>
> /A link [[https://orgmode.org/?oops=true][Org Mode]]
> or
> /A code ~user/?my-user-variable~ with slash/
> or
> /A verbatim =text/.= with slash/
You can use a zero-width space to help Org sorting out
Nicolas Goaziou writes:
>> My intuition says that the current parser behaviour is not correct. It
>> would make more sense to prioritise link over italics. However, it would
>> require a major change in the parser - instead of a single pass, the
>> parser may parse different types of objects sequ
Hello,
Ihor Radchenko writes:
> My intuition says that the current parser behaviour is not correct. It
> would make more sense to prioritise link over italics. However, it would
> require a major change in the parser - instead of a single pass, the
> parser may parse different types of objects s
Max Nikulin writes:
> These regexps will always fail under some conditions, since it is not
> strict markup. An example is emphasis terminated inside link target
>
> /A link [[https://orgmode.org/?oops=true][Org Mode]]
Your example actually reveals a much bigger issue with current element
parse
i think i found it useful, long ago, when it was ok/tolerated to
change the var, and probably still, to /"do this"/ and /this,/.
although the latter seems weird to me now so i must not now understand
what i was doing.
i think changing the var was at least in a faq or on worg or so, so it
might be
On 17/11/2021 04:56, Samuel Wales wrote:
might be useful to know whether a default regexp change could satisfy
everybody? in my case i remove " and , from third re.
Samuel, I have seen your next message, but it still may be helpful to
have an example (for a case if you will meet the problem a
i should point out that my changes are old and i don't know if they
have already been done
On 11/16/21, Samuel Wales wrote:
> hmm i will have to try not setting o-e-r-c [ordinary user]. probably
> a lot of users do.
>
> might be useful to know whether a default regexp change could satisfy
> ever
hmm i will have to try not setting o-e-r-c [ordinary user]. probably
a lot of users do.
might be useful to know whether a default regexp change could satisfy
everybody? in my case i remove " and , from third re. i also have a
note "org-set-emph-re is what you are supposed to use, but it is
undo
Max Nikulin writes:
> Better docs and some restriction on defcustom values were discussed earlier:
> https://list.orgmode.org/87k0oyd3pw@nicolasgoaziou.fr/
> Nicolas Goaziou. Re: Using backticks for the inline code delimeter? Mon,
> 19 Apr 2021 11:27:07 +0200
>
> Sorry, I have not prepared a
On 15/11/2021 22:20, Ihor Radchenko wrote:
Nicolas Goaziou writes:
Ihor Radchenko writes:
This commit may cause random failures when
org-emphasis-regexp-components is changed by user.
This is not supported anyway.
Yeah. Though I have seen people changing this variable.
Maybe we should chan
Nicolas Goaziou writes:
> Ihor Radchenko writes:
>
>> This commit may cause random failures when
>> org-emphasis-regexp-components is changed by user.
>
> This is not supported anyway.
Yeah. Though I have seen people changing this variable.
Maybe we should change defvar to defconst?
>> org-emp
Hello,
Ihor Radchenko writes:
> This commit may cause random failures when
> org-emphasis-regexp-components is changed by user.
This is not supported anyway.
> org-emph-re is calculated according to org-emphasis-regexp-components.
> Changing org-emphasis-regexp-components can make "(when (look
This commit may cause random failures when
org-emphasis-regexp-components is changed by user. org-emph-re is
calculated according to org-emphasis-regexp-components. Changing
org-emphasis-regexp-components can make "(when (looking-at org-emph-re)"
in parsers return nil. The emphasised text will stil
24 matches
Mail list logo
