unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jérémy Compostella" <jeremy.compostella@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: other-buffer advice on kill-buffer
Date: Tue, 02 Aug 2011 02:06:44 +0200	[thread overview]
Message-ID: <86hb60ekx7.fsf@gmail.com> (raw)
In-Reply-To: 87d3go4t4d.fsf@gmail.com

Antoine Levitt <antoine.levitt@gmail.com> 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




  reply	other threads:[~2011-08-02  0:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-01 23:03 other-buffer advice on kill-buffer Jérémy Compostella
2011-08-01 23:19 ` Antoine Levitt
2011-08-02  0:06   ` Jérémy Compostella [this message]
2011-08-02  0:40     ` Antoine Levitt
2011-08-02 12:20       ` Jérémy Compostella
2011-08-02 18:04     ` Dimitri Fontaine
2011-08-03  7:41   ` Stephen J. Turnbull
2011-08-02  0:55 ` Tim Cross
2011-08-02  1:00   ` Tim Cross
2011-08-02 12:29     ` Jérémy Compostella
2011-08-02  1:52   ` Alp Aker
2011-08-02 11:58     ` Jérémy Compostella
2011-08-02 21:55     ` Richard Stallman
2011-08-03  6:18       ` David Kastrup
2011-08-03 15:14         ` Jérémy Compostella
2011-08-04  2:24           ` Stephen J. Turnbull
2011-08-03 19:18         ` Richard Stallman
2011-08-04  6:42         ` Tim Cross
2011-08-04 14:03           ` Stefan Monnier
2011-08-04 19:56             ` Jérémy Compostella
2011-08-19  7:10       ` Leo
2011-08-14 17:16 ` Chong Yidong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86hb60ekx7.fsf@gmail.com \
    --to=jeremy.compostella@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).