[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12081: 24.1; buffer-predicate often not called
From: |
Dave Abrahams |
Subject: |
bug#12081: 24.1; buffer-predicate often not called |
Date: |
Mon, 13 Aug 2012 18:13:49 -0400 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) |
on Tue Jul 31 2012, martin rudalics <rudalics-AT-gmx.at> wrote:
>> When I kill a buffer in a particular workgroup, I want the replacement
>> buffer to be one that appeared recently in that workgroup, rather than
>> just something that's been seen recently in this frame.
>
> So a workgroup specifies a subset of all live buffers and the
> buffer-predicate you run on any of the buffers `switch-to-prev-buffer'
> proposes, sanctions the argument buffer iff it's part of that workgroup.
> Is that correct?
Almost. When a buffer is displayed, it is associated with the current
workgroup via a buffer-local variable. The buffer-predicate returns
true for any buffer associated with the current workgroup and returns
false for any others.
> This gives you little space in choosing the most suitable buffer from
> that workgroup.
True. I figure Emacs already has a heuristic for "most suitable," and
I just want it to apply that to the set of buffers whose last appearance
was in the current workgroup.
> Wouldn't it make more sense to provide a
> `switch-to-prev-buffer-function' with the window as argument and, if
> that function returns a live buffer which is not the same as the
> window's current buffer, use that buffer to replace the current one?
>
> Or maybe better: Give each window a `prev-buffer' window parameter such
> that
>
> (1) if it is a function, have `switch-to-prev-buffer' call that function
> and use its return value (in your case, the function would choose
> the buffer from the workgroup),
>
> (2) if it is a regexp or a list of buffers or names, try to use that
> list for determining the buffer to switch to (in your case, that
> list would be the buffers of the workgroup sorted acording to some
> criteria). If a buffer name in that list has no associated buffer,
> `switch-to-prev-buffer' could create one if needed.
Well, yeah, all these things make sense if you're going to go so far as
to redesign or extend Emacs itself. I was looking for a less-intrusive
solution, and to me, it seemed that the buffer predicate was simply not
working as it was supposed to.
>> Yes, I realized that only after I had implemented this. But as
>> mentioned elsewhere:
>>
>> 1. there are no obvious uses for buffer-predicate if it doesn't also
>> work for kill-buffer
>
> If the buffer predicate affects _only_ what `kill-buffer', `bury-buffer'
> or `replace-buffer-in-windows' do, then this should be reflected in the
> name of the parameter
OK
> and `other-buffer' probably should not even care about this parameter.
Why not?
>> 2. IIUC it used to work for kill-buffer, probably because kill-buffer
>> used to call other-buffer.
>
> I think so. And it would have been easier to avoid the problem we
> discuss here if the parameter had a better name and/or description.
Probably.
--
Dave Abrahams
BoostPro Computing Software Development Training
http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
- bug#12081: 24.1; buffer-predicate often not called,
Dave Abrahams <=