cperl-mode.el: twigils and opers

[Trey Harris]

This has been driving me mad, and an hour of hacking at cperl-mode.el has
only convinced me that I don't know elisp well enough to solve the
problem....

Variables with twigils whose name matches something else are getting
recognized incorrectly. For example, $.x is getting interpreted as $.
followed by the x operator, $.system as $. and system, and so on. Worst
of all are $.s, $.y, $.q and so on, because emacs is looking for the
closing quote, wrecking all the syntax highlighting and indention from
then on. It also appears that @.foo and %.foo aren't being interpreted
correctly either, even when foo doesn't match anything else.

This observation is of the cperl-mode.el from the pugs repository.

Can anyone help fix cperl-mode with twigils?

Trey

--

[Steffen Schwigon]

Trey Harris <tr...@lopsa.org> writes:
> [cperl-mode.el]

As you already noticed cperl-mode.el is a very strange piece of
software. It's probably misunderstood like astronomers in the Dark
Ages.

> Variables with twigils whose name matches something else are getting
> recognized incorrectly. For example, $.x is getting interpreted as
> $. followed by the x operator, $.system as $. and system, and so on.

I already tried to do something about twigils and the dot syntax
($.foo, %.foo, ...) *should* already work. If not, I might have
introduced bugs during rather strange merge sessions with original
cperl-mode that sometimes happen.

First you could try an older revision, I recommend r7845 or r10822 of
pugs repository.

Second, there are known issues with two, hm, how to say?, "different
highlighting models" that seem to rival each other. Bind a key to
re-fontify and see what happens. In my emacs config I use

(global-set-key [f3] 'font-lock-fontify-buffer)

and pressing f3 corrects the wrong highlighting. I don't know why
that's the case. Dark Ages are calling.

> Can anyone help fix cperl-mode with twigils?

I will help, I already have some kind of that "thousand yard stare"
when I look at it. I'm only just in the middle of one of those "lack
of time" phases.

Generally I currently feel quite alone with my patches. I already
contacted local lisp heros in my town but they say: start to refactor
some things (even with concrete code suggestions), but I didn't
implemented them because of drifting away from original
cperl-mode. Incorporating my patches is difficult because of at least
one huge, silly copy'n'paste hack to make the new regex syntax
possible. And my Lisp-Foo an not match with the "officialness" and the
extreme backwards compatibility demands of the original cperl-mode.

*Maybe* a clear fork away from the original cperl-mode would make
sense. We could refactor with the help of other lisp coders and throw
away backwards compatibility issues we don't know about. But it's a
very big "maybe". Having one mode for all perl versions and for both
major Emacs variants with high backwards compatibility is a big plus
and there is much knowledge in original cperl-mode that progresses
itself, even as we speak. Currently I wouldn't fork it.

BTW, I work with XEmacs 21.4.7.
What's your Emacs?

GreetinX
Steffen
--
Steffen Schwigon <schw...@webit.de>
Dresden Perl Mongers <http://dresden-pm.org/>

[Trey Harris]

In a message dated Mon, 4 Sep 2006, Steffen Schwigon writes:
> First you could try an older revision, I recommend r7845 or r10822 of
> pugs repository.

No, neither of those work. To see what I'm talking about, just create a
file containing:

use v6-alpha;

class Point {
has $.x;
has $.y;
}

and try creating more code under the "has $.y" line, and notice that
indenting and highlighting after that point don't work because emacs
thinks it's in the middle of a y///.

> Second, there are known issues with two, hm, how to say?, "different
> highlighting models" that seem to rival each other. Bind a key to
> re-fontify and see what happens. In my emacs config I use
>
> (global-set-key [f3] 'font-lock-fontify-buffer)
>
> and pressing f3 corrects the wrong highlighting. I don't know why
> that's the case. Dark Ages are calling.

No, that doesn't help either, at any of rHEAD|r10822|r7845.

> *Maybe* a clear fork away from the original cperl-mode would make
> sense. We could refactor with the help of other lisp coders and throw
> away backwards compatibility issues we don't know about. But it's a
> very big "maybe". Having one mode for all perl versions and for both
> major Emacs variants with high backwards compatibility is a big plus
> and there is much knowledge in original cperl-mode that progresses
> itself, even as we speak. Currently I wouldn't fork it.

Well, a fork for cperl6-mode wouldn't be the worst thing... at least then
it would be possible to have working syntax highlighting and indention for
Perl 6. Right now I'm reduced to either turning off cperl-mode or
choosing my attribute names based on what Emacs can deal with, both of
which are maddening.

> BTW, I work with XEmacs 21.4.7.
> What's your Emacs?

XEmacs 21.4.14 and Emacs 22.0.50.1 (Aquamacs). Both show the same
behavior in this case.

Trey

[Steffen Schwigon]

Trey Harris <tr...@eecs.harvard.edu> writes:
> In a message dated Mon, 4 Sep 2006, Steffen Schwigon writes:
>> First you could try an older revision, I recommend r7845 or r10822 of
>> pugs repository.
>
> No, neither of those work. To see what I'm talking about, just create
> a file containing:
>
> use v6-alpha;
>
> class Point {
> has $.x;
> has $.y;
> }
>
> and try creating more code under the "has $.y" line, and notice that
> indenting and highlighting after that point don't work because emacs
> thinks it's in the middle of a y///.

I checked and indeed the twigils don't work. My test source file
(which worked correctly some time ago) also highlights wrong. It's for
sure a bug I introduced.

I can't promise that it also worked with "y" as variable name. That's
probably a second issue. But it should also be possible to solve.

> Well, a fork for cperl6-mode wouldn't be the worst thing... at least
> then it would be possible to have working syntax highlighting and
> indention for Perl 6.

This time the issues should be solvable. Forking shouldn't be
neccessary for this. I try to have a look at it this week.
Sorry that I'm not as fast as pugs development normally feels. :-)

[Steffen Schwigon]

Steffen Schwigon <schw...@webit.de> writes:
> I checked and indeed the twigils don't work. My test source file
> (which worked correctly some time ago) also highlights wrong. It's for
> sure a bug I introduced.

I now did some things on cperl-mode (eg. syncing with original v5.20)
and it seems highlighting of twigils generally works again.

Please try again, but in the meantime with longer variable names,
because ...

> I can't promise that it also worked with "y" as variable
> name. That's probably a second issue.

That's indeed a different issue. Using short variable names
y,tr,s,m,... with twigils still irritates it. Not yet solved.