Merging mistakes

Merging mistakes

[Eli Zaretskii]

The kind of problems described below happens too much lately.  I think
the unbearable lightness of merging with Bazaar is at least one of the
reasons.  Unless we find a safer way of doing this, I fear that Emacs
23.3 will either take a very long pretesting or will be released more
buggy than Emacs 23.2.

Any suggestions for how to avoid destabilizing the release branch by
too indiscriminate back-ports from the trunk?

------- Start of forwarded message -------
Resent-From: Sven Joachim <svenjoac@gmx.de>
Original-Sender: debbugs-submit-bounces@debbugs.gnu.org
Resent-To: owner@debbugs.gnu.org
Resent-CC: svenjoac@gmx.de, bug-gnu-emacs@gnu.org
Resent-Sender: help-debbugs@gnu.org
To: 7539@debbugs.gnu.org
From: Sven Joachim <svenjoac@gmx.de>
Date: Fri, 03 Dec 2010 11:15:15 +0100
Cc: Sven Joachim <svenjoac@gmx.de>
Subject: bug#7539: 23.2.90; smie.el uses stuff not available in emacs-23


Byte-compiling lisp/emacs-lisp/smie.el in emacs-23 gives the following
warnings:

,----
| In smie-setup:
| smie.el:1536:14:Warning: assignment to free variable
|     `blink-matching-check-function'
| 
| In end of data:
| smie.el:1559:1:Warning: the function `blink-matching-check-mismatch' is not
|     known to be defined.
`----

Indeed blink-matching-check-function and blink-matching-check-mismatch
only exist in the trunk, not in emacs-23.
------- End of forwarded message -------

Re: Merging mistakes

[Stefan Monnier]

> The kind of problems described below happens too much lately.  I think
> the unbearable lightness of merging with Bazaar is at least one of the
> reasons.  Unless we find a safer way of doing this, I fear that Emacs
> 23.3 will either take a very long pretesting or will be released more
> buggy than Emacs 23.2.

Actually, these specific smie byte-compiler-warnings have nothing to do
with bzr merging.  Just like others have already figured it in this
thread, they are simply the result of 2 conflicting desires:
- distribute smie.el with Emacs-23.3 so external packages can start to
  use it earlier.
- change as little of the code compared to the "upstream code".
So I left the blink-matching code, even though it's ineffective: it uses
a hook that's never run in Emacs-23.

I've tested the smie.el code in Emacs-23 about as much as is possible
(i.e. with coq-mode, sml-mode, octave-mode, modula2-mode, prolog-mode;
the last three requiring extra steps to perform this check since they
use pcase which doesn't exist/work in Emacs-23).

> Any suggestions for how to avoid destabilizing the release branch by
> too indiscriminate back-ports from the trunk?

But you're right that we need to be careful with it.  We haven't
received too many bug reports about the pretest code, tho, so it's not
clear whether we have a problem here.


        Stefan


> ------- Start of forwarded message -------
> Resent-From: Sven Joachim <svenjoac@gmx.de>
> Original-Sender: debbugs-submit-bounces@debbugs.gnu.org
> Resent-To: owner@debbugs.gnu.org
> Resent-CC: svenjoac@gmx.de, bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> To: 7539@debbugs.gnu.org
> From: Sven Joachim <svenjoac@gmx.de>
> Date: Fri, 03 Dec 2010 11:15:15 +0100
> Cc: Sven Joachim <svenjoac@gmx.de>
> Subject: bug#7539: 23.2.90; smie.el uses stuff not available in emacs-23


> Byte-compiling lisp/emacs-lisp/smie.el in emacs-23 gives the following
> warnings:

> ,----
> | In smie-setup:
> | smie.el:1536:14:Warning: assignment to free variable
> |     `blink-matching-check-function'
> | 
> | In end of data:
> | smie.el:1559:1:Warning: the function `blink-matching-check-mismatch' is not
> |     known to be defined.
> `----

> Indeed blink-matching-check-function and blink-matching-check-mismatch
> only exist in the trunk, not in emacs-23.
> ------- End of forwarded message -------

Re: Merging mistakes

[Leo]

On 2010-12-04 14:00 +0000, Stefan Monnier wrote:
> I've tested the smie.el code in Emacs-23 about as much as is possible
> (i.e. with coq-mode, sml-mode, octave-mode, modula2-mode, prolog-mode;
> the last three requiring extra steps to perform this check since they
> use pcase which doesn't exist/work in Emacs-23).

pcase.el seems to be working with this patch (I also add r100617) from
trunk:

commit f150e3df20d5fbfde1d2cfd3f58b390d3e9bd005
Author: Leo <sdl.web@gmail.com>
Date:   Mon Sep 27 00:05:57 2010 +0100

    Phase out old-style backquotes a bit more (r100605)
    
    Needed for pcase.el.

	Modified src/lread.c
diff --git a/src/lread.c b/src/lread.c
index ceac9de..72c01ed 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2700,7 +2700,17 @@ read1 (readcharfun, pch, first_in_list)
       }
 
     case '`':
-      if (first_in_list)
+      /* Transition from old-style to new-style:
+	 If we see "(`" it used to mean old-style, which usually works
+	 fine because ` should almost never appear in such a position
+	 for new-style.  But occasionally we need "(`" to mean new
+	 style, so we try to distinguish the two by the fact that we
+	 can either write "( `foo" or "(` foo", where the first
+	 intends to use new-style whereas the second intends to use
+	 old-style.  For Emacs-25, we should completely remove this
+	 first_in_list exception (old-style can still be obtained via
+	 "(\`" anyway).  */
+      if (first_in_list && (c = READCHAR, UNREAD (c), c == ' '))
 	{
 	  Vold_style_backquotes = Qt;
 	  goto default_label;

Re: Merging mistakes

[Stefan Monnier]

>> I've tested the smie.el code in Emacs-23 about as much as is possible
>> (i.e. with coq-mode, sml-mode, octave-mode, modula2-mode, prolog-mode;
>> the last three requiring extra steps to perform this check since they
>> use pcase which doesn't exist/work in Emacs-23).

> pcase.el seems to be working with this patch (I also add r100617) from
> trunk:

I know, but this patch introduces incompatibilities (e.g. with bbdb), so
it is not appropriate for Emacs-23.3.


        Stefan

Re: Merging mistakes

[Leo]

On 2010-12-04 16:14 +0000, Stefan Monnier wrote:
>> pcase.el seems to be working with this patch (I also add r100617) from
>> trunk:
>
> I know, but this patch introduces incompatibilities (e.g. with bbdb),
> so it is not appropriate for Emacs-23.3.

I must have fixed bbdb locally since I haven't noticed any problem with
bbdb. If necessary, we can ask for a bug fix release on bbdb. Roland
Winkler (maintainer of bibtex) seems to be taking over bbdb's
development.

Thanks.
Leo

Re: Merging mistakes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Sat, 04 Dec 2010 09:00:24 -0500
> 
> > Any suggestions for how to avoid destabilizing the release branch by
> > too indiscriminate back-ports from the trunk?
> 
> But you're right that we need to be careful with it.  We haven't
> received too many bug reports about the pretest code, tho, so it's not
> clear whether we have a problem here.

There were a few similar mistakes recently, so I think we do have a
problem.  We shouldn't wait until we see bug reports, IMO.