Relation with package authors (CPerl-mode follow-ups)

Relation with package authors (CPerl-mode follow-ups)

[Jérôme Marant]

Hi,

I've been recently in touch with Ilya Zakharevich (CPerl-mode author)
about Cperl-mode bugs I found in current version from Emacs CVS
trunk (version 5).
He was kind to take a look at them and found out those bugs have
already been fixed in 5.0 (I do confirm) and decided to stop
investigating further. This means changes to the CVS version lead
to regressions. Now, I'm left alone with my bugs.

It appears that there is a big delta between his original version and
the CVS version.
Why patches to Cperl-mode have never been sent back to him? Isn't he
meant to be the author of the mode?

I noticed this happens very often (speedbar is another example) and
this is quite disappointing.

Regards,

--
Jérôme Marant

Re: Relation with package authors (CPerl-mode follow-ups)

[Stefan Monnier]

> I've been recently in touch with Ilya Zakharevich (CPerl-mode author)
> about Cperl-mode bugs I found in current version from Emacs CVS
> trunk (version 5).

Please post them here.

> He was kind to take a look at them and found out those bugs have
> already been fixed in 5.0 (I do confirm) and decided to stop
> investigating further. This means changes to the CVS version lead
> to regressions.  Now, I'm left alone with my bugs.

What makes you think so?  Obviously someone else than Ilya must have caused
the changes between Ilya's version and Emacs's and it's quite likely
he/she's reading this mailing-list.

> It appears that there is a big delta between his original version and the
> CVS version.

Not that big, really.

> Why patches to Cperl-mode have never been sent back to him?
> Isn't he meant to be the author of the mode?

There was a disagreement about what the code should look like (I don't know
the specifics but my understanding is that Richard wanted some changes that
Ilya rejected), so his version and the Emacs version are not the same.
I do send him every patch I apply to Emacs's cperl-mode.el.


        Stefan

Re: Relation with package authors (CPerl-mode follow-ups)

[Richard Stallman]

    Why patches to Cperl-mode have never been sent back to him? Isn't he
    meant to be the author of the mode?

Because he told me he was not interested in maintaining it any more.

If he wants to start again, that would be great.  Would you like to
ask him?

Re: Relation with package authors (CPerl-mode follow-ups)

[Jérôme Marant]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I've been recently in touch with Ilya Zakharevich (CPerl-mode author)
>> about Cperl-mode bugs I found in current version from Emacs CVS
>> trunk (version 5).
>
> Please post them here.

I will do. Last time I reported one, you told me perl-mode did not
have such a bug :-P

>> He was kind to take a look at them and found out those bugs have
>> already been fixed in 5.0 (I do confirm) and decided to stop
>> investigating further. This means changes to the CVS version lead
>> to regressions.  Now, I'm left alone with my bugs.
>
> What makes you think so?  Obviously someone else than Ilya must have caused

Last time I reported a bug, I had the impression noone wanted to
maintain it in favour of perl-mode. I'm glad if not.

> the changes between Ilya's version and Emacs's and it's quite likely
> he/she's reading this mailing-list.

Quite.

...

>> Why patches to Cperl-mode have never been sent back to him?
>> Isn't he meant to be the author of the mode?
>
> There was a disagreement about what the code should look like (I don't know
> the specifics but my understanding is that Richard wanted some changes that
> Ilya rejected), so his version and the Emacs version are not the same.
> I do send him every patch I apply to Emacs's cperl-mode.el.

I'm happy you do. How does he react to your changes?

-- 
Jérôme Marant

Re: Relation with package authors (CPerl-mode follow-ups)

[Stefan Monnier]

>>> I've been recently in touch with Ilya Zakharevich (CPerl-mode author)
>>> about Cperl-mode bugs I found in current version from Emacs CVS
>>> trunk (version 5).
>> 
>> Please post them here.

> I will do. Last time I reported one, you told me perl-mode did not
> have such a bug :-P

But either you didn't mention or I didn't notice that the bug is also absent
from the original cperl-mode.el.  I'm not really interested in fixing
cperl-mode bugs, but I do find it important that our local changes to
cperl-mode don't add new bugs.

>> There was a disagreement about what the code should look like (I don't know
>> the specifics but my understanding is that Richard wanted some changes that
>> Ilya rejected), so his version and the Emacs version are not the same.
>> I do send him every patch I apply to Emacs's cperl-mode.el.

