From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?J=C3=A9r=C3=A9my_Compostella?= Newsgroups: gmane.emacs.devel Subject: Re: other-buffer advice on kill-buffer Date: Tue, 02 Aug 2011 02:06:44 +0200 Message-ID: <86hb60ekx7.fsf@gmail.com> References: <8662mgg2ea.fsf@gmail.com> <87d3go4t4d.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1312243635 5850 80.91.229.12 (2 Aug 2011 00:07:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2011 00:07:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 02:07:11 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qo2Vr-0003r4-47 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 02:07:11 +0200 Original-Received: from localhost ([::1]:35691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo2Vq-0003gC-J6 for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2011 20:07:10 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo2Vm-0003g6-US for emacs-devel@gnu.org; Mon, 01 Aug 2011 20:07:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qo2Vk-0006Ws-Sp for emacs-devel@gnu.org; Mon, 01 Aug 2011 20:07:06 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:60723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo2Vk-0006WU-I8 for emacs-devel@gnu.org; Mon, 01 Aug 2011 20:07:04 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qo2Vh-0003p9-N2 for emacs-devel@gnu.org; Tue, 02 Aug 2011 02:07:01 +0200 Original-Received: from lmontsouris-156-26-33-131.w80-14.abo.wanadoo.fr ([80.14.208.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Aug 2011 02:07:01 +0200 Original-Received: from jeremy.compostella by lmontsouris-156-26-33-131.w80-14.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Aug 2011 02:07:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 78 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lmontsouris-156-26-33-131.w80-14.abo.wanadoo.fr User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:4WVQMJX0VDN6AMOVTjppFX7rUPY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142652 Archived-At: Antoine Levitt writes: > 02/08/11 01:03, Jérémy Compostella >> All, >> >> I'm trying to modify the behavior of the kill-buffer function to fit my >> needs. I would like to limit the list of eligible buffers used to select >> the buffer which will be displayed in place of the killed buffer. >> >> I have tried to advice the other-buffer function which seems called >> (Cf. buffer.c) but my advice is never called in this case. Indeed, my >> other-buffer advice is correctly called on switch-to-buffer call but >> never on kill-buffer call. >> >> So am I missing something ? >> Is there a restriction on advices for C implemented function ? >> How the kill-buffer function select the new displayed buffer ? Could I >> really modify its behavior and how ? >> >> Thanks for your help. >> >> Jeremy > > Hi Jeremy, > > I believe you can't advice a C function (not sure). In any case, advice > is generally best left as last resort. What's keeping you from defining > your own my-kill-buffer that'd call kill-buffer (which would switch to > the most recent buffer) and then do some buffer switching of your own? > > Also see the docstring of kill-buffer. In particular, the docstring > tells you than it calls replace-buffer-in-windows, and then the source > code for replace-buffer-in-windows tells you that it calls > switch-to-prev-buffer. So if you must advice or redefine an emacs > function, these two look like better access points. Thanks I will take a look at it. > Just out of curiosity, what buffers are you trying to exclude? I developed an activity manager since I use Emacs as my full desktop environment (Web, Mail, Jabber, Code with different project at the same time). This activity module let me define statically and dynamically activities. Activities are named and have open/enable/disable handlers to modify the Emacs behavior in regards of what I like to do under a particular activity. It provides functions to switch between activities remembering the window configuration and now it has the ability to help me to select a relevant buffer. Actually in some occasion I have several thousands of buffers for different kind of activities / projects. So I particularly appreciate this help to select the buffer I want to display by pre-filtering the buffer list. Moreover, each visited buffer is automatically associated to the current activity. So I have a issue when I switch to another activty and call the kill-buffer function. A buffer of the previous activity is usually selected in place of the killed buffer and this newly selected buffer is automatically associated to the current activity which is not the behavior I wish. I would like the newly selected buffer is selected from the current activity buffer list. The activity is written as less intrusive as possible. Yet, for this issue if I use the kill-buffer function a badly selected buffer will be associated to the current activity. So, even if I add an advice to switch to a relevant buffer afterwards I will have to unassociated the non-relevant buffer. Therefore I don't see another clean way than modifying the kill-buffer function behavior to prevent this unrelevant buffer selection issue. You could take a look at: http://www.jerryland.fr/git/?p=emacs-config.git/.git;a=blob;f=.emacs.d/activity.el;h=96ab194f00d5224210c505739e96152dae99f9c6;hb=refs/heads/activity-improvements Best regards, Jeremy -- Sent from my Emacs