Emacs-23 release branch

Emacs-23 release branch

[Stefan Monnier]

I have just cut the release branch for Emacs-23.2.  It's at:

   sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23

Any changes which you'd like to see in Emacs-23.x should be installed
there and only there (from where we will then merge it back onto the
trunk).


        Stefan

Re: Emacs-23 release branch

[Chong Yidong]

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

> I have just cut the release branch for Emacs-23.2.  It's at:
>
>    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
>
> Any changes which you'd like to see in Emacs-23.x should be installed
> there and only there (from where we will then merge it back onto the
> trunk).

Also, note that I intend to make a new pretest tomorrow, from the
release branch.

Now that the release branch has been made, please install there only
fixes that are regressions with respect to Emacs 22.3.  If you think a
non-regression fix should go into the branch, please ask Stefan or
myself, or discuss on emacs-devel.

Some of the changes in NEWS have yet to be documentated; if you have
some time, help in this area would be much appreciated.

As for the trunk, new features intended for Emacs 24 (and bugfixes not
safe for Emacs 23.2) can now be checked in.  However, if the change is
major (or if you have commit access but are not a regular contributor)
please inform emacs-devel first.

-----

This is also a good point for people to chime in on their plans for
Emacs 24.  Stefan and I have had some discussions about this; here is
our current list of major changes that we'd like to see included:

* The package manager (Tromey et al.).

* Bidi support (Eli).

* Better VC interaction DVCSs (Dan, etc?).
  As an exception, we plan to backport VC improvements to Emacs 23.3.

* Color-theme, or something like it.
  (Maybe using Custom Themes?).

* Concurrency? (Scrivano et al.)
  (Even if we can't get this ready in time, it would be good to make
  this an "experimental" compile-time option.)

* Lexbind? (Miles).
  (Miles, how realistic is it to include this?)

* TTZ's experiment with SVG progress bar, abstracted into a general
  Emacs library for embedded graphics.
  If we can do this, I would also like to seriously consider switching
  to SVG as the default image library, replacing our use of xpm (e.g.,
  the inline xpm images that we use for certain buffer widgets should be
  turned into SVG).

* GTK widget embedding code? (Joakim).
  (Joakim, how realistic is it to include this?)
  The preceding SVG widget feature might make this less necessary; I'm
  not sure.

Other stuff we'd like to see happen, if possible, are:

* Increased usage of the Semantic library by other parts of Emacs.

* Improving the Customize user interface (I have some working in this
  area that I'm going to commit soon).

Re: Emacs-23 release branch

[Jason Rumney]

On 10/03/2010 12:09, Chong Yidong wrote:
> * TTZ's experiment with SVG progress bar, abstracted into a general
>    Emacs library for embedded graphics.
>    If we can do this, I would also like to seriously consider switching
>    to SVG as the default image library, replacing our use of xpm (e.g.,
>    the inline xpm images that we use for certain buffer widgets should be
>    turned into SVG).
>    

Sounds good, but currently our implementation of SVG is tied heavily to 
GTK, which makes using it on other platforms difficult and bug prone due 
to all the dependencies that get pulled in, not all of which have been 
ported well.

If we make some effort to support the cairo backend of librsvg as an 
alternative to the gdk_pixbuf backend, then it might help.

Re: Emacs-23 release branch

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Sounds good, but currently our implementation of SVG is tied heavily
> to GTK, which makes using it on other platforms difficult and bug
> prone due to all the dependencies that get pulled in, not all of which
> have been ported well.

Could you elaborate?  Is it possible to get Emacs+SVG working on (say)
Windows if you install enough libraries?  From what I know, librsvg
itself is supposed to work on all POSIX systems and on Windows.

Re: Emacs-23 release branch

[Jason Rumney]

Chong Yidong <cyd@stupidchicken.com> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> Sounds good, but currently our implementation of SVG is tied heavily
>> to GTK, which makes using it on other platforms difficult and bug
>> prone due to all the dependencies that get pulled in, not all of which
>> have been ported well.
>
> Could you elaborate?  Is it possible to get Emacs+SVG working on (say)
> Windows if you install enough libraries?  From what I know, librsvg
> itself is supposed to work on all POSIX systems and on Windows.

It's possible after installing most of GTK and some libraries from
Gnome. About 20 libraries in total.  It then crashes if you open any SVG
file that contains stretched or rotated text.

Re: Emacs-23 release branch

[Lennart Borgman]

On Thu, Mar 11, 2010 at 12:11 AM, Jason Rumney <jasonr@gnu.org> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>> Sounds good, but currently our implementation of SVG is tied heavily
>>> to GTK, which makes using it on other platforms difficult and bug
>>> prone due to all the dependencies that get pulled in, not all of which
>>> have been ported well.
>>
>> Could you elaborate?  Is it possible to get Emacs+SVG working on (say)
>> Windows if you install enough libraries?  From what I know, librsvg
>> itself is supposed to work on all POSIX systems and on Windows.
>
> It's possible after installing most of GTK and some libraries from
> Gnome. About 20 libraries in total.  It then crashes if you open any SVG
> file that contains stretched or rotated text.


Sounds bad. Is that a problem with the library "division" or is it
Emacs use of them that is problematic?

Re: Emacs-23 release branch

[Stefan Monnier]

> This is also a good point for people to chime in on their plans for
> Emacs 24.  Stefan and I have had some discussions about this; here is
> our current list of major changes that we'd like to see included:

BTW, I've put this list in etc/TODO.


        Stefan

Re: Emacs-23 release branch

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I have just cut the release branch for Emacs-23.2.  It's at:
>>
>>    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23>
>> Any changes which you'd like to see in Emacs-23.x should be installed
>> there and only there (from where we will then merge it back onto the
>> trunk).
>
> Also, note that I intend to make a new pretest tomorrow, from the
> release branch.
>
> Now that the release branch has been made, please install there only
> fixes that are regressions with respect to Emacs 22.3.  If you think a
> non-regression fix should go into the branch, please ask Stefan or
> myself, or discuss on emacs-devel.
>
> Some of the changes in NEWS have yet to be documentated; if you have
> some time, help in this area would be much appreciated.
>
> As for the trunk, new features intended for Emacs 24 (and bugfixes not
> safe for Emacs 23.2) can now be checked in.  However, if the change is
> major (or if you have commit access but are not a regular contributor)
> please inform emacs-devel first.
>
> -----
>
> This is also a good point for people to chime in on their plans for
> Emacs 24.  Stefan and I have had some discussions about this; here is
> our current list of major changes that we'd like to see included:
>
> * The package manager (Tromey et al.).
>
> * Bidi support (Eli).
>
> * Better VC interaction DVCSs (Dan, etc?).
>   As an exception, we plan to backport VC improvements to Emacs 23.3.
>
> * Color-theme, or something like it.
>   (Maybe using Custom Themes?).
>
> * Concurrency? (Scrivano et al.)
>   (Even if we can't get this ready in time, it would be good to make
>   this an "experimental" compile-time option.)
>
> * Lexbind? (Miles).
>   (Miles, how realistic is it to include this?)
>
> * TTZ's experiment with SVG progress bar, abstracted into a general
>   Emacs library for embedded graphics.
>   If we can do this, I would also like to seriously consider switching
>   to SVG as the default image library, replacing our use of xpm (e.g.,
>   the inline xpm images that we use for certain buffer widgets should be
>   turned into SVG).

I have an interactive bounding box app "dragbox.el" for marking regions
in images. It would be nice if that usecase could also be covered by the
new embedded svg library.

It would also be nice if the ImageMagick patch could be included.
It would give us an extra way of rendering SVG too.

Maybe image libraries could be made pluggable, as discussed in the ffi
thread recently? I think the image library support code is already very
modular, only actual dynamic loading is missing.


> * GTK widget embedding code? (Joakim).
>   (Joakim, how realistic is it to include this?)
>   The preceding SVG widget feature might make this less necessary; I'm
>   not sure.

Its not totally unrealistic. The patch needs way more testing and code
quality assurance though, at the least. The interface isn't finished.

There are also several corner cases I've ignored for now.

Maybe it could be an experimental option, like you describe for
"concurrency" above.

> Other stuff we'd like to see happen, if possible, are:
>
> * Increased usage of the Semantic library by other parts of Emacs.

Indeed. Also more language support(I have some half baked Java support
code using Clojure I'd like to discuss (Clojure is a Lisp on top of the
Java Virtual Machine which interacts nicely with Emacs))