> I'm happy you do.  How does he react to your changes?

He acknowledges them (along the lines of "OK, I'll check later whether these
are appropriate for my version").


        Stefan

Re: Relation with package authors (CPerl-mode follow-ups)

[Richard Stallman]

    >> There was a disagreement about what the code should look like (I don't know
    >> the specifics but my understanding is that Richard wanted some changes that
    >> Ilya rejected), so his version and the Emacs version are not the same.

I don't remember for certain what happened.  I think I showed him some
bugs and asked him to fix them, and he didn't want to fix them.  However,
it is also possible that we made some general change in Emacs conventions
which called for changes in cperl-mode.

CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Jérôme Marant]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> I've been recently in touch with Ilya Zakharevich (CPerl-mode author)
>>>> about Cperl-mode bugs I found in current version from Emacs CVS
>>>> trunk (version 5).
>>> 
>>> Please post them here.
>
>> I will do. Last time I reported one, you told me perl-mode did not
>> have such a bug :-P
>
> But either you didn't mention or I didn't notice that the bug is also absent
> from the original cperl-mode.el.  I'm not really interested in fixing
> cperl-mode bugs, but I do find it important that our local changes to
> cperl-mode don't add new bugs.

Hi,

I'm sorry for being very late on this issue.

After trying to reproduce all cperl-mode bugs from the Debian BTS,
it seems that most of them have been fixed in the CVS trunk, but
one which is a regression from the original CPerl-mode from
Ilya.

Could you please take care of this?

Thanks in advance.

Here is the bug report:

-------------------------------------------------
The following bug report seems to be fixed in 4.32 but I could
reproduce it with 5.0 from the Emacs CVS.


> From vivek@etla.org Fri Nov 23 12:41:46 2001
Received: (at submit) by bugs.debian.org; 23 Nov 2001 18:41:46 +0000
Return-path: <vivek@etla.org>
Received: from salmon.pepperfish.org [195.149.39.195] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 167LGi-0006Fb-00; Fri, 23 Nov 2001 12:41:44 -0600
Received: from localhost ([127.0.0.1])
	by salmon.pepperfish.org with esmtp (Exim 3.32 #1 (Debian))
	id 167LGY-0001aw-00
	for <submit@bugs.debian.org>; Fri, 23 Nov 2001 18:41:34 +0000
Date: Fri, 23 Nov 2001 18:41:34 +0000 (GMT)
From: Vivek <vivek@etla.org>
X-X-Sender:  <vivek@salmon.pepperfish.org>
To:  <submit@bugs.debian.org>
Subject: emacs21-el: keyword highlighting bug in cperl-mode.el
Message-ID: <Pine.LNX.4.33.0111231840220.3595-100000@salmon.pepperfish.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Delivered-To: submit@bugs.debian.org


Package: emacs21-el
Version: 21.1-2woody
Severity: normal

subroutine names which contain built in keywords/function-names
delimited by _ characters get highlighted incorrectly:

For example, in emacs20-el:

sub foo_print_desc ()
{

}

'foo_print_desc' gets highlighted in font-lock-function-name-face
whereas under emacs21-el the 'print' part gets highlighted in
cperl-nonoverridable-face and the foo_ and _desc parts don't get
any highlighting at all. (This may be a bug in emacs21, of course)

The emacs package is one I compiled from source on woody, but I didn't
make any changes to the source - the sid system here is down at the moment,
but it should be easy to check that the bug exists there too...

-------------------------------------------------

-- 
Jérôme Marant

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Stefan Monnier]

[ Hi Ilya, I've installed another minor patch in Emacs's CVS repository.
  It's not needed for your version of cperl-mode, but you might still be
  interested. ]

> After trying to reproduce all cperl-mode bugs from the Debian BTS,
> it seems that most of them have been fixed in the CVS trunk, but
> one which is a regression from the original CPerl-mode from
> Ilya.

> Could you please take care of this?

[...]

> subroutine names which contain built in keywords/function-names
> delimited by _ characters get highlighted incorrectly:

> For example, in emacs20-el:

> sub foo_print_desc ()
> {

> }

> 'foo_print_desc' gets highlighted in font-lock-function-name-face

