From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Session management patch, please comment. Date: Wed, 20 Feb 2002 21:29:12 +0100 Message-ID: <80384FF2-2640-11D6-ABC5-00039363E640@mbox200.swipnet.se> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: quimby2.netfonds.no 1014237089 31419 195.204.10.66 (20 Feb 2002 20:31:29 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 20 Feb 2002 20:31:29 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16ddOj-0008Af-00 for ; Wed, 20 Feb 2002 21:31:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16ddNf-0007ao-00; Wed, 20 Feb 2002 15:30:23 -0500 Original-Received: from [195.196.30.60] (helo=aurora.natverket.com) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16ddMt-0007Sp-00 for ; Wed, 20 Feb 2002 15:29:35 -0500 Original-Received: from marmor (pc35.bodenonline.com [195.196.29.227] (may be forged)) by aurora.natverket.com (8.9.3/8.9.3) with ESMTP id WAA27005; Wed, 20 Feb 2002 22:08:46 +0100 (CET) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: <5xk7t9cctt.fsf@kfs2.cua.dk> X-Mailer: Apple Mail (2.480) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1362 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1362 tisdagen den 19 februari 2002 kl 23.43 skrev Kim F. Storm: > "Jan D." writes: > >>> + DEFUN ("x-sm-interact-done", Fx_sm_interact_done, >> >> Emacs is executing C code when this happens. To get into lisp code, a >> save-yourself-event is generated and the lisp function bound to the >> event executes (handle-save-yourself). >> >> handle-save-yourself then executes functions in the save-yourself-hook >> and by calling x-sm-interact-done it finally informs the C code that >> it shall send the interaction-done message to the session manager. >> > > What about this approach: > > In C, you declare a hook variable emacs-session-save-function. > > In Lisp, you bind a save-session-state function to this variable. > > When the save_yourself event arrives, the function bound to > emacs-session-save-function is called (with whatever arguments you > think it needs). I don't quite understand. What purpose does the emacs-session-save-function serve, why not call a lisp function directly? And if one can call lisp functions, why not call the functions in save-session-state-hook from C? The reason I did it the way presented, is was I think you can't call lisp functions from the X event input handler. Thus an Emacs event is used to get control to the lisp part. But maybe this can be made an internal event and the hooks can be called from Emacs input loop. I did not know how to do that, I was not sure where such code should go to not mess things up with recursive calls. But if someone knows and can give a pointer I can modify the code. > > The save-session-state function runs the save-session-state-hook hooks. > > The return value from save-session-state is nil or t - corresponding > to the CANCEL argument of your x-sm-interact-done function. > > >>> + doc: /* The previous session id Emacs got from session manager. >>> + This is nil if Emacs was not started by the session manager. >>> + The value of this variable and `x-sm-id' may be the same, >>> depending on how >>> + the session manager works. >>> + See also `x-sm-id'.*/); >>> This doc string should explain what the previous session id is good >>> for. What does it mean? Documentation for data should explain its >>> overall meaning, not just what it looks like and what values are found >>> when. > > Does these really need to be a C-level lisp variables? > > Isn't it enough that the previous session id is passed as an argument > to the emacs-session-restore-function and the current session id is an > argument to emacs-session-save-function? > > In general, I would suspect that you only need to know either the > previous session id (when doing restore), or the current session id > (when doing save). If you have saved state in a file with a filename based on the previous id, you presumably would want remove or move that file, either when doing restore or save session. > If necessary, the restore-session-state function could store it in a > lisp variable for the hooks to access -- or you can rely on the > dynamic binding of the argument to restore-session-state, e.g. > > (defun save-session-state (session-id) ;; current session-id > ...) > > (defun restore-session-state (session-id) ;; previous session-id > ...) > >>> + DEFVAR_LISP ("x-sm-cancel-shutdown", &Vx_sm_cancel_shutdown, > > With the suggested solution above, this variable could also be declared in > lisp > (actually it could be dynamically bound in the save-session-state function) > : > > (defun save-session-state (session-id) > (let ((cancel-session-shutdown nil)) > (run-hooks 'save-session-state-hook) > cancel-session-shutdown)) > This looks useful, thanks for the hint. Jan D. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel