bug#23461: perl-mode: Displaying HERE-docs as strings instead of comments [PATCH]

[haj@posteo.de (Harald Jörg)]

Stefan Monnier writes:

> I suspect that shifting the "here-doc start" to the next line (in the
> "#\n" case only) and placing a `syntax-multiline` property on all three
> chars (#, \n, and the first char of the next line) will be our least
> bad option.

I have some doubts here regarding the effort and the side effects....

The current regexp for here-doc detection ends with the newline, so
either it needs to capture that first char of the next line, or the
property needs to be explicitly set.  Also, the regexp in the following
rule ("\\(?:$\\)\\s<" would no longer fire to call
`perl-syntax-propertize-special-constructs`.  Finally, that first
character of the here-doc would fail to pass the "(eq 2 (nth 7 state))"
test which has been introduced to fix the "current" bug#23461 in
`perl-font-lock-syntactic-face-function`; the same test is used in some
other places.  That's a lot of special cases to handle, for an edge case
like a "#" starting a comment in the last column.

As for side effects, it would break word movement for the first word of
within the here-doc, like it has been observed for the replacement
string of a regexp in Bug#24101.  While that's not a big deal, I found
it pretty stunning.  I understand now why this is happening, but I've no
fix.

Compared to that, just ignoring that special case is easy.  It has no
non-local side effects.  The only downside is that in this special case
a comment starter "#" is converted to a comment terminator "#" - so left
unfontified.  I could easily live with that.

> [...]
> I must admit I don't use Perl very much these days, but when I used it,
> I used it as a "better shell", so I thought of Perl's here docs in
> exactly the same way as sh's here docs.
>
> So maybe a compromise is to add a new `perl-heredoc` face and make it
> inherit from `font-lock-string-face` by default?

That's a possibility, sure.
-- 
Cheers,
haj