Looking for a new Emacs maintainer or team

Looking for a new Emacs maintainer or team

[Richard Stallman]

Once Emacs 22 is released, I would like to hand over Emacs maintenance
to one person or a small team.  The new maintainer or maintainers
would take responsibility for making sure new releases are made and
that they are reliable, and for focusing attention on priority
projects for improvement.

Please write to me if you would like to offer to be the maintainer or
to be one of a team.

Re: Looking for a new Emacs maintainer or team

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Once Emacs 22 is released, I would like to hand over Emacs maintenance
  > to one person or a small team.  The new maintainer or maintainers
  > would take responsibility for making sure new releases are made and
  > that they are reliable, and for focusing attention on priority
  > projects for improvement.

Is this still the plan?  Last time this was discussed on the list many
very capable volunteers were found.

Wouldn't it be better for Emacs to do this sooner rather than later?

Is there anything that the Emacs contributors can do to help this
process? (Other than put in on their 2008 wishlists :-)

Thanks.

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

      > Once Emacs 22 is released, I would like to hand over Emacs maintenance
      > to one person or a small team.  The new maintainer or maintainers
      > would take responsibility for making sure new releases are made and
      > that they are reliable, and for focusing attention on priority
      > projects for improvement.

    Is this still the plan?  Last time this was discussed on the list many
    very capable volunteers were found.

A few people volunteered, and they could be useful members of a team,
but (as I recall) they didn't include the most knowledgeable people.

Re: Looking for a new Emacs maintainer or team

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >       > Once Emacs 22 is released, I would like to hand over Emacs maintenance
  >       > to one person or a small team.  The new maintainer or maintainers
  >       > would take responsibility for making sure new releases are made and
  >       > that they are reliable, and for focusing attention on priority
  >       > projects for improvement.
  > 
  >     Is this still the plan?  Last time this was discussed on the list many
  >     very capable volunteers were found.
  > 
  > A few people volunteered, and they could be useful members of a team,
  > but (as I recall) they didn't include the most knowledgeable people.

OK, if this is the cause of the blockage, then let's work on what your
criteria would be for choosing the maintainer(s).


One proposal was to have a committee with 3 people:

- a "technical lead" which is responsible for the "quality" of the
  major modifications to the software (i.e. C and Lisp code).

- a "release manager" which is responsible for the release, including
  documentation, copyright stuff, packaging, etc  (basically anything
  else)

- a "chairman" (the third person) who has the "final word" on any
  disputes in the committee, based on an overall understanding of
  Emacs "policies, history and visions" (whatever they are)...

And there were volunteers for these positions: Kenichi Handa, Chong
Yidong and Stefan Monnier.

If you'd like more people on the committee, why not just nominate them
and maybe they will accept?

Re: Looking for a new Emacs maintainer or team

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 3036 bytes --]

On Mon, 31 Dec 2007 15:22:53 -0800
Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
>   >       > Once Emacs 22 is released, I would like to hand over
>   >       > Emacs maintenance to one person or a small team.  The new
>   >       > maintainer or maintainers would take responsibility for
>   >       > making sure new releases are made and that they are
>   >       > reliable, and for focusing attention on priority projects
>   >       > for improvement.
>   > 
>   >     Is this still the plan?  Last time this was discussed on the
>   > list many very capable volunteers were found.
>   > 
>   > A few people volunteered, and they could be useful members of a
>   > team, but (as I recall) they didn't include the most
>   > knowledgeable people.
> 
> OK, if this is the cause of the blockage, then let's work on what your
> criteria would be for choosing the maintainer(s).
> 
> 
> One proposal was to have a committee with 3 people:
> 
> - a "technical lead" which is responsible for the "quality" of the
>   major modifications to the software (i.e. C and Lisp code).
> 
> - a "release manager" which is responsible for the release, including
>   documentation, copyright stuff, packaging, etc  (basically anything
>   else)
> 
> - a "chairman" (the third person) who has the "final word" on any
>   disputes in the committee, based on an overall understanding of
>   Emacs "policies, history and visions" (whatever they are)...

I don't think that is a very good description of a chairman. A chairman
arbitrates procedure and typically does not vote. With your triad
you cannot even reach a quorum without the chairman.

Creating a political structure is non-trivial with many subtle pitfalls.
Programmers are not automatically skilled at this simply because they
work with complex systems.

Most of the politically structured projects I have read, or participated
in functioned more like an Asperger's convention than a decision making
process.

I think a benevolent dictator who can interact with people according
to social norms is key for a project, especially when the profession
is considered a haven for High Functioning Autism and a variety of
other handicaps.

A leader should be able to understand the people he leads, where their
strengths can be used, and how to avoid the certain pitfalls inherent
in every personality. If a committee helps then it's a good thing. 

The one certainty of this thread is that it will grow like cancer until
the constitutionalists form a separate mailing list.

Just stating the obvious from the back row.

> And there were volunteers for these positions: Kenichi Handa, Chong
> Yidong and Stefan Monnier.
> 
> If you'd like more people on the committee, why not just nominate them
> and maybe they will accept?
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Looking for a new Emacs maintainer or team

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> A few people volunteered, and they could be useful members of a team,
> but (as I recall) they didn't include the most knowledgeable people.

Stefan volunteered, and he's extremely knowledgeable about Emacs, and
about software in general (as well as having a generally easy-going
temperment, which is good for a maintainer).

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

    Stefan volunteered, and he's extremely knowledgeable about Emacs, and
    about software in general (as well as having a generally easy-going
    temperment, which is good for a maintainer).