>
> * Improving the Customize user interface (I have some working in this
>   area that I'm going to commit soon).
>
-- 
Joakim Verona

Re: Emacs-23 release branch

[Ted Zlatanov]

On Wed, 10 Mar 2010 06:58:16 +0100 joakim@verona.se wrote: 

j> Chong Yidong <cyd@stupidchicken.com> writes:
>> * TTZ's experiment with SVG progress bar, abstracted into a general
>> Emacs library for embedded graphics.
>> If we can do this, I would also like to seriously consider switching
>> to SVG as the default image library, replacing our use of xpm (e.g.,
>> the inline xpm images that we use for certain buffer widgets should be
>> turned into SVG).

j> I have an interactive bounding box app "dragbox.el" for marking regions
j> in images. It would be nice if that usecase could also be covered by the
j> new embedded svg library.

I have some custom code to generate colorful gauges for Gnus
unread/unseen counts.  I'd love to get that working with the general
Emacs library and minimize the custom code.  I have my own functions to
insert a SVG image scaled down so the line height doesn't grow
unnecessarily.

Ted

Re: Emacs-23 release branch

[Ulrich Mueller]

>>>>> On Tue, 09 Mar 2010, Chong Yidong wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I have just cut the release branch for Emacs-23.2.  It's at:
>> 
>> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23

> As for the trunk, new features intended for Emacs 24 (and bugfixes
> not safe for Emacs 23.2) can now be checked in.

Could the version number in the trunk be changed please (24.0.50?)?
That would make it easier to install both trunk and release branch
alongside.

Ulrich

Re: Emacs-23 release branch

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> writes:

> Could the version number in the trunk be changed please (24.0.50?)?
> That would make it easier to install both trunk and release branch
> alongside.

I've just done that now.

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Tue, 09 Mar 2010 23:09:29 -0500
> 
> This is also a good point for people to chime in on their plans for
> Emacs 24.  Stefan and I have had some discussions about this; here is
> our current list of major changes that we'd like to see included:
> 
> * The package manager (Tromey et al.).
> 
> * Bidi support (Eli).

Does this mean it is okay to merge my local bidi branch with mainline
any time I feel like it?

If there are some prerequisites or requirements before such a merge
can be done, please tell what they are.

Re: Emacs-23 release branch

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Does this mean it is okay to merge my local bidi branch with mainline
> any time I feel like it?

Yes, if the bidi branch is in a usable state, please do so.

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 10 Mar 2010 12:34:23 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does this mean it is okay to merge my local bidi branch with mainline
> > any time I feel like it?
> 
> Yes, if the bidi branch is in a usable state, please do so.

It _should_ be in a usable state, as all of the bidi support is
entirely dormant until you flip a buffer-local variable.  With a
single exception, all the bidi support code is only run if that
variable was set non-nil, and only for the buffer where it was set.
(The default is nil, of course.)  The single exception is the function
set_cursor_from_row, which needed a complete rewrite to be able to
support bidirectional display with `display' properties.

That said, I didn't yet have time to run the branch in a GUI session,
so maybe it would be prudent to wait with the merge until I do and can
see that it is stable (as long as the above-mentioned variable is not
set).

WDYT?

Re: Emacs-23 release branch

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> It _should_ be in a usable state, as all of the bidi support is
> entirely dormant until you flip a buffer-local variable.  With a
> single exception, all the bidi support code is only run if that
> variable was set non-nil, and only for the buffer where it was set.
> (The default is nil, of course.)  The single exception is the function
> set_cursor_from_row, which needed a complete rewrite to be able to
> support bidirectional display with `display' properties.
>
> That said, I didn't yet have time to run the branch in a GUI session,
> so maybe it would be prudent to wait with the merge until I do and can
> see that it is stable (as long as the above-mentioned variable is not
> set).

Yes, that sounds fine.

Re: Emacs-23 release branch

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Tue, 09 Mar 2010 23:09:29 -0500
>> 
>> This is also a good point for people to chime in on their plans for
>> Emacs 24.  Stefan and I have had some discussions about this; here is
>> our current list of major changes that we'd like to see included:
>> 
>> * The package manager (Tromey et al.).
>> 
>> * Bidi support (Eli).
>
> Does this mean it is okay to merge my local bidi branch with mainline
> any time I feel like it?

Wouldn't it make more sense to push your local bidi branch as a branch
first?  That way, people can experiment with it and possibly indicate
problems.  Right now, at least the git mirror only carries a rather old
bidi branch.

-- 
David Kastrup

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 10 Mar 2010 18:37:29 +0100
> 
> >> * Bidi support (Eli).
> >
> > Does this mean it is okay to merge my local bidi branch with mainline
> > any time I feel like it?
> 
> Wouldn't it make more sense to push your local bidi branch as a branch
> first?

I don't mind.  That's why I asked the question in the first place.

However, given my explanation in the other mail just sent, what would
be the advantage of having a branch, rather than merging with the
trunk?

Re: Emacs-23 release branch

[Stefan Monnier]

> Wouldn't it make more sense to push your local bidi branch as a branch
> first?

One of us is missing something:

sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi has been around for
a while now.


        Stefan

Re: Emacs-23 release branch

[David Kastrup]

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

>> Wouldn't it make more sense to push your local bidi branch as a branch
>> first?
>
> One of us is missing something:
>
> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi has been around for
> a while now.

As I said, I am using the git mirror.  Its emacs-bidi branch sports the
following "latest" commits:

commit 81d7dec9e1cc67b222f16697f2c9943c7f1131ef
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Dec 3 17:02:01 2005 +0000

    *** empty log message ***

commit c7e2ed7f183b98437998a469e4556b113ba19645
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Dec 3 17:00:50 2005 +0000

    Include stdio.h unconditionally.  Fix and elaborate commentary.
    Add Copyright blurb.

commit d8b4eef7074bfe981e165e902efe40ccbb7d518d
Author: Kenichi Handa <handa@m17n.org>
Date:   Mon Mar 8 07:47:50 2004 +0000

    *** empty log message ***

commit c1bdf76c67bd7cc89ea525b317b185e68e4a10a9
Author: Kenichi Handa <handa@m17n.org>
Date:   Mon Mar 8 07:47:37 2004 +0000

    (bidi_init_it): Set bidi_it->ch_len even if POS > 0.


-- 
David Kastrup

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Mar 2010 14:23:46 -0500
> Cc: emacs-devel@gnu.org
> 
> > Wouldn't it make more sense to push your local bidi branch as a branch
> > first?
> 
> One of us is missing something:
> 
> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi has been around for
> a while now.

As David points out, that branch is effectively dead.  It is based on
an old and unstable development version of Emacs 22.1 (yes, 22.1!),
has a couple of grave bugs in the bidirectional code itself, and so is
not useful.

By contrast, the local branch where I develop bidi Emacs is based on
Emacs 23.1 and is merged with mainline once a week.

Re: Emacs-23 release branch

[Stefan Monnier]

> By contrast, the local branch where I develop bidi Emacs is based on
> Emacs 23.1 and is merged with mainline once a week.

What are you waiting for to publish it at
sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi?


        Stefan

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 10 Mar 2010 22:15:37 -0500
> 
> > By contrast, the local branch where I develop bidi Emacs is based on
> > Emacs 23.1 and is merged with mainline once a week.
> 
> What are you waiting for to publish it at
> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi?

Why does it make sense not to merge to the trunk directly?

Re: Emacs-23 release branch

[Stefan Monnier]

>> > By contrast, the local branch where I develop bidi Emacs is based on
>> > Emacs 23.1 and is merged with mainline once a week.
>> What are you waiting for to publish it at
>> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi?
> Why does it make sense not to merge to the trunk directly?

;-)


        Sefan

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 11 Mar 2010 09:00:49 -0500
> 
> >> > By contrast, the local branch where I develop bidi Emacs is based on
> >> > Emacs 23.1 and is merged with mainline once a week.
> >> What are you waiting for to publish it at
> >> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi?
> > Why does it make sense not to merge to the trunk directly?
> 
> ;-)

That was an honest question.  Yidong said it was okay to merge with
the trunk, but if you disagree, I won't.

(Not that you should expect the merge today or tomorrow, even if
everybody agrees.)

Re: Emacs-23 release branch

[Stefan Monnier]

>> >> > By contrast, the local branch where I develop bidi Emacs is based on
>> >> > Emacs 23.1 and is merged with mainline once a week.
>> >> What are you waiting for to publish it at
>> >> sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-bidi?
>> > Why does it make sense not to merge to the trunk directly?
>> ;-)

> That was an honest question.  Yidong said it was okay to merge with
> the trunk, but if you disagree, I won't.

My question was meant as "why keep it for yourself rather than publish
it in the emacs-bidi branch?".  Of course, installing it on the trunk
would be even better.

> (Not that you should expect the merge today or tomorrow, even if
> everybody agrees.)

Right, so unless this is expected to be "real soon now", you might want
to publish your branch in `emacs-bidi'.  You could even use that to ask
people to test it (in non-bidi mode) before merging it into trunk.


        Stefan

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 11 Mar 2010 14:04:54 -0500
> 
> > (Not that you should expect the merge today or tomorrow, even if
> > everybody agrees.)
> 
> Right, so unless this is expected to be "real soon now", you might want
> to publish your branch in `emacs-bidi'.

Is that even possible?  `emacs-bidi' was branched from pre-22.1 Emacs,
while my development branch was branched from Emacs 23.1.  Wouldn't
merging them create some very messy history DAG?

Re: Emacs-23 release branch

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right, so unless this is expected to be "real soon now", you might want
>> to publish your branch in `emacs-bidi'.
>
> Is that even possible?

Not useful, at least.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs-23 release branch

[James Cloos]

>>>>> "E" == Eli Zaretskii <eliz@gnu.org> writes:

