`buffer-list' and the frame-parameter `buffer-predicate'

`buffer-list' and the frame-parameter `buffer-predicate'

[Oliver Scholz]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

I tried to write a frame-local minor mode that was intended to provide
a feature to deal with the metric tons of buffers and that could be
useful -- in my humble opinion -- especially for beginners.

In the middle of writing this package I discovered that the whole
approach has a bug which makes it unusable. I can think of no way to
get around this, except for a change in Emacs itself. (But I may, of
course, be missing something.)

So this is the feature that I want to implement: it should be possible
to "dedicate" a frame to a certain pre-configured type of
buffers. That means that this special frame hides all buffers that it
doesn't cover.

I think, it is best explained with an example of the possible
usage. Say, I want to have two frames, one for Gnus and the other one
for all the rest of my editing. The effect of my mode should be that
all functions for buffer-listing or buffer-switching in the Gnus-frame
show only resp. apply only to the *Group*, *Summary*, *Article* and
the message-buffers, while exactly those buffer are not visible in the
other frame. In other words: it would seem as if Gnus were running in
a separate instance of Emacs, while, of course, it still _is_ the same
instance with all the benefits implied by this.

The same could be useful for Emacs/W3 (separate browser-frame), dired
(separate file-manager frame), shell-mode (separate Emacs-terms) or
whatever. I could even think of, say, frames dedicated to a certain
programming-project.

Now, my approach is to add a predicate-function to the frame-parameter
`buffer-predicate' and to advise the function `buffer-list' to return
only buffers for which this predicate function returns non-nil. This
way the mode bypasses the myriads of available buffer-switch- and
-list-functions.

The big, big problem is that this bypasses functions like
`save-buffers-kill-emacs', too. And exactly this makes it unusable.

So here is my petition: change `buffer-list' to return _always_ only
buffers for which the function in the frame-paramter 'buffer-predicate
returns non-nil. And add a second, underlying function for the
internal use in functions like `save-buffers-kill-emacs'.  Provided,
of course, that you find this feature useful enough, that you want to
add it to Emacs.

I have attached the unfinished code that I have written so far; so you
can see what I am aiming at. Or at least, that I am serious about
this.

[BTW: one thing that puzzles me: this works for functions like
`iswitchb-mode' or the according function in `ido' or for
`bs-show' and -- unfortunately -- for `save-buffers-kill-emacs'. But
not for `switch-to-buffer'.]

    -- Oliver


[-- Attachment #2: sframes.el --]
[-- Type: application/emacs-lisp, Size: 13443 bytes --]

[-- Attachment #3: Type: text/plain, Size: 72 bytes --]


-- 
29 Thermidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Robert J. Chassell]

    a frame-local minor mode ... to "dedicate" a frame to a certain
    pre-configured type of buffers.

This is a great idea!  Instead of being a spatial constraint system in
which, for example, a mode line goes below a working buffer and a
scroll bar goes on one side, this is a `concepts constraint system' in
which concepts of a given sort are held together.