Indeed, Stefan is quite knowledgeable.
I didn't remember Stefan had volunteered.

I will talk with Stefan and Yidong and Handa about this.

Re: Looking for a new Emacs maintainer or team

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Stefan volunteered, and he's extremely knowledgeable about Emacs, and
  >     about software in general (as well as having a generally easy-going
  >     temperment, which is good for a maintainer).
  > 
  > Indeed, Stefan is quite knowledgeable.
  > I didn't remember Stefan had volunteered.
  > 
  > I will talk with Stefan and Yidong and Handa about this.

Is there anything happening about this? Many of us would like to know... 

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

Stefan and Yidong offered to take over, so I am willing to hand
over Emacs development to them.

Re: Looking for a new Emacs maintainer or team

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Stefan and Yidong offered to take over, so I am willing to hand
  > over Emacs development to them.

Thank you for the many years in service!

Congratulation Stefan and Chong!

Re: Looking for a new Emacs maintainer or team

[Mike Mattie]

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

On Fri, 22 Feb 2008 15:08:24 -0800
Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
>   > Stefan and Yidong offered to take over, so I am willing to hand
>   > over Emacs development to them.
> 
> Thank you for the many years in service!
> 
> Congratulation Stefan and Chong!
> 
> 

Emacs is one for the history books. Congratulations, RMS, if it is not premature.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Looking for a new Emacs maintainer or team

[David Kastrup]

Mike Mattie <codermattie@gmail.com> writes:

> On Fri, 22 Feb 2008 15:08:24 -0800
> Dan Nicolaescu <dann@ics.uci.edu> wrote:
>
>> Richard Stallman <rms@gnu.org> writes:
>> 
>>   > Stefan and Yidong offered to take over, so I am willing to hand
>>   > over Emacs development to them.
>> 
>> Thank you for the many years in service!
>> 
>> Congratulation Stefan and Chong!
>> 
>
> Emacs is one for the history books. Congratulations, RMS, if it is not
> premature.

It is.  The revolution goes on.  Now that Fidel Castro has retired,
Emacs has the chance to develop into the longest ruling entity ever.  Of
course, it is the longest ruling editor already.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Looking for a new Emacs maintainer or team

[Paul Michael Reilly]

Richard Stallman wrote:
> Stefan and Yidong offered to take over, so I am willing to hand
> over Emacs development to them.
> 

Wow!  That has to be one of the most understated email messages I've 
seen in ~30 years of receiving email, most of it using Rmail.

I'll echo Dan's congratulations to Stefan and Yidong.  Best of luck to you.

And for all that Emacs has meant to me, I still owe you an unmeasurable 
debt for your contributions Richard, which I look forward to seeing 
continued in other arenas.  Thank you so much.

-pmr

Re: Looking for a new Emacs maintainer or team

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Stefan and Yidong offered to take over, so I am willing to hand
> over Emacs development to them.

I have been recently blessed with a write access to Emacs CVS.

I only hope that your decision to hand over Emacs development has
nothing to do with this.

-- 
Bastien

Re: Looking for a new Emacs maintainer or team

[Juanma Barranquero]

>  Wow!  That has to be one of the most understated email messages I've
>  seen in ~30 years of receiving email, most of it using Rmail.

I suppose some sort of official announcement will be released sooner or later...

             Juanma

Re: Looking for a new Emacs maintainer or team

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>>  Wow!  That has to be one of the most understated email messages I've
>>  seen in ~30 years of receiving email, most of it using Rmail.
>
> I suppose some sort of official announcement will be released sooner
> or later...

Well, there is hardly a place where "released sooner or later" sounds
more ominous than the Emacs developer list.

But great news, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Looking for a new Emacs maintainer or team

[Juanma Barranquero]

On Sat, Feb 23, 2008 at 3:33 PM, David Kastrup <dak@gnu.org> wrote:

>  Well, there is hardly a place where "released sooner or later" sounds
>  more ominous than the Emacs developer list.

The community of NetHack fans.

3.4.3 -- 2003-12-08  (last minor release, now more than four years ago)
3.4.2 -- 2003-08-11
3.4.1 -- 2003-02-23
3.4.0 -- 2002-02-20  (last major release)
3.3.0 -- 1999-12-10  (previous major release)

That's a pace similar to Emacs development, with the added drawback
that NetHack development is not done in the open; the DevTeam
maintains absolute silence (there's no public repository, or mailing
list), and suddenly, a new release springs fully formed, like Athena
from Zeus' forehead.

>  But great news, anyway.

Yeah. Congrats to Stefan and Yidong, of course.

             Juanma

Re: Looking for a new Emacs maintainer or team

[Jay Belanger]

Bastien <bzg@altern.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Stefan and Yidong offered to take over, so I am willing to hand
>> over Emacs development to them.
>
> I have been recently blessed with a write access to Emacs CVS.
>
> I only hope that your decision to hand over Emacs development has
> nothing to do with this.

Probably not, but you might wonder about the upcoming switch to use bzr
for Emacs.

Jay

Re: Looking for a new Emacs maintainer or team

[Vijay Rao]

I suppose I am not alone in experiencing this.Work is a joy because of  
emacs.

After 15 years of so-called 'on the job training' and apprenticeship,  
I discovered the Emacs editor, and my journey began all over again.
Congratulations and gratitude are due to the people who are associated  
with emacs development.


Vijay Rao.

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

