* `buffer-list' and the frame-parameter `buffer-predicate' @ 2002-08-16 18:27 Oliver Scholz 2002-08-16 20:15 ` Robert J. Chassell 2002-08-17 4:50 ` Richard Stallman 0 siblings, 2 replies; 10+ messages in thread From: Oliver Scholz @ 2002-08-16 18:27 UTC (permalink / raw) [-- 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é! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-16 18:27 `buffer-list' and the frame-parameter `buffer-predicate' Oliver Scholz @ 2002-08-16 20:15 ` Robert J. Chassell 2002-08-17 4:50 ` Richard Stallman 1 sibling, 0 replies; 10+ messages in thread From: Robert J. Chassell @ 2002-08-16 20:15 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-16 18:27 `buffer-list' and the frame-parameter `buffer-predicate' Oliver Scholz 2002-08-16 20:15 ` Robert J. Chassell @ 2002-08-17 4:50 ` Richard Stallman 2002-08-17 11:19 ` Oliver Scholz 1 sibling, 1 reply; 10+ messages in thread From: Richard Stallman @ 2002-08-17 4:50 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-17 4:50 ` Richard Stallman @ 2002-08-17 11:19 ` Oliver Scholz 2002-08-17 12:54 ` Alex Schroeder 2002-08-18 6:31 ` Richard Stallman 0 siblings, 2 replies; 10+ messages in thread From: Oliver Scholz @ 2002-08-17 11:19 UTC (permalink / raw) 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é! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-17 11:19 ` Oliver Scholz @ 2002-08-17 12:54 ` Alex Schroeder 2002-08-17 15:33 ` Oliver Scholz 2002-08-18 6:31 ` Richard Stallman 1 sibling, 1 reply; 10+ messages in thread From: Alex Schroeder @ 2002-08-17 12:54 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-17 12:54 ` Alex Schroeder @ 2002-08-17 15:33 ` Oliver Scholz 0 siblings, 0 replies; 10+ messages in thread From: Oliver Scholz @ 2002-08-17 15:33 UTC (permalink / raw) 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é! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-17 11:19 ` Oliver Scholz 2002-08-17 12:54 ` Alex Schroeder @ 2002-08-18 6:31 ` Richard Stallman 2002-08-18 17:24 ` Kai Großjohann 2002-08-18 18:26 ` Oliver Scholz 1 sibling, 2 replies; 10+ messages in thread From: Richard Stallman @ 2002-08-18 6:31 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-18 6:31 ` Richard Stallman @ 2002-08-18 17:24 ` Kai Großjohann 2002-08-18 21:12 ` Oliver Scholz 2002-08-18 18:26 ` Oliver Scholz 1 sibling, 1 reply; 10+ messages in thread From: Kai Großjohann @ 2002-08-18 17:24 UTC (permalink / raw) Cc: alkibiades, emacs-devel 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) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-18 17:24 ` Kai Großjohann @ 2002-08-18 21:12 ` Oliver Scholz 0 siblings, 0 replies; 10+ messages in thread From: Oliver Scholz @ 2002-08-18 21:12 UTC (permalink / raw) 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é! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: `buffer-list' and the frame-parameter `buffer-predicate' 2002-08-18 6:31 ` Richard Stallman 2002-08-18 17:24 ` Kai Großjohann @ 2002-08-18 18:26 ` Oliver Scholz 1 sibling, 0 replies; 10+ messages in thread From: Oliver Scholz @ 2002-08-18 18:26 UTC (permalink / raw) 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é! ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-08-18 21:12 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-08-16 18:27 `buffer-list' and the frame-parameter `buffer-predicate' Oliver Scholz 2002-08-16 20:15 ` Robert J. Chassell 2002-08-17 4:50 ` Richard Stallman 2002-08-17 11:19 ` Oliver Scholz 2002-08-17 12:54 ` Alex Schroeder 2002-08-17 15:33 ` Oliver Scholz 2002-08-18 6:31 ` Richard Stallman 2002-08-18 17:24 ` Kai Großjohann 2002-08-18 21:12 ` Oliver Scholz 2002-08-18 18:26 ` Oliver Scholz
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.