[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37127: [PATCH] cperl-mode: Suppress a misleading message
From: |
Harald Jörg |
Subject: |
bug#37127: [PATCH] cperl-mode: Suppress a misleading message |
Date: |
Sat, 31 Oct 2020 02:09:45 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> In an unterminated RE, the message will appear for every single
>> character you type, until the RE is terminated. I'd find it odd if the
>> `)` was the only character where the message didn't appear :)
>
> I agree that `)` should be no different. And while as a user I find
> such messages more annoying than helpful (I much prefer to be warned by
> some font-lock highlighting (e.g. by "bleeding" past what I expected to
> be the end) or something like a tooltip), I'm OK with the current
> behavior. I just don't think that not emitting the message should
> trigger a test failure.
I agree. Also, I would be fine with different warning mechanisms, but I
guess these need more work (and are not in the scope for the current bug).
>> In Perl, almost any non-whitespace character can be used as
>> a delimiter, including letters, quotes, comment starters, and colons.
>
> Yes, I remember that from when I wrote the corresponding
> syntax-propertize code for `perl-mode` ;-)
>
>> I see now that at least this test should be skipped in Perl mode, which
>> I failed to do. Again. Sorry for that.
>
> No problem.
>
> BTW, I just noticed that if I revert your patch to cperl-mode.el, the
> test still succeeds :-(
Maybe I should look into that.... When run manually, the symptom is
there, in various Emacs versions, and goes away with the patch. Without
the patch, the test fails when I run ERT interactively with emacs -Q in
Emacs 26.1. It succeeds without the patch when I run ERT in batch :(
I know I had several attempts to trick ERT into simulating a closing
paren keyboard event, but apparently still failed. I suspect the tests
don't make it past The caller of blink-matching-open
(blink-paren-post-self-insert-function), which tests for interactive
use. Your version calls blink-matching-open directly and avoids that
problem.
>> In general, handling of REs with non-standard delimiters is one of the
>> areas where Perl mode has significant deficiencies.
> Hmm... I thought I had managed to make it cover most cases back then.
> I'd be interested to know which cases I missed (or which new cases were
> introduced since then: after all it was quite some years ago).
I'll send that off-list (it has nothing to do with the current bug).
> In any case, along the way I decided that this bug was in large part to
> blame on blink-matching-open because it calls `syntax-propertize` from
> within narrowing. So I changed it which made your `cperl-mode`
> patch unnecessary. I also tweaked your test so that it does fail in the
> old code (and passes with the new code) and so it also works in
> `perl-mode` (except for the second part which I kept but which would
> fail in `perl-mode`).
This is excellent! I didn't dare to even think about changing this
function which apparently works for all other modes, so I tried to work
around the issue.
> The patch I installed can be found below.
Great! Much better now. Many thanks!
--
Cheers,
haj