other-buffer advice on kill-buffer

other-buffer advice on kill-buffer

[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

Re: other-buffer advice on kill-buffer

[Antoine Levitt]

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.

Just out of curiosity, what buffers are you trying to exclude?

Re: other-buffer advice on kill-buffer

[Jérémy Compostella]

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

Re: other-buffer advice on kill-buffer

[Antoine Levitt]

02/08/11 02:06, Jérémy Compostella
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>> 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.

That seems interesting. I toyed with the idea in my mind some time ago,
but couldn't figure out something neat enough to be really
usable. Ideally, you'd have separate buffer groups, and C-x b with
ido/iswitchb/whatever would only display the current group. There'd be a
system to switch activity, with memorised window configurations, and
notifications (say, ERC or gnus has received new messages, or a
compilation has finished) would be unified (so you could have one
keybinding to "switch to the activity requiring attention"). However,
that all seems a bit hackish, and I wonder if that's not twisting emacs
around too much.

Your code looks cool, but I'm thinking of something a little more static
- ie "c-mode or emacs-lisp-mode files under ~/emacs go to activity
emacs-hack", etc.

Re: other-buffer advice on kill-buffer

[Jérémy Compostella]

Antoine Levitt <antoine.levitt <at> gmail.com> writes:

> 
> 02/08/11 02:06, Jérémy Compostella
> > Antoine Levitt <antoine.levitt <at> gmail.com> writes:
> >> 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.
> 
> That seems interesting. I toyed with the idea in my mind some time ago,
> but couldn't figure out something neat enough to be really
> usable. Ideally, you'd have separate buffer groups, and C-x b with
> ido/iswitchb/whatever would only display the current group. There'd be a
> system to switch activity, with memorised window configurations, and
> notifications (say, ERC or gnus has received new messages, or a
> compilation has finished) would be unified (so you could have one
> keybinding to "switch to the activity requiring attention"). However,
> that all seems a bit hackish, and I wonder if that's not twisting emacs
> around too much.
I didn't really think about the notification stuff. The only notifications I
care about are already bound to the mode-line : jabber and gnus notify me this
way. Especially since my objective is having a distraction-less work optimized
environment (fullscreen, no bar, no window decoration, no scrollbar, ...). I
don't like to be disturbed by notifications.

Note: I wrote this activity buffer filtering mechanism flexible to easily, for
example, associate a jabber buffer to my Linux kernel coding activity just by
calling the interactive jabber-chat-with function.

> Your code looks cool, but I'm thinking of something a little more static
> - ie "c-mode or emacs-lisp-mode files under ~/emacs go to activity
> emacs-hack", etc.
This module is ready for that. The automatic associated buffer is the bonus part
:) For example, this is how I define my Emacs hack activity.
(add-to-list 'available-activities (make-activity :name "Emacs"
						    :enable-hook (lambda () (toggle-debug-on-error t))
						    :disable-hook (lambda () (toggle-debug-on-error nil))
						    :buffer-filter-p (lambda (buf)
								       (with-current-buffer buf
									 (eq major-mode 'emacs-lisp-mode)))))

Re: other-buffer advice on kill-buffer

[Dimitri Fontaine]

Jérémy Compostella <jeremy.compostella@gmail.com> writes:
> 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.

escreen allows me to have about this feature set, have a look at how it
handles the per-screen window-configuration and buffer list:

  http://www.splode.com/~friedman/software/emacs-lisp/src/escreen.el

Regards,
-- 
dim

Re: other-buffer advice on kill-buffer

[Stephen J. Turnbull]

Antoine Levitt writes:
 > 02/08/11 01:03, Jérémy 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 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.

`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érémy 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?
 > 
 > 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.

Re: other-buffer advice on kill-buffer

[Tim Cross]

2011/8/2 Jérémy Compostella <jeremy.compostella@gmail.com>:
> 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 ?
>

Yes, there are some restrictions in how defadvice can be used and
which function sit can affect. From memory, you cannot advise
functions implemented in C, only those implemented in elisp.

With respect to the buffer display, there is a current work being done
in this area for emas 24. If you are using emacs 24, have a look at
the buffer-display-alist thread. One of the things that was being
asked for was examples of how the new configuration could/would be
used. Your request may be a good test case.

If your using emacs23 or earlier, personally, I would hold off until
the emacs 24 changes have settled as you will likely have to change
things once emacs 24 is released anyway. One of the objectives, as I
understand it, is to make this sort of configuration easier and more
flexible.so I expect you would be considered to be what they call an
'interested party'.

Tim

Re: other-buffer advice on kill-buffer

[Tim Cross]

2011/8/2 Tim Cross <theophilusx@gmail.com>:
> 2011/8/2 Jérémy Compostella <jeremy.compostella@gmail.com>:
>> 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 ?
>>
>
> Yes, there are some restrictions in how defadvice can be used and
> which function sit can affect. From memory, you cannot advise
> functions implemented in C, only those implemented in elisp.
>
> With respect to the buffer display, there is a current work being done
> in this area for emas 24. If you are using emacs 24, have a look at
> the buffer-display-alist thread. One of the things that was being
> asked for was examples of how the new configuration could/would be
> used. Your request may be a good test case.
>
> If your using emacs23 or earlier, personally, I would hold off until
> the emacs 24 changes have settled as you will likely have to change
> things once emacs 24 is released anyway. One of the objectives, as I
> understand it, is to make this sort of configuration easier and more
> flexible.so I expect you would be considered to be what they call an
> 'interested party'.
>

Correction - the thread you should look at is called
display-buffer-alist simplifications. Based on your subsequent
messages regarding the activity mode you have developed, I think this
thread may be even more relevant and worth checking out.

Tim

Re: other-buffer advice on kill-buffer

[Jérémy Compostella]

Tim Cross <theophilusx <at> gmail.com> writes:

> 
> 2011/8/2 Tim Cross <theophilusx <at> gmail.com>:
> Correction - the thread you should look at is called
> display-buffer-alist simplifications. Based on your subsequent
> messages regarding the activity mode you have developed, I think this
> thread may be even more relevant and worth checking out.
> 
This thread seems interesting. I will take look at it tonight and maybe switch
to emacs24.

Thanks helping me.

Re: other-buffer advice on kill-buffer

[Alp Aker]

Tim Cross wrote:

> From memory, you cannot advise functions implemented in C, only those
> implemented in elisp.

That's not correct.  You can advise a primitive function, but the advice will
only affect calls to that function made from Lisp, not calls from other
primitives.

Jérémy Compostella wrote:

>> 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.

Are you sure your advice on other-buffer is being called when
switch-to-buffer is called?  That shouldn't be possible, as switch-to-buffer
is a primitive, like kill-buffer; neither should see your advice.

Re: other-buffer advice on kill-buffer

[Jérémy Compostella]

Alp Aker <alptekin.aker <at> gmail.com> writes:

> 
> Tim Cross wrote:
> 
> > From memory, you cannot advise functions implemented in C, only those
> > implemented in elisp.
> 
> That's not correct.  You can advise a primitive function, but the advice will
> only affect calls to that function made from Lisp, not calls from other
> primitives.
Reading emacs source code let met think that way. Thanks you for confirming my
understanding.

> Jérémy Compostella wrote:
> 
> >> 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.
> 
> Are you sure your advice on other-buffer is being called when
> switch-to-buffer is called?  That shouldn't be possible, as switch-to-buffer
> is a primitive, like kill-buffer; neither should see your advice.
Indeed, I did not understand why it was possible in that case. I finally figure
out that actually my switch-to-buffer was bound to iswitchb-buffer which lisp
implemented. My mistake.

Thanks.

Re: other-buffer advice on kill-buffer

[Richard Stallman]

    That's not correct.  You can advise a primitive function, but the advice will
    only affect calls to that function made from Lisp, not calls from other
    primitives.

It may be that in a few special cases
we should modify calls within C code to some primitive functions
so that they call the Lisp symbol.
That way, it would work to advise those functions.

To do this for all the primitive functions would be impossible, I
think, and certainly not worth the pain.  But there might be a few
functions for which this would be particularly useful, and it might be
worth doing this for them.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: other-buffer advice on kill-buffer

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     That's not correct.  You can advise a primitive function, but the
>     advice will only affect calls to that function made from Lisp, not
>     calls from other primitives.
>
> It may be that in a few special cases
> we should modify calls within C code to some primitive functions
> so that they call the Lisp symbol.
> That way, it would work to advise those functions.
>
> To do this for all the primitive functions would be impossible, I
> think, and certainly not worth the pain.  But there might be a few
> functions for which this would be particularly useful, and it might be
> worth doing this for them.

If it is worth making it advisable, it is worth giving it a hook.

The problem is that advice is intended for adding functionality that has
not been imagined previously.  So it is hard to think of a case where
one would explicitly make a function advisable.

-- 
David Kastrup

Re: other-buffer advice on kill-buffer

[Jérémy Compostella]

David Kastrup <dak <at> gnu.org> writes:

> 
> Richard Stallman <rms <at> gnu.org> writes:
> 
> >     That's not correct.  You can advise a primitive function, but the
> >     advice will only affect calls to that function made from Lisp, not
> >     calls from other primitives.
> >
> > It may be that in a few special cases
> > we should modify calls within C code to some primitive functions
> > so that they call the Lisp symbol.
> > That way, it would work to advise those functions.
> >
> > To do this for all the primitive functions would be impossible, I
> > think, and certainly not worth the pain.  But there might be a few
> > functions for which this would be particularly useful, and it might be
> > worth doing this for them.
> 
> If it is worth making it advisable, it is worth giving it a hook.
> 
> The problem is that advice is intended for adding functionality that has
> not been imagined previously.  So it is hard to think of a case where
> one would explicitly make a function advisable.
I do not understand why all these primitives functions do not call the Lisp
symbol instead of the C one. What is the reason ? Performance ? Constraints ?

It looks inconsistent that way from my point of view but I suppose there is a
good reason.

Thanks

Re: other-buffer advice on kill-buffer

[Stephen J. Turnbull]

Jérémy Compostella writes:

 > I do not understand why all these primitives functions do not call the Lisp
 > symbol instead of the C one. What is the reason ? Performance ? Constraints ?

Partly performance, I would think.  Advice is clearly a second-class
citizen here.  While I agree with the rule that advice must not be
used to implement core functionality, even in "minor" modules such as
rarely used modes, I think advice deserves more use than it gets.
However, the general opinion is (as you saw) that advice is to be
avoided.  So making advice work everywhere is not considered to be as
important as even a small performance loss in a very large number of
function calls.

However, code readability is probably far more important.
`Fother_buffer(buffer_object)' is far more readable than
`Ffuncall(2, intern("other_buffer"), buffer_object)' or even
`Ffuncall(2, Qother_buffer, buffer_object)'.

Re: other-buffer advice on kill-buffer

[Richard Stallman]

    If it is worth making it advisable, it is worth giving it a hook.

I don't see it that way.  Adding a hook is heavier, since it is added
complexity and calls for documentation.  By contrast, one less
function that can't effectively be advised is LESS complexity at the
interface level, even though it is a little more complexity in the
code.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: other-buffer advice on kill-buffer

[Tim Cross]

On Wed, Aug 3, 2011 at 4:18 PM, David Kastrup <dak@gnu.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>>     That's not correct.  You can advise a primitive function, but the
>>     advice will only affect calls to that function made from Lisp, not
>>     calls from other primitives.
>>
>> It may be that in a few special cases
>> we should modify calls within C code to some primitive functions
>> so that they call the Lisp symbol.
>> That way, it would work to advise those functions.
>>
>> To do this for all the primitive functions would be impossible, I
>> think, and certainly not worth the pain.  But there might be a few
>> functions for which this would be particularly useful, and it might be
>> worth doing this for them.
>
> If it is worth making it advisable, it is worth giving it a hook.
>
> The problem is that advice is intended for adding functionality that has
> not been imagined previously.  So it is hard to think of a case where
> one would explicitly make a function advisable.
>
[
There is one special case where being able to add advice to more
functions, especially some primitive ones, accessibility. At least two
packages written to make emacs accessible to blind and vision impaired
users achieves this through advising functions. Currently, there are a
couple of places where accessibility is limited because of the problem
of advising primitive functions. So, adding this ability would likely
benefit at least one group of users and do so without any issue for
other users.

Tim

Re: other-buffer advice on kill-buffer

[Stefan Monnier]

> There is one special case where being able to add advice to more
> functions, especially some primitive ones, accessibility. At least two
> packages written to make emacs accessible to blind and vision impaired
> users achieves this through advising functions. Currently, there are a
> couple of places where accessibility is limited because of the problem
> of advising primitive functions. So, adding this ability would likely
> benefit at least one group of users and do so without any issue for
> other users.

Making all calls from C go through the symbol's function field rather
than calling the C function directly, so as to make advice work right,
is unlikely to happen any time soon.
But if you have specific requests of particular functions which might
deserve such a treatment, we might do it (tho it'll probably depend on
the specifics).
After all, I did do such a change myself for `expand-abbrev' in the past.


        Stefan

Re: other-buffer advice on kill-buffer

[Jérémy Compostella]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There is one special case where being able to add advice to more
>> functions, especially some primitive ones, accessibility. At least two
>> packages written to make emacs accessible to blind and vision impaired
>> users achieves this through advising functions. Currently, there are a
>> couple of places where accessibility is limited because of the problem
>> of advising primitive functions. So, adding this ability would likely
>> benefit at least one group of users and do so without any issue for
>> other users.
>
> Making all calls from C go through the symbol's function field rather
> than calling the C function directly, so as to make advice work right,
> is unlikely to happen any time soon.
> But if you have specific requests of particular functions which might
> deserve such a treatment, we might do it (tho it'll probably depend on
> the specifics).
> After all, I did do such a change myself for `expand-abbrev' in the past.

OK. So I will do some test this week-end see if it solves my problem. If
it does I will let you know.

Jérémy

-- 
Sent from my Emacs

Re: other-buffer advice on kill-buffer

[Leo]

On 2011-08-03 05:55 +0800, Richard Stallman wrote:
> It may be that in a few special cases
> we should modify calls within C code to some primitive functions
> so that they call the Lisp symbol.
> That way, it would work to advise those functions.
>
> To do this for all the primitive functions would be impossible, I
> think, and certainly not worth the pain.  But there might be a few
> functions for which this would be particularly useful, and it might be
> worth doing this for them.

I am interested in getting advice to narrow-to-region to work.

For example:

(defadvice narrow-to-region (before wow activate)
  (message "wow!"))

now uses 'C-x n d' (narrow-to-defun) which calls narrow-to-region and I
see no wow printed in the echo area.

What to do to make it work? Thanks.

Leo

Re: other-buffer advice on kill-buffer

[Chong Yidong]

Jérémy Compostella <jeremy.compostella@gmail.com> writes:

> 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)

You probably want to define a custom kill-buffer command, and bind that
command to C-x k, instead of advising kill-buffer.