E> Is that even possible?  `emacs-bidi' was branched from pre-22.1
E> Emacs, while my development branch was branched from Emacs 23.1.
E> Wouldn't merging them create some very messy history DAG?

You could create a new branch; or perhaps the current emacs-bidi branch
could be renamed to, eg, old-branches/old-bidi, leaving the emacs-bidi
name available for a new branch.

Having the code in the repo in its own branch will be useful for the
rest of us, especially given that you wrote that merging into trunk
would not happen right away.

And even if it were to happen right away, going through a public branch
may ease future bisection and other anthropological pursuits withing the
repository.

In any case, I cannot hurt to make your branch public, and there is no
good reason not to do so within the master repo.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: bidi branch (was: Emacs-23 release branch)

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Copyright: Copyright 2009 James Cloos
> OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
> Date: Thu, 11 Mar 2010 17:19:16 -0500
> 
> Having the code in the repo in its own branch will be useful for the
> rest of us, especially given that you wrote that merging into trunk
> would not happen right away.

As I explained elsewhere, the bidi code is inactive unless the user
customizes a per-buffer variable.  So the reasons for not merging into
the trunk are not for fear of totally breaking Emacs, and will also
delay publishing as a public branch.

> And even if it were to happen right away, going through a public branch
> may ease future bisection and other anthropological pursuits withing the
> repository.

Unless someone objects strenuously, I intend to merge all the current
history I have on my local branch, without any rebasing or similar
tricks that futz with the history.  Therefore, bisection will not
suffer either way.

> In any case, I cannot hurt to make your branch public, and there is no
> good reason not to do so within the master repo.

I'm still unclear why it makes more sense to have a public branch than
to merge with the trunk.

Re: bidi branch

[James Cloos]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> As I explained elsewhere, the bidi code is inactive unless the user
EZ> customizes a per-buffer variable.

Yes, I read that and had it in mind when replying.

EZ> So the reasons for not merging into the trunk are not for fear of
EZ> totally breaking Emacs, and will also delay publishing as a public
EZ> branch.

I was, as I hoped you'd notice, trying to give you a reason to publish
early and often, rather than waiting ...

EZ> Unless someone objects strenuously, I intend to merge all the
EZ> current history I have on my local branch, without any rebasing
EZ> or similar tricks that futz with the history.

Which is exactly what I was hoping to get to see. 

EZ> I'm still unclear why it makes more sense to have a public branch
EZ> than to merge with the trunk.

Just to get it out there before the merge.

I we cannot convince you to let us see it and test it out now, I
suppose there is no reason. :(

And to be clear, I am not complaining about your choice to keep it
close, just failing to persuade otherwise. :)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: bidi branch

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 13 Mar 2010 13:16:42 -0500
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> EZ> I'm still unclear why it makes more sense to have a public branch
> EZ> than to merge with the trunk.
> 
> Just to get it out there before the merge.
> 
> I we cannot convince you to let us see it and test it out now, I
> suppose there is no reason. :(

IMO, it doesn't make sense to publish code that wasn't yet made to
compile on anything but GNU/Windows (i.e., the Windows build will be
broken), and which I never tried to run in a GUI session.  Why would
anyone want to see such code so badly?

I hope to get past those two obstacles in about 4 weeks, and then I'll
be ready to go public.  The merge itself is a non-issue, since I'm
resyncing with the trunk every week.  Stefan and Yidong agreed to this
plan.

Re: bidi branch

[Eli Zaretskii]

> Date: Sat, 13 Mar 2010 21:03:55 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> IMO, it doesn't make sense to publish code that wasn't yet made to
> compile on anything but GNU/Windows (i.e., the Windows build will be
                          ^^^^^^^^^^^
That'd be the day ;-)  I meant GNU/Linux, of course...

RE: bidi branch

[Drew Adams]

> > IMO, it doesn't make sense to publish code that wasn't yet made to
> > compile on anything but GNU/Windows (i.e., the Windows build will be
>                           ^^^^^^^^^^^
> That'd be the day ;-)  I meant GNU/Linux, of course...

Oy vey! We're gonna have to send you back for regrooving, Eli. ;-)

Re: bidi branch

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > IMO, it doesn't make sense to publish code that wasn't yet made to
 > compile on anything but GNU/Windows (i.e., the Windows build will be
 > broken), and which I never tried to run in a GUI session.  Why would
 > anyone want to see such code so badly?

Because they've got lots of time on their hands.

Of course it's up to you, but there are a *lot* of very skilled
hackers around here, and anybody who's abused their retinas with UAX
#9 knows there is not much short of a full-blown operating system that
has the hack value of a bidi algorithm!

:-)

Re: Emacs-23 release branch

[Stefan Monnier]

>> > (Not that you should expect the merge today or tomorrow, even if
>> > everybody agrees.)
>> Right, so unless this is expected to be "real soon now", you might want
>> to publish your branch in `emacs-bidi'.
> Is that even possible?  `emacs-bidi' was branched from pre-22.1 Emacs,
> while my development branch was branched from Emacs 23.1.  Wouldn't
> merging them create some very messy history DAG?

No need to merge them.  You can just "bzr push --overwrite .../emacs-bidi".
That will throw away the current emacs-bidi, so if you want to keep it
around, better move it elsewhere first.


        Stefan

Re: bidi branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 11 Mar 2010 17:45:57 -0500
> 
> >> > (Not that you should expect the merge today or tomorrow, even if
> >> > everybody agrees.)
> >> Right, so unless this is expected to be "real soon now", you might want
> >> to publish your branch in `emacs-bidi'.
> > Is that even possible?  `emacs-bidi' was branched from pre-22.1 Emacs,
> > while my development branch was branched from Emacs 23.1.  Wouldn't
> > merging them create some very messy history DAG?
> 
> No need to merge them.  You can just "bzr push --overwrite .../emacs-bidi".

I prefer to merge with the trunk, unless you object.  Since the bidi
code is not run unless the user turns on a variable, I don't see any
reasons for a separate branch.  A separate branch complicates
logistics (for me, at least) and increases chances of a mistaken
commit.  It also exposes the modified code to fewer users.

As for reasons for not merging VSN, they will delay a separate branch
as well, since they are unrelated to the stability of the code.

Re: Emacs-23 release branch

[Andreas Schwab]

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

> You can just "bzr push --overwrite

Never ever do that with a public branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs-23 release branch

[Stefan Monnier]

>> You can just "bzr push --overwrite
> Never ever do that with a public branch.

I know.  Luckily, that's one of those "exceptions that proves the rule".


        Stefan

Re: Emacs-23 release branch

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> This is also a good point for people to chime in on their plans for
> Emacs 24.

Last year, the GNOME Keyring and KDE Wallet developers have agreed a
common API, called Secret Services, to access their password
repositories. This API is D-Bus based, see
<http://www.freedesktop.org/wiki/Specifications/secret-storage-spec>.

I have written a small package, secrets.el, which uses this API to read
and write passwords. It is tested with GNOME Keyring 2.29.90; a public
KWallet implementation is under work. Ted Zlatanov has volunteered to
integrate it into auth-sources.el as new backend, and I intend to use it
also in Tramp.

Are there objections to install it under lisp/net/secrets.el?

Best regards, Michael.

Re: Emacs-23 release branch

[Stefan Monnier]

> Are there objections to install it under lisp/net/secrets.el?

Why "net"?


        Stefan


PS: It sounds like a good idea overall.

Re: Emacs-23 release branch

[Michael Albinus]

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

>> Are there objections to install it under lisp/net/secrets.el?
>
> Why "net"?

It uses D-Bus internally, and all D-Bus related packages are there. But
there is no problem to install it as lisp/secrets.el.

>         Stefan
>
> PS: It sounds like a good idea overall.

Best regards, Michael.

Re: Emacs-23 release branch

[Stefan Monnier]

>>> Are there objections to install it under lisp/net/secrets.el?
>> Why "net"?
> It uses D-Bus internally, and all D-Bus related packages are there.

Having dbus in "net" makes just as little sense to me, so I guess
that'd be OK ;-)
But we should maybe think of a better directory structure.


        Stefan

Re: Emacs-23 release branch

[Michael Albinus]

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

> Having dbus in "net" makes just as little sense to me, so I guess
> that'd be OK ;-)
> But we should maybe think of a better directory structure.

D'accord. D-Bus is designed for inter process communication, like
Corba. Maybe we could introduce a subdirectory "lisp/ipc".

OTOH, there are discussions to extend the scope of D-Bus over the
machine boundary. Telepathy Tubes[1] is a first implementation. Packages
using this feature would be OK in "lisp/net" (secrets.el does not belong
to this category).

I'm completely open to your decision.

[1] http://telepathy.freedesktop.org/wiki/

>         Stefan

Best regards, Michael.

Re: Emacs-23 release branch

[Stefan Monnier]

>> Having dbus in "net" makes just as little sense to me, so I guess
>> that'd be OK ;-)
>> But we should maybe think of a better directory structure.
> D'accord. D-Bus is designed for inter process communication, like
> Corba. Maybe we could introduce a subdirectory "lisp/ipc".

Can you find enough .el files to put in there to justify the creation of
this directory?

Maybe we should look in a different direction, tho I'm not sure what
that should be.  But if it's something that could accomodate several of
the lisp/*.el files that would be good.


        Stefan

Re: Emacs-23 release branch

[Michael Albinus]

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

>> D'accord. D-Bus is designed for inter process communication, like
>> Corba. Maybe we could introduce a subdirectory "lisp/ipc".
>
> Can you find enough .el files to put in there to justify the creation of
> this directory?

battery.el, comint.el, proced.el, server.el, net/dbus.el, net/socks.el,
net/xesam.el, net/zeroconf.el.

Maybe also epa*.el, epg*.el, pgg*.el, talk.el, net/imap.el, net/ldap.el.

I would also like to see password-cache.el and gnus/auth-sorce.el there,
but they don't fit any of the selection criteria ...

I plan soap.el, but this could also go into lisp/net when it is ready.

> Maybe we should look in a different direction, tho I'm not sure what
> that should be.  But if it's something that could accomodate several of
> the lisp/*.el files that would be good.
>
>
>         Stefan

Best regards, Michael.

Re: Emacs-23 release branch

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Can you find enough .el files to put in there to justify the creation of
>> this directory?
>
> battery.el, comint.el, proced.el, server.el, net/dbus.el, net/socks.el,
> net/xesam.el, net/zeroconf.el.
>
> Maybe also epa*.el, epg*.el, pgg*.el, talk.el, net/imap.el, net/ldap.el.
>
> I would also like to see password-cache.el and gnus/auth-sorce.el there,
> but they don't fit any of the selection criteria ...
>
> I plan soap.el, but this could also go into lisp/net when it is ready.

Maybe call the directory `os' or something like that?

Re: Emacs-23 release branch

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

