Extensive changes during pretest

Extensive changes during pretest

[Eli Zaretskii]

Why are so many changes being checked-in so late in the pretest?  They
don't seem to be bugfixes to me (see below).

Would the head maintainers please state clear guidelines on what
should and what should not be installed at this time?  In the absence
of a formal procedure for reviewing patches before they are committed
and/or for posting them after the commit, I think it's imperative we
have clear and agreed-upon guidelines.

Here are the changes that prompted this message:

  2008-02-21  Michael McNamara  <mac@mail.brushroad.com>

	  * progmodes/verilog-mode.el (verilog-xemacs-menu): Remove XEmacs
	  conditional.
	  (verilog-font-grouping-keywords-face): Make the begin..end
	  keywords standout more than other verilog keywords.
	  (verilog-type-font-keywords): Move the begin..end out of this list
	  to facilitate making them to (potentially) stand out more.
	  (verilog-backward-token): Fix indent of bare always{_*}?, initial,
	  function & task blocks.
	  (verilog-behavioral-block-beg-re): Fix indent of bare always{_*}?,
	  initial, function & task blocks.
	  (verilog-forward-sexp): Handle the new "disable fork" statement of
	  IEEE-1800 Verilog.
	  (verilog-beg-block-re-ordered): Handle the new "disable fork"
	  statement of IEEE-1800 Verilog.
	  (verilog-calc-1): Handle the new "disable fork" statement of
	  IEEE-1800 Verilog.
	  (verilog-disable-fork-re): Add const to help handle the new
	  "disable fork" statement of IEEE-1800 Verilog.
	  (verilog-declaration-core-re): Add port directions by themselves,
	  with no qualification, as base item of a declaration.
	  (verilog-pretty-declarations): Add new flag to ask it to refrain
	  from printing to the message buffer.
	  (verilog-pretty-expr): Add a QUIET flag to ask it to refrain from
	  printing to the message buffer.  Improve handling of the many
	  types of expression line up.
	  (verilog-just-one-space): Remove printing of an empty message.
	  (verilog-get-lineup-indent): Rework to support the better handling
	  of expression lineup for verilog-pretty-expr.
	  (verilog-auto-wire): Pass the quiet flag to verilog-pretty-expr.

  2008-02-19  Alan Mackenzie  <acm@muc.de>

	  Set of changes so that "obtrusive" syntactic elements in a
	  C/C++/ObjC preprocessor line (e.g. an unbalanced string quote or
	  unmatched paren) don't interact syntactically with stuff outside
	  the CPP line.

	  * progmodes/cc-awk.el (c-awk-beyond-logical-line, c-awk-old-ByLL):
	  Replace c-awk-end-of-logical-line and c-awk-old-EoLL to solve an
	  off-by-one bug.
	  (c-awk-record-region-clear-NL): Replaces c-awk-before-change, with
	  a bit of refactoring.
	  (c-awk-extend-and-syntax-tablify-region): Takes some of the
	  functionality of c-awk-advise-fl-for-awk-region, which has been
	  refactored away.

	  * progmodes/cc-defs.el (c-clear-char-property-with-value-function)
	  (c-clear-char-property-with-value): New function and macro which
	  remove text-properties `equal' to a supplied value.

	  * progmodes/cc-engine.el: Comment about text properties amended.

	  * progmodes/cc-fonts.el (c-cpp-matchers): Make it put regexp
	  parens around "error\\|warning".

	  * progmodes/cc-langs.el (c-get-state-before-change-function)
	  (c-before-font-lock-function, c-anchored-cpp-prefix):
	  New language variables.
	  (c-cpp-message-directives): Handle "#warning" in C, C++ and ObjC.

	  * progmodes/cc-mode.el (c-basic-common-init): C and ObjC now use
	  syntax-table text properties.
	  (c-common-init): Call language specific before/after-change
	  functions at mode initialisation.
	  (c-new-BEG, c-new-END, c-old-BOM, c-old-EOM): New variables.
	  (c-extend-region-for-CPP, c-neutralize-CPP-line)
	  (c-neutralize-syntax-in-CPP): New functions.
	  (c-before-change, c-after-change): Call the new language specific
	  change functions defined in cc-langs.el.
	  (c-advise-fl-for-region): New macro.
	  (awk-mode): Remove AWK specific stuff which has been refactored
	  into language independent stuff.

Re: Extensive changes during pretest

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Why are so many changes being checked-in so late in the pretest?  They
> don't seem to be bugfixes to me (see below).
>
> Would the head maintainers please state clear guidelines on what
> should and what should not be installed at this time?  In the absence
> of a formal procedure for reviewing patches before they are committed
> and/or for posting them after the commit, I think it's imperative we
> have clear and agreed-upon guidelines.

We're still working out how the release process is going to be
handled.

In the meantime, while I'm aware that maintainers such as Michael
McNamara (for verilog) and Alan Mackenzie (for CC mode) have
significant leeway for checkins affecting their parts of the code, Eli
is right: Emacs 22.2 is already in pretest, so such changes shouldn't
be made to the branch at this point in time.  At the very least,
please inform emacs-devel to make sure it doesn't clash with the
pretest.

For small safe bug fixes, do continue sending them directly into the
branch, as we're currently doing, for the moment.

New features should be going into the trunk; if you want to backport
it to Emacs 22, please wait till after 22.2 is released and propose
the backport on emacs-devel.

Where in doubt, email emacs-devel.

Thanks!

Re: Extensive changes during pretest

[Stefan Monnier]

> Why are so many changes being checked-in so late in the pretest?  They
> don't seem to be bugfixes to me (see below).

AFAIU, Alan's change was announced before hand, tho not as a "sample
patch for review", more as a heads up.


        Stefan

Minor Gnus changes for EMACS 22.2 pretest (was: Extensive changes during pretest)

[Reiner Steib]

On Sat, Feb 23 2008, Chong Yidong wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>> Would the head maintainers please state clear guidelines on what
>> should and what should not be installed at this time?  In the absence
>> of a formal procedure for reviewing patches before they are committed
>> and/or for posting them after the commit, I think it's imperative we
>> have clear and agreed-upon guidelines.
[...]
> Where in doubt, email emacs-devel.

There are some changes in Gnus stable branch (v5-10) that have not
been merges to EMACS_22_BASE, see below.  Miles, could you please sync
these ASAP?  Let me know if you don't have time now, then I'll do it.

--8<---------------cut here---------------start------------->8---
$ head ... v5-10/lisp/ChangeLog
2008-02-16  Reiner Steib  <Reiner.Steib@gmx.de>

        * mail-source.el (mail-source-delete-incoming): Change default.
        Supplement doc string.

2008-02-14  Reiner Steib  <Reiner.Steib@gmx.de>

        * nnmail.el (nnmail-message-id-cache-file): Derive from
        `gnus-home-directory'.

