Re: Looking for a new Emacs maintainer or team

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]

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

[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

[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: 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