This is the fourth time that the Maintainer of GNU Emacs has been
someone other than me.  Previous maintainers include Joe Arceneaux,
Jim Blandy, and Gerd Moellmann.

Re: Looking for a new Emacs maintainer or team

[T. V. Raman]

1+ on all counts.

Richard, please accept my thanks for Emacs --- life wouldn't be
the same without it.

>>>>> "Paul" == Paul Michael Reilly <pmr@pajato.com> writes:
    Paul> Richard Stallman wrote:
    >> Stefan and Yidong offered to take over, so I am willing to
    >> hand over Emacs development to them.
    >> 
    Paul> 
Wow!  That has to be one of the most understated email messages
    Paul> I've seen in ~30 years of receiving email, most of it
    Paul> using Rmail.
    Paul> 
    Paul> I'll echo Dan's congratulations to Stefan and Yidong.
    Paul> Best of luck to you.
    Paul> 
    Paul> And for all that Emacs has meant to me, I still owe you
    Paul> an unmeasurable debt for your contributions Richard,
    Paul> which I look forward to seeing continued in other
    Paul> arenas.  Thank you so much.
    Paul> 
    Paul> -pmr
    Paul> 
    Paul> 
    Paul> 
    Paul> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

    Wow!  That has to be one of the most understated email messages I've 
    seen in ~30 years of receiving email, most of it using Rmail.

People are writing as if I had announced my final retirement.
This is just a matter of other people maintaining Emacs.

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

    Well, there is hardly a place where "released sooner or later" sounds
    more ominous than the Emacs developer list.

That is a mean thing to say.  Attacks like that make the job the Emacs
maintainer harder.

If you cannot say something constructive, please don't say anything.

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

There is a lot of work to be done on Emacs.  Would you like
to help?

Re: Looking for a new Emacs maintainer or team

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> People are writing as if I had announced my final retirement.
> This is just a matter of other people maintaining Emacs.

There was a somewhat misleading headline posted on reddit.com (a
tabloid-like discussion site), which may account for some of the odd
responses:

   "After 32 years, RMS to step down as GNU Emacs maintainer "
   http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html

-Miles

p.s., no I don't read reddit, I just heard about it ... :-)

-- 
Virtues, n. pl. Certain abstentions.

Re: Looking for a new Emacs maintainer or team

[Xavier Maillard]

   Stefan and Yidong offered to take over, so I am willing to hand
   over Emacs development to them.

What a revolution ! Thank you very much for all you have done on
GNU Emacs and for the free software in general !

Congratulations to our new maintainer team !

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Looking for a new Emacs maintainer or team

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> There was a somewhat misleading headline posted on reddit.com (a
> tabloid-like discussion site), which may account for some of the odd
> responses:
>
>    "After 32 years, RMS to step down as GNU Emacs maintainer "
>    http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html

It's on Slashdot as well.  Not unexpected considering RMS's rock star
status in certain circles... :-)

Re: Looking for a new Emacs maintainer or team

[Paul Michael Reilly]

Richard Stallman wrote:
>     Wow!  That has to be one of the most understated email messages I've 
>     seen in ~30 years of receiving email, most of it using Rmail.
> 
> People are writing as if I had announced my final retirement.
> This is just a matter of other people maintaining Emacs.

I think most people realize that you're not packing in your laptop but 
that your announcement is a chance to say something that otherwise might 
seem out of place, specifically how grateful most of us are for Emacs 
and your many accomplishments.  And a chance to offer up a vote of 
confidence in Stefan and Yidong.

Enjoy,

-pmr

Re: Looking for a new Emacs maintainer or team

[Vijay Rao]

Yes, I would like to help.


On Feb 23, 2008, at 7:54 PM, Richard Stallman wrote:

> There is a lot of work to be done on Emacs.  Would you like
> to help?

Re: Looking for a new Emacs maintainer or team

[Claus]

>  I think most people realize that you're not packing in your laptop but
>  that your announcement is a chance to say something that otherwise might
>  seem out of place, specifically how grateful most of us are for Emacs
>  and your many accomplishments.  And a chance to offer up a vote of
>  confidence in Stefan and Yidong.

Well put, I couldn't have said it better.

I'm just another emacs-user lurking for a chance to say "thank you" to
it's creator and (future) maintainers.

Claus

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

    What a revolution ! Thank you very much for all you have done on
    GNU Emacs and for the free software in general !

The best way to thank us is to join in and help.
You are already doing that -- so thank you, too.

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

    > There is a lot of work to be done on Emacs.  Would you like
    > to help?

How about looking at etc/TODO in the latest sources, and implementing
one of the projects there?

Re: Looking for a new Emacs maintainer or team

[Vijay Rao]

Have looked at the list in etc/TODO.
Will Do.


On Feb 24, 2008, at 6:04 PM, Richard Stallman wrote:

>> There is a lot of work to be done on Emacs.  Would you like
>> to help?
>
> How about looking at etc/TODO in the latest sources, and implementing
> one of the projects there?

TODO [was Re: Looking for a new Emacs maintainer or team]

[Nick Roberts]

 > Have looked at the list in etc/TODO.
 > Will Do.

If you do start working on something in TODO, it is worth posting to this list
to say what it is, in case someone else is doing/plans to do similar stuff.

 > On Feb 24, 2008, at 6:04 PM, Richard Stallman wrote:
 > 
 > >> There is a lot of work to be done on Emacs.  Would you like
 > >> to help?
 > >
 > > How about looking at etc/TODO in the latest sources, and implementing
 > > one of the projects there?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Looking for a new Emacs maintainer or team