I have used this sort of scheme in the past:  when I worked on images
and graphics for my neice's Web site, I switched from my usual TWM
window manager to a GNOME/sawfish window manager with four virtual
screens (or viewpoints -- I don't know the jargon).  

In one screen, I put my Emacs that showed both my `how-to add new
horse pictures to Cathy's site so she can sell them', and the source
for the Web page.  In another screen, I put the GIMP, with several
images.  In another screen, I put a graphical Web browser, so I could
see the results of my work.  I would shift among screens as I cropped
the pictures, put frames around them, added them and the accompanying
text to the page sources, and looked at them in the graphical browser.

It was convenient to put similar tasks together.

-- 
    Robert J. Chassell            bob@rattlesnake.com  bob@gnu.org
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Richard Stallman]

    for all the rest of my editing. The effect of my mode should be that
    all functions for buffer-listing or buffer-switching in the Gnus-frame
    show only resp. apply only to the *Group*, *Summary*, *Article* and
    the message-buffers, while exactly those buffer are not visible in the
    other frame. In other words: it would seem as if Gnus were running in
    a separate instance of Emacs, while, of course, it still _is_ the same
    instance with all the benefits implied by this.

Do you mean that C-x b would hide the existence of other buffers?
Would it simply refuse to show them in completion?
Would it refuse to switch to them if you specify their names?
What about C-x C-b?

The other question is, why is this feature useful?  If you want to use
a certain frame only for Gnus, you could simply choose not to switch
to any other buffer in that frame.  If that is not a sufficient
solution to the problem, could you tell me why not?

    The big, big problem is that this bypasses functions like
    `save-buffers-kill-emacs', too. And exactly this makes it unusable.

Why is that a problem?  It seems like a feature to me.

I guess the question is, are you trying to improve your own
convenience as a user, or are you trying to create a mode which will
truly "fool" a user into thinking that two separate Emacses are running?

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

>     for all the rest of my editing. The effect of my mode should be that
>     all functions for buffer-listing or buffer-switching in the Gnus-frame
>     show only resp. apply only to the *Group*, *Summary*, *Article* and
>     the message-buffers, while exactly those buffer are not visible in the
>     other frame. In other words: it would seem as if Gnus were running in
>     a separate instance of Emacs, while, of course, it still _is_ the same
>     instance with all the benefits implied by this.
>
> Do you mean that C-x b would hide the existence of other buffers?
> Would it simply refuse to show them in completion?

Yes, that's the intention.

> Would it refuse to switch to them if you specify their names?

I have not yet thought about this. Usually I insert the first two or
three characters of a buffer-name and then I "tab" my way through
until I have the full name in the minibuffer (with `switch-to-buffer')
or I start to type a part of the name until I have my buffer selected
(with `ido-switch-buffer' or `iswitch-buffer'). The "other" buffers
should stay "hidden" in a specialized frame then. But if a user
specifies the _full_ name of a buffer out of her head, then this is a
clear signal that she _really_ wants to switch to this buffer. So
ideally this should be an exception.

> What about C-x C-b?

The same. It should list only the predefined buffers of the specified
type.

> The other question is, why is this feature useful?  If you want to use
> a certain frame only for Gnus, you could simply choose not to switch
> to any other buffer in that frame.  If that is not a sufficient
> solution to the problem, could you tell me why not?

The whole idea behind this is to get the buffers sorted. It is like
keeping my stuff sorted in different drawers instead of keeping it in
one single box in the middle of my room. Or to take another metaphor:
it is like keeping my books and papers on my working desk and the food
and dishes on the dining table. If I want to work, I go to my desk,
and if I want to eat, I go to the dining table. This way I don't have
to search for a book under pizza-boxes and I don't have to rummage in
the papers to find a spoon.

Maybe I am wrong to make a conclusion from myself to others. But I
have usually about 50 buffers around and I do seldom recall the exact
name of a buffer on which I was working half an hour ago. So if I want
to switch back, it typically goes like this:

"Enough played, now back to the paper about XYZ ..."

C-x b

"No, wait, what was the name?"

<some characters> TAB

[Looking at a list of buffers] "No, that's wrong."

C-a C-k TAB

[Looking at a list of 30 to 60 buffers] "Hmm ... where is it? ..."

---

(Actually the real story is /slightly/ different, because I use `ido'
and not `switch-to-buffer'. And I am not quite so lost as this
suggests, because I have `C-x C-b' bound to `bs-show' and there
already is a mechanism in `bs-show' to limit the buffer-listing.  But
I hope this makes clear what I mean.)

Want I would like to see in Emacs is a generalized way to deal with
this. Or rather: I want to make an additional abstraction
possible. Like every abstraction this includes closing options,
i.e. it is based on negating possibilities in order to shape something
out of the continuum of possible relations. 

At it's core the idea is to make frames (_some_ of them) optionally to
/work-spaces/. I think, Robert Chassell, explained this in a better
way than I could do it.

If I -- for example -- want to add something to my personal Wiki, I go
to the "emacs-wiki" frame, where all the buffers in emacs-wiki-mode
"lie". If I want to execute a shell-command, I go to the shell-frame,
where all my shell-mode buffers "lie". If I want to learn Scheme, I go
to the Scheme-frame, where two or three *.scm file-buffers "lie",
together with the inferior-scheme-process buffer, the r5rs in an
Info-buffer and the html-version of SICP in a W3-buffer. If I want to
work on my paper about Hegel, I go to the Hegel-frame
... etc. etc. ...

Much the same as I go to the kitchen to prepare a meal and back to my
working desk to work at my computer, rather than peeling potatoes and
writing an email to the Emacs-developers on the same table.

>     The big, big problem is that this bypasses functions like
>     `save-buffers-kill-emacs', too. And exactly this makes it unusable.
>
> Why is that a problem?  It seems like a feature to me.

Suppose I have two frames. I have some modified buffers in frame A,
but I have frame B selected, which is, say, a specialized frame for
emacs-wiki and none of the Wiki buffers is modified. If I hit `C-x
C-c' now, Emacs will quit unconditionally and without offering to save
the modified buffers. All modifications are lost.

> I guess the question is, are you trying to improve your own
> convenience as a user, or are you trying to create a mode which will
> truly "fool" a user into thinking that two separate Emacses are running?

I am not sure about the wording here. I don't want to fool anyone. On
the contrary I have thought quite a bit about the user interface, but
I still think I have not yet the ideal solution to indicate visually
that there is something special with the specialized frames.

This is certainly not (only) for my own convenience. If it were only
for myself, I would neither take the pains to implement this as a
minor mode, nor bother you with it. I would simply hack something for
the functions I currently use on `C-x b' and `C-x C-b'. It would take
less time than it took to write this email.

I am not sure if I understand this question correctly.

    -- Oliver

-- 
30 Thermidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Alex Schroeder]

Perhaps you need to find the variable for ido or iswitch-buffer that
filters the buffers, and make it frame-local.  Then switching buffers
will offer different buffers based what frame you are on, without
interfering with low-level stuff.  Your idea would be limited to
user-level buffer switching.  The only problem is that you can only
implement this for buffer-switching functions that allow you to filter
the buffers.  But all interesting packages i know (iswitchb, ibuffer,
ido) allow you to do that.

Alex.

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Oliver Scholz]

