From: Dave Abrahams <dave@boostpro.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Alp Aker <alptekin.aker@gmail.com>, 12081@debbugs.gnu.org
Subject: bug#12081: 24.1; buffer-predicate often not called
Date: Mon, 13 Aug 2012 18:13:49 -0400 [thread overview]
Message-ID: <m2628mtp7m.fsf@boostpro.com> (raw)
In-Reply-To: <501799D4.1000707@gmx.at> (martin rudalics's message of "Tue, 31 Jul 2012 10:39:48 +0200")
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
next prev parent reply other threads:[~2012-08-13 22:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-28 20:47 bug#12081: 24.1; buffer-predicate often not called Dave Abrahams
2012-07-29 13:56 ` martin rudalics
2012-07-29 15:05 ` Dave Abrahams
2012-07-29 17:08 ` martin rudalics
2012-07-29 17:31 ` Alp Aker
2012-07-29 18:24 ` Dave Abrahams
2012-07-29 21:37 ` Dave Abrahams
2012-07-29 23:30 ` Alp Aker
2012-07-29 23:53 ` Dave Abrahams
2012-07-30 9:13 ` martin rudalics
2012-07-30 9:35 ` Dave Abrahams
2012-07-30 17:42 ` martin rudalics
2012-07-30 20:13 ` Dave Abrahams
2012-07-31 8:39 ` martin rudalics
2012-08-13 22:13 ` Dave Abrahams [this message]
2012-08-14 9:09 ` martin rudalics
2012-08-14 16:07 ` Dave Abrahams
2012-07-30 16:22 ` Alp Aker
2012-07-30 16:33 ` Alp Aker
2012-07-30 17:42 ` martin rudalics
2012-07-31 6:59 ` Alp Aker
2012-07-31 8:40 ` martin rudalics
2012-08-31 17:15 ` martin rudalics
2012-09-05 14:30 ` martin rudalics
2012-07-30 17:42 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2628mtp7m.fsf@boostpro.com \
--to=dave@boostpro.com \
--cc=12081@debbugs.gnu.org \
--cc=alptekin.aker@gmail.com \
--cc=rudalics@gmx.at \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.