2008-02-11  Reiner Steib  <Reiner.Steib@gmx.de>

        * gnus-topic.el (gnus-topic-select-group, gnus-topic-read-group):
        Document negativ prefix.

        * gnus-group.el (gnus-group-read-group): Document negativ prefix.

2008-02-03  Reiner Steib  <Reiner.Steib@gmx.de>

        * gnus.el (gnus-group-startup-message): Add `find-image' call before
        image-load-path is let-bound.  Reported by Harald Hanche-Olsen
        <hanche@math.ntnu.no>.
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ head EMACS_22_BASE/emacs/lisp/gnus/ChangeLog
2008-02-03  Reiner Steib  <Reiner.Steib@gmx.de>

        * gnus.el (gnus-group-startup-message): Add `find-image' call before
        image-load-path is let-bound.  Reported by Harald Hanche-Olsen
        <hanche@math.ntnu.no>.
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Extensive changes during pretest

[Glenn Morris]

Eli Zaretskii wrote:

> Why are so many changes being checked-in so late in the pretest?  They
> don't seem to be bugfixes to me (see below).
[...]
> 	  * progmodes/verilog-mode.el

With things like verilog mode, the attitude seems to be "it's never
been in an Emacs release, therefore we can keep modifying it up to the
last minute, because there's no pre-existing behaviour to break". I
don't think this makes sense.

Re: Extensive changes during pretest

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 23 Feb 2008 14:46:28 -0500
> 
> With things like verilog mode, the attitude seems to be "it's never
> been in an Emacs release, therefore we can keep modifying it up to the
> last minute, because there's no pre-existing behaviour to break". I
> don't think this makes sense.

No, it doesn't, because the goal is to release a stable Emacs, not
just Emacs that is no worse than the previous version.