[Richard Stallman]

    I'm just another emacs-user lurking for a chance to say "thank you" to
    it's creator and (future) maintainers.

How about thanking us by helping?  You could pick something in
etc/TODO and implement it.

Re: Looking for a new Emacs maintainer or team

[Xavier Maillard]

       Wow!  That has to be one of the most understated email messages I've 
       seen in ~30 years of receiving email, most of it using Rmail.

   People are writing as if I had announced my final retirement.

I hope you won't retire :) We need people like you, we need *you* ;)

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Looking for a new Emacs maintainer or team

[Xavier Maillard]

       What a revolution ! Thank you very much for all you have done on
       GNU Emacs and for the free software in general !

   The best way to thank us is to join in and help.
   You are already doing that -- so thank you, too.

Compared to others, my contributions are rather small but thank
you for your encouragements.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: TODO [was Re: Looking for a new Emacs maintainer or team]

[V.Rao]

Please let me know if anyone is already working on one of these tasks.

** make emacsclient accept -nw as a synonym to -t.

** Replace some uses of the preprocessor code in Makefile.in with the  
equivalent autoconf.

** Make vc-checkin avoid reverting the buffer if has not changed after
    the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be enough.

** Make "emacs --daemon" start emacs without showing any frame.
Use emacsclient later to open frames.







On Sun, 24 Feb 2008 23:45:54 -0500, Nick Roberts <nickrob@snap.net.nz>  
wrote:

>  > Have looked at the list in etc/TODO.
>  > Will Do.
>
> If you do start working on something in TODO, it is worth posting to  
> this list
> to say what it is, in case someone else is doing/plans to do similar  
> stuff.
>
>  > On Feb 24, 2008, at 6:04 PM, Richard Stallman wrote:
>  >
>  > >> There is a lot of work to be done on Emacs.  Would you like
>  > >> to help?
>  > >
>  > > How about looking at etc/TODO in the latest sources, and  
> implementing
>  > > one of the projects there?
>

Re: TODO [was Re: Looking for a new Emacs maintainer or team]

[Dan Nicolaescu]

"V.Rao" <mail.vjrao@yahoo.com> writes:

  > Please let me know if anyone is already working on one of these tasks.
  > 
  > ** make emacsclient accept -nw as a synonym to -t.
  > 
  > ** Replace some uses of the preprocessor code in Makefile.in with the
  > equivalent autoconf.
  > 
  > ** Make "emacs --daemon" start emacs without showing any frame.
  > Use emacsclient later to open frames.

AFAIK nobody has publicly announced that is working on any of these.

Do you have a copyright assignment on file?  If not, it would make sense
to get started on that as soon as possible, so that it is ready by the
time you finish writing the code.


  > ** Make vc-checkin avoid reverting the buffer if has not changed after
  >    the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be enough.

I have a patch for this one.

But it needs a few more eyes on it from people that know the code
involved very well to make sure it is correct and the right thing to do.
The patch itself is not too complicated.

--- vc.el       10 Oct 2007 10:34:53 -0700      1.464
+++ vc.el       11 Oct 2007 12:18:02 -0700      
@@ -1328,7 +1327,19 @@
     (save-excursion
       ;; t means don't call normal-mode;
       ;; that's to preserve various minor modes.
-      (revert-buffer arg no-confirm t))
+      (if (string=
+          (with-temp-buffer
+            ;; Insert the file on disk in a temporary buffer and compute the md5 there.
+            (let ((coding-system-for-read 'binary))
+              (insert-file-contents file)
+              (md5 (current-buffer))))
+          (md5 (current-buffer)))  ;; md5 for the current buffer
+         (let ((writable (file-writable-p (buffer-file-name)))) ;; Try to set the read-only state.
+           (unless (eq buffer-read-only writable)
+             (setq buffer-read-only writable))
+           (message "not reverting"))
+       (message "reverting :-(")
+       (revert-buffer arg no-confirm t)))
     (vc-restore-buffer-context context)))
 
 (defun vc-buffer-sync (&optional not-urgent)

Re: TODO

[Stefan Monnier]

>> Please let me know if anyone is already working on one of these tasks.
>> 
>> ** make emacsclient accept -nw as a synonym to -t.
>> 
>> ** Replace some uses of the preprocessor code in Makefile.in with the
>> equivalent autoconf.
>> 
>> ** Make "emacs --daemon" start emacs without showing any frame.
>> Use emacsclient later to open frames.

> AFAIK nobody has publicly announced that is working on any of these.

> Do you have a copyright assignment on file?  If not, it would make sense
> to get started on that as soon as possible, so that it is ready by the
> time you finish writing the code.


>> ** Make vc-checkin avoid reverting the buffer if has not changed after
>> the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be enough.

> I have a patch for this one.

> But it needs a few more eyes on it from people that know the code
> involved very well to make sure it is correct and the right thing to do.
> The patch itself is not too complicated.

BTW, I'd like someone to clarify the goal.  I.e. what is it trying
to fix.  It seems that if the file hasn't been changed, the current code
should at the very least end up not modifying the buffer (since
insert-file-contents already compares the bytes to find the unchanged
prefix and suffix).  So what is the difference in this case between
calling revert-buffer and not calling it?

Also I expect that if the file hasn't changed, it will often have kept
its modification time as well, so in which circumstances would the
modtime check fail but the md5 check succeed?


        Stefan


> --- vc.el       10 Oct 2007 10:34:53 -0700      1.464
> +++ vc.el       11 Oct 2007 12:18:02 -0700      
> @@ -1328,7 +1327,19 @@
>      (save-excursion
>        ;; t means don't call normal-mode;
>        ;; that's to preserve various minor modes.
> -      (revert-buffer arg no-confirm t))
> +      (if (string=
> +          (with-temp-buffer
> +            ;; Insert the file on disk in a temporary buffer and compute the md5 there.
> +            (let ((coding-system-for-read 'binary))
> +              (insert-file-contents file)
> +              (md5 (current-buffer))))
> +          (md5 (current-buffer)))  ;; md5 for the current buffer
> +         (let ((writable (file-writable-p (buffer-file-name)))) ;; Try to set the read-only state.
> +           (unless (eq buffer-read-only writable)
> +             (setq buffer-read-only writable))
> +           (message "not reverting"))
> +       (message "reverting :-(")
> +       (revert-buffer arg no-confirm t)))
>      (vc-restore-buffer-context context)))
 