Alex Schroeder <alex@emacswiki.org> writes:

> Perhaps you need to find the variable for ido or iswitch-buffer that
> filters the buffers, and make it frame-local.  Then switching buffers
> will offer different buffers based what frame you are on, without
> interfering with low-level stuff.
[...]

Yes, thank you. I will do something along these lines, if I can not
convince you all, that this is a) a useful feature and that it is b)
useful enough to justify a change in Emacs. Personally I wouldn't even
mind to redefine the critical function of my most beloved
switch-function, if necessary. I guess my main point is, that I think
this is useful as a generalized feature, regardless of the SFDJ
(Switch Function Du Jour) that someone might use.

In fact the history how I came to this idea is as follows: I have
usually six frames: one for Gnus, one for emacs-wiki-mode, one for
eshell and the shell-mode and three for everything else. I simply
maintained those "dedications" for months by refraining to switch to a
buffer of another type, as Richard Stallmann suggested. I found it
always a bit annoying, that I had to stay alert to avoid messing this
setting up. So I decided lately to hack something in my .emacs. While
I was looking up in ido.el, how to do this in the best way, it
occurred to me that something like this as an optional addition might
be an improvement to the user interface of Emacs in general. So
thought a bit about the possibilities this might offer and then I
decided to write a package. I intended to publish it on
gnu.emacs.sources. But in the middle of the work I discovered that my
approach is doomed to fail without a change to Emacs. A quick survey
on gnu.emacs.help revealed nothing better and so -- well -- here I am.

    -- Oliver

-- 
30 Thermidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Richard Stallman]

    The whole idea behind this is to get the buffers sorted. It is like
    keeping my stuff sorted in different drawers instead of keeping it in
    one single box in the middle of my room.

Now I understand.  The idea of limiting which buffers you can switch
to is not the issue, I think.  What you want to do is limit that
buffers are included in lists that are shown or offered to you.

It should be easy to do as a customization that by writing
replacements for the buffer menu commands, for list-buffers, and for
switch-to-buffer (supplying a different list for completion, perhaps).
I suggest you give these commands new names and bind them to keys as
you see fit.  That is cleaner than redefiniting the standard
functions.

