From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: other-buffer advice on kill-buffer Date: Wed, 03 Aug 2011 16:41:57 +0900 Message-ID: <878vrbhrga.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8662mgg2ea.fsf@gmail.com> <87d3go4t4d.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1312357325 21259 80.91.229.12 (3 Aug 2011 07:42:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2011 07:42:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Antoine Levitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 03 09:42:00 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 1QoW5W-0007Ns-70 for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 09:41:58 +0200 Original-Received: from localhost ([::1]:52832 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoW5V-0008E7-EQ for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 03:41:57 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoW5S-0008E1-9m for emacs-devel@gnu.org; Wed, 03 Aug 2011 03:41:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoW5R-0007t0-7w for emacs-devel@gnu.org; Wed, 03 Aug 2011 03:41:54 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:59909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoW5Q-0007qR-NZ for emacs-devel@gnu.org; Wed, 03 Aug 2011 03:41:53 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D0ADF3FA06F9; Wed, 3 Aug 2011 16:41:49 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 125841A26F8; Wed, 3 Aug 2011 16:41:58 +0900 (JST) In-Reply-To: <87d3go4t4d.fsf@gmail.com> X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:142789 Archived-At: Antoine Levitt writes: > 02/08/11 01:03, J=E9r=E9my Compostella > > 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 sele= ct > > 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. `other-buffer''s advice will be respected if called as Ffuncall(n, intern("other-buffer"), ...) but not if called as Fother_buffer(...) > > Is there a restriction on advices for C implemented function ? No, you can advise functions implemented in C just like any other function. The question is whether they are called via their symbol (ie, with Ffuncall), or via the C-level function. > > How the kill-buffer function select the new displayed buffer ? Could I > > really modify its behavior and how ? > I believe you can't advice a C function (not sure). In any case, advice > is generally best left as last resort. Actually, advice is best used as a first resort. If it doesn't work (as here), or if you want to distribute it with Emacs, then you need to do things more carefully. Besides the fact that advice for `foo' will be ignored by C functions that call Ffoo directly, the big problem with an advice'd function is that it's not standard and therefore different people will get different results from using the function. In this case, that is exactly what J=E9r=E9my wants, so no problem! > 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? >=20 > 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. You might also consider using kill-buffer-hook to manipulate the buffer list, eg by doing a switch-to-prev-buffer there.