[cperl-mode] fontification problem with PODs

[LanX]

Hi

I experienced a problem with the fontification of POD's.

In the following example the second line is not classified as pod but
the keyword "for" is considered part of a loop statement.

--------------------------
lanx@nc10-ubuntu:~/tmp$ cat perlpod.pm
for (1..9) {print}
=for comment

This B<document> is in Pod format. To read this, use a Pod formatter,
like "perldoc perlpod".

=cut
---------------------------

which might be OK since there is an empty line missing between POD and
code.

So adding a newline at the second line should solve the problem, but
doesn't do so!!!

Strangely this problem is NOT present when calling emacs with -Q

---------------------------
lanx@nc10-ubuntu:~/tmp$ emacs -Q perlpod.pm -f cperl-mode
---------------------------

So adding the newline solves the problem!
And calling "M-x describe-text-properties" shows that the POD-text is
classified as such.

This emacs is bundled with cperl-mode.5.23.

Now I tried to figure out which cperl-mode version is causing the
problem, since I had 6.2 loaded in my configs.

---------------------------
lanx@nc10-ubuntu:~/tmp$ emacs -Q -l cperl-mode.el perlpod.pm -f cperl-
mode
lanx@nc10-ubuntu:~/tmp$ ll cperl-mode.el
lrwxrwxrwx 1 lanx lanx 18 2009-10-21 05:51 cperl-mode.el -> cperl-
mode.el.5.24
lanx@nc10-ubuntu:~/tmp$ ll cperl-mode.el*
lrwxrwxrwx 1 lanx lanx 18 2009-10-21 05:51 cperl-mode.el -> cperl-
mode.el.5.24
-r-------- 1 lanx lanx 399064 2009-10-21 05:48 cperl-mode.el.5.22
-r-------- 1 lanx lanx 395839 2009-10-21 05:32 cperl-mode.el.5.24
-r-------- 1 lanx lanx 402932 2009-10-21 05:32 cperl-mode.el.6.2
---------------------------

But it doesn't matter which version I'm loading the problem remains. I
also tried emacs23 instead of emacs22, without success.

It seems that loading another cperl-mode version causes conflicts with
the bundled version!