>  (defun vc-buffer-sync (&optional not-urgent)

Re: TODO

[Dan Nicolaescu]

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

  > >> Please let me know if anyone is already working on one of these tasks.
  > >> 
  > >> ** make emacsclient accept -nw as a synonym to -t.
  > >> 
  > >> ** Replace some uses of the preprocessor code in Makefile.in with the
  > >> equivalent autoconf.
  > >> 
  > >> ** Make "emacs --daemon" start emacs without showing any frame.
  > >> Use emacsclient later to open frames.
  > 
  > > AFAIK nobody has publicly announced that is working on any of these.
  > 
  > > Do you have a copyright assignment on file?  If not, it would make sense
  > > to get started on that as soon as possible, so that it is ready by the
  > > time you finish writing the code.
  > 
  > 
  > >> ** Make vc-checkin avoid reverting the buffer if has not changed after
  > >> the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be enough.
  > 
  > > I have a patch for this one.
  > 
  > > But it needs a few more eyes on it from people that know the code
  > > involved very well to make sure it is correct and the right thing to do.
  > > The patch itself is not too complicated.
  > 
  > BTW, I'd like someone to clarify the goal.  I.e. what is it trying
  > to fix.  It seems that if the file hasn't been changed, the current code
  > should at the very least end up not modifying the buffer (since
  > insert-file-contents already compares the bytes to find the unchanged
  > prefix and suffix).  So what is the difference in this case between
  > calling revert-buffer and not calling it?

The goal is not to revert the buffer after a checkin.  Right now files
are reverted by default after a checkin (because of the possibility that
keyword expansion can change the file?).  Not reverting would be good
because it would keep the undo history (you probably remember that
discussion).

[BTW, it's quite possible that my patch is barking at the wrong tree...]

Re: TODO

[Stefan Monnier]

>> >> Please let me know if anyone is already working on one of these tasks.
>> >> 
>> >> ** make emacsclient accept -nw as a synonym to -t.
>> >> 
>> >> ** Replace some uses of the preprocessor code in Makefile.in with the
>> >> equivalent autoconf.
>> >> 
>> >> ** Make "emacs --daemon" start emacs without showing any frame.
>> >> Use emacsclient later to open frames.
>> 
>> > AFAIK nobody has publicly announced that is working on any of these.
>> 
>> > Do you have a copyright assignment on file?  If not, it would make sense
>> > to get started on that as soon as possible, so that it is ready by the
>> > time you finish writing the code.
>> 
>> 
>> >> ** Make vc-checkin avoid reverting the buffer if has not changed after
>> >> the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be enough.
>> 
>> > I have a patch for this one.
>> 
>> > But it needs a few more eyes on it from people that know the code
>> > involved very well to make sure it is correct and the right thing to do.
>> > The patch itself is not too complicated.
>> 
>> BTW, I'd like someone to clarify the goal.  I.e. what is it trying
>> to fix.  It seems that if the file hasn't been changed, the current code
>> should at the very least end up not modifying the buffer (since
>> insert-file-contents already compares the bytes to find the unchanged
>> prefix and suffix).  So what is the difference in this case between
>> calling revert-buffer and not calling it?

> The goal is not to revert the buffer after a checkin.  Right now files
> are reverted by default after a checkin (because of the possibility that
> keyword expansion can change the file?).  Not reverting would be good
> because it would keep the undo history (you probably remember that
> discussion).

If the problem is the undo-list, then we can change insert-file-contents
to not clear the buffer-undo-list in the case where it did make any
changes to the buffer.


        Stefan

Re: TODO

[Dan Nicolaescu]

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

  > >> >> Please let me know if anyone is already working on one of these tasks.
  > >> >> 
  > >> >> ** make emacsclient accept -nw as a synonym to -t.
  > >> >> 
  > >> >> ** Replace some uses of the preprocessor code in Makefile.in with the
  > >> >> equivalent autoconf.
  > >> >> 
  > >> >> ** Make "emacs --daemon" start emacs without showing any frame.
  > >> >> Use emacsclient later to open frames.
  > >> 
  > >> > AFAIK nobody has publicly announced that is working on any of these.
  > >> 
  > >> > Do you have a copyright assignment on file?  If not, it would make sense
  > >> > to get started on that as soon as possible, so that it is ready by the
  > >> > time you finish writing the code.
  > >> 
  > >> 
  > >> >> ** Make vc-checkin avoid reverting the buffer if has not changed after
  > >> >> the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be enough.
  > >> 
  > >> > I have a patch for this one.
  > >> 
  > >> > But it needs a few more eyes on it from people that know the code
  > >> > involved very well to make sure it is correct and the right thing to do.
  > >> > The patch itself is not too complicated.
  > >> 
  > >> BTW, I'd like someone to clarify the goal.  I.e. what is it trying
  > >> to fix.  It seems that if the file hasn't been changed, the current code
  > >> should at the very least end up not modifying the buffer (since
  > >> insert-file-contents already compares the bytes to find the unchanged
  > >> prefix and suffix).  So what is the difference in this case between
  > >> calling revert-buffer and not calling it?
  > 
  > > The goal is not to revert the buffer after a checkin.  Right now files
  > > are reverted by default after a checkin (because of the possibility that
  > > keyword expansion can change the file?).  Not reverting would be good
  > > because it would keep the undo history (you probably remember that
  > > discussion).
  > 
  > If the problem is the undo-list, then we can change insert-file-contents
  > to not clear the buffer-undo-list in the case where it did make any
  > changes to the buffer.

Yep, the problem is the undo-list.  Please do that if you think it's
better/easier. (I know nothing about that code, to can't help there... :-()

Re: TODO

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> The goal is not to revert the buffer after a checkin.  Right now files
> are reverted by default after a checkin (because of the possibility that
> keyword expansion can change the file?).

Surely only backends like CVS that actually do keyword expansion revert
the file, right....?

-Miles

-- 
Patience, n. A minor form of despair, disguised as a virtue.

Re: TODO

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > The goal is not to revert the buffer after a checkin.  Right now files
  > > are reverted by default after a checkin (because of the possibility that
  > > keyword expansion can change the file?).
  > 
  > Surely only backends like CVS that actually do keyword expansion revert
  > the file, right....?

No, the file is reverted anyway.  AFAICT there's no way right now for a
vc backend to specify that it does not want to revert the file after
commit....

Re: TODO

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > > The goal is not to revert the buffer after a checkin.  Right now files
>   > > are reverted by default after a checkin (because of the possibility that
>   > > keyword expansion can change the file?).
>   > 
>   > Surely only backends like CVS that actually do keyword expansion revert
>   > the file, right....?
>
> No, the file is reverted anyway.  AFAICT there's no way right now for a
> vc backend to specify that it does not want to revert the file after
> commit....

Looks like low-hanging fruit to me... :-)

[Even backends that _do_ do keyword expansion might easily be able to
detect whether it's really necessary or not for a particular commit, and
indicate that to vc.]

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: TODO

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > > The goal is not to revert the buffer after a checkin.  Right now files
  > >   > > are reverted by default after a checkin (because of the possibility that
  > >   > > keyword expansion can change the file?).
  > >   > 
  > >   > Surely only backends like CVS that actually do keyword expansion revert
  > >   > the file, right....?
  > >
  > > No, the file is reverted anyway.  AFAICT there's no way right now for a
  > > vc backend to specify that it does not want to revert the file after
  > > commit....
  > 
  > Looks like low-hanging fruit to me... :-)

Patches are welcome!

Re: TODO

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > Looks like low-hanging fruit to me... :-)
>
> Patches are welcome!

