* Merging mistakes
@ 2010-12-04 9:35 Eli Zaretskii
2010-12-04 14:00 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2010-12-04 9:35 UTC (permalink / raw)
To: emacs-devel
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 -------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Merging mistakes
2010-12-04 9:35 Merging mistakes Eli Zaretskii
@ 2010-12-04 14:00 ` Stefan Monnier
2010-12-04 14:42 ` Leo
2010-12-04 15:18 ` Eli Zaretskii
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2010-12-04 14:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
> 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 -------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Merging mistakes
2010-12-04 14:00 ` Stefan Monnier
@ 2010-12-04 14:42 ` Leo
2010-12-04 16:14 ` Stefan Monnier
2010-12-04 15:18 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Leo @ 2010-12-04 14:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
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;
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Merging mistakes
2010-12-04 14:00 ` Stefan Monnier
2010-12-04 14:42 ` Leo
@ 2010-12-04 15:18 ` Eli Zaretskii
1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2010-12-04 15:18 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Merging mistakes
2010-12-04 14:42 ` Leo
@ 2010-12-04 16:14 ` Stefan Monnier
2010-12-04 16:34 ` Leo
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2010-12-04 16:14 UTC (permalink / raw)
To: Leo; +Cc: Eli Zaretskii, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Merging mistakes
2010-12-04 16:14 ` Stefan Monnier
@ 2010-12-04 16:34 ` Leo
0 siblings, 0 replies; 6+ messages in thread
From: Leo @ 2010-12-04 16:34 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-12-04 16:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-04 9:35 Merging mistakes Eli Zaretskii
2010-12-04 14:00 ` Stefan Monnier
2010-12-04 14:42 ` Leo
2010-12-04 16:14 ` Stefan Monnier
2010-12-04 16:34 ` Leo
2010-12-04 15:18 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).