So effectively one has to stick with the bundled version ... :(

cheers
Rolf

[Ilya Zakharevich]

On 2009-10-21, LanX <lanx...@googlemail.com> wrote:
> In the following example the second line is not classified as pod but
> the keyword "for" is considered part of a loop statement.

Since it is not POD, I do not see any problem

> --------------------------
> lanx@nc10-ubuntu:~/tmp$ cat perlpod.pm
> for (1..9) {print}
>=for comment

> It seems that loading another cperl-mode version causes conflicts with
> the bundled version!

This may happen if the buggy version is preloaded... [I do not see
any problem with my version, both with emacs v19 and v21.]

> So effectively one has to stick with the bundled version ... :(

One may try to remove the buggy version from preloaded stuff (do not
remember how).

Yours,
Ilya

[Will Willis]

over the years I've had to do alot of repeated M-x cperl-mode whilst coding in perl scripts containing POD - as the syntax highlighting would get lost or confused part-way down the file (usually turning everything into the comment color). Just something I've dealt with and never really attempted to fix.

I'm glad I'm not the only one having issues.

-Will

[Joseph Brenner]

LanX <lanx...@googlemail.com> writes:

> I experienced a problem with the fontification of POD's.
>
> In the following example the second line is not classified as pod but
> the keyword "for" is considered part of a loop statement.
>
> --------------------------
> lanx@nc10-ubuntu:~/tmp$ cat perlpod.pm
> for (1..9) {print}
> =for comment
>
> This B<document> is in Pod format. To read this, use a Pod formatter,
> like "perldoc perlpod".
>
> =cut
> ---------------------------
>
> which might be OK since there is an empty line missing between POD and
> code.
>
> So adding a newline at the second line should solve the problem, but
> doesn't do so!!!

I was going to point out the same thing, but also, I recommend running
the "podchecker" program occasionally.

pod is cool, but very wasteful of vertical whitespace, and weirdly
enough it's whitespace sensitive: it wants completely empty blank lines
before and after the tags -- blank lines with spaces on them are not
good enough.

> Strangely this problem is NOT present when calling emacs with -Q
>
> ---------------------------
> lanx@nc10-ubuntu:~/tmp$ emacs -Q perlpod.pm -f cperl-mode
> ---------------------------
>
> So adding the newline solves the problem!
> And calling "M-x describe-text-properties" shows that the POD-text is
> classified as such.

This is indeed sounding pretty weird.

> It seems that loading another cperl-mode version causes conflicts with
> the bundled version!
>
> So effectively one has to stick with the bundled version ... :(

Well... I might suspect a conflict between something else you normally
load and cperl-mode. It's difficult to say what... remember that emacs
has just one big global namespace, so hypothetically all sorts of
action-at-a-distance problems are possible with poorly written elisp.

[LanX]

Hi Joe

What I learned in this thread is that one simply has to stick with the
bundled version of cperl-mode.

Loading another version causes conflicts...

So if you need a newer version of cperl better upgrade emacs, since
the newest version is in the repository now.

Cheers
Rolf

[Ilya Zakharevich]

AFAIU, the question is not whether the version is "newer" or "older",
but whether it is mine or not. My versions work. Bundled do not.

Moreover, preloading a bundled version breaks something when somebody
loads mine version later. Sorry, I cannot investigate it since
computers around do not have anything runnable which is newer than
v21 (which does not preload)...

Hope this helps,
Ilya

[Alan Mackenzie]

Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> On 2009-12-09, LanX <lanx...@googlemail.com> wrote:
>> Hi Joe

>> What I learned in this thread is that one simply has to stick with the
>> bundled version of cperl-mode.

>> Loading another version causes conflicts...

>> So if you need a newer version of cperl better upgrade emacs, since
>> the newest version is in the repository now.

> AFAIU, the question is not whether the version is "newer" or "older",
> but whether it is mine or not. My versions work. Bundled do not.

And your version is available from which URL, please?

> Moreover, preloading a bundled version breaks something when somebody
> loads mine version later. Sorry, I cannot investigate it since
> computers around do not have anything runnable which is newer than
> v21 (which does not preload)...

> Hope this helps,
> Ilya

--
Alan Mackenzie (Nuremberg, Germany).

[Ilya Zakharevich]

On 2010-05-02, Alan Mackenzie <a...@muc.de> wrote:
> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
>> On 2009-12-09, LanX <lanx...@googlemail.com> wrote:
>>> Hi Joe
>
>>> What I learned in this thread is that one simply has to stick with the
>>> bundled version of cperl-mode.
>
>>> Loading another version causes conflicts...
>
>>> So if you need a newer version of cperl better upgrade emacs, since
>>> the newest version is in the repository now.
>
>> AFAIU, the question is not whether the version is "newer" or "older",
>> but whether it is mine or not. My versions work. Bundled do not.
>
> And your version is available from which URL, please?

I think it is there in the file. Should be in
ilyaz.org/software/emacs/

(But, as I said, with newer versions of Emacs I suspect one ALSO
needs to prune all cperl-* symbols first - there is some
contamination left from the bundled (pre-loaded!) version.)

Yours,
Ilya

[Alan Mackenzie]

Ilya Zakharevich <nospam...@ilyaz.org> wrote:
> On 2010-05-02, Alan Mackenzie <a...@muc.de> wrote:
>> Ilya Zakharevich <nospam...@ilyaz.org> wrote:
>>> On 2009-12-09, LanX <lanx...@googlemail.com> wrote:
>>>> Hi Joe

>>>> What I learned in this thread is that one simply has to stick with the
>>>> bundled version of cperl-mode.

>>>> Loading another version causes conflicts...

>>>> So if you need a newer version of cperl better upgrade emacs, since
>>>> the newest version is in the repository now.

>>> AFAIU, the question is not whether the version is "newer" or "older",
>>> but whether it is mine or not. My versions work. Bundled do not.

>> And your version is available from which URL, please?

> I think it is there in the file. Should be in
> ilyaz.org/software/emacs/

Thanks.

> (But, as I said, with newer versions of Emacs I suspect one ALSO
> needs to prune all cperl-* symbols first - there is some
> contamination left from the bundled (pre-loaded!) version.)

Which is a way of saying that the initialisation for cperl-mode isn't
watertight. ;-)

> Yours,

[LanX]

> Which is a way of saying that the initialisation for cperl-mode isn't
> watertight.  ;-)

no it's a way to say that emacs is not watertight.

There is no automatic testing system and every little incompatible
changes can easily break a complex mode like cperl.

I recently had a long discussion until the dev team admitted that they
screwed font locking in compilation buffer because they started
appending newlines to all regexes ...

[Ilya Zakharevich]

On 2010-05-04, Alan Mackenzie <a...@muc.de> wrote:
>> (But, as I said, with newer versions of Emacs I suspect one ALSO
>> needs to prune all cperl-* symbols first - there is some
>> contamination left from the bundled (pre-loaded!) version.)
>
> Which is a way of saying that the initialisation for cperl-mode isn't
> watertight. ;-)

Could you be more specific with your "watertight" adjective? How
should a module writer deal with a possibility to have a buggy version
preloaded?

[And keep in mind that I have no clue how `defvar' should work with
preloaded modules]

Yours,
Ilya

[Juanma Barranquero]

On Thu, May 6, 2010 at 22:08, Ilya Zakharevich <nospam...@ilyaz.org> wrote:

> How
> should a module writer deal with a possibility to have a buggy version
> preloaded?

Assuming your version is loaded with `load' (because with `require' it
won't be loaded if the buggy version already is), perhaps some
variation of this:

(when (featurep 'cperl-mode) ; or some other check
(unload-feature 'cperl-mode)
(require 'cperl-mode))

How effective that is depends on how well `unload-feature' deals with
cperl-mode. (Not very well, at the moment, but a
cperl-mode-unload-function could be added to standard Emacs.)

Juanma

[Stefan Monnier]

>> How should a module writer deal with a possibility to have a buggy
>> version preloaded?

> Assuming your version is loaded with `load' (because with `require' it
> won't be loaded if the buggy version already is), perhaps some
> variation of this:

> (when (featurep 'cperl-mode) ; or some other check
> (unload-feature 'cperl-mode)
> (require 'cperl-mode))

> How effective that is depends on how well `unload-feature' deals with
> cperl-mode. (Not very well, at the moment, but a
> cperl-mode-unload-function could be added to standard Emacs.)

Emacs's cperl-mode is not preloaded, so (featurep 'cperl-mode) should
pretty much always return nil.
If there are issues, they would come from the parts of Emacs's
cperl-mode.el that have a ;;;###autoload cookie. Everything else should
have no effect.

Stefan

[Juanma Barranquero]

On Fri, May 7, 2010 at 04:55, Stefan Monnier <mon...@iro.umontreal.ca> wrote:

> Emacs's cperl-mode is not preloaded, so (featurep 'cperl-mode) should
> pretty much always return nil.

I took Ilya's "preloaded" as meaning "already loaded".

Juanma