>> battery.el, comint.el, proced.el, server.el, net/dbus.el, net/socks.el,
>> net/xesam.el, net/zeroconf.el.
>>
>> Maybe also epa*.el, epg*.el, pgg*.el, talk.el, net/imap.el, net/ldap.el.
>>
>> I would also like to see password-cache.el and gnus/auth-sorce.el there,
>> but they don't fit any of the selection criteria ...
>>
>> I plan soap.el, but this could also go into lisp/net when it is ready.
>
> Maybe call the directory `os' or something like that?

This would be a broader range. Packages like dired.el would fit there as
well.

Best regards, Michael.

Re: Emacs-23 release branch

[Ted Zlatanov]

On Thu, 11 Mar 2010 17:02:14 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> D'accord. D-Bus is designed for inter process communication, like
>>> Corba. Maybe we could introduce a subdirectory "lisp/ipc".
>> 
>> Can you find enough .el files to put in there to justify the creation of
>> this directory?

MA> battery.el, comint.el, proced.el, server.el, net/dbus.el, net/socks.el,
MA> net/xesam.el, net/zeroconf.el.

MA> Maybe also epa*.el, epg*.el, pgg*.el, talk.el, net/imap.el, net/ldap.el.

MA> I would also like to see password-cache.el and gnus/auth-sorce.el there,
MA> but they don't fit any of the selection criteria ...

MA> I plan soap.el, but this could also go into lisp/net when it is ready.

This actually ties into the recent package.el discussions.  Ideally all
these directories would not matter to the user, who would just install a
package from a category.  So perhaps the taxonomy work should not aim to
reorganize the directory structure (though that could happen too) but to
create a category structure useful to the end user.  All the reference
tools within Emacs can then use this structure as well.

In this light, creating one category per package is not as onerous as
creating one directory per package, so I think we can have more useful
and varied categories.

I also propose that we treat categorizing packages and creating a useful
package taxonomy as a process, like code review and bug fixes.  It
should be done both as a periodic review and every time new packages are
introduced.

Ted

Re: Emacs-23 release branch

[Ted Zlatanov]

On Fri, 12 Mar 2010 09:28:31 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I also propose that we treat categorizing packages and creating a useful
TZ> package taxonomy as a process, like code review and bug fixes.  It
TZ> should be done both as a periodic review and every time new packages are
TZ> introduced.

Also see the "tags for functions" thread from a while ago, for instance
message ID <864ozgajtx.fsf@lifelogs.com>.  Package categories would
logically assist in tagging and searching for the package's functions by
providing a stable category path in addition to the free-form function
tags.

Ted

Keywords (was: Emacs-23 release branch)

[Juri Linkov]

> TZ> I also propose that we treat categorizing packages and creating a useful
> TZ> package taxonomy as a process, like code review and bug fixes.  It
> TZ> should be done both as a periodic review and every time new packages are
> TZ> introduced.
>
> Also see the "tags for functions" thread from a while ago, for instance
> message ID <864ozgajtx.fsf@lifelogs.com>.

I think tags for functions are necessary only for core functions, i.e.
files likes simple.el and subr.el can't have useful file-level keywords.
They are a collection of diverse functions where it's difficult to find
the necessary function.

> Package categories would logically assist in tagging and searching for
> the package's functions by providing a stable category path in
> addition to the free-form function tags.

Please note the terminology.  A tag is a non-hierarchical free-form term.
In Emacs a keyword not registered in `finder-known-keywords' is really
a tag.  To extend Emacs keywords we could take a well-established taxonomy
like Debian package tags and add to the Emacs taxonomy in finder.

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

Re: Emacs-23 release branch

[Juri Linkov]

>> Having dbus in "net" makes just as little sense to me, so I guess
>> that'd be OK ;-)
>> But we should maybe think of a better directory structure.
>
> D'accord. D-Bus is designed for inter process communication, like
> Corba. Maybe we could introduce a subdirectory "lisp/ipc".

De facto all files in the "lisp/net" subdirectory currently belong to
the "comm" keyword category.  This keyword has the description:
"communications, networking, remote access to files".

I think it makes no sense to create a new subdirectory like "comm"
because in this case we'll have endless discussions whether a file
belongs to the "communications" category and should go to the "comm"
subdirectory or it belongs to the "networking" category and should
go to the "net" subdirectory.

One option is to rename "net" to "comm", so the keyword will match
the subdirectory name, but I'm not sure what practical benefits this
would provide.

Until it is renamed, we could accept the fact that the keyword "comm"
corresponds to the subdirectory name "net", and put all files that
fit the description "communications, networking, remote access to files"
to the "net" subdirectory.

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

Re: Emacs-23 release branch

[Stefan Monnier]

> Until it is renamed, we could accept the fact that the keyword "comm"
> corresponds to the subdirectory name "net", and put all files that
> fit the description "communications, networking, remote access to files"
> to the "net" subdirectory.

Fair enough.


        Stefan


PS: The directory structure doesn't have to have anything to do with
a user-visible taxonomy.  The main constraints it has are:

- each directory should be large enough to justify its existence
  (typically the threshold is considered to be "more than 20 .el
  files").

- large packages should have their own directory.

- try to use directories so as to avoid having everything right under
  lisp/ (in case the filesystem doesn't handle large directories
  efficiently, or because we don't like the appearance of lack of
  organization).

We could also just use a subdirectory "a" for packages whose name starts
with "a", for all I care.

secrets.el (was: Emacs-23 release branch)

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Until it is renamed, we could accept the fact that the keyword "comm"
>> corresponds to the subdirectory name "net", and put all files that
>> fit the description "communications, networking, remote access to files"
>> to the "net" subdirectory.
>
> Fair enough.

So I have installed it at lisp/net/secrets.el. I guess it could be
relocated easily, if needed.

Comments and proposals for enhancement are welcome!

>         Stefan

Best regards, Michael.

Re: secrets.el

[Stefan Monnier]

> So I have installed it at lisp/net/secrets.el.

Thank you.

> I guess it could be relocated easily, if needed.

Yes, of course.  Even more now that we got rid of CVS.


        Stefan

Re: secrets.el

[Ted Zlatanov]

On Sat, 13 Mar 2010 21:40:50 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>> Until it is renamed, we could accept the fact that the keyword "comm"
>>> corresponds to the subdirectory name "net", and put all files that
>>> fit the description "communications, networking, remote access to files"
>>> to the "net" subdirectory.
>> 
>> Fair enough.

MA> So I have installed it at lisp/net/secrets.el. I guess it could be
MA> relocated easily, if needed.

I fixed an unbalanced parenthesis bug in it.  It was my first Bazaar
commit, I hope I didn't destroy the repository :)

On a recent Ubuntu system secrets.el doesn't do anything (listing
collections fails for example).  Some docs would be good.

Ted

Keywords (Re: Emacs-23 release branch)

[Juri Linkov]

> Having dbus in "net" makes just as little sense to me, so I guess
> that'd be OK ;-)
> But we should maybe think of a better directory structure.

And better keyword dictionary structure too.

AFAIS currently there are two types of lisp subdirectories:

1. Subdirectories that contain a separate package:
   calc calendar cedet erc eshell gnus mh-e nxml org url

   (It seems heuristics for creating a separate subdirectory for the
   package is when the number of its files reaches some threshold like
   a dozen of files.)

2. The names of remaining subdirectories look very like keywords.

Actually there are already at least 3 different Emacs taxonomies:

1. Directory structure

2. Keywords for finder (info "(emacs) Library Keywords")

3. Customization group hierarchy

There are still many mismatches between them.  For instance,
`quickurl.el' is located in the `net' subdirectory, has the keyword
`hypermedia' and its customization groups belongs to `abbrev'.

Fortunately, there were attempts to merge existing taxonomies,
so finder keywords correspond to top-level customization groups.

There is also already some match between subdirectory names
and finder keywords:

  Dir calendar
    Keyword calendar (calendar and time management support)

  Dir emulation
    Keyword emulations (emulations of other editors)
    Keyword unix (front-ends/assistants for, or emulators of, UNIX-like features)

  Dir emacs-lisp
    Keyword extensions (Emacs Lisp language extensions)
    Keyword lisp (Lisp support, including Emacs Lisp)
    Keyword maint (maintenance aids for the Emacs development group)

  Dir international
  Dir language
    Keyword i18n (internationalization and alternate character-set support)

  Dir mail
    Keyword mail (modes for electronic-mail handling)

  Dir play
    Keyword games (games, jokes and amusements)

  Dir progmodes
    Keyword languages (specialized modes for editing programming languages)
    Keyword c (support for the C language and related languages)

  Dir term
    Keyword terminals (support for terminal types)

  Dir textmodes
    Keyword tex (supporting code for the TeX formatter)
    Keyword wp (word processing)

If we will try to merge keywords and directory names, then we could create
new subdirectories for existing keywords (and put these files in them):

  Dir for Keyword comm (communications, networking, remote access to files)

    Files like a new file secrets.el, etc.

  Dir for Keyword hypermedia (support for links between text or other media types)
  Dir for Keyword multimedia (images and sound support)

    Files doc-view.el iimage.el image-dired.el image.el image-file.el
    image-mode.el ezimage.el

  Dir for Keyword help (support for on-line help systems)

    Files ehelp.el help-at-pt.el help.el help-fns.el help-macro.el
    help-mode.el info.el info-look.el informat.el info-xref.el

Also we could add new keywords and their corresponding subdirectories:

  Keyword completion and Dir completion:

    Files complete.el completion.el icomplete.el
    minibuf-eldef.el minibuffer.el pcomplete.el

  Keyword diff and Dir diff:

     Files compare-w.el diff.el diff-mode.el ediff-diff.el ediff.el
     ediff-help.el ediff-hook.el ediff-init.el ediff-merg.el
     ediff-mult.el ediff-ptch.el ediff-util.el ediff-vers.el
     ediff-wind.el

  Keyword vcs and Dir vcs:

    Files vc.el vc-annotate.el vc-arch.el vc-bzr.el vc-cvs.el
    vc-dav.el vc-dir.el vc-dispatcher.el vc-git.el vc-hg.el
    vc-hooks.el vc-mtn.el vc-rcs.el vc-sccs.el vc-svn.el cvs-status.el
    pcvs-defs.el pcvs-info.el pcvs-parse.el pcvs-util.el pcvs.el

