all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: haj@posteo.de (Harald Jörg)
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 37127@debbugs.gnu.org
Subject: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Sat, 31 Oct 2020 02:09:45 +0100	[thread overview]
Message-ID: <87tuubciau.fsf@hajtower> (raw)
In-Reply-To: <jwvwnz78mih.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 30 Oct 2020 18:12:13 -0400")

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





  reply	other threads:[~2020-10-31  1:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 12:17 bug#37127: 27.0.50; in cperl mode, scan-error Unbalanced parentheses Vincent Lefevre
2019-10-03 23:02 ` Stefan Kangas
2020-10-29 21:11 ` bug#37127: [PATCH] cperl-mode: Suppress a misleading message Harald Jörg
2020-10-30 12:24   ` Lars Ingebrigtsen
2020-10-30 14:30   ` Stefan Monnier
2020-10-30 20:19     ` Harald Jörg
2020-10-30 22:12       ` Stefan Monnier
2020-10-31  1:09         ` Harald Jörg [this message]
2020-11-02 22:52 ` bug#37127: [PATCH] A final tweak: Skip the test for older Emacsen Harald Jörg
2020-11-02 23:13   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuubciau.fsf@hajtower \
    --to=haj@posteo.de \
    --cc=37127@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.