Re: Extensive changes during pretest

[Alan Mackenzie]

'Evening, Eli!

On Sat, Feb 23, 2008 at 01:40:56PM +0200, Eli Zaretskii wrote:
> Why are so many changes being checked-in so late in the pretest?  They
> don't seem to be bugfixes to me (see below).

[ .... ]

> Here are the changes that prompted this message:

[ .... ]

>   2008-02-19  Alan Mackenzie  <acm@muc.de>

> 	  Set of changes so that "obtrusive" syntactic elements in a
> 	  C/C++/ObjC preprocessor line (e.g. an unbalanced string quote or
> 	  unmatched paren) don't interact syntactically with stuff outside
> 	  the CPP line.

[ .... ]

This was to fix a bug reported by a user.  I decided to fix it
properly, rather than with some temporary cludge (they rarely work well).
The bug report was:

>Message-ID: <8f5cebf20801201202t672b135fp80fb27dbb25e223f@mail.gmail.com>
>Date: Sun, 20 Jan 2008 20:02:13 +0000
>From: "Diogo Sousa" <orium69@gmail.com>
>To: bug-gnu-emacs@gnu.org
>Subject: Bug in emacs 22.1.1 (cosmetic bug)

>* Write the line: #warning for isn't a keyword here

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Extensive changes during pretest

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Eli Zaretskii <eliz@gnu.org> writes:
  > 
  > > Why are so many changes being checked-in so late in the pretest?  They
  > > don't seem to be bugfixes to me (see below).
  > >
  > > Would the head maintainers please state clear guidelines on what
  > > should and what should not be installed at this time?  In the absence
  > > of a formal procedure for reviewing patches before they are committed
  > > and/or for posting them after the commit, I think it's imperative we
  > > have clear and agreed-upon guidelines.
  > 
  > We're still working out how the release process is going to be
  > handled.
  > 
  > In the meantime, while I'm aware that maintainers such as Michael
  > McNamara (for verilog) and Alan Mackenzie (for CC mode) have
  > significant leeway for checkins affecting their parts of the code, Eli
  > is right: Emacs 22.2 is already in pretest, so such changes shouldn't
  > be made to the branch at this point in time.  At the very least,
  > please inform emacs-devel to make sure it doesn't clash with the
  > pretest.
  > 
  > For small safe bug fixes, do continue sending them directly into the
  > branch, as we're currently doing, for the moment.
  > 
  > New features should be going into the trunk; if you want to backport
  > it to Emacs 22, please wait till after 22.2 is released and propose
  > the backport on emacs-devel.

Why not have the up to date checkin policy for each branch in
FOR-RELEASE?
That way there's no ambiguity what is going on, and there's a single
place to check what it TRTD.  A message on the mailing list is very easy
to miss...

Re: Extensive changes during pretest

[Richard Stallman]

It seems plausible to me that the verilog-mode changes should
be removed from Emacs 22 and added to the trunk.

Yidong, since you are doing the pretests, it's up to you.

Re: Extensive changes during pretest

[Eli Zaretskii]

> Date: Sat, 23 Feb 2008 21:52:35 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> >   2008-02-19  Alan Mackenzie  <acm@muc.de>
> 
> > 	  Set of changes so that "obtrusive" syntactic elements in a
> > 	  C/C++/ObjC preprocessor line (e.g. an unbalanced string quote or
> > 	  unmatched paren) don't interact syntactically with stuff outside
> > 	  the CPP line.
> 
> [ .... ]
> 
> This was to fix a bug reported by a user.  I decided to fix it
> properly, rather than with some temporary cludge (they rarely work well).
> The bug report was:

Was that bug really that grave to warrant such extensive changes at
the last moment?  The bug was in incorrect fontification, right?

Re: Extensive changes during pretest

[Alan Mackenzie]

Hi, Eli,

On Sun, Feb 24, 2008 at 06:18:41AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 23 Feb 2008 21:52:35 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > >   2008-02-19  Alan Mackenzie  <acm@muc.de>

> > > 	  Set of changes so that "obtrusive" syntactic elements in a
> > > 	  C/C++/ObjC preprocessor line (e.g. an unbalanced string quote
> > > 	  or unmatched paren) don't interact syntactically with stuff
> > > 	  outside the CPP line.

> > [ .... ]

