all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.