As for making this a feature in Emacs, the question is whether people
can develop simple and easy-to-use ways of specifying which buffers
to list for each frame.  I think that is the crucial issue.
If those methods are simple and don't require users to remember a lot,
they could be widely used.  Otherwise they won't be used much, so it
is not worth the trouble of adding them.

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> Now I understand.  The idea of limiting which buffers you can switch
> to is not the issue, I think.  What you want to do is limit that
> buffers are included in lists that are shown or offered to you.
>
> It should be easy to do as a customization that by writing
> replacements for the buffer menu commands, for list-buffers, and for
> switch-to-buffer (supplying a different list for completion, perhaps).
> I suggest you give these commands new names and bind them to keys as
> you see fit.  That is cleaner than redefiniting the standard
> functions.

I think this is not the right solution, as there are a lot of
functions that list buffers (either as completions, like
switch-to-buffer, or as a menu, like buffer-menu).  It would be a lot
of work to change all of them, and if each one is changed
individually, the behaviors are wont to be slightly different for
each one.

For example, switch-to-buffer doesn't offer a buffer as the default
that has only been selected in another frame, but buffer-menu does.
(Most of the time, C-x b RET and M-x buffer-menu RET n RET switch to
the same buffer, but with switch-to-buffer avoiding buffers which
have been selected in another frame, the behavior becomes different.)

There should be a single function that returns the list of buffers to
be used for switching to another buffer, and all functions for
switching buffers should use this function.  Then there is one spot
to tweak in order to tweak the switching behavior.

Oliver can use this for his "frames as workspaces" idea (which is
great), and I could use this to cleanly implement flobl.el.  (This
stands for frame-local buffer list and it means that switching to a
buffer in frame X does not change the order of buffers in frame Y.)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Oliver Scholz]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Now I understand.  The idea of limiting which buffers you can switch
>> to is not the issue, I think.  What you want to do is limit that
>> buffers are included in lists that are shown or offered to you.
>>
>> It should be easy to do as a customization that by writing
>> replacements for the buffer menu commands, for list-buffers, and for
>> switch-to-buffer (supplying a different list for completion, perhaps).
>> I suggest you give these commands new names and bind them to keys as
>> you see fit.  That is cleaner than redefiniting the standard
>> functions.
>
> I think this is not the right solution, as there are a lot of
> functions that list buffers (either as completions, like
> switch-to-buffer, or as a menu, like buffer-menu).  

Just an addition:

This issue is not only related to the functions of the type
`buffer-menu' and of the type `switch-to-buffer'. It is does also
matter for packages that provide ways to cycle through the buffer-list
via simple keystrokes.

Here are a few examples from my personal Wiki:

,----
|     - buffer-stack.el
|     http://www.sixfingeredman.net/proj/xemacs/buffer-stack.el
|     Beschrieben in <aea4k1$c5i$2@wsc10.lrz-muenchen.de>.
| 
|     - ibs.el
|     http://www.geekware.de/software/emacs/ibs.el
| 
|     - swbuf.el
|     http://perso.wanadoo.fr/david.ponce/downloads/swbuff-3.1.zip
|     
|     - swbuff-advice.el
|     http://www.northbound-train.com/emacs/swbuff-advice.el
`----

[Disclaimer: Personally I have tested none of them.]

    -- Oliver

-- 
1 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: `buffer-list' and the frame-parameter `buffer-predicate'

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

[...]
> Now I understand.  The idea of limiting which buffers you can switch
> to is not the issue, I think.  What you want to do is limit that
> buffers are included in lists that are shown or offered to you.

Basically, yes. I think the behaviour of `bury-buffer', for example,
does matter, too. But basically that's it. Sorry, if I explained it in
an unclear way.

[...]
> As for making this a feature in Emacs, the question is whether people
> can develop simple and easy-to-use ways of specifying which buffers
> to list for each frame.  I think that is the crucial issue.
> If those methods are simple and don't require users to remember a lot,
> they could be widely used.  Otherwise they won't be used much, so it
> is not worth the trouble of adding them.

I see. I guess, it is up to me to invent something clever then, if I
can.

    -- Oliver

-- 
1 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!