> > This was to fix a bug reported by a user.  I decided to fix it
> > properly, rather than with some temporary cludge (they rarely work
> > well).  The bug report was:

> Was that bug really that grave to warrant such extensive changes at the
> last moment?

I think it was.  The only workaround would require the user to change his
source code (or use a different editor).  Possibly I was mistaken.   

> The bug was in incorrect fontification, right?

Incorrect fontification over the entire buffer after the #warning line
(or at least until the next apostrophe within a comment).  It also made
M-[ae] (statement/sentence movement) and C-M-[ae] (function movement) and
probably quite a lot else (anything involving the syntax table) go
haywire.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Extensive changes during pretest

[Juri Linkov]

>> The bug was in incorrect fontification, right?
>
> Incorrect fontification over the entire buffer after the #warning line
> (or at least until the next apostrophe within a comment).  It also made
> M-[ae] (statement/sentence movement) and C-M-[ae] (function movement) and
> probably quite a lot else (anything involving the syntax table) go
> haywire.

There are many other modes that often cause incorrect fontification
after a quote or some other special character.  Is there a way to
prevent such incorrect fontification (other than a hack of modifying
the source file and putting the closing character in the comments)?
Maybe there should be a limit on the maximum length of a string
to fontify as a string?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Extensive changes during pretest

[Eli Zaretskii]

> Date: Sun, 24 Feb 2008 08:20:54 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Was that bug really that grave to warrant such extensive changes at the
> > last moment?
> 
> I think it was.  The only workaround would require the user to change his
> source code (or use a different editor).  Possibly I was mistaken.   
> 
> > The bug was in incorrect fontification, right?
> 
> Incorrect fontification over the entire buffer after the #warning line
> (or at least until the next apostrophe within a comment).  It also made
> M-[ae] (statement/sentence movement) and C-M-[ae] (function movement) and
> probably quite a lot else (anything involving the syntax table) go
> haywire.

And this problem existed since when?

Re: Extensive changes during pretest

[Alan Mackenzie]

'Evening, Eli!

On Sun, Feb 24, 2008 at 09:38:24PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 24 Feb 2008 08:20:54 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Was that bug really that grave to warrant such extensive changes
> > > at the last moment?

> > I think it was.  The only workaround would require the user to
> > change his source code (or use a different editor).  Possibly I was
> > mistaken.   

> > > The bug was in incorrect fontification, right?

> > Incorrect fontification over the entire buffer after the #warning
> > line (or at least until the next apostrophe within a comment).  It
> > also made M-[ae] (statement/sentence movement) and C-M-[ae]
> > (function movement) and probably quite a lot else (anything
> > involving the syntax table) go haywire.

> And this problem existed since when?

A very long time indeed.  Who knows?  It's fixed, now.

-- 
Alan.

Re: Extensive changes during pretest

[Eli Zaretskii]

> Date: Sun, 24 Feb 2008 20:03:43 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > And this problem existed since when?
> 
> A very long time indeed.

Then it could have existed for one more release.  I think fixing it
with such extensive changes was unjustified.

Re: Extensive changes during pretest

[Alan Mackenzie]

Hi, Juri!

On Sun, Feb 24, 2008 at 09:31:00PM +0200, Juri Linkov wrote:
> >> The bug was in incorrect fontification, right?

> > Incorrect fontification over the entire buffer after the #warning
> > line (or at least until the next apostrophe within a comment).  It
> > also made M-[ae] (statement/sentence movement) and C-M-[ae]
> > (function movement) and probably quite a lot else (anything
> > involving the syntax table) go haywire.

> There are many other modes that often cause incorrect fontification
> after a quote or some other special character.  Is there a way to
> prevent such incorrect fontification (other than a hack of modifying
> the source file and putting the closing character in the comments)?
> Maybe there should be a limit on the maximum length of a string to
> fontify as a string?