PS:
The remaining existing keywords that IMO are too specific
for a separate subdirectory:

  Keyword abbrev (abbreviation handling, typing shortcuts, macros)
  Keyword bib (code related to the `bib' bibliography processor)
  Keyword faces (support for multiple fonts)
  Keyword hardware (support for interfacing with exotic hardware)
  Keyword mouse (mouse support)
  Keyword outlines (support for hierarchical outlining)

The remaining existing keywords that IMO are too broad for a separate
subdirectory (but are good for top-level customization groups):

  Keyword convenience (convenience features for faster editing)
  Keyword data (support for editing files of data)
  Keyword docs (support for Emacs documentation)
  Keyword files (support for editing and manipulating files)
  Keyword frames (support for Emacs frames and window systems)
  Keyword internal (code for Emacs internals, build process, defaults)
  Keyword local (code local to your site)
  Keyword matching (various sorts of searching and matching)
  Keyword news (support for netnews reading and posting)
  Keyword oop (support for object-oriented programming)
  Keyword processes (process, subshell, compilation, and job control support)
  Keyword tools (programming tools)

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

Re: Keywords

[Juri Linkov]

A few days ago I got a bug report about numeric keywords displayed by
ee-finder - a package that lists all unknown finder keywords (that are
not registered in `finder-known-keywords').  I already fixed "RFC 2104"
that resulted in two separate keywords "RFC" and "2104" in finder-inf.el.
But I'm not going to hunt for more such keywords.  The problem lies in the
design flaw of keywords handling in finder.el and lisp-mnt.el.

`lm-keywords-list' assumes that keywords are separated by a sequence
of commas and whitespace.  This means that in:

  ;; Keywords: mule, multilingual, character composition

there is 4 keywords: "mule", "multilingual", "character" and "composition".
So a list of all unknown keywords currently is a mess.

To fix this problem I propose the following heuristics: if the keywords
line contains a comma, then split keywords using a comma and not whitespace,
because the presence of a comma means that the author decided to separate
keywords by commas only.

The patch below implements this:

Using parent branch file:///home/work/emacs/bzr/emacs/trunk/
=== modified file 'lisp/emacs-lisp/lisp-mnt.el'
--- lisp/emacs-lisp/lisp-mnt.el	2010-01-13 08:35:10 +0000
+++ lisp/emacs-lisp/lisp-mnt.el	2010-03-11 21:43:07 +0000
@@ -458,7 +458,9 @@ (defun lm-keywords-list (&optional file)
   "Return list of keywords given in file FILE."
   (let ((keywords (lm-keywords file)))
     (if keywords
-	(split-string keywords "[, \t\n]+" t))))
+	(if (string-match-p "," keywords)
+	    (split-string keywords ",[ \t\n]*" t)
+	  (split-string keywords "[, \t\n]+" t)))))
 
 (defvar finder-known-keywords)
 (defun lm-keywords-finder-p (&optional file)

But there are more problems.  In finder-inf.el multi-word keywords need
to be grouped using Lisp syntax.  Currently they are symbols, and the
entry look like:

    ("composite.el"
        "support character composition"
        (mule multilingual character composition))

There are two ways to group multi-word keywords:

1. Converting symbols to strings:

    ("composite.el"
        "support character composition"
        (mule multilingual "character composition"))

2. Adding some separator to symbols:

    ("composite.el"
        "support character composition"
        (mule multilingual character-composition))

I don't know yet what to prefer.

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

Re: Keywords

[Stefan Monnier]

> To fix this problem I propose the following heuristics: if the keywords
> line contains a comma, then split keywords using a comma and not whitespace,
> because the presence of a comma means that the author decided to separate
> keywords by commas only.

Sounds good,

> But there are more problems.  In finder-inf.el multi-word keywords need
> to be grouped using Lisp syntax.  Currently they are symbols, and the
> entry look like:

You can use

     ("composite.el"
         "support character composition"
         (mule multilingual character\ composition))


-- Stefan

Re: Keywords

[Juri Linkov]

> You can use
>
>      ("composite.el"
>          "support character composition"
>          (mule multilingual character\ composition))

I implemented this with your suggestion.

Also now it's possible to see a list of all "unknown" keywords
using `M-x info-finder'.

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

Re: Keywords

[Juri Linkov]

There are remaining two tasks in finder.el that I think would be useful:

;; Things to do:
;;    1. Support multiple keywords per search.  This could be extremely hairy;
;; there doesn't seem to be any way to get completing-read to exit on
;; an EOL with no substring pending, which is what we'd want to end the loop.
;;    2. Search by string in synopsis line?

The first task is easy to implement with the help of
`completing-read-multiple'.

The second task is also easy to implement by just listing all packages
with synopsis lines and keywords thus allowing to search a string
simply using Isearch.

=== modified file 'lisp/finder.el'
--- lisp/finder.el	2010-03-14 19:59:20 +0000
+++ lisp/finder.el	2010-03-15 21:32:35 +0000
@@ -27,12 +27,6 @@
 
 ;; This mode uses the Keywords library header to provide code-finding
 ;; services by keyword.
-;;
-;; Things to do:
-;;    1. Support multiple keywords per search.  This could be extremely hairy;
-;; there doesn't seem to be any way to get completing-read to exit on
-;; an EOL with no substring pending, which is what we'd want to end the loop.
-;;    2. Search by string in synopsis line?
 
 ;;; Code:
 

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-03-14 16:59:20 +0000
+++ lisp/info.el	2010-03-15 21:31:05 +0000
@@ -3390,7 +3390,8 @@ (defun Info-finder-find-node (filename n
 	 (insert (format "* %-14s %s.\n"
 			 (concat (symbol-name keyword) "::")
 			 (cdr assoc)))))
-     (cons '(unknown . "unknown keywords")
+     (append '((all . "All package info")
+	       (unknown . "unknown keywords"))
 	   finder-known-keywords)))
    ((equal nodename "unknown")
     ;; Display unknown keywords
@@ -3405,6 +3406,22 @@ (defun Info-finder-find-node (filename n
 		       (concat (symbol-name (car assoc)) "::")
 		       (cdr assoc))))
      (finder-unknown-keywords)))
+   ((equal nodename "all")
+    ;; Display all package info.
+    (insert (format "\n\^_\nFile: %s,  Node: %s,  Up: Top\n\n"
+		    Info-finder-file nodename))
+    (insert "Finder Package Info\n")
+    (insert "*******************\n\n")
+    (mapc (lambda (package)
+	    (insert (format "%s - %s\n"
+			    (format "*Note %s::" (nth 0 package))
+			    (nth 1 package)))
+	    (insert "Keywords: "
+		    (mapconcat (lambda (keyword)
+				 (format "*Note %s::" (symbol-name keyword)))
+			       (nth 2 package) ", ")
+		    "\n\n"))
+	  finder-package-info))
    ((string-match-p "\\.el\\'" nodename)
     ;; Display commentary section
     (insert (format "\n\^_\nFile: %s,  Node: %s,  Up: Top\n\n"
@@ -3429,6 +3446,7 @@ (defun Info-finder-find-node (filename n
 	   (buffer-string))))))
    (t
     ;; Display packages that match the keyword
+    ;; or the list of keywords separated by comma.
     (insert (format "\n\^_\nFile: %s,  Node: %s,  Up: Top\n\n"
 		    Info-finder-file nodename))
     (insert "Finder Packages\n")
@@ -3436,21 +3454,39 @@ (defun Info-finder-find-node (filename n
     (insert
      "The following packages match the keyword `" nodename "':\n\n")
     (insert "* Menu:\n\n")
-    (let ((id (intern nodename)))
+    (let ((keywords
+	   (mapcar 'intern (if (string-match-p "," nodename)
+			       (split-string nodename ",[ \t\n]*" t)
+			     (list nodename)))))
       (mapc
-       (lambda (x)
-	 (when (memq id (cadr (cdr x)))
+       (lambda (package)
+	 (unless (memq nil (mapcar (lambda (k) (memq k (nth 2 package)))
+				   keywords))
 	   (insert (format "* %-16s %s.\n"
-			   (concat (car x) "::")
-			   (cadr x)))))
+			   (concat (nth 0 package) "::")
+			   (nth 1 package)))))
        finder-package-info)))))
 
 ;;;###autoload
