in reply to Re^3: How would you indent this?
in thread How would you indent this?

Hm. I can't reproduce that one. Do you have a example snippet for that behavior?

That might be just me. I used to write BEGIN: {}; with a semicolon after it, as you can see here, so it was doing something possibly excessive rather than actually wrong.

... and in at least one case things have got much worse, the case where it immediately throws an error about unbalanced parentheses whenever one presses the m or s keys. That should not happen and I can not reproduce it.

I couldn't reproduce it very well under emacs -Q, since it happens sometimes and doesn't happen other times. Here is a screenshot of a case when it happened. But it is reproducibly throwing the error message if I type m/ or tr/ instead of just m. The scrolling happens as well, which is much more annoying than the error message. I remember talking about the annoying error message to Ilya in about 2007 or so on comp.lang.perl.misc.

Replies are listed 'Best First'.
Re^5: How would you indent this?
by haj (Vicar) on Mar 19, 2021 at 12:15 UTC
    I used to write BEGIN: {}; with a semicolon after it

    In this case, the behavior of CPerl mode is understandable. One of the more difficult things when parsing Perl is to distinguish in which cases you need a semicolon after a closing brace and in which cases you don't. In your example, the semicolon is not required, so it is actually a statement of its own. I'd say CPerl mode is, to some extent, entitled to move this statement on a separate line, if only as a hint that you might revisit your code.

    By the way: Your BEGIN: is actually a label. If you want a BEGIN block, get rid of the colon.

    it happens sometimes and doesn't happen other times. Here is a screenshot...

    I can explain that, too. The message is technically correct. Read closely: End of ‘m} ... }’. The closing brace in the next line is interpreted as the starting delimiter of the match. That's weird, but it is actually valid to write m}foo}. The two numbers in the message are the character positions of the closing brace and the following newline, so M-g c 462 will take you to the closing brace. This is, in fact, the same situation as when you type m/ without a closing delimiter.

    Without that strange scrolling (which I still fail to reproduce), the message is harmless and will disappear as soon as the closing delimiter is entered. Since the message is also an indicator that syntax highlighting and indentation will not work correctly until the closing delimiter is found, I'd hesitate to just suppress it.

[reply]
      I'd say CPerl mode is, to some extent, entitled to move this statement on a separate line, if only as a hint that you might revisit your code.

      I don't think it's useful but it's not worth arguing about.

      Without that strange scrolling (which I still fail to reproduce)

      With emacs -Q I got the scrolling every time the error message was produced. It is a huge nuisance to deal with this scrolling.

      Since the message is also an indicator that syntax highlighting and indentation will not work correctly until the closing delimiter is found, I'd hesitate to just suppress it.

      That is absolutely ridiculous. Pressing the "m" key or the "s" key should not cause an error message to appear, especially not because of the extremely faint possibility that the user actually wants to start their regex with 

      m
}

      I don't know of any other language mode in Emacs, or even another instance in cperl-mode, where an unfinished statement of any kind, like a /* in c-mode or an open quote " without its closing quote causes an error message to appear. This unwanted error message is a truly exasperating nuisance.

[reply]
[d/l]
        I don't think it's useful but it's not worth arguing about.

        This behavior also goes away if you set the configuration variable ‘cperl-indent-region-fix-constructs’ to nil.

        I don't know of any other language mode in Emacs, or even another instance in cperl-mode, where an unfinished statement of any kind, like a /* in c-mode or an open quote " without its closing quote causes an error message to appear.

        Well, parens (of any kind) are sort of magical in Emacs, even in situations where they should not be, like within comments or strings. Comments and strings, on the other hand, have ... a different kind of magic.

        I am still at a loss why the message would cause scrolling. Emacs emits warnings rather frequently without any scrolling taking place. I have a hunch that the issue is not caused by CPerl mode. There are similar cases, which might help to narrow down the issue:

        • Start with an empty buffer and hit } (or any other "closing" paren). This should - in any mode - cause a message No matching parenthesis found. Does this message also cause scrolling for you?
        • Does the issue go away if you set the variable blink-matching-paren to nil or t? A value of 'jump (which was the default for some time) can indeed cause unwanted scrolling.
[reply]

In Section Seekers of Perl Wisdom