bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Fri, 30 Oct 2020 21:19:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +(ert-deftest cperl-bug37127 ()
> [...]
>> +    ;; part two: Regex terminator missing -> message
>> +    (ert-with-message-capture collected-messages
>> +      (with-temp-buffer
>> +        (insert "$_ =~ /(..;")
>> +        (goto-char (point-min))
>> +        (cperl-mode)
>> +        (search-forward ".")
>> +        (let ((last-command-event ?\)))
>> +          (cperl-electric-rparen 1)
>> +          (cperl-find-pods-heres (point-min) (point-max) t)))
>> +      (should (string-match "^End of .* string/RE"
>> +                            collected-messages)))))
>
> Why is this behavior desirable?

> I mean, I don't necessarily mind it, but as a user I find it odd that
> typing a `)` which has a matching `(` nearby (which can be found without
> crossing any string/RE boundary) should emit a warning about some
> "unrelated" surrounding entity like the RE in which it is located.

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 :)

> Emacs usually doesn't emit any such warning when editing within an
> unclosed string.

That's true.  However, unclosed strings are rather simple constructs
when compared to Perl's quote-like operators.  Often, in particular with
the /x modifier, they span several lines.  The message contains
information about which operator is currently being processed, and also
what terminator is used.  In Perl, almost any non-whitespace character
can be used as a delimiter, including letters, quotes, comment starters,
and colons.  So, I think the warning is ok as a real-time syntax check.

> I don't think we should necessarily change CPerl's behavior in this
> regard, but that we shouldn't consider it a feature and thus shouldn't
> enforce it in our tests.

I see now that at least this test should be skipped in Perl mode, which
I failed to do.  Again.  Sorry for that.  In general, handling of REs
with non-standard delimiters is one of the areas where Perl mode has
significant deficiencies.

But of course, I'm also fine with just deleting this test case.  I wrote
it more out of a habit to check that the fix doesn't change the behavior
in other situations.
-- 
Cheers,
haj





reply via email to

[Prev in Thread] Current Thread [Next in Thread]