next emacs version?

next emacs version?

[Drew Adams]

What will the next Emacs version be?

I just got a bug report for my Dired+ code, because of a recent change to
files.el for the regexp `dired-move-to-filename-regexp'. I have a fix that takes
the new regexp into account, but I need to test for the Emacs version that has
the new regexp (since I support multiple versions).

The person who filed the bug report has GNU Emacs version 24.0.50.1
(i686-pc-linux-gnu, GTK+ Version 2.16.6)... He says he just updated from BZR.

But I thought the next release would be Emacs 23.2, not 24. What is the proper
test (or a reasonable test) to use in the code, for this change? It's OK if I
don't support the change until the release is out. It's the test for the
official release I'm most interested in. (But I'm also interested in advice
about testing against an in-development version.)


 Thx.

Re: next emacs version?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 19 Mar 2010 04:23:31 -0700
> 
> What will the next Emacs version be?

23.2

> I just got a bug report for my Dired+ code, because of a recent change to
> files.el for the regexp `dired-move-to-filename-regexp'. I have a fix that takes
> the new regexp into account, but I need to test for the Emacs version that has
> the new regexp (since I support multiple versions).
> 
> The person who filed the bug report has GNU Emacs version 24.0.50.1
> (i686-pc-linux-gnu, GTK+ Version 2.16.6)... He says he just updated from BZR.
> 
> But I thought the next release would be Emacs 23.2, not 24.

That's not a contradiction.  Emacs 23.2 will be delivered from a
branch, not from the trunk.  Version 24.0.50 is from the development
trunk.

> What is the proper
> test (or a reasonable test) to use in the code, for this change? It's OK if I
> don't support the change until the release is out. It's the test for the
> official release I'm most interested in. (But I'm also interested in advice
> about testing against an in-development version.)

If you want to discern v23.x from v24.x, emacs-major-version is the
first thing I'd try.

Re: next emacs version?

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> What will the next Emacs version be?

23.2.  It is due to be released Real Soon Now, but the bugs are still
coming in at a sufficient rate that we can't release yet.

(There are also documentation tasks to be done, but I am hoping to find
time this weekend to clear them up.)

RE: next emacs version?

[Drew Adams]

> > What will the next Emacs version be?
> 
> 23.2

Confirms what I thought.

> > 24.0.50.1
> > But I thought the next release would be Emacs 23.2, not 24.
> 
> That's not a contradiction.  Emacs 23.2 will be delivered from a
> branch, not from the trunk.  Version 24.0.50 is from the development
> trunk.

Also confirms what I thought. Thanks.

> > What is the proper test (or a reasonable test) to use in the
> > code, for this change? It's OK if I don't support the change
> > until the release is out. It's the test for the
> > official release I'm most interested in. (But I'm also 
> > interested in advice about testing against an in-development version.)
> 
> If you want to discern v23.x from v24.x, emacs-major-version is the
> first thing I'd try.

I said I want to discern this code change, which will be made by Emacs Dev to
23.2 (probably; it is made now in 24.0.50.1). So `emacs-major-version' is not
the way to check that.

In the past, I've checked `emacs-major-version' and `emacs-minor-version'
together, or I've checked for the change using string-match with
`emacs-version'. I was wondering if there is a recommendation here.

And I was wondering if there isn't a simple check that will match anything more
recent than the release 23.1. That is, including the dev version 24.0.50.1 and
the next release, 23.2. That's a typical use case for me: Emacs Dev has changed
something after the last release and I expect that the change will remain in
place for the new release. 

Yes, obviously, if the change is in fact removed before the new release then my
test will no longer be accurate. But that's the minority of such cases, in my
experience, and I can live with that maintenance problem.

Obviously, if there is a more pertinent test such as a new variable or function,
I use that instead. But this example is pretty typical of the problem. The value
of a regexp variable has changed, and that changes the behavior of the code. I
need to test which regexp value is in use, the old one or the new one.

FWIW, the regexp in question, `directory-listing-before-filename-regexp', is
among the hairiest I've come across (have a look - quite amusing), and I don't
think it's a good idea to try to test against that value. I see no alternative
but to test the Emacs version. (This affects Dired font-locking. The new value
of the regexp adds a level of group nesting.)

Re: next emacs version?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 19 Mar 2010 10:29:40 -0700
> 
> > If you want to discern v23.x from v24.x, emacs-major-version is the
> > first thing I'd try.
> 
> I said I want to discern this code change, which will be made by Emacs Dev to
> 23.2 (probably; it is made now in 24.0.50.1). So `emacs-major-version' is not
> the way to check that.

Please explain more.  The above advice was based on a guess, and it
turns out I guessed wrongly.  What exactly do you want to test for?

Was the change in files.el made before the 23.2 release branch was
cut, or after it?  If the latter, was it made to both the trunk and
the branch?

> In the past, I've checked `emacs-major-version' and `emacs-minor-version'
> together, or I've checked for the change using string-match with
> `emacs-version'. I was wondering if there is a recommendation here.

Perhaps the various predicates for comparing versions could help you
(version<, version<=, etc.).

RE: next emacs version?

[Drew Adams]

> > > If you want to discern v23.x from v24.x, 
> > > emacs-major-version is the first thing I'd try.
> > 
> > I said I want to discern this code change, which will be 
> > made by Emacs Dev to 23.2 (probably; it is made now in
> > 24.0.50.1). So `emacs-major-version' is not
> > the way to check that.
> 
> Please explain more.  The above advice was based on a guess, and it
> turns out I guessed wrongly.  What exactly do you want to test for?
> 
> Was the change in files.el made before the 23.2 release branch was
> cut, or after it?  If the latter, was it made to both the trunk and
> the branch?