The way I did it was by putting a 'punctuation syntax-table property on
each umatched string quote (and also each unmatched brace/bracket/paren).
The meat of this is in `c-neutralize-CPP-line' in cc-mode.el.

The essential precondition here is that C preprocessor lines live,
logically, in a different world from other statements, a bit like in
chess there are white-squared bishops and black-squared bishops.

> Juri Linkov

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Extensive changes during pretest

[Alan Mackenzie]

Hi, Eli,

On Sun, Feb 24, 2008 at 10:09:45PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 24 Feb 2008 20:03:43 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > And this problem existed since when?

> > A very long time indeed.

> Then it could have existed for one more release.  I think fixing it
> with such extensive changes was unjustified.
 
Possibly.  However, a real user reported it as a real bug, and it was a
serious bug.  It's effect is to render Emacs unusable on any C file
containing such an apostrophe.

What are you trying to tell me, Eli, assuming there's no intention to
remove the fix from the Emacs-22 branch?  That my judgement may have
been mistaken?  I know that.

-- 
Alan.

Re: Extensive changes during pretest

[Eli Zaretskii]

> Date: Sun, 24 Feb 2008 20:42:34 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> What are you trying to tell me, Eli, assuming there's no intention to
> remove the fix from the Emacs-22 branch?  That my judgement may have
> been mistaken?  I know that.

I'm trying to say that maybe next time you could ask for opinions and
advice in such cases, before checking in such non-trivial changes
close to a release.

As for removing the fix, that's your call.  I'm not in a position to
do that, even if I wanted to.

Re: Extensive changes during pretest

[Alan Mackenzie]

Hello again,

On Sun, Feb 24, 2008 at 11:52:36PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 24 Feb 2008 20:42:34 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > What are you trying to tell me, Eli, assuming there's no intention to
> > remove the fix from the Emacs-22 branch?  That my judgement may have
> > been mistaken?  I know that.

> I'm trying to say that maybe next time you could ask for opinions and
> advice in such cases, before checking in such non-trivial changes
> close to a release.

OK, thanks.

-- 
Alan.

Re: Extensive changes during pretest

[Michael McNamara]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> Why are so many changes being checked-in so late in the pretest?  They
> don't seem to be bugfixes to me (see below).

My changes are all bug fixes. Note I and my colleagues have been maintaining
this mode for 15 years at http://www.verilog.com, including a test suite.  With
this release of emacs, we are including the current version of verilog-mode.el
as a progmode inside of emacs-22.  It would be excellent if we start out with
the current version of the verilog-mode.el in the emacs-22 release.

Please let me know what you would like me to do.

> 
> Would the head maintainers please state clear guidelines on what
> should and what should not be installed at this time?  In the absence
> of a formal procedure for reviewing patches before they are committed
> and/or for posting them after the commit, I think it's imperative we
> have clear and agreed-upon guidelines.
> 
> Here are the changes that prompted this message:
> 
>   2008-02-21  Michael McNamara  <mac <at> mail.brushroad.com>
> 

...

Re: Extensive changes during pretest

[Chong Yidong]

Michael McNamara <mac@brushroad.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> 
>> Why are so many changes being checked-in so late in the pretest?  They
>> don't seem to be bugfixes to me (see below).
>
> My changes are all bug fixes. Note I and my colleagues have been maintaining
> this mode for 15 years at http://www.verilog.com, including a test suite.  With
> this release of emacs, we are including the current version of verilog-mode.el
> as a progmode inside of emacs-22.  It would be excellent if we start out with
> the current version of the verilog-mode.el in the emacs-22 release.
>
> Please let me know what you would like me to do.

We'll keep it in the branch.

Re: Extensive changes during pretest

[Eli Zaretskii]

> From: Michael McNamara <mac@brushroad.com>
> Date: Mon, 25 Feb 2008 16:24:52 +0000 (UTC)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 
> > Why are so many changes being checked-in so late in the pretest?  They
> > don't seem to be bugfixes to me (see below).
> 
> My changes are all bug fixes. Note I and my colleagues have been maintaining
> this mode for 15 years at http://www.verilog.com, including a test suite.  With
> this release of emacs, we are including the current version of verilog-mode.el
> as a progmode inside of emacs-22.  It would be excellent if we start out with
> the current version of the verilog-mode.el in the emacs-22 release.

How long ago was this version of verilog-mode released to the users,
before it was committed to the Emacs CVS?

I realize the urge to ship the latest and the greatest, but Emacs 22.2
is a bugfix release, so it must be stable and relatively bug-free.
Adding new code that had little chance of being used runs a risk of
destabilizing the release.

> Please let me know what you would like me to do.

I'm not in a position to tell you that, I will leave it to Stefan and
Yidong.  But in general, committing new code on the release branch is
better done with great care, and it is my personal opinion that prior
discussion should be preferable.

In any case, thanks for working on verilog-mode.