-(defun info-finder ()
-  "Display descriptions of the keywords in the Finder virtual manual."
-  (interactive)
+(defun info-finder (&optional keywords)
+  "Display descriptions of the keywords in the Finder virtual manual.
+In interactive use, a prefix argument directs this command to read
+a list of keywords separated by comma.  After that, it displays a node
+with a list packages that contain all specified keywords."
+  (interactive
+   (when current-prefix-arg
+     (require 'finder)
+     (list
+      (completing-read-multiple
+       "Keywords (separated by comma): "
+       (mapcar 'symbol-name (mapcar 'car (append finder-known-keywords
+						 (finder-unknown-keywords))))
+       nil t))))
   (require 'finder)
-  (Info-find-node Info-finder-file "Top"))
+  (if keywords
+      (Info-find-node Info-finder-file (mapconcat 'identity keywords ", "))
+    (Info-find-node Info-finder-file "Top")))
+
 \f
 (defun Info-undefined ()
   "Make command be undefined in Info."


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

finder.el UI (was: Keywords)

[Ted Zlatanov]

On Mon, 15 Mar 2010 23:33:03 +0200 Juri Linkov <juri@jurta.org> wrote: 

JL> There are remaining two tasks in finder.el that I think would be useful:
JL> ;; Things to do:
JL> ;;    1. Support multiple keywords per search.  This could be extremely hairy;
JL> ;; there doesn't seem to be any way to get completing-read to exit on
JL> ;; an EOL with no substring pending, which is what we'd want to end the loop.
JL> ;;    2. Search by string in synopsis line?

...

Is there any possibility of rethinking the UI of finder.el?  It's
very... episodic.

The BBDB UI, for instance, does a great job filtering and displaying a
few choices from a large list.  The Gnus summary/article buffers are
another good UI example, with the limiting commands.  package.el can
list hundreds of packages concisely.

Ted

Re: finder.el UI (was: Keywords)

[Juri Linkov]

> Is there any possibility of rethinking the UI of finder.el?  It's
> very... episodic.

Yes, the old finder UI was too ad-hoc.  This is the reason why
there was a task in etc/TODO to replace it with the Info UI
that I implemented for 23.2 with `M-x info-finder'.

> The BBDB UI, for instance, does a great job filtering and displaying a
> few choices from a large list.  The Gnus summary/article buffers are
> another good UI example, with the limiting commands.  package.el can
> list hundreds of packages concisely.

package.el has a different usage of keywords.  While Info UI is useful
for informational purposes (to find a package etc.), the purpose of
package.el is to select and install a package.  This requires
a different UI.  I think the most convenient UI for this task
would be UI like http://www.jurta.org/en/emacs/ee/finder

Please note that I don't propose to use this package as is
in package.el.  I'm referring to its UI that would be useful
for package.el.

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

Re: finder.el UI

[Ted Zlatanov]

On Sat, 20 Mar 2010 00:48:03 +0200 Juri Linkov <juri@jurta.org> wrote: 

>> Is there any possibility of rethinking the UI of finder.el?  It's
>> very... episodic.

JL> Yes, the old finder UI was too ad-hoc.  This is the reason why
JL> there was a task in etc/TODO to replace it with the Info UI
JL> that I implemented for 23.2 with `M-x info-finder'.

Is that blocked by something else or just waiting for tuits?

I tried it and it's a browser that deadends at the commentary.  Wouldn't
it make sense to at least let the user browse the original package
sources?  But this is still much better than the old finder and I would
get rid of the old one.  But you mention another finder:

>> The BBDB UI, for instance, does a great job filtering and displaying a
>> few choices from a large list.  The Gnus summary/article buffers are
>> another good UI example, with the limiting commands.  package.el can
>> list hundreds of packages concisely.

JL> package.el has a different usage of keywords.  While Info UI is useful
JL> for informational purposes (to find a package etc.), the purpose of
JL> package.el is to select and install a package.  This requires
JL> a different UI.  I think the most convenient UI for this task
JL> would be UI like http://www.jurta.org/en/emacs/ee/finder

I looked.  I like that it has multiple views plus the ability to visit
the source code.

JL> Please note that I don't propose to use this package as is
JL> in package.el.  I'm referring to its UI that would be useful
JL> for package.el.

So I'm a little confused.  Is the jurta.org finder proposed for Emacs
inclusion?  Or is info-finder the way to go?

Either way, users who look for packages also like to install and
activate them, so IMHO it makes sense that all the finder UIs should
link to package.el installation+activation somehow, either internally by
calling package.el functions or externally by launching package.el, when
it's part of Emacs.

Ted

Re: finder.el UI

[Stefan Monnier]

> I tried it and it's a browser that deadends at the commentary.  Wouldn't
> it make sense to at least let the user browse the original package
> sources?  But this is still much better than the old finder and I would
> get rid of the old one.  But you mention another finder:

Indeed, maybe we should move finder.el to lisp/obsolete?

> Either way, users who look for packages also like to install and
> activate them,

All packages bundled with Emacs (i.e. all those found by finder.el) are
already installed and activated.


        Stefan

Re: finder.el UI

[Ted Zlatanov]

On Mon, 22 Mar 2010 10:19:15 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I tried it and it's a browser that deadends at the commentary.  Wouldn't
>> it make sense to at least let the user browse the original package
>> sources?  But this is still much better than the old finder and I would
>> get rid of the old one.  But you mention another finder:

SM> Indeed, maybe we should move finder.el to lisp/obsolete?

Works for me.  But Juri's `finder' looks better than `info-finder' so
perhaps `info-finder' can be folded into it.

>> Either way, users who look for packages also like to install and
>> activate them,

SM> All packages bundled with Emacs (i.e. all those found by finder.el) are
SM> already installed and activated.

I thought it would make sense to link what package.el will manage into
finder.el and other Emacs facilities, so this would no longer be true.
finder.el would show (clearly marked regarding their state and repo
origin) available, installed, and activated packages; there would also
be a way from there to install and activate a package, either internally
or through a link to the package.el UI.  Do you disagree with that
proposal?

Ted

Re: finder.el UI

[Juri Linkov]

>>> I tried it and it's a browser that deadends at the commentary.  Wouldn't
>>> it make sense to at least let the user browse the original package
>>> sources?  But this is still much better than the old finder and I would
>>> get rid of the old one.  But you mention another finder:
>
> SM> Indeed, maybe we should move finder.el to lisp/obsolete?
>
> Works for me.  But Juri's `finder' looks better than `info-finder' so
> perhaps `info-finder' can be folded into it.

You are comparing apples and oranges.  `info-finder' is an Info manual
useful to browse a list of keywords.  My `finder' is a part of separate
package with different goals.  I referred to it only to show you an example
how UI of package.el could look.

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

Re: finder.el UI

[Ted Zlatanov]

On Mon, 22 Mar 2010 17:08:27 +0200 Juri Linkov <juri@jurta.org> wrote: 

>>>> I tried it and it's a browser that deadends at the commentary.  Wouldn't
>>>> it make sense to at least let the user browse the original package
>>>> sources?  But this is still much better than the old finder and I would
>>>> get rid of the old one.  But you mention another finder:
>> 
SM> Indeed, maybe we should move finder.el to lisp/obsolete?
>> 
>> Works for me.  But Juri's `finder' looks better than `info-finder' so
>> perhaps `info-finder' can be folded into it.

JL> You are comparing apples and oranges.  `info-finder' is an Info manual
JL> useful to browse a list of keywords.  My `finder' is a part of separate
JL> package with different goals.  I referred to it only to show you an example
JL> how UI of package.el could look.

Sorry I misunderstood your intent.

JL> Besides the old Finder UI, finder.el also contains code that
JL> collects keywords and generates finder-inf.el with keyword data
JL> that is used by other interfaces.

I think that's:

finder-compile-keywords-make-dist
finder-compile-keywords
finder-commentary

plus the initialization code and variables.

So the rest: interactive functions, support and the mode support
(keymaps, summary, etc.) could be removed safely, or maybe moved to
lisp/obsolete/finder-old.el.

JL> I think package.el should have its own UI designed for its
JL> requirements.

All right.  Thank you for explaining.

Ted

Re: finder.el UI

[Stefan Monnier]

SM> All packages bundled with Emacs (i.e. all those found by finder.el) are
SM> already installed and activated.

> I thought it would make sense to link what package.el will manage into
> finder.el and other Emacs facilities, so this would no longer be true.
> finder.el would show (clearly marked regarding their state and repo
> origin) available, installed, and activated packages; there would also
> be a way from there to install and activate a package, either internally
> or through a link to the package.el UI.  Do you disagree with that
> proposal?

I'm not opposed to it, but just pointing out that currently they do
things that are quite different, since finder.el lets you find things
among the installed&activated packages, whereas package.el lets you find
things among the nonactivated&noninstalled packages and lets you
activate&|install them.

AFAIK the urgent thing is to add the ability to install several version
of a package and then separately to choose which one to activate in
a given session.
And then to install package.el (the paperwork from other contributors
can even come later since those contributions aren't needed for those
features anyway).


        Stefan

Re: finder.el UI

[Ted Zlatanov]

On Mon, 22 Mar 2010 12:09:36 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> All packages bundled with Emacs (i.e. all those found by finder.el) are
SM> already installed and activated.

>> I thought it would make sense to link what package.el will manage into
>> finder.el and other Emacs facilities, so this would no longer be true.
>> finder.el would show (clearly marked regarding their state and repo
>> origin) available, installed, and activated packages; there would also
>> be a way from there to install and activate a package, either internally
>> or through a link to the package.el UI.  Do you disagree with that
>> proposal?

SM> I'm not opposed to it, but just pointing out that currently they do
SM> things that are quite different, since finder.el lets you find things
SM> among the installed&activated packages, whereas package.el lets you find
SM> things among the nonactivated&noninstalled packages and lets you
SM> activate&|install them.

OK.  I'll delay this discussion until package.el is integrated.

SM> AFAIK the urgent thing is to add the ability to install several version
SM> of a package and then separately to choose which one to activate in
SM> a given session.
SM> And then to install package.el (the paperwork from other contributors
SM> can even come later since those contributions aren't needed for those
SM> features anyway).

I'll start on that work in my free time.

Ted

Re: finder.el UI

[Juri Linkov]

>> I tried it and it's a browser that deadends at the commentary.  Wouldn't
>> it make sense to at least let the user browse the original package
>> sources?  But this is still much better than the old finder and I would
>> get rid of the old one.  But you mention another finder:
>
> Indeed, maybe we should move finder.el to lisp/obsolete?

Besides the old Finder UI, finder.el also contains code that
collects keywords and generates finder-inf.el with keyword data
that is used by other interfaces.

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

RE: finder.el UI

[Drew Adams]

> Indeed, maybe we should move finder.el to lisp/obsolete?

I don't have the time now to follow this thread. I would just like to say that
I, for one, do use some finder.el features. If those become available only in
some other form then I will try to adjust my code to that form. But I would not
like to see them disappear altogether.

In particular, I use `finder-commentary'. I use it, for example, to add a button
to *Help* buffer content (e.g. `C-h m') that opens the corresponding Commentary
section in Finder mode. Here is a typical example:

(define-button-type 'bookmarkp-commentary-button
  :supertype 'help-xref
  'help-function #'(lambda ()
                     (finder-commentary "bookmark+"))
  'help-echo "mouse-2, RET: Bookmark+ documentation")

...

(help-insert-xref-button "[Doc]" 'bookmarkp-commentary-button)

Re: finder.el UI

[Juri Linkov]

> I tried it and it's a browser that deadends at the commentary.  Wouldn't
> it make sense to at least let the user browse the original package
> sources?  But this is still much better than the old finder and I would
> get rid of the old one.

It is possible to implement Info links to source code like
links to http are already implemented.

There is also a related task in etc/TODO:

  ** In Emacs Info, examples of using Customize should be clickable
     and they should create Custom buffers.

These should be another type of Info links to Custom buffers.

> JL> Please note that I don't propose to use this package as is
> JL> in package.el.  I'm referring to its UI that would be useful
> JL> for package.el.
>
> So I'm a little confused.  Is the jurta.org finder proposed for Emacs
> inclusion?  Or is info-finder the way to go?

No, it's not proposed for Emacs inclusion.

> Either way, users who look for packages also like to install and
> activate them, so IMHO it makes sense that all the finder UIs should
> link to package.el installation+activation somehow, either internally by
> calling package.el functions or externally by launching package.el, when
> it's part of Emacs.

I think package.el should have its own UI designed for its requirements.

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

Customize UI (was: Emacs-23 release branch)

[Juri Linkov]

> * Improving the Customize user interface (I have some working in this
>   area that I'm going to commit soon).

I propose more improvements for the Customize user interface:

** Move sub-group links to the top of the Customize buffer.
   This will make the group tree navigation much easier.
   Most file browsers do the same: they put links to subdirectories
   before links to files (in Customize, options are analogous to files,
   and groups - to directories).

  So UI would look like:
  _____________________________________________________
  Parent groups: Environment Files
  Subgroups:
    Dired Faces : Faces used by Dired.
    Dired Mark : Handling marks in Dired.
    Dired X : Extended directory editing (dired-x).
    Find Dired : Run a `find' command and dired the output.
    Ls Lisp : Emulate the ls program completely in Emacs Lisp.
    Wdired : Mode to rename files by editing their names in dired buffers.
  _____________________________________________________
  Dired group: Directory editing.
        State: visible group members are all at standard values.

  Directory Free Space Args
     Options to use when running `directory-free-space-program'.

  Directory Free Space Program
     Program to get the amount of free space on a file system. More

  [more options...]

** Implement Info-like navigation, so `t' will go to the Top
   of the group tree, `l' will go to the previous Customize buffer
   (`u' already goes Up like in Info).

** There are "floating mountains" - groups that can't be reached from the Top.
   There should be a way to find all such groups, and now I accidentally
   found one such group `mime' (but its related groups `mime-display' and
   `mime-security' are ok - they have the parent `mail').

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

Re: Customize UI

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> ** Move sub-group links to the top of the Customize buffer.
>    This will make the group tree navigation much easier.
>    Most file browsers do the same: they put links to subdirectories
>    before links to files (in Customize, options are analogous to files,
>    and groups - to directories).

This is only reasonable if the list of sub-groups is sufficiently small
that they don't push the actual options off the screen.  I don't know
the degree to which this is possible in typical customize groups.

[Note this is a problem with mac/windows-style file dialogs too -- it
can be very annoying when you want to open a file in a directory with
only a few files, but lots of subdirectories, and the files are pushed
way to the bottom....]

-Miles

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

Re: Customize UI

[Juri Linkov]

>> ** Move sub-group links to the top of the Customize buffer.
>>    This will make the group tree navigation much easier.
>>    Most file browsers do the same: they put links to subdirectories
>>    before links to files (in Customize, options are analogous to files,
>>    and groups - to directories).
>
> This is only reasonable if the list of sub-groups is sufficiently small
> that they don't push the actual options off the screen.  I don't know
> the degree to which this is possible in typical customize groups.

The same problem exists now when a large list of options pushes links to
sub-groups off the screen.  This can be resolved by creating a sub-group
and moving such options to the new sub-group, so only links to sub-groups
will remain in the group.

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

Re: Customize UI

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> This is only reasonable if the list of sub-groups is sufficiently small
>> that they don't push the actual options off the screen.  I don't know
>> the degree to which this is possible in typical customize groups.
>
> The same problem exists now when a large list of options pushes links to
> sub-groups off the screen.  This can be resolved by creating a sub-group
> and moving such options to the new sub-group, so only links to sub-groups
> will remain in the group.

Ergh, that sounds _extremely_ annoying...

Note, I'm not saying groups first is _bad_ per-se, just that it has to
be done carefully.  [Sadly, many GUI file browsers seem to do it very
badly... :( ]

For instance, the way "C-h m" presents the list of minor modes, with a
fairly compressed list of obvious links that precedes the major-mode
info, so it all fits on a few lines, seems pretty good.

-Miles

-- 
Innards, n. pl. The stomach, heart, soul, and other bowels.

Re: Customize UI

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> ** Move sub-group links to the top of the Customize buffer.
>    This will make the group tree navigation much easier.
>    Most file browsers do the same: they put links to subdirectories
>    before links to files (in Customize, options are analogous to files,
>    and groups - to directories).

`custom-browse-order-groups' does this, BTW.  I have no objections to
changing the default to `first'.

Re: Customize UI

[Lennart Borgman]

On Mon, Mar 15, 2010 at 6:17 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Juri Linkov <juri@jurta.org> writes:
>
>> ** Move sub-group links to the top of the Customize buffer.
>>    This will make the group tree navigation much easier.
>>    Most file browsers do the same: they put links to subdirectories
>>    before links to files (in Customize, options are analogous to files,
>>    and groups - to directories).
>
> `custom-browse-order-groups' does this, BTW.  I have no objections to
> changing the default to `first'.


I agree with Juri that the groups should be first. They tend to be few
and also takes up less space than options. They are also quite
important.

Re: Customize UI

[Juri Linkov]

>> ** Move sub-group links to the top of the Customize buffer.
>>    This will make the group tree navigation much easier.
>>    Most file browsers do the same: they put links to subdirectories
>>    before links to files (in Customize, options are analogous to files,
>>    and groups - to directories).
>
> `custom-browse-order-groups' does this, BTW.  I have no objections to
> changing the default to `first'.

I see there are three related options:

(defcustom custom-browse-order-groups nil
(defcustom custom-buffer-order-groups 'last
(defcustom custom-menu-order-groups 'first

After setting `custom-buffer-order-groups' to `first', some groups
push the options off the screen.  To make a list of links to sub-groups
to occupy less lines, maybe we should remove empty lines between
sub-group links when `custom-buffer-order-groups' is `first'?

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

Re: Customize UI

[Ted Zlatanov]

On Sun, 14 Mar 2010 23:34:35 +0200 Juri Linkov <juri@jurta.org> wrote: 

>> * Improving the Customize user interface (I have some working in this
>> area that I'm going to commit soon).

JL> I propose more improvements for the Customize user interface:

JL> ** Move sub-group links to the top of the Customize buffer.
JL>    This will make the group tree navigation much easier.
JL>    Most file browsers do the same: they put links to subdirectories
JL>    before links to files (in Customize, options are analogous to files,
JL>    and groups - to directories).

JL>   So UI would look like:
JL>   _____________________________________________________
JL>   Parent groups: Environment Files
JL>   Subgroups:
JL>     Dired Faces : Faces used by Dired.
JL>     Dired Mark : Handling marks in Dired.
JL>     Dired X : Extended directory editing (dired-x).
JL>     Find Dired : Run a `find' command and dired the output.
JL>     Ls Lisp : Emulate the ls program completely in Emacs Lisp.
JL>     Wdired : Mode to rename files by editing their names in dired buffers.
JL>   _____________________________________________________
JL>   Dired group: Directory editing.
JL>         State: visible group members are all at standard values.

JL>   Directory Free Space Args
JL>      Options to use when running `directory-free-space-program'.

JL>   Directory Free Space Program
JL>      Program to get the amount of free space on a file system. More

JL>   [more options...]

I like the goal (immediate visibility of the available subgroups), but
would suggest that instead of putting them first in a vertical list,
perhaps they could be arranged horizontally (wrapped as needed) by
default.  The `t' key, for instance, could toggle between a horizontal
and a vertical list; that way the user can see the details or hide them
as needed.  In a 80x25 terminal that would make a big difference to
usability, as others have mentioned.

A smaller font (80% of normal) could also be appropriate, and a
graphical indicator stamping each subgroup would be nice.

Ted

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 09 Mar 2010 21:22:53 -0500
> 
> I have just cut the release branch for Emacs-23.2.  It's at:
> 
>    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23

Thanks.

It would be good if someone could post a recipe for a cheap creation
of such a branch on a machine where there's already a bound branch for
the trunk.  I hope a full-blown "bzr checkout" is not necessary, but
rather some sequence of "bzr branch"+"bzr bind"+"bzr up" or something.

Or is this a pipe dream?

Re: Emacs-23 release branch

[Sven Joachim]

On 2010-03-10 18:21 +0100, Eli Zaretskii wrote:

> It would be good if someone could post a recipe for a cheap creation
> of such a branch on a machine where there's already a bound branch for
> the trunk.  I hope a full-blown "bzr checkout" is not necessary, but
> rather some sequence of "bzr branch"+"bzr bind"+"bzr up" or something.

If you have set up a shared repository as recommended, it's just

bzr branch --bind sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23 emacs-23

This will only fetch the revisions that are not already in the local
repository (i.e. currently none if your copy of the trunk is up to
date).

Sven

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Sven Joachim <svenjoac@gmx.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Wed, 10 Mar 2010 18:48:55 +0100
> 
> On 2010-03-10 18:21 +0100, Eli Zaretskii wrote:
> 
> > It would be good if someone could post a recipe for a cheap creation
> > of such a branch on a machine where there's already a bound branch for
> > the trunk.  I hope a full-blown "bzr checkout" is not necessary, but
> > rather some sequence of "bzr branch"+"bzr bind"+"bzr up" or something.
> 
> If you have set up a shared repository as recommended, it's just
> 
> bzr branch --bind sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23 emacs-23
> 
> This will only fetch the revisions that are not already in the local
> repository (i.e. currently none if your copy of the trunk is up to
> date).

Thanks, that will save a lot of bandwidth.

Re: Emacs-23 release branch

[Chad Brown]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

On Mar 10, 2010, at 9:48 AM, Sven Joachim wrote:

> bzr branch --bind sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23 emacs-23

bzr: ERROR: no such option: --bind
Exit 3

Is there some extra package that I need to install?

Thanks in advance,
*Chad

[-- Attachment #2: Type: text/html, Size: 1255 bytes --]

Re: Emacs-23 release branch

[Óscar Fuentes]

Chad Brown <yandros@MIT.EDU> writes:

>> bzr branch --bind sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23 emacs-23
>
> bzr: ERROR: no such option: --bind
> Exit 3
>
> Is there some extra package that I need to install?

You probably have an old version of bzr. Try

bzr branch sftp://<yourusername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23 emacs-23
cd emacs-23
bzr bind sftp://<yourusername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23

Re: Emacs-23 release branch

[Chad Brown]

> You probably have an old version of bzr. Try

Indeed; I had missed an update (from 2.0.2 to 2.1.0).  I should have checked this first myself.

Thanks again,
*Chad

Re: Emacs-23 release branch

[Sven Joachim]

On 2010-03-10 20:30 +0100, Chad Brown wrote:

> On Mar 10, 2010, at 9:48 AM, Sven Joachim wrote:
>
>> bzr branch --bind sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23 emacs-23
>
> bzr: ERROR: no such option: --bind
> Exit 3

Ah, I see.  The --bind option is only available since bzr 2.1.0rc1.

> Is there some extra package that I need to install?

No, with older bzr versions you use

bzr branch … emacs-23
cd emacs-23
bzr bind …

where … is the location of the upstream branch,
i.e. http://bzr.savannah.gnu.org/r/emacs/emacs-23 for anonymous access.

Sven

Re: Emacs-23 release branch

[Stefan Monnier]

> bzr branch … emacs-23
> cd emacs-23
> bzr bind …

AKA  bzr co … emacs-23


        Stefan

Re: Emacs-23 release branch

[Sven Joachim]

On 2010-03-11 04:16 +0100, Stefan Monnier wrote:

>> bzr branch … emacs-23
>> cd emacs-23
>> bzr bind …
>
> AKA  bzr co … emacs-23

Well, almost.  "bzr co" does not set the parent location, which makes a
difference if you run "bzr pull" later.  However,

bzr co … emacs-23
cd emacs-23
bzr pull …

seems to be fully equivalent.  Is it just me who finds this rather
confusing?

Sven

Re: Emacs-23 release branch

[Óscar Fuentes]

Sven Joachim <svenjoac@gmx.de> writes:

>>> bzr branch … emacs-23
>>> cd emacs-23
>>> bzr bind …
>>
>> AKA  bzr co … emacs-23
>
> Well, almost.  "bzr co" does not set the parent location, which makes a
> difference if you run "bzr pull" later.  However,
>
> bzr co … emacs-23
> cd emacs-23
> bzr pull …
>
> seems to be fully equivalent.  Is it just me who finds this rather
> confusing?

bzr developers thinks that is a minor bug that `pull' works on
checkouts.

Re: Emacs-23 release branch

[Stefan Monnier]

>>> bzr branch … emacs-23
>>> cd emacs-23
>>> bzr bind …
>> AKA  bzr co … emacs-23
> Well, almost.  "bzr co" does not set the parent location, which makes a
> difference if you run "bzr pull" later.  However,

IIUC the use of "pull" in this way is not encouraged.
Use "bzr update" instead.


        Stefan

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 09 Mar 2010 21:22:53 -0500
> 
> I have just cut the release branch for Emacs-23.2.  It's at:
> 
>    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23

Are there any bzr commands to show what revision on the (remote) trunk
was the parent of this branch?

Re: Emacs-23 release branch

[Eli Zaretskii]

> Date: Wed, 10 Mar 2010 19:48:57 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Tue, 09 Mar 2010 21:22:53 -0500
> > 
> > I have just cut the release branch for Emacs-23.2.  It's at:
> > 
> >    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
> 
> Are there any bzr commands to show what revision on the (remote) trunk
> was the parent of this branch?

In case it wasn't clear, I meant _without_ checking out the branch.

TIA

Re: Emacs-23 release branch

[Stefan Monnier]

>> > I have just cut the release branch for Emacs-23.2.  It's at:
>> >    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
>> Are there any bzr commands to show what revision on the (remote) trunk
>> was the parent of this branch?
> In case it wasn't clear, I meant _without_ checking out the branch.

Not sure about "without checking out the branch", but I don't think
that's a big issue anyway.

As for the question _with_ checking out the branch, there are various
tools that allow you to display the DAG and hence let you see the split
and merge points between emacs-23 and trunk.

I have never needed this kind of info, so I don't know the
specifics, OTOH.  Why do you ask?


        Stefan

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 10 Mar 2010 14:31:39 -0500
> 
> Why do you ask?

Because I didn't see any record of the branch in the ChangeLog, so I
wondered how to know when the branch was cut.  With CVS, we used to
have a tag at the branch point.

Re: Emacs-23 release branch

[Stefan Monnier]

>> Why do you ask?
> Because I didn't see any record of the branch in the ChangeLog, so I
> wondered how to know when the branch was cut.  With CVS, we used to
> have a tag at the branch point.

Yes, under CVS this is needed in order to keep track of merge.
Bzr automatically tracks this info for us, so we don't need it.


        Stefan

Re: Emacs-23 release branch

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I have just cut the release branch for Emacs-23.2.  It's at:
>> > 
>> >    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
>> 
>> Are there any bzr commands to show what revision on the (remote) trunk
>> was the parent of this branch?
>
> In case it wasn't clear, I meant _without_ checking out the branch.

I think your best bet is 

bzr missing --mine-only sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23

However, as we are using the dumb http/sftp server, there is no
guarantee that the amount of data needed for the operation above is
significantly less than the data needed for checking out the emacs-23
branch.

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Mar 2010 20:44:43 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Are there any bzr commands to show what revision on the (remote) trunk
> >> was the parent of this branch?
> >
> > In case it wasn't clear, I meant _without_ checking out the branch.
> 
> I think your best bet is 
> 
> bzr missing --mine-only sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23

Doesn't seem to work:

  eliz@fencepost:~/bzr/emacs/trunk$ bzr missing --mine-only sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23
  This branch is up to date.

Can't "bzr log" help here?  It should show branches, right?

> However, as we are using the dumb http/sftp server, there is no
> guarantee that the amount of data needed for the operation above is
> significantly less than the data needed for checking out the emacs-23
> branch.

I don't want to check-out every branch whose branch point I'd like to
know.

Re: Emacs-23 release branch

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Are there any bzr commands to show what revision on the (remote) trunk
>> >> was the parent of this branch?
>> >
>> > In case it wasn't clear, I meant _without_ checking out the branch.
>> 
>> I think your best bet is 
>> 
>> bzr missing --mine-only sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
>
> Doesn't seem to work:
>
>   eliz@fencepost:~/bzr/emacs/trunk$ bzr missing --mine-only sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23
>   This branch is up to date.

Did you `bzr update' your local mirror first? Maybe `bzr missing' does
not work with bound branches.

My trunk mirror is not bound, and after a `bzr pull' the `bzr missing'
method above shows that the oldest revision that the emacs-23 branch is
missing is

revno: 99635 [merge]
committer: Stefan Monnier <monnier@iro.umontreal.ca>
branch nick: trunk
timestamp: Wed 2010-03-10 00:18:51 -0500
message:
  Merge pending branch

which means that the branch was created from revision 99634.

> Can't "bzr log" help here?  It should show branches, right?

No. Branching is copying the full history. You get a clone of the
original branch (actually, there is a `clone' bzr command that is
synonymous of `branch') The original branch does not reflect that a
clone was spawned, nor the cloned branch remembers the tip revision.

>> However, as we are using the dumb http/sftp server, there is no
>> guarantee that the amount of data needed for the operation above is
>> significantly less than the data needed for checking out the emacs-23
>> branch.
>
> I don't want to check-out every branch whose branch point I'd like to
> know.

That's reasonable.

Re: Emacs-23 release branch

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Mar 2010 23:19:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >> Are there any bzr commands to show what revision on the (remote) trunk
> >> >> was the parent of this branch?
> >> >
> >> > In case it wasn't clear, I meant _without_ checking out the branch.
> >> 
> >> I think your best bet is 
> >> 
> >> bzr missing --mine-only sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
> >
> > Doesn't seem to work:
> >
> >   eliz@fencepost:~/bzr/emacs/trunk$ bzr missing --mine-only sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23
> >   This branch is up to date.
> 
> Did you `bzr update' your local mirror first?

No.  Why should I?

> Maybe `bzr missing' does not work with bound branches.

It does work.  Just "bzr missing" in the trunk shows me the few
revisions I don't have, which had been added to the repository since
my last update.

> My trunk mirror is not bound, and after a `bzr pull' the `bzr missing'
> method above shows that the oldest revision that the emacs-23 branch is
> missing is
> 
> revno: 99635 [merge]
> committer: Stefan Monnier <monnier@iro.umontreal.ca>
> branch nick: trunk
> timestamp: Wed 2010-03-10 00:18:51 -0500
> message:
>   Merge pending branch
> 
> which means that the branch was created from revision 99634.

I hoped for a more direct evidence, something like the way "bzr log"
shows branches and merges.

> > Can't "bzr log" help here?  It should show branches, right?
> 
> No. Branching is copying the full history. You get a clone of the
> original branch (actually, there is a `clone' bzr command that is
> synonymous of `branch') The original branch does not reflect that a
> clone was spawned, nor the cloned branch remembers the tip revision.

There's probably something I miss here: "bzr log -n0" does show, for
all the merged branches, both their branch point and their merge
point.  And if that's not enough, the major revno number in the X.Y.Z
revno notation is precisely the number of the revision that is the
parent of the branch.  Here's an example:

  99599: Kenichi Handa 2010-03-02 [merge] Fix handling of the multibyte form...
    99322.1.39: Kenichi Handa 2010-03-02 [merge] from trunk
    99322.1.38: Kenichi Handa 2010-03-02 Fix handling of the multibyte form ...
  99598: Glenn Morris 2010-03-01 Small tweaks to etc/refcards/Makefile rules...

99322 is the revno from which Handa-san made his quickfixes branch.

Re: Emacs-23 release branch

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Doesn't seem to work:
>> >
>> >   eliz@fencepost:~/bzr/emacs/trunk$ bzr missing --mine-only sftp://eliz@bzr.savannah.gnu.org/srv/bzr/emacs/emacs-23
>> >   This branch is up to date.
>> 
>> Did you `bzr update' your local mirror first?
>
> No.  Why should I?

`bzr missing' shows the differences among two branches. If one of the
branches is not up to date, you'll get old results.

[snip]

>> which means that the branch was created from revision 99634.
>
> I hoped for a more direct evidence, something like the way "bzr log"
> shows branches and merges.

`bzr log' shows branch points only for merged history.

[snip]

Re: Emacs-23 release branch

[Stefan Monnier]

>> No. Branching is copying the full history. You get a clone of the
>> original branch (actually, there is a `clone' bzr command that is
>> synonymous of `branch') The original branch does not reflect that a
>> clone was spawned, nor the cloned branch remembers the tip revision.

> There's probably something I miss here: "bzr log -n0" does show, for
> all the merged branches, both their branch point and their merge
> point.

Yes.  But that info is only present for merged branches.  When you make
a branch, the parent branch is unchanged and the new branch is identical
to the parent branch, so neither explicitly keeps track of the "branch
point".  But by comparing the two branches's history, Bzr can easily
figure out the branch point when it needs it.


        Stefan