To be honest I'm kind of afraid to touch the vc code these days...
(especially something that involves adding any kind of interface)

-miles

-- 
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.

Re: TODO

[Richard Stallman]

    If the problem is the undo-list, then we can change insert-file-contents
    to not clear the buffer-undo-list in the case where it did make any
    changes to the buffer.

I think this should not be the normal case for insert-file-contents,
when VISIT = nil.  Rather, it should be a special option to be used in
particular cases like this.  Perhaps visit = vc?

Re: TODO

[Stefan Monnier]

>     If the problem is the undo-list, then we can change insert-file-contents
>     to not clear the buffer-undo-list in the case where it did make any
>     changes to the buffer.

I've installed a change that does just that.

> I think this should not be the normal case for insert-file-contents,
> when VISIT = nil.  Rather, it should be a special option to be used in
> particular cases like this.  Perhaps visit = vc?

If `insert-file-contents' does not change any part of the buffer, it's
basically a no-op.  I see hence no reason for it to flush the undo-list
in that case.

AFAIK, flushing the undo list is done on the expectation that the new
content is substantially different, so the original undo-list is only
valid if we add a big undo-entry that represents the changes made by
insert-file-contents (hence making the insert-file-contents operation
undoable).  In the case where the new content is equal to the old
content, we may as well keep the undo-list.


        Stefan

Re: TODO [was Re: Looking for a new Emacs maintainer or team]

[Xavier Maillard]

   Please let me know if anyone is already working on one of these tasks.

I can't answer your question but this entry is really
interesting. So if you need to "orient" your choice, I'd vote for
this :)

   ** Make "emacs --daemon" start emacs without showing any frame.
   Use emacsclient later to open frames.

This idea would be excellent to have. I am using a hack to mimic
such behaviour based on GNU screen (I have a GNU Emacs launched
through a screen session that acts as a server).

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: TODO

[Michael Albinus]

Xavier Maillard <xma@gnu.org> writes:

>    Please let me know if anyone is already working on one of these tasks.
>
> I can't answer your question but this entry is really
> interesting. So if you need to "orient" your choice, I'd vote for
> this :)
>
>    ** Make "emacs --daemon" start emacs without showing any frame.
>    Use emacsclient later to open frames.
>
> This idea would be excellent to have. I am using a hack to mimic
> such behaviour based on GNU screen (I have a GNU Emacs launched
> through a screen session that acts as a server).

This could be implemented easily by DBus, because it supports starting
services on request. To give an impression how it could work (hacked
on my Ubuntu machine, paths needed to be adapted):

- Place a file daemon.el into the Emacs load path, containing:

(require 'dbus)
(dbus-register-method
 :session "org.gnu.Emacs" "/org/gnu/Emacs" "org.gnu.Emacs"
 "Daemon" 'recursive-edit)

- Create a DBus service file "emacs.service" (in my case located at
  /usr/share/dbus-1/services), containing:

[D-BUS Service]
Name=org.gnu.Emacs
Exec=/usr/local/src/emacs/src/emacs -l daemon

- Emulate the DBus message, emacsclient could send:

# dbus-send --session --print-reply --dest="org.gnu.Emacs" \
    "/org/gnu/Emacs" "org.gnu.Emacs.Daemon"

That is of course *very* rough. And going into this direction, it
would require to enhance emacsclient and server.el understanding DBus
messages (when available).

What do people think?

> 	Xavier

Best regards, Michael.

Re: TODO

[Richard Stallman]

    If `insert-file-contents' does not change any part of the buffer, it's
    basically a no-op.  I see hence no reason for it to flush the undo-list
    in that case.

