[-- Attachment #1: Type: text/plain, Size: 1197 bytes --] Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. ------------------------------------------------------------------------ When parsing the following code: Am richtigen Ort zur richtigen Zeit (=+=; 1x pro Abenteuer im richtigen Moment auftauchen), Computeraffinität (=+= oder =++=; Bonus von 3 oder 6), Kurze Aufmerksamskeitsspanne (~-~), Photographisches Gedächtnis (=+=), Primitive Technologie (~-~), Schreckhaft (~-~), Schrecklich Schusselig (~-~), Toller Laptop (=+=) oder Verträumt (~-~). The fourth line is highlighted as code beginning at the first ~-~ until the final closing paren (")") of the paragraph. LaTeX-Export is correct, though. Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/) -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
[-- Attachment #1: Type: text/plain, Size: 636 bytes --] "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: > When parsing the following code: > > Am richtigen Ort zur richtigen Zeit (=+=; 1x pro Abenteuer im richtigen > Moment auftauchen), Computeraffinität (=+= oder =++=; Bonus von 3 oder 6), > Kurze Aufmerksamskeitsspanne (~-~), Photographisches Gedächtnis (=+=), > Primitive Technologie (~-~), Schreckhaft (~-~), Schrecklich Schusselig (~-~), > Toller Laptop (=+=) oder Verträumt (~-~). > > The fourth line is highlighted as code beginning at the first ~-~ until > the final closing paren (")") of the paragraph. Confirmed The fix is attached. Best, Ihor [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-org-do-emphasis-faces-Never-treat-closing-marker-as-.patch --] [-- Type: text/x-diff, Size: 1151 bytes --] From a4c864b7f983a135e8debbc32d8ef4ff3f2e89f4 Mon Sep 17 00:00:00 2001 Message-Id: <a4c864b7f983a135e8debbc32d8ef4ff3f2e89f4.1633082097.git.yantar92@gmail.com> From: Ihor Radchenko <yantar92@gmail.com> Date: Fri, 1 Oct 2021 17:47:02 +0800 Subject: [PATCH] org-do-emphasis-faces: Never treat closing marker as next opening marker * lisp/org.el (org-do-emphasis-faces): Make sure that we never match ending marker of an emphasis as a beginning marker of another emphasis. For example, in "(~-~) test (~+~)" "~) test (~" is a valid code match unless we move point to the end the first code emphasis completely during parsing. Fixes https://orgmode.org/list/87fsujp7mc.fsf@web.de --- lisp/org.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org.el b/lisp/org.el index 9608b52ee..9f68182d9 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4855,6 +4855,7 @@ (defun org-do-emphasis-faces (limit) '(invisible t)) (add-text-properties (match-beginning 3) (match-end 3) '(invisible t))) + (goto-char (match-end 0)) (throw :exit t))))))))) (defun org-emphasize (&optional char) -- 2.32.0
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> The fix is attached.
Looks good, feel free to apply in the bugfix branch.
--
Bastien
Bastien <bzg@gnu.org> writes:
> Hi Ihor,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> The fix is attached.
>
> Looks good, feel free to apply in the bugfix branch.
Done (fa315986a). Marking the bug as fixed.
Should I also merge main with bugfix every time?
Best,
Ihor
Thanks!
Ihor Radchenko <yantar92@gmail.com> writes:
> Should I also merge main with bugfix every time?
You should merge bugfix into main, yes (but not main into bugfix.)
--
Bastien
Also marking patch as applied
Bastien <bzg@gnu.org> writes:
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Should I also merge main with bugfix every time?
>
> You should merge bugfix into main, yes (but not main into bugfix.)
Thanks for the clarification. It indeed makes sense, but I was not sure
if merging too frequently is ok or not.
Best,
Ihor
Bastien <bzg@gnu.org> writes: > Thanks! > > Ihor Radchenko <yantar92@gmail.com> writes: > >> Should I also merge main with bugfix every time? > > You should merge bugfix into main, yes (but not main into bugfix.) This patch is actually not good. It breaks nested emphasis like /italic *bold* more italic/ and some other cases [1]. I feel that a proper fix should leverage org-element parser API to determine the emphasis boundaries. However, I am not sure about performance. I am thinking to revert the patch and reopen (BTW, how to do it in Woof!?) this bug report for now. WDYT? [1] https://orgmode.org/list/875yu4pc9m.fsf@localhost Best, Ihor
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> I am thinking to revert the patch and reopen (BTW, how to do it in
> Woof!?) this bug report for now.
Sure, please go ahead, thanks.
PS: I'm not sure how to do this with Woof! but I'm working on the next
version of Woof! where this will be possible.
--
Bastien
Bastien,
> PS: I'm not sure how to do this with Woof! but I'm working on the next
> version of Woof! where this will be possible.
i hope you will call the next version: Woof, woof!
:)
Greg Minshall <minshall@umich.edu> writes:
> i hope you will call the next version: Woof, woof!
Ahah!
Actually, when I told my daughter I was programming "Woof!" as a tool
to ensure that important emails where receiving enough attention from
the community, she suggested I should program something for the "poor
unimportant emails" out there... of course she'd call it "Mew!"
And I'm seriously considering this: something like an auto-bumper for
bug reports and help requests that didn't get any anwer...
:)
--
Bastien
> Actually, when I told my daughter I was programming "Woof!" as a tool
> to ensure that important emails where receiving enough attention from
> the community, she suggested I should program something for the "poor
> unimportant emails" out there... of course she'd call it "Mew!"
>
> And I'm seriously considering this: something like an auto-bumper for
> bug reports and help requests that didn't get any anwer...
:)
On 26/10/2021 00:33, Bastien wrote:
> Ihor Radchenko writes:
>
>> I am thinking to revert the patch and reopen (BTW, how to do it in
>> Woof!?) this bug report for now.
>
> Sure, please go ahead, thanks.
>
> PS: I'm not sure how to do this with Woof! but I'm working on the next
> version of Woof! where this will be possible.
Would not it be enough to just add X-Woof-Bug header to the message?
Maybe even with "(Reopened)" suffix to the title to warn other people
that it is not a forgotten bug, even if they remember that some patch
was committed. It is a wild guess, I did not looked into the "Woof!"
code. I just assume that logic inside is not overcomplicated.
We need to fix the problem (see the first message in the thread) in some other way. I currently cannot think anything better than using org-element parser (which may be slow) to avoid treating closing emphasis marker as a new opening marker. Max Nikulin <manikulin@gmail.com> writes: > Would not it be enough to just add X-Woof-Bug header to the message? > Maybe even with "(Reopened)" suffix to the title to warn other people > that it is not a forgotten bug, even if they remember that some patch > was committed. It is a wild guess, I did not looked into the "Woof!" > code. I just assume that logic inside is not overcomplicated. Trying it now in this message. I was mostly confused by the new Woof! docs in https://github.com/bzg/woof/blob/master/resources/md/howto.md Best, Ihor
Canceled.
On 27/10/2021 14:08, Ihor Radchenko wrote:
> Max Nikulin writes:
>
>> Would not it be enough to just add X-Woof-Bug header to the message?
>> Maybe even with "(Reopened)" suffix to the title to warn other people
>> that it is not a forgotten bug, even if they remember that some patch
>> was committed. It is a wild guess, I did not looked into the "Woof!"
>> code. I just assume that logic inside is not overcomplicated.
>
> Trying it now in this message. I was mostly confused by the new Woof!
> docs in https://github.com/bzg/woof/blob/master/resources/md/howto.md
It works in the sense that your message added a bug named "yes", I am
going to remove it and to create a more informative one.
I agree that older docs were more clear.
Sorry for the noise.
On 27/10/2021 18:50, Max Nikulin wrote: > Canceled. Magic in the message body did not help, so one more attempt with the header. > On 27/10/2021 14:08, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>> Would not it be enough to just add X-Woof-Bug header to the message? >>> Maybe even with "(Reopened)" suffix to the title to warn other people >>> that it is not a forgotten bug, even if they remember that some patch >>> was committed. It is a wild guess, I did not looked into the "Woof!" >>> code. I just assume that logic inside is not overcomplicated. >> >> Trying it now in this message. I was mostly confused by the new Woof! >> docs in https://github.com/bzg/woof/blob/master/resources/md/howto.md > > It works in the sense that your message added a bug named "yes", I am > going to remove it and to create a more informative one. > > I agree that older docs were more clear. gitk does not like emoji in commits... > Sorry for the noise.
This is a message to track the issue on https://updates.orgmode.org On 01/10/2021 16:56, Ihor Radchenko wrote: > "Dr. Arne Babenhauserheide" writes: > >> When parsing the following code: >> >> Am richtigen Ort zur richtigen Zeit (=+=; 1x pro Abenteuer im richtigen >> Moment auftauchen), Computeraffinität (=+= oder =++=; Bonus von 3 oder 6), >> Kurze Aufmerksamskeitsspanne (~-~), Photographisches Gedächtnis (=+=), >> Primitive Technologie (~-~), Schreckhaft (~-~), Schrecklich Schusselig (~-~), >> Toller Laptop (=+=) oder Verträumt (~-~). >> >> The fourth line is highlighted as code beginning at the first ~-~ until >> the final closing paren (")") of the paragraph. > > The fix is attached. So Ihor reverted the change by commit 52cdf53328 > Revert "org-do-emphasis-faces: Never treat closing marker as next opening marker" > > This reverts commit fa315986a115028d289f4921281e44e35842a27b. > > The commit broke fontification of nested emphasis like > /italic *bold* more italic/. P.S. Earlier added "yes" entry were successfully removed by my previous message to this thread with "X-Woof-Bug: canceled" header. Hope, correct header will be set by "X-Woof-Bug: Bug: font-lock error with - in code-mode (reopened)"
Max Nikulin <manikulin@gmail.com> writes:
> P.S. Earlier added "yes" entry were successfully removed by my previous
> message to this thread with "X-Woof-Bug: canceled" header. Hope, correct
> header will be set by "X-Woof-Bug: Bug: font-lock error with - in
> code-mode (reopened)"
Thanks! I can see the correct bug title in updates.orgmode.org now.
Best,
Ihor