Dunno. The change is in the latest files.el:
http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/annotate/head%3A/lisp/files
.el. And it is not in the 23.1 release.

Clicking the change-indicator link closest to the regexp definition in question
doesn't really provide useful info wrt the change, AFAICT. But clicking `View
changes to the file' and searching for "regexp" leads me to this change, which
seems to be the one:

 Chong Yidong2010-02-21 21:12:46Revision ID: 
 cyd@stupidchicken.com-20100221211246-i6nketjrj58mq1qt

 * files.el (directory-listing-before-filename-regexp): Use
 stricter matching for iso-style dates, to avoid false matches with
 date-like filenames (Bug#5597).

(The site is so slow and keeps telling me "Please try again. Sorry, there was a
problem connecting to the Launchpad server." that it's almost unusable. I had to
kill my browser, IE7, a couple of times and start over. And it kept telling me
that the page was running a script that was slowing things down so much that it
advised me to stop it.)

The change I am interested in testing for is a change in the value of
`directory-listing-before-filename-regexp', as I said before. Please see my
previous email for more details. That is really what I want to check - the goal.
Checking for a particular Emacs version would only be an indirect (and
approximate) means toward that goal.

> > In the past, I've checked `emacs-major-version' and 
> > `emacs-minor-version' together, or I've checked for the change
> > using string-match with `emacs-version'. I was wondering if
> > there is a recommendation here.
> 
> Perhaps the various predicates for comparing versions could help you
> (version<, version<=, etc.).

Good to know; I wasn't aware of them. That's essentially what I was doing using
string-match, but they simplify things. (However, I will need to combine them
with `fboundp', since they don't exist in older Emacs versions.)

The question remains, however, which >, <=, etc. test could do the job robustly,
since the dev version is 24.0.50.1 and the first corresponding release will be
23.2?

Re: next emacs version?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 19 Mar 2010 11:46:18 -0700
> 
>  Chong Yidong2010-02-21 21:12:46Revision ID: 
>  cyd@stupidchicken.com-20100221211246-i6nketjrj58mq1qt
> 
>  * files.el (directory-listing-before-filename-regexp): Use
>  stricter matching for iso-style dates, to avoid false matches with
>  date-like filenames (Bug#5597).

This is revision 99545, which is before the branch.  So this change
will be both in Emacs 23.2 and Emacs 24.

> (The site is so slow and keeps telling me "Please try again. Sorry, there was a
> problem connecting to the Launchpad server." that it's almost unusable. I had to
> kill my browser, IE7, a couple of times and start over. And it kept telling me
> that the page was running a script that was slowing things down so much that it
> advised me to stop it.)

Why don't you install Bazaar?  Even if you don't build your own
binaries, the ability to browse sources and history locally can be a
boon.

> The question remains, however, which >, <=, etc. test could do the job robustly,
> since the dev version is 24.0.50.1 and the first corresponding release will be
> 23.2?

I think you want `(version<= emacs-version "23.2")'.

RE: next emacs version?

[Drew Adams]

> >  * files.el (directory-listing-before-filename-regexp): Use
> >  stricter matching for iso-style dates, to avoid false matches
> >  with date-like filenames (Bug#5597).
> 
> This is revision 99545, which is before the branch.  So this change
> will be both in Emacs 23.2 and Emacs 24.

OK. Where do you see such info (on the Web site)? That info could be useful in
the future. I'm only interested in HTTP access to such info.

> > The question remains, however, which >, <=, etc. test could 
> > do the job robustly, since the dev version is 24.0.50.1 and the first 
> > corresponding release will be 23.2?
> 
> I think you want `(version<= emacs-version "23.2")'.

Really? 

Won't some builds of 24.0.50.1 have the change and some not? As you say, it
depends whether the build is after revision #99545.

If I use version< 23.2 to distinguish instead, then the same problem occurs:
Some 24.0.50.1 versions will not have the change.

As I said, my main concern it wrt official releases, but "I'm also interested in
advice about testing against an in-development version."

AFAICT, there is no simple solution to that. I think you've pretty much
confirmed that, so at least I know I'm not missing something obvious.

(This release is apparently imminent, so no problem in this particular case.)


We can test for the existence of a var or function. How about being able (in
Lisp) to test for a particular source-code revision, such as #99545, for cases
where there is nothing specific and handy to check (like a var or fn)? Or being
able to test for a particular bug-fix (like #5597)?

Re: next emacs version?

[Stefan Monnier]

> This is revision 99545, which is before the branch.  So this change
> will be both in Emacs 23.2 and Emacs 24.

BTW, every change in Emacs-23.2 will be in Emacs-24 as well, in any case.

> I think you want `(version<= emacs-version "23.2")'.

Of course checking (string-match
directory-listing-before-filename-regexp <wellcraftedteststring>) might
work at least as well for the problem at hand.


        Stefan

Re: next emacs version?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 19 Mar 2010 13:02:52 -0700
> 
> > >  * files.el (directory-listing-before-filename-regexp): Use
> > >  stricter matching for iso-style dates, to avoid false matches
> > >  with date-like filenames (Bug#5597).
> > 
> > This is revision 99545, which is before the branch.  So this change
> > will be both in Emacs 23.2 and Emacs 24.
> 
> OK. Where do you see such info (on the Web site)?

I don't use the Web site.  I got it from Bazaar, in my local mirror of
the development trunk.  You showed me the revision-id of this change,
cyd@stupidchicken.com-20100221211246-i6nketjrj58mq1qt, and there's a
Bazaar command (bzr revision-info) to show a revision number for it.
Then I did a "bzr annotate ChangeLog" and found that this change:

    2010-03-10  Chong Yidong  <cyd@stupidchicken.com>

	    * Branch for 23.2.

was made in revision 99640, which is later than 99545.  That's it.

> > I think you want `(version<= emacs-version "23.2")'.
> 
> Really? 
> 
> Won't some builds of 24.0.50.1 have the change and some not?

No.  The trunk was switched to 24.0.50 only after the 23.x release
branch was cut.  So all development versions before that would have a
version 23.x.y, and all the versions after it will be 24.x.y.  The
first officially released version that will have it will be 23.2.

RE: next emacs version?

[Drew Adams]

> checking (string-match directory-listing-before-filename-regexp 
> <wellcraftedteststring>) might work at least as well for
> the problem at hand.

Ugh. It could be done, but as I said earlier:

>> FWIW, the regexp in question,
>> `directory-listing-before-filename-regexp', is
>> among the hairiest I've come across (have a look
>> - quite amusing), and I don't think it's a good idea to
>> try to test against that value.

Anyway, there is no problem in this particular case, as I can just test for 23.2
and ignore supporting dev versions before that (since the release is imminent).

The general question remains, however - see my last mail.

RE: next emacs version?

[Drew Adams]

> > OK. Where do you see such info (on the Web site)?
> 
> [snipped info that is not about using the Web site]

Again, anyone know how to get such info from the Web site?

> > Won't some builds of 24.0.50.1 have the change and some not?
> 
> No.  The trunk was switched to 24.0.50 only after the 23.x release
> branch was cut.  So all development versions before that would have a
> version 23.x.y, and all the versions after it will be 24.x.y.  The
> first officially released version that will have it will be 23.2.

OK in this particular case, but the general question remains. If this change had
been made in a 23.0.50.1 dev version (or whatever the nomenclature is), then
some such dev versions would have the change and some would not.

Re: next emacs version?

[Ken Raeburn]

On Mar 19, 2010, at 17:23, Drew Adams wrote:
>>> Won't some builds of 24.0.50.1 have the change and some not?
>> 
>> No.  The trunk was switched to 24.0.50 only after the 23.x release
>> branch was cut.  So all development versions before that would have a
>> version 23.x.y, and all the versions after it will be 24.x.y.  The
>> first officially released version that will have it will be 23.2.
> 
> OK in this particular case, but the general question remains. If this change had
> been made in a 23.0.50.1 dev version (or whatever the nomenclature is), then
> some such dev versions would have the change and some would not.

Unless you want to start putting bzr revision numbers into the emacs version string (which I think is a bad idea), that's going to be the case.  Version numbers like 23.0.50.1 apply to a long string of development revisions.  If you need discrete points in time where you can distinguish "fixed before" from "fixed after", that's what releases are for.  If you (=> users of your, Drew's, code) want to experiment with development versions, it shouldn't be too much to ask for you to keep fairly current, or at least update before complaining about bugs.  (And if you want to ship non-released development versions to your friends or customers, you're on your own.)

Ken

Re: next emacs version?

[Lennart Borgman]

On Sat, Mar 20, 2010 at 3:35 AM, Ken Raeburn <raeburn@raeburn.org> wrote:
>
> Unless you want to start putting bzr revision numbers into the emacs version string (which I think is a bad idea), that's going to be the case.

But perhaps having the bzr version available in another variable in
the build Emacs would be a good idea?

RE: next emacs version?

[Drew Adams]

> > OK in this particular case, but the general question 
> > remains. If this change had been made in a 23.0.50.1 dev version
> > (or whatever the nomenclature is), then some such dev versions
> > would have the change and some would not.
> 
> Unless you want to start putting bzr revision numbers into 
> the emacs version string (which I think is a bad idea), 

Agreed; a bad idea.

> that's going to be the case.  Version numbers like 23.0.50.1 
> apply to a long string of development revisions.

Yes, that was my understanding.

> If you need discrete points in time where you can distinguish "fixed 
> before" from "fixed after", that's what releases are for.

The granularity is too gross.

> If you (=> users of your, Drew's, code) want to experiment with 
> development versions, it shouldn't be too much to ask for you 
> to keep fairly current, or at least update before complaining 
> about bugs.

It's not about bugs or keeping current. The user in question ("you") had the
very latest BZR code in his build.

The point is that whereas it is typically simple to support fine-grained
differences when a change adds a variable or function (use boundp or fboundp),
other kinds of changes are not so easily identified.

In practice, many large changes do involve some change that is readily
identifiable (e.g a new fn). In the case in point, the code change was small (a
new regexp value) but the change in effect was not so small (use of the regexp
for font-locking).

> (And if you want to ship non-released development versions to
> your friends or customers, you're on your own.)

I guess "you" here is back to meaning me, rather than users of my code. No, I
don't ship Emacs versions of any kind.

And I generally don't try to support Emacs development versions in my libraries.
Instead, I wait until the next release to update my code.

But sometimes (esp. if the release cycle is long) I do make changes (esp. if
minor) that allow my code to keep working with the latest development version.
That's sometimes easy when it concerns a new var or fn (but not arity change
etc. for a fn). Otherwise, it is usually impractical.

A case in point: changes to info.el immediately after the 23.1 release. I did
update my code to accommodate those changes, to allow users to keep using my
code. Otherwise, their only choice is to either forego using my library until
the next release or forego using the latest (dev) Emacs.

But in general trying to keep up with Emacs dev changes is something I avoid,
even if users would prefer to keep up-to-date with Emacs dev and still have
their 3rd-party code also work.

This is a common occurrence/predicament. I (and I assume others too) sometimes
get bug reports for my libraries that really amount to Emacs dev changes
"breaking" things. Much of the time my answer must be "Too bad. I don't support
ongoing Emacs development. Wait until the next Emacs release".

Re: next emacs version?

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>> Unless you want to start putting bzr revision numbers into the emacs
>> version string (which I think is a bad idea), that's going to be the
>> case.
>
> But perhaps having the bzr version available in another variable in
> the build Emacs would be a good idea?

It would be useful to include bzr's revision id (not revision number)
along the info sent by M-x report-emacs-bug.

Re: next emacs version?

[Jason Rumney]

"Drew Adams" <drew.adams@oracle.com> writes:

> OK in this particular case, but the general question remains. If this
> change had been made in a 23.0.50.1 dev version (or whatever the
> nomenclature is), then some such dev versions would have the change
> and some would not.

It's a transient problem that is not worth worrying about. Users who
build from development sources will update and rebuild soon anyway.

Re: next emacs version?

[Ken Raeburn]

On Mar 19, 2010, at 23:38, Drew Adams wrote:
>> If you need discrete points in time where you can distinguish "fixed 
>> before" from "fixed after", that's what releases are for.
> 
> The granularity is too gross.
> 
>> If you (=> users of your, Drew's, code) want to experiment with 
>> development versions, it shouldn't be too much to ask for you 
>> to keep fairly current, or at least update before complaining 
>> about bugs.
> 
> It's not about bugs or keeping current. The user in question ("you") had the
> very latest BZR code in his build.
> 
> The point is that whereas it is typically simple to support fine-grained
> differences when a change adds a variable or function (use boundp or fboundp),
> other kinds of changes are not so easily identified.

If you insist that they keep current (or more specifically, that the only dev version you'll support is the current one, when you support any dev version at all), you shouldn't need anything more fine-grained than "release X" or "dev version leading up to release Y", should you?  I think I'm confused about whether you're trying to support people running outdated dev versions.

>> (And if you want to ship non-released development versions to
>> your friends or customers, you're on your own.)
> 
> I guess "you" here is back to meaning me, rather than users of my code.

Or anyone redistributing emacs in a software distribution, maintaining a local installation for a site, etc.  Thinking back to the gcc-2.96 mess, where there was no official release with that number, but lots of people wound up running something identifying itself that way anyways.

> But sometimes (esp. if the release cycle is long) I do make changes (esp. if
> minor) that allow my code to keep working with the latest development version.

When you do this, do you also try to keep it working with the earlier development versions?  Or is it okay to break things for dev-from-last-month as long as 23.1 and dev-from-this-month both still work?

If the changes are easy enough to identify, supporting all of them is great.  But if they're too difficult to identify without resorting to version numbers, is it really that important to support (in effect) multiple dev versions rather than just the latest (at this point, perhaps along both of the next-minor-release and next-major-release branches)?

Ken

Re: next emacs version?

[Ken Raeburn]

On Mar 19, 2010, at 22:39, Lennart Borgman wrote:
> On Sat, Mar 20, 2010 at 3:35 AM, Ken Raeburn <raeburn@raeburn.org> wrote:
>> 
>> Unless you want to start putting bzr revision numbers into the emacs version string (which I think is a bad idea), that's going to be the case.
> 
> But perhaps having the bzr version available in another variable in
> the build Emacs would be a good idea?

I think it would have some similar problems.  If you rely on it in anything, what happens when you start dealing with a branch on savannah, or someone's published branch based on one of the savannah versions?  And, perhaps worse, if you stick bzr commands into the build process to get the number, what if someone's using a different VCS locally (and it seems like most of the popular DVCSes these days can import/export in various combinations, so this isn't at all hard to imagine) and thus there's no bzr info to be had?

Ken

Re: next emacs version?

[Ken Raeburn]

BTW...

On Mar 19, 2010, at 23:38, Drew Adams wrote:
> But sometimes (esp. if the release cycle is long) I do make changes (esp. if
> minor) that allow my code to keep working with the latest development version.
> That's sometimes easy when it concerns a new var or fn (but not arity change
> etc. for a fn).

advice.el has code for figuring out the arg list of a function, so you can check arity changes.  Though, the easiest way may turn out to be loading advice and calling ad-arglist....

Ken

RE: next emacs version?

[Drew Adams]

> > OK in this particular case, but the general question 
> > remains. If this change had been made in a 23.0.50.1 dev
> > version (or whatever the nomenclature is), then some such
> > dev versions would have the change and some would not.
> 
> It's a transient problem that is not worth worrying about. Users who
> build from development sources will update and rebuild soon anyway.

Good point.

RE: next emacs version?

[Drew Adams]

> If you insist that they keep current (or more specifically, 
> that the only dev version you'll support is the current one, 
> when you support any dev version at all), you shouldn't need 
> anything more fine-grained than "release X" or "dev version 
> leading up to release Y", should you?  I think I'm confused 
> about whether you're trying to support people running 
> outdated dev versions.

Yes, I wasn't very clear.

My only real intention is to support official releases. Occasionally, I try to
support the latest dev version (or the dev version when I make the update) as
well as the last (i.e., previous) release.

The point of fixing things so the code still works after the last release is so
that users can continue to use it. But Jason is no doubt right that most people
who use dev versions rebuild frequently. 

> > But sometimes (esp. if the release cycle is long) I do make 
> > changes (esp. if minor) that allow my code to keep working
> > with the latest development version.
> 
> When you do this, do you also try to keep it working with the 
> earlier development versions?  Or is it okay to break things 
> for dev-from-last-month as long as 23.1 and 
> dev-from-this-month both still work?

The latter is fine, from my point of view.

> If the changes are easy enough to identify, supporting all of 
> them is great.  But if they're too difficult to identify 
> without resorting to version numbers, is it really that 
> important to support (in effect) multiple dev versions rather 
> than just the latest (at this point, perhaps along both of 
> the next-minor-release and next-major-release branches)?

No, I have no intention of supporting multiple dev versions in different ways.

RE: next emacs version?

[Drew Adams]

> > But sometimes (esp. if the release cycle is long) I do make 
> > changes (esp. if minor) that allow my code to keep working with the latest 
> > development version. That's sometimes easy when it concerns a
> > new var or fn (but not arity change etc. for a fn).
> 
> advice.el has code for figuring out the arg list of a 
> function, so you can check arity changes.  Though, the 
> easiest way may turn out to be loading advice and calling 
> ad-arglist....

No, I'm not going to go there. If I really have to deal with that, then I'm more
likely to use `condition-case' and try first the newer signature, backing out to
the older signature in case of error. (Obviously, that only works for some kinds
of changes.)

Re: next emacs version?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 19 Mar 2010 14:23:03 -0700
> 
> If this change had
> been made in a 23.0.50.1 dev version (or whatever the nomenclature is), then
> some such dev versions would have the change and some would not.

If you want to support development versions, then indeed the version
number is not an unequivocal indicator of a change.

Re: next emacs version?

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 20 Mar 2010 11:51:29 +0800
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> > OK in this particular case, but the general question remains. If this
> > change had been made in a 23.0.50.1 dev version (or whatever the
> > nomenclature is), then some such dev versions would have the change
> > and some would not.
> 
> It's a transient problem that is not worth worrying about. Users who
> build from development sources will update and rebuild soon anyway.

Right.  And because of this, I think testing with version< against the
last officially released version would be good enough.

RE: next emacs version?

[Drew Adams]

> > It's a transient problem that is not worth worrying about. Users who
> > build from development sources will update and rebuild soon anyway.
> 
> Right.  And because of this, I think testing with version< against the
> last officially released version would be good enough.

Actually, this is the test I think is appropriate, where N is the _next_
official release (e.g. "23.2" in the current case):

(if (or (not (fboundp 'version<))
        (version< emacs-version N))
     OLD
  NEW)

24.0.50.1, 23.2, and later will pick up NEW.
23.1 and anything older will pick up OLD.

Testing with `version<' against the _last_ official release won't help, I think.
Maybe you meant `version<='?  E.g.:

(if (version<= emacs-version "23.1") OLD NEW)

Re: next emacs version?

[Lennart Borgman]

On Sat, Mar 20, 2010 at 4:42 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>>> Unless you want to start putting bzr revision numbers into the emacs
>>> version string (which I think is a bad idea), that's going to be the
>>> case.
>>
>> But perhaps having the bzr version available in another variable in
>> the build Emacs would be a good idea?
>
> It would be useful to include bzr's revision id (not revision number)
> along the info sent by M-x report-emacs-bug.


I suggest that something like this is used to get the info

  bzr version-info --custom --template "(defconst
emacs-bzr-revision-id \"{revision_id}\")"
  bzr version-info --custom --template "(defconst emacs-bzr-date \"{date}\")"
  bzr version-info --custom --template "(defconst emacs-bzr-revno {revno})"
  bzr version-info --custom --template "(defconst
emacs-bzr-branch-nick \"{branch_nick}\")"

and the output is put in a file emacs-bzr-id.el that is loaded at startup.

Re: next emacs version?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Sat, 20 Mar 2010 07:58:10 -0700
> 
> > > It's a transient problem that is not worth worrying about. Users who
> > > build from development sources will update and rebuild soon anyway.
> > 
> > Right.  And because of this, I think testing with version< against the
> > last officially released version would be good enough.
> 
> Actually, this is the test I think is appropriate, where N is the _next_
> official release (e.g. "23.2" in the current case):
> 
> (if (or (not (fboundp 'version<))
>         (version< emacs-version N))
>      OLD
>   NEW)
> 
> 24.0.50.1, 23.2, and later will pick up NEW.
> 23.1 and anything older will pick up OLD.
> 
> Testing with `version<' against the _last_ official release won't help, I think.
> Maybe you meant `version<='?

Yes, sorry.

Re: next emacs version?

[Stefan Monnier]

>> checking (string-match directory-listing-before-filename-regexp 
>> <wellcraftedteststring>) might work at least as well for
>> the problem at hand.

> Ugh. It could be done, but as I said earlier:

>>> FWIW, the regexp in question,
>>> `directory-listing-before-filename-regexp', is
>>> among the hairiest I've come across (have a look
>>> - quite amusing), and I don't think it's a good idea to
>>> try to test against that value.

The test I propose above is not to test the value of
directory-listing-before-filename-regexp but its behavior.
Basically: figure out the bug that the change was intended to fix, and
then use the thing that triggered the bug as the string to pass to
string-match (presumably the match will succeed in one case and fail in
the other).


        Stefan

RE: next emacs version?

[Drew Adams]

> >> checking (string-match directory-listing-before-filename-regexp 
> >> <wellcraftedteststring>) might work at least as well for
> >> the problem at hand.
> 
> > Ugh. It could be done, but as I said earlier:
> 
> >>> FWIW, the regexp in question,
> >>> `directory-listing-before-filename-regexp', is
> >>> among the hairiest I've come across (have a look
> >>> - quite amusing), and I don't think it's a good idea to
> >>> try to test against that value.
> 
> The test I propose above is not to test the value of
> directory-listing-before-filename-regexp but its behavior.
> Basically: figure out the bug that the change was intended to fix, and
> then use the thing that triggered the bug as the string to pass to
> string-match (presumably the match will succeed in one case 
> and fail in the other).

Double-ugh, in that case.

That would involve my code with the bug-fix code (logic). It would impose
complexity, obscurity, and possibly an additional maintenance (evolution)
burden.

My code is pretty much unrelated to the bug fix code - it just uses the regexp
for font-locking. I don't even explicitly call any function that uses the
regexp.

This is all I'm doing. This is an entry in font-lock-keywords. It fontifies (1)
the date+time and also (2) the file name (w/o suffix):

(list dired-move-to-filename-regexp  ; Hairy regexp
      (if (or (not (fboundp 'version<))
              (version< emacs-version "23.2"))
          (list 1 'diredp-date-time t t)
        (list 2 'diredp-date-time t t)) ; Date/time
      (list "\\(.+\\)$" nil nil   ; File w/o suffix
            (list 0 diredp-file-name 'keep t)))

The #5597 bug fix was this: "Use stricter matching for iso-style dates, to avoid
false matches with date-like filenames (Bug#5597)."

I might be misunderstanding what you're suggesting. Feel free to show explicitly
what you have in mind, based on the specifics of my use case.

According to bug #5597, a file name that would provoke the (unfixed) bug would
be "~/2010-02-18\ foo". How would you pass that to `string-match'? Would you
wrap that call with `condition-case' to see if an error is raised? Is that your
idea? 

Is the following what you are suggesting?

(list dired-move-to-filename-regexp  ; Hairy regexp
      (if (condition-case nil
              (string-match
               dired-move-to-filename-regexp
               "-rw-rw-rw- 1 10 2010-04-01 2010-04-01 foo"))
             (error nil))
          (list 1 'diredp-date-time t t)
        (list 2 'diredp-date-time t t)) ; Date/time
      (list "\\(.+\\)$" nil nil   ; File w/o suffix
            (list 0 diredp-file-name 'keep t)))

I'm not sure what the 2nd arg to `string-match' should be here. The 2nd arg I
used is no doubt wrong. It does _not_ fail to match in versions (that support
ISO dates in Dired) prior to the bug fix.

In fact, in `emacs -Q' on Windows at least (which uses `ls-lisp'), I cannot even
reproduce the bug (e.g. in 23.1). I can create a file named "2010-04-01 foo"; it
appears fine in Dired (including mouse-face); and RET visits it just fine.

So for the moment what I think you're suggesting sounds like a can of worms. But
I'd like to learn what you really meant.

Re: next emacs version?

[Stefan Monnier]

> That would involve my code with the bug-fix code (logic). It would impose

Not at all.  It simply amounts to writing the unit-test that checks
whether the bug is fixed:

  (string-match <regexp> <problematic-dired-line>)

It's simple and robust.


        Stefan

RE: next emacs version?

[Drew Adams]

>> That would involve my code with the bug-fix code (logic).
>
> Not at all.  It simply amounts to writing the unit-test that checks
> whether the bug is fixed: (string-match <regexp> <problematic-dired-line>)
> It's simple and robust.

That's precisely what I mean by involving my code with the bug-fix code: adding
a unit-test for an unrelated bug fix in the middle of font-lock keywords. Extra
code-coupling.

*Why* the regexp is the way it is (better support for file names that include
ISO dates, or whatever) is unimportant for the font-lock code logic. That code
should not care how the regexp does its job of matching a date and file-name or
which formats are currently supported. All that the font-lock code cares about
is picking up the correct regexp group for the date+time info.

(I see, BTW, that I should not have mentioned condition-case in my mail - dunno
what I was thinking there.)

This is presumably what you're suggesting for the font-lock keyword entry:

(list dired-move-to-filename-regexp
      (if (string-match           ; Date/time
            dired-move-to-filename-regexp
            <problematic-dired-line>)
          (list 2 'diredp-date-time t t)
        (list 1 'diredp-date-time t t))
      (list "\\(.+\\)$" nil nil   ; File w/o suffix
            (list 0 diredp-file-name 'keep t)))

It's not obvious to me what the <problematic-dired-line> string should be. I
tried this, based on the bug #5597 report, which says that a file named
"~/2010-02-18\ foo" causes the unfixed (i.e. old) regexp not to match:

 "-rw-rw-rw- 1 10 2010-04-01 2010-02-18 foo"

But that in fact _matches_ the old regexp as well, i.e., in versions before the
fix (Emacs 20.7, 21.3.1, 22.3, 23.1, 23.1.92). And of course there's a
possibility that the regexp might match even in the bugged case, but match in
the wrong way. None of that is called out in the bug history, so it would
require further investigation (with an extremely hairy regexp).

So you can see one manifestation of the added complication already: getting the
unit test right.

And as I said, I cannot even reproduce the bug itself on Windows, starting with
emacs -Q, in any release that I have. That seems to indicate that the bug (and
hence your approach) might be platform-specific. (Or perhaps the bug report and
fix description are not clear.)

Whereas a simple `emacs-version' test has to work (since the fix is in only in
newer versions), code that addresses the bug case directly will do the wrong
thing on any platforms where the bug was not manifested. The buggy file name can
only serve to identify which regexp is which if in fact one of the regexps (the
old one) is buggy on the current platform.

To fix it further (assuming such platform-dependence), I would need to then
investigate all platforms and add platform tests to the embedded unit-test code.
And if the problem was not that the regexp didn't match but that it matched in
the wrong way...

Such an approach is not clean and sound, IMO. It means unnecessary
code-coupling, which is unhealthy: mixing in bug-case unit-test code with the
font-lock code, which is logically unrelated.

Coding that way and maintaining the code then requires understanding the bug and
the fix. At the very least, a WTF comment would need to be added so that anyone
reading the code would have some idea what was going on.

Again, if you think I misunderstand, please clarify. Thx.

RE: next emacs version?

[Drew Adams]

> And as I said, I cannot even reproduce the bug itself on 
> Windows, starting with emacs -Q, in any release that I have.
> That seems to indicate that the bug (and hence your approach)
> might be platform-specific. (Or perhaps the bug report and
> fix description are not clear.)

Indeed, the bug history does indicates that this is platform-specific. As you
yourself said in the bug history, it depends whether your `ls' supports --dired.

The bug history then says that it fails if you set `dired-use-ls-dired' to nil.
So that could presumably be tested in the "unit-test" code you suggest
inserting. 

But even that isn't true on Windows (perhaps because it uses `ls-lisp'). Setting
`dired-use-ls-dired' to nil does not manifest the bug.

> Whereas a simple `emacs-version' test has to work (since the 
> fix is in only in newer versions), code that addresses the
> bug case directly will do the wrong thing on any platforms
> where the bug was not manifested. The buggy file name can
> only serve to identify which regexp is which if in fact one 
> of the regexps (the old one) is buggy on the current platform.

Re: next emacs version?

[Thien-Thi Nguyen]

() "Drew Adams" <drew.adams@oracle.com>
() Fri, 19 Mar 2010 10:29:40 -0700

   I don't think it's a good idea to try to test against that value.

Don't check the regexp value; check the regexp behavior against a
(properly chosen) string.  This way, you perceive its quality directly.

thi

RE: next emacs version?

[Drew Adams]

> Don't check the regexp value; check the regexp behavior against a
> (properly chosen) string.  This way, you perceive its quality 
> directly.

See my reply to Stefan wrt that suggestion.

Re: next emacs version?

[Stefan Monnier]

>>> That would involve my code with the bug-fix code (logic).
>> Not at all.  It simply amounts to writing the unit-test that checks
>> whether the bug is fixed: (string-match <regexp> <problematic-dired-line>)
>> It's simple and robust.

> That's precisely what I mean by involving my code with the bug-fix
> code: adding a unit-test for an unrelated bug fix in the middle of
> font-lock keywords. Extra code-coupling.

> *Why* the regexp is the way it is (better support for file names that
> include ISO dates, or whatever) is unimportant for the font-lock code
> logic. That code should not care how the regexp does its job of
> matching a date and file-name or which formats are currently
> supported. All that the font-lock code cares about is picking up the
> correct regexp group for the date+time info.

Now that you say what you want, I can even agree that there's a better
solution which is to just check what you want:

   (list dired-move-to-filename-regexp
         (let ((test "<some random dired line>"))
           (when (string-match dired-move-to-filename-regexp test)
             (list
              (cond
               ((equal (match-string 2 test) "<the line's date>") 2)
               ((equal (match-string 1 test) "<the line's date>") 1))
              'diredp-date-time t t)))
           (list 1 'diredp-date-time t t))
         (list "\\(.+\\)$" nil nil   ; File w/o suffix
               (list 0 diredp-file-name 'keep t)))

You could even loop through all submatches to find the one which matches
the date.


        Stefan

RE: next emacs version?

[Drew Adams]

> >>> That would involve my code with the bug-fix code (logic).
> >>
> >> Not at all.  It simply amounts to writing the unit-test that checks
> >> whether the bug is fixed: (string-match <regexp> 
> >> <problematic-dired-line>) It's simple and robust.
> 
> > That's precisely what I mean by involving my code with the bug-fix
> > code: adding a unit-test for an unrelated bug fix in the middle of
> > font-lock keywords. Extra code-coupling.
> 
> > *Why* the regexp is the way it is (better support for file 
> > names that include ISO dates, or whatever) is unimportant for
> > the font-lock code logic. That code should not care how the
> > regexp does its job of matching a date and file-name or which
> > formats are currently supported. All that the font-lock code
> > cares about is picking up the correct regexp group for the
> > date+time info.
> 
> Now that you say what you want, I can even agree that there's a better
> solution which is to just check what you want:
> 
>    (list dired-move-to-filename-regexp
>          (let ((test "<some random dired line>"))
>            (when (string-match dired-move-to-filename-regexp test)
>              (list
>               (cond
>                ((equal (match-string 2 test) "<the line's date>") 2)
>                ((equal (match-string 1 test) "<the line's date>") 1))
>               'diredp-date-time t t)))
>            (list 1 'diredp-date-time t t))
>          (list "\\(.+\\)$" nil nil   ; File w/o suffix
>                (list 0 diredp-file-name 'keep t)))
> 
> You could even loop through all submatches to find the one 
> which matches the date.

Yes, that code gets closer to expressing the real requirement. It gets away from
the bug and the bug-fix, which have no business being in this font-lock code.

My point before was that trying to manifest the bug in order to choose the
proper code path would be misguided and fragile (if it even worked in all
cases), especially since the bug is platform-dependent.

Re: next emacs version?

[Stefan Monnier]

> Yes, that code gets closer to expressing the real requirement. It gets
> away from the bug and the bug-fix, which have no business being in
> this font-lock code.

Agreed.

> My point before was that trying to manifest the bug in order to choose the
> proper code path would be misguided and fragile (if it even worked in all
> cases), especially since the bug is platform-dependent.

I recommeded it, based on the assumption that the only alternative was
to test the version number.


        Stefan

Re: next emacs version?

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Sat, Mar 20, 2010 at 3:35 AM, Ken Raeburn <raeburn@raeburn.org> wrote:
 > >
 > > Unless you want to start putting bzr revision numbers into the emacs version string (which I think is a bad idea), that's going to be the case.
 > 
 > But perhaps having the bzr version available in another variable in
 > the build Emacs would be a good idea?

There is no such thing as *the* bzr revision number, because (a)
revision numbers are supposed to be ordered, but revision numbers on
parallel branches cannot be ordered, and (b) revision numbers are not
consistent across repositories.

It is a good idea to put in the revision ID in a variable (SHA1s are
barely tolerable in the version string because of their length, but
bzr revision IDs can be much longer), but revision IDs aren't ordered,
either.

This is not useful for Drew, though.

RE: next emacs version?

[Stephen J. Turnbull]

Drew Adams writes:

 > > If you need discrete points in time where you can distinguish "fixed 
 > > before" from "fixed after", that's what releases are for.
 > 
 > The granularity is too gross.

Too bad.  There's no good way to linearize the whole DAG for your
purpose.  Dates won't work because parallel branches will not
necessarily merge a given change at the same time.  The approximation
used is for the Emacs developers to agree on a conventional ordering,
which is called "the mainline".  If you know your user is "on the
mainline", then dates can be used to do the ordering, or the revision
number.  The problem with the revision number, though, is that in
general it is unstable (the same revision will be numbered differently
in different workspaces, depending on which branch they are derived
from).  Note that pragmatically the reason for using releases as
markers is that socially the project (except for a very few long-lived
branches, and the special "pending" branch, which may be used by users
who should be assumed to know what they're doing) converges to a
*single* point of agreement.  After a release, things get fuzzy.

And if your users are using the pending branch, or a feature branch
(such as Eli's bidi or Miles's lexbind), all bets are off.  You really
should just tell those folks it's *their* problem.  After all, that's
what they asked for by using bleeding edge branches.

 > In practice, many large changes do involve some change that is
 > readily identifiable (e.g a new fn). In the case in point, the code
 > change was small (a new regexp value) but the change in effect was
 > not so small (use of the regexp for font-locking).

Grin and bear it, man.  On this one, you lose.  You are not going to
get the fine-grained test you want.  The exact form of that test is to
trace back in bzr's DAG for the build to determine whether the
revision that introduced the change is an ancestor of this build.
(And even that's not good enough, because it might get reverted or
"perverted" by a later change that you'd have to test for.)

For your purpose here, you can test the regexp value (or even force it
to one you can deal with).  Or you can test for release order and tell
users that "between these two releases you're out of luck."

 > This is a common occurrence/predicament. I (and I assume others
 > too) sometimes get bug reports for my libraries that really amount
 > to Emacs dev changes "breaking" things. Much of the time my answer
 > must be "Too bad. I don't support ongoing Emacs development. Wait
 > until the next Emacs release".

What's the problem?  That is the correct answer (modulo the addition
of "patches that work before and after the Emacs change welcome", if
appropriate for your development policy).

Re: next emacs version?

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> The approximation used is for the Emacs developers to agree on a
> conventional ordering, which is called "the mainline".  If you know
> your user is "on the mainline", then dates can be used to do the
> ordering, or the revision number.

"Trunk"

(yes, I know it's a silly quibble, but the name "mainline" is just so
stupid sounding that I'd hate to see people pick it up...)

-Miles

-- 
You can hack anything you want, with TECO and DDT.

RE: next emacs version?

[Drew Adams]

>> This is a common occurrence/predicament. I (and I assume others
>> too) sometimes get bug reports for my libraries that really amount
>> to Emacs dev changes "breaking" things. Much of the time my answer
>> must be "Too bad. I don't support ongoing Emacs development. Wait
>> until the next Emacs release".
> 
> What's the problem?  That is the correct answer (modulo the addition
> of "patches that work before and after the Emacs change welcome", if
> appropriate for your development policy).

There's no problem. That is exactly what I do.

But as I mentioned, in some cases a minor change to my code can enable users to
keep using it after some Emacs dev change. And so I sometimes make such a change
to help them out, though still with no commitment to keep things synced and
working wrt a moving dev target.

IOW, I do this kind of update only exceptionally, and only if the change is
minor and I expect that the dev code will be fairly stable wrt the change.