From: Stefan Monnier <monnier@iro.umontreal.ca>
To: haj@posteo.de (Harald Jörg)
Cc: 37127@debbugs.gnu.org
Subject: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Fri, 30 Oct 2020 10:30:04 -0400 [thread overview]
Message-ID: <jwvpn4zaj1j.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87eelg3ffl.fsf@hajtower> ("Harald Jörg"'s message of "Thu, 29 Oct 2020 22:11:58 +0100")
> +(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.
Emacs usually doesn't emit any such warning when editing within an
unclosed string.
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.
Stefan
next prev parent reply other threads:[~2020-10-30 14:30 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 [this message]
2020-10-30 20:19 ` Harald Jörg
2020-10-30 22:12 ` Stefan Monnier
2020-10-31 1:09 ` Harald Jörg
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvpn4zaj1j.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=37127@debbugs.gnu.org \
--cc=haj@posteo.de \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).