So the bug is indeed absent from Ilya's cperl-mode and it is triggered by
the fact that Emacs's cperl-mode.el does not give _ word syntax.

To make up for it, the normal answer is to set font-lock-defaults so that _
does have word syntax during font-locking (but not while editing).

To get it to work I had to remove an apparently spurious set-syntax-table in
cperl-find-pods-heres.

See the patch below which seems to fix it,


        Stefan


--- cperl-mode.el	20 jun 2005 09:35:15 -0400	1.70
+++ cperl-mode.el	29 jun 2005 03:53:37 -0400	
@@ -1516,7 +1516,8 @@
 	 (t
 	  '((cperl-load-font-lock-keywords
 	     cperl-load-font-lock-keywords-1
-	     cperl-load-font-lock-keywords-2)))))
+	     cperl-load-font-lock-keywords-2)
+            nil nil ((?_ . "w"))))))
   (make-local-variable 'cperl-syntax-state)
   (if cperl-use-syntax-table-text-property
       (progn
@@ -3840,7 +3841,11 @@
       (and (buffer-modified-p)
 	   (not modified)
 	   (set-buffer-modified-p nil))
-      (set-syntax-table cperl-mode-syntax-table))
+      ;; I do not understand what this is doing here.  It breaks font-locking
+      ;; because it resets the syntax-table from font-lock-syntax-table to
+      ;; cperl-mode-syntax-table.
+      ;; (set-syntax-table cperl-mode-syntax-table)
+      )
     (car err-l)))
 
 (defun cperl-backward-to-noncomment (lim)

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Jérôme Marant]

Selon Stefan Monnier <monnier@iro.umontreal.ca>:

> > 'foo_print_desc' gets highlighted in font-lock-function-name-face
>
> So the bug is indeed absent from Ilya's cperl-mode and it is triggered by
> the fact that Emacs's cperl-mode.el does not give _ word syntax.
>
> To make up for it, the normal answer is to set font-lock-defaults so that _
> does have word syntax during font-locking (but not while editing).
>
> To get it to work I had to remove an apparently spurious set-syntax-table in
> cperl-find-pods-heres.

Thanks for taking care of this. I thought you forgot about it but I hate
harassing people.

> See the patch below which seems to fix it,

It does. Thanks again.

Regards,

--
Jérôme Marant

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Wed, Jun 29, 2005 at 04:00:23AM -0400, Stefan Monnier wrote:
> To make up for it, the normal answer is to set font-lock-defaults so that _
> does have word syntax during font-locking (but not while editing).
> 
> To get it to work I had to remove an apparently spurious set-syntax-table in
> cperl-find-pods-heres.

Could you please replace the CVS version of the cperl-mode.el with one on
my site?  Given that all the edits in CVS version break the mode more
and more, the users will appreciate this a lot.

The common fix to problems in FSF's cperl-mode is to upgrade to my version...

Thanks,
Ilya

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Miles Bader]

2005/6/30, Ilya Zakharevich <ilya@math.berkeley.edu>:
> Could you please replace the CVS version of the cperl-mode.el with one on
> my site?  Given that all the edits in CVS version break the mode more
> and more, the users will appreciate this a lot.
> 
> The common fix to problems in FSF's cperl-mode is to upgrade to my version...

In general we don't want to "replacements" like this, but rather do
proper merge.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Thu, Jun 30, 2005 at 02:26:59PM +0900, Miles Bader wrote:
> 2005/6/30, Ilya Zakharevich <ilya@math.berkeley.edu>:
> > Could you please replace the CVS version of the cperl-mode.el with one on
> > my site?  Given that all the edits in CVS version break the mode more
> > and more, the users will appreciate this a lot.
> > 
> > The common fix to problems in FSF's cperl-mode is to upgrade to my version...
> 
> In general we don't want to "replacements" like this, but rather do
> proper merge.

I suspect that in this case "a proper merge" will consist of removing
95% of changes made w.r.t. the reference (my) implementation.  I do
not think people have this much of time...

Hope this helps,
Ilya

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Miles Bader]

2005/6/30, Ilya Zakharevich <ilya@math.berkeley.edu>:
> > In general we don't want to "replacements" like this, but rather do
> > proper merge.
> 
> I suspect that in this case "a proper merge" will consist of removing
> 95% of changes made w.r.t. the reference (my) implementation. 