The point is that it is somewhat unclean for the flushing to depend on
the data in the file.  So the usual ways of calling `insert-file-contents'
should either flush or not, regardless of the data in the file.

Re: TODO

[Dan Nicolaescu]

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

  > Xavier Maillard <xma@gnu.org> writes:
  > 
  > >    Please let me know if anyone is already working on one of these tasks.
  > >
  > > I can't answer your question but this entry is really
  > > interesting. So if you need to "orient" your choice, I'd vote for
  > > this :)
  > >
  > >    ** Make "emacs --daemon" start emacs without showing any frame.
  > >    Use emacsclient later to open frames.
  > >
  > > This idea would be excellent to have. I am using a hack to mimic
  > > such behaviour based on GNU screen (I have a GNU Emacs launched
  > > through a screen session that acts as a server).
  > 
  > This could be implemented easily by DBus, because it supports starting
  > services on request. To give an impression how it could work (hacked
  > on my Ubuntu machine, paths needed to be adapted):
  > 
  > - Place a file daemon.el into the Emacs load path, containing:
  > 
  > (require 'dbus)
  > (dbus-register-method
  >  :session "org.gnu.Emacs" "/org/gnu/Emacs" "org.gnu.Emacs"
  >  "Daemon" 'recursive-edit)
  > 
  > - Create a DBus service file "emacs.service" (in my case located at
  >   /usr/share/dbus-1/services), containing:
  > 
  > [D-BUS Service]
  > Name=org.gnu.Emacs
  > Exec=/usr/local/src/emacs/src/emacs -l daemon
  > 
  > - Emulate the DBus message, emacsclient could send:
  > 
  > # dbus-send --session --print-reply --dest="org.gnu.Emacs" \
  >     "/org/gnu/Emacs" "org.gnu.Emacs.Daemon"
  > 
  > That is of course *very* rough. And going into this direction, it
  > would require to enhance emacsclient and server.el understanding DBus
  > messages (when available).
  > 
  > What do people think?

There's some misunderstanding here.  What's missing here is a way to
start emacs and not create any frame, just have it run as a daemon (and
do not quit when the user logs out for example).  Then create frames
connected with that running emacs process.  The method of connecting to
the running emacs:  dbus or emacsclient is not important.

Re: TODO [was Re: Looking for a new Emacs maintainer or team]

[V.Rao]

Regarding the copyright assignment, I have seen some samples.
Is there a template that could be provided to me - that I would review and  
sign?
(I was reading http://www.gnu.org/prep/maintain/html_node/index.html).

thanks.



On Tue, 26 Feb 2008 13:13:13 -0500, Dan Nicolaescu <dann@ics.uci.edu>  
wrote:

> "V.Rao" <mail.vjrao@yahoo.com> writes:
>
>   > Please let me know if anyone is already working on one of these  
> tasks.
>   >
>   > ** make emacsclient accept -nw as a synonym to -t.
>   >
>   > ** Replace some uses of the preprocessor code in Makefile.in with the
>   > equivalent autoconf.
>   >
>   > ** Make "emacs --daemon" start emacs without showing any frame.
>   > Use emacsclient later to open frames.
>
> AFAIK nobody has publicly announced that is working on any of these.
>
> Do you have a copyright assignment on file?  If not, it would make sense
> to get started on that as soon as possible, so that it is ready by the
> time you finish writing the code.
>
>
>   > ** Make vc-checkin avoid reverting the buffer if has not changed  
> after
>   >    the checkin. Comparing (md5 BUFFER) to (md5 FILE) should be  
> enough.
>
> I have a patch for this one.
>
> But it needs a few more eyes on it from people that know the code
> involved very well to make sure it is correct and the right thing to do.
> The patch itself is not too complicated.
>
> --- vc.el       10 Oct 2007 10:34:53 -0700      1.464
> +++ vc.el       11 Oct 2007 12:18:02 -0700
> @@ -1328,7 +1327,19 @@
>      (save-excursion
>        ;; t means don't call normal-mode;
>        ;; that's to preserve various minor modes.
> -      (revert-buffer arg no-confirm t))
> +      (if (string=
> +          (with-temp-buffer
> +            ;; Insert the file on disk in a temporary buffer and  
> compute the md5 there.
> +            (let ((coding-system-for-read 'binary))
> +              (insert-file-contents file)
> +              (md5 (current-buffer))))
> +          (md5 (current-buffer)))  ;; md5 for the current buffer
> +         (let ((writable (file-writable-p (buffer-file-name)))) ;; Try  
> to set the read-only state.
> +           (unless (eq buffer-read-only writable)
> +             (setq buffer-read-only writable))
> +           (message "not reverting"))
> +       (message "reverting :-(")
> +       (revert-buffer arg no-confirm t)))
>      (vc-restore-buffer-context context)))
> (defun vc-buffer-sync (&optional not-urgent)

Re: TODO

[Stefan Monnier]

>> Please let me know if anyone is already working on one of these tasks.
>> 
>> I can't answer your question but this entry is really
>> interesting. So if you need to "orient" your choice, I'd vote for
>> this :)
>> 
>> ** Make "emacs --daemon" start emacs without showing any frame.
>> Use emacsclient later to open frames.
>> 
>> This idea would be excellent to have. I am using a hack to mimic
>> such behaviour based on GNU screen (I have a GNU Emacs launched
>> through a screen session that acts as a server).

> This could be implemented easily by DBus, because it supports starting
> services on request. To give an impression how it could work (hacked
> on my Ubuntu machine, paths needed to be adapted):

You're talking about something different.  You're talking about
auto-starting Emacs (in daemon mode) on demand.  This can already be
done by a few changes to emacsclient.c (to make it run "emacs -f
server-mode" if the server is not running already).

What the above TODO item is talking about is the question of how to
start Emacs without showing any frame.  Most of the code is there
already: if you look in startup.el you'll see that Emacs starts with
an "initial-terminal" which is basically a pseudo terminal with
a pseudo frame which corresponds to stdin/stdout and at some later point
a real terminal (with a real frame) is created either on the current tty
or on the current GUI display.  When running in batch mode, we only run
with this initial-terminal.

Maybe all we need is something like "emacs --batch -f server-mode -f
top-level".  But I expect that this will uncover all kinds of funny
problems.


        Stefan

Re: TODO

[Michael Albinus]

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

> You're talking about something different.  You're talking about
> auto-starting Emacs (in daemon mode) on demand.  This can already be
> done by a few changes to emacsclient.c (to make it run "emacs -f
> server-mode" if the server is not running already).

I know it is different. I just wanted to show that the same *effect* can
be reached simply by DBus messages (or by extending emacsclient, as you
have shown).

> What the above TODO item is talking about is the question of how to
> start Emacs without showing any frame.

I don't see the use case where starting Emacs without a frame is
preferrable over starting it on demand. Is it that Emacs shall run as
background server process?

>         Stefan

Best regards, Michael.

Re: TODO

[Evans Winner]

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

    I don't see the use case where starting Emacs without a
    frame is preferrable over starting it on demand. Is it
    that Emacs shall run as background server process?

I use Emacs sort-of like this.  I leave one instance running
(usually an X version) on my desktop machine at home.  It
has a lot of state and loads a lot of libraries at start-up.
I connect to it with emacsclient from other virtual
consoles, from my laptop at home or at coffee shops, from
work, from school, from friends' houses.  When I connect, it
takes much less than a second to be back where I was with
whatever I was working on.

But sometimes I actually work on my desktop machine, where
if X crashes, or I accidentally blow something up, I lose
that state.  I may be missing some normal mode of use that
would solve that problem, but it seems like it would be
pretty elegant to have Emacs as a daemon that starts on
boot-up (ideally--or login) and then I could otherwise
forget about it, and connect on demand.

Re: TODO [was Re: Looking for a new Emacs maintainer or team]

[Richard Stallman]

We send out forms preprinted.  Normally the package maintainers tell
you how to request one, but I'll answer this time.

Re: TODO

[Dan Nicolaescu]

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

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > 
  > > You're talking about something different.  You're talking about
  > > auto-starting Emacs (in daemon mode) on demand.  This can already be
  > > done by a few changes to emacsclient.c (to make it run "emacs -f
  > > server-mode" if the server is not running already).
  > 
  > I know it is different. I just wanted to show that the same *effect* can
  > be reached simply by DBus messages (or by extending emacsclient, as you
  > have shown).
  >
  > > What the above TODO item is talking about is the question of how to
  > > start Emacs without showing any frame.
  > 
  > I don't see the use case where starting Emacs without a frame is
  > preferrable over starting it on demand. Is it that Emacs shall run as
  > background server process?

Yep, and not only that, it is the fact that it shall not quit running
when the user logs out.  This is a good way to access a single emacs
session (and keep all the state).  The way people do it today is to use
"screen" to connect to the machine, run emacs -nw -f server-start and
then disconnect the screen session.

Re: TODO

[Michael Albinus]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Yep, and not only that, it is the fact that it shall not quit running
> when the user logs out.  This is a good way to access a single emacs
> session (and keep all the state).

I see, thanks. In this case, DBus messages for communication would be
useless, because the DBus session daemon has a lifetime related to,
you guess it, the user session.

Best regards, Michael.

Re: TODO

[Xavier Maillard]

   Dan Nicolaescu <dann@ics.uci.edu> writes:

   > Yep, and not only that, it is the fact that it shall not quit running
   > when the user logs out.  This is a good way to access a single emacs
   > session (and keep all the state).

   I see, thanks. In this case, DBus messages for communication would be
   useless, because the DBus session daemon has a lifetime related to,
   you guess it, the user session.

Even if it is useless to complete the TODO item, I find the
idea/hack pretty cool. I have learnt something and I want to
thank you for this.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org