Perhaps so, but somebody has to make that judgement...

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Thu, Jun 30, 2005 at 03:16:24PM +0900, Miles Bader wrote:
> 2005/6/30, Ilya Zakharevich <ilya@math.berkeley.edu>:
> > > In general we don't want to "replacements" like this, but rather do
> > > proper merge.
> > 
> > I suspect that in this case "a proper merge" will consist of removing
> > 95% of changes made w.r.t. the reference (my) implementation. 
> 
> Perhaps so, but somebody has to make that judgement...

Sure.  Do you know somebody more quialified than me?

Thanks,
Ilya

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Miles Bader]

2005/6/30, Ilya Zakharevich <ilya@math.berkeley.edu>:
> > > I suspect that in this case "a proper merge" will consist of removing
> > > 95% of changes made w.r.t. the reference (my) implementation.
> >
> > Perhaps so, but somebody has to make that judgement...
> 
> Sure.  Do you know somebody more quialified than me?

Well if you've gone though the changes in the Emacs CVS and determined
that they're all safely discarded, then sure, of course; but your
previous posts to the thread made it sound as if you hadn't looked at
the details.

Or we could decide that it just doesn't matter and it's safe enough to
ignore the details -- but we usually don't do that.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Stefan Monnier]

>> To make up for it, the normal answer is to set font-lock-defaults so that _
>> does have word syntax during font-locking (but not while editing).
>> 
>> To get it to work I had to remove an apparently spurious set-syntax-table in
>> cperl-find-pods-heres.

> Could you please replace the CVS version of the cperl-mode.el with one on
> my site?  Given that all the edits in CVS version break the mode more
> and more, the users will appreciate this a lot.

As mentioned in my message, the reason for this particular problem is that
your code changes _ to have word syntax, which is considered in Emacs to be
a bug.  So the Emacs version of cperl-mode.el fixes this bug, which then
triggered the other bug I just fixed.

Yes the Emacs version has bugs that your version doesn't have, but your
version also has bugs that the Emacs version doesn't have (they're usually
different kinds of bugs, that have more to do with coding and UI
conventions, but they're bugs nevertheless for us Emacs maintainers).

I'd be very happy to merge the two versions, and indeed when I merged the
4.32 and then 5.0 version of your code I tried to reduce the differences
between the two, but we won't be able to get to a full merge until your
version integrates some of our changes.


        Stefan

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Thu, Jun 30, 2005 at 04:17:59PM +0900, Miles Bader wrote:
> 2005/6/30, Ilya Zakharevich <ilya@math.berkeley.edu>:
> > > > I suspect that in this case "a proper merge" will consist of removing
> > > > 95% of changes made w.r.t. the reference (my) implementation.
> > >
> > > Perhaps so, but somebody has to make that judgement...
> > 
> > Sure.  Do you know somebody more quialified than me?
> 
> Well if you've gone though the changes in the Emacs CVS and determined
> that they're all safely discarded, then sure, of course; but your
> previous posts to the thread made it sound as if you hadn't looked at
> the details.

Not now.  But I did during the previous iteration - when I released
v5.0 (it was not 95% that time; but *for non-configuration type edits*
it might have been about 100%).  And what I see are the bug reports
which are solved by switching from FSF's version.

Trying to maintain two separate versions was a bold experiment; I
supported it for a long time.  However, it looks like this experiment
failed miserably - most of FSF edits are backwards in usability.

*Something* must be done in this situation.  [I realize that it is a
potentially painful topic; it does not help that a lot of people find
my writing style offending.  My apologies (including "in advance"); it
is not intendend.]

Yours,
Ilya

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Thu, Jun 30, 2005 at 02:01:29PM -0400, Stefan Monnier wrote:
> I'd be very happy to merge the two versions, and indeed when I merged the
> 4.32 and then 5.0 version of your code I tried to reduce the differences
> between the two, but we won't be able to get to a full merge until your
> version integrates some of our changes.

I'm afraid you have it backwards.  When I released 5.0, I merged all
the "useful" stuff from FSF version.

Hope this helps,
Ilya

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Stefan Monnier]

>> I'd be very happy to merge the two versions, and indeed when I merged the
>> 4.32 and then 5.0 version of your code I tried to reduce the differences
>> between the two, but we won't be able to get to a full merge until your
>> version integrates some of our changes.

> I'm afraid you have it backwards.  When I released 5.0, I merged all
> the "useful" stuff from FSF version.

No, I don't have it backwards.  We both tried to reduce the divergence.


        Stefan

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Richard M. Stallman]

    I suspect that in this case "a proper merge" will consist of removing
    95% of changes made w.r.t. the reference (my) implementation.

If that's the right thing to do, then let's do it.  However, we have
to find the other 5% (or whatever fraction it is) and keep them--we
can't throw them away without checking.  Also, we'll need change log
entries for the changes, starting from our current version.

If you want to do this work, that would be ideal, but our changes do
need to be look at one by one, not discarded en masse.

The easiest way to look at them is to diff our current version against
a suitable old version.  I will do that for you if you want.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Miles Bader]

Ilya Zakharevich <ilya@Math.Berkeley.EDU> writes:
> *Something* must be done in this situation.

Sure, it sounds like a proper merge is in order.

That is, apply all Emacs changes since the last merge point to your
current version, and resolve any conflicts.  You or some other cperl
knowledgable person can look over the changes to see if there are any
which don't make sense.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Richard M. Stallman]

    Trying to maintain two separate versions was a bold experiment; I
    supported it for a long time.  However, it looks like this experiment
    failed miserably - most of FSF edits are backwards in usability.

Each of them was made to fix a problem.  So they were improvements.
If you fixed the same problems better, by all means let's switch
to your fixes.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Stefan Monnier]

>> *Something* must be done in this situation.

> Sure, it sounds like a proper merge is in order.

> That is, apply all Emacs changes since the last merge point to your
> current version, and resolve any conflicts.  You or some other cperl
> knowledgable person can look over the changes to see if there are any
> which don't make sense.

cvs diff -r Ilya_5_0 lisp/progmodes/cperl-mode.el

Note that a rapid glance indicates that the "cperl-foo-face => cperl-foo"
conversion was probably not done quite right.


        Stefan

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> cvs diff -r Ilya_5_0 lisp/progmodes/cperl-mode.el
>
> Note that a rapid glance indicates that the "cperl-foo-face => cperl-foo"
> conversion was probably not done quite right.

Any pointers?  I did actually test the result a bit... :-)

-Miles
-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Stefan Monnier]

>> cvs diff -r Ilya_5_0 lisp/progmodes/cperl-mode.el
>> 
>> Note that a rapid glance indicates that the "cperl-foo-face => cperl-foo"
>> conversion was probably not done quite right.

> Any pointers?  I did actually test the result a bit... :-)

My impression is that the result still works but not in the same way
if the user sets cperl-foo-face to something else than `cperl-foo'.
But there was too much quoting to be sure without taking more time.


        Stefan

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Fri, Jul 01, 2005 at 10:20:31AM +0900, Miles Bader wrote:
> Ilya Zakharevich <ilya@Math.Berkeley.EDU> writes:
> > *Something* must be done in this situation.
> 
> Sure, it sounds like a proper merge is in order.
> 
> That is, apply all Emacs changes since the last merge point to your
> current version, and resolve any conflicts.

My point is that most edits must be removed, since they introduce much
more problems than they fix.

Hope this helps,
Ilya

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Miles Bader]

2005/7/2, Ilya Zakharevich <ilya@math.berkeley.edu>:
> > That is, apply all Emacs changes since the last merge point to your
> > current version, and resolve any conflicts.
> 
> My point is that most edits must be removed, since they introduce much
> more problems than they fix.

Maybe you are right, but this must be determined individually for each
change, using real information.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Richard M. Stallman]

    My point is that most edits must be removed, since they introduce much
    more problems than they fix.

Removing them is fine, as long as the important problems we fixed get
fixed some other way.

Re: CPerl-mode bug [Re: Relation with package authors (CPerl-mode follow-ups)]

[Ilya Zakharevich]

On Sat, Jul 02, 2005 at 10:08:20AM +0900, Miles Bader wrote:

> > My point is that most edits must be removed, since they introduce much
> > more problems than they fix.

> Maybe you are right, but this must be determined individually for each
> change, using real information.

Well, you know my opinion now.  And my principal target was to share
this opinion.

Best,
Ilya