* Neat features in Eclipse editor @ 2008-03-22 21:45 Richard Stallman 2008-03-22 21:56 ` Chong Yidong ` (2 more replies) 0 siblings, 3 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-22 21:45 UTC (permalink / raw) To: emacs-devel; +Cc: Paul Michael Reilly I just got a demo of the Eclipse editor and saw these features which we should have in Emacs. * Having tabs above a window to switch buffers in it. * "Perspectives" are named persistent window configurations. We have had the window configuration mechanism in GNU Emacs since the beginning but we have never developed a good user interface to take advantage of them. Eclipse's user interface seems to be good. * Perspectives work well even if you do the equivalent of C-x 4 C-f because of the distinction between view windows vs file windows. In Emacs this is more or less the "dedicated window" feature, but we have never really made it work for this. * Perspectives also need to interact with the tabs. * Imenu could be extended into a file-structure browsing mechanism using code like that of customize-groups. * Flymake's customization mechanism needs to be both simpler (fewer levels of indirection) and better documented, so it is easier to understand. I find it quite hard to figure out what compilation command it will use. I suggest totally rewriting that part of Flymake, using the simplest mechanism that sufficies for the specific needs. That will be easy for users to customize. * Display something in the margin on lines that have compilation errors. * Compilation error navigation bar, parallel to the scroll bar, indicating where in the buffer there are compilation errors. Perhaps we could arrange to display these error indications on top of the scroll bar itself. That depends on to what extent toolkit scroll bars are extensible. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:45 Neat features in Eclipse editor Richard Stallman @ 2008-03-22 21:56 ` Chong Yidong 2008-03-22 21:36 ` Tom Tromey ` (4 more replies) 2008-03-24 1:51 ` Dan Nicolaescu 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov 2 siblings, 5 replies; 141+ messages in thread From: Chong Yidong @ 2008-03-22 21:56 UTC (permalink / raw) To: rms; +Cc: Paul Michael Reilly, emacs-devel Richard Stallman <rms@gnu.org> writes: > * "Perspectives" are named persistent window configurations. We have > had the window configuration mechanism in GNU Emacs since the > beginning but we have never developed a good user interface to take > advantage of them. Eclipse's user interface seems to be good. Well, we already have `C-x r w R' (window-configuration-to-register) and `C-x r f R' (frame-configuration-to-register) for saving window configurations, and `C-x r j R' for restoring them. Though it's true that this could certainly be more user-friendly. Maybe the simplest way to do this is to add a "window configuration" submenu to the File menu on the menu-bar. What kind of user interface does Eclipse provide for this? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:56 ` Chong Yidong @ 2008-03-22 21:36 ` Tom Tromey 2008-03-22 23:09 ` Leo ` (3 subsequent siblings) 4 siblings, 0 replies; 141+ messages in thread From: Tom Tromey @ 2008-03-22 21:36 UTC (permalink / raw) To: Chong Yidong; +Cc: Paul Michael Reilly, rms, emacs-devel >>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes: >> * "Perspectives" are named persistent window configurations. We have >> had the window configuration mechanism in GNU Emacs since the >> beginning but we have never developed a good user interface to take >> advantage of them. Eclipse's user interface seems to be good. Chong> What kind of user interface does Eclipse provide for this? The user interface for a perspective is that there is a list of perspectives on a toolbar-ish thing (the overflow turns into a dropdown menu). Clicking switches perspectives. As I recall for some operations, Eclipse will automatically switch perspectives for you. I think the first time it will ask if you want this behavior in the future; e.g. if you run the debugger, it will switch to the debug perspective and ask if you want to always do that when debugging. In a perspective you can rearrange the various sub-windows; Eclipse just remembers where you put everything, plus what is open or closed. In case it matters, in Eclipse a perspective is more than just an Emacs window configuration; a perspective can change the content of various views. Perspectives tend to be kind of heavyweight, as well. E.g., in the Java perspective, the file browser thingy will by default show a java package/class-based view rather than a strictly file-based view. At least, this is my recollection. I haven't used Eclipse this past year, but I did use it daily for a couple years before that. Most distros package Eclipse these days. It isn't hard to give it a whirl :-) Tom ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:56 ` Chong Yidong 2008-03-22 21:36 ` Tom Tromey @ 2008-03-22 23:09 ` Leo 2008-03-23 14:18 ` William Xu 2008-03-23 2:27 ` Juri Linkov ` (2 subsequent siblings) 4 siblings, 1 reply; 141+ messages in thread From: Leo @ 2008-03-22 23:09 UTC (permalink / raw) To: Chong Yidong; +Cc: Paul Michael Reilly, rms, emacs-devel On 2008-03-22 21:56 +0000, Chong Yidong wrote: > Well, we already have `C-x r w R' (window-configuration-to-register) > and `C-x r f R' (frame-configuration-to-register) for saving window > configurations, and `C-x r j R' for restoring them. These commands also save the marker in each buffer at the time of saving the configuration, not at the time the configuration is destroyed. Therefore, I find myself surprised at the position of the cursor after restoring the configuration. -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the best OS -- http://www.fedoraproject.org/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 23:09 ` Leo @ 2008-03-23 14:18 ` William Xu 0 siblings, 0 replies; 141+ messages in thread From: William Xu @ 2008-03-23 14:18 UTC (permalink / raw) To: emacs-devel Leo <sdl.web@gmail.com> writes: > These commands also save the marker in each buffer at the time of saving > the configuration, not at the time the configuration is > destroyed. Therefore, I find myself surprised at the position of the > cursor after restoring the configuration. Same here. It'd be better to update the configuration at the time of destroying old configuration. -- William http://williamxu.net9.org 点绛唇 王禹 雨恨云愁,江南依旧称佳丽。 水村渔市,一缕孤烟细。 天际征鸿,遥认行如缀。 平生事,此时凝睇,谁会恁栏意! ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:56 ` Chong Yidong 2008-03-22 21:36 ` Tom Tromey 2008-03-22 23:09 ` Leo @ 2008-03-23 2:27 ` Juri Linkov 2008-03-23 9:53 ` joakim 2008-03-24 0:53 ` Richard Stallman 2008-03-25 0:48 ` Bastien 4 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-03-23 2:27 UTC (permalink / raw) To: Chong Yidong; +Cc: Paul Michael Reilly, rms, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1568 bytes --] >> * "Perspectives" are named persistent window configurations. We have >> had the window configuration mechanism in GNU Emacs since the >> beginning but we have never developed a good user interface to take >> advantage of them. Eclipse's user interface seems to be good. > > Well, we already have `C-x r w R' (window-configuration-to-register) > and `C-x r f R' (frame-configuration-to-register) for saving window > configurations, and `C-x r j R' for restoring them. > > Though it's true that this could certainly be more user-friendly. > Maybe the simplest way to do this is to add a "window configuration" > submenu to the File menu on the menu-bar. I use such Emacs configuration where there is only one full-size Emacs frame. But it is practically impossible to use Emacs without an equivalent of Emacs frames that group a set of Emacs windows into separate frame units. So window configurations are real saver for me. But using window configurations is limited to a few inconvenient commands like `C-x r w' and `C-x r j'. So I wrote a package that displays a list of all recorded window configurations and allows to easily switch between them. It works like a list of windows in many window managers: when you type a key (e.g. M-TAB), it displays a list of window configurations (windows in window managers), another key switches to the selected window configuration. Below is the source code of this package. Initially it was part of the ee package, but I rewrote it based on buff-menu.el to remove dependencies, so now it is a standalone package. [-- Attachment #2: wincows.el --] [-- Type: application/emacs-lisp, Size: 10258 bytes --] [-- Attachment #3: Type: text/plain, Size: 45 bytes --] -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 2:27 ` Juri Linkov @ 2008-03-23 9:53 ` joakim 2008-03-23 10:50 ` martin rudalics ` (3 more replies) 0 siblings, 4 replies; 141+ messages in thread From: joakim @ 2008-03-23 9:53 UTC (permalink / raw) To: emacs-devel Juri Linkov <juri@jurta.org> writes: >>> * "Perspectives" are named persistent window configurations. We have >>> had the window configuration mechanism in GNU Emacs since the >>> beginning but we have never developed a good user interface to take >>> advantage of them. Eclipse's user interface seems to be good. Eclipse, and nearly all other IDE:s also have the feature that the main frame is sub-divided in minor frames that dont affect each other. That is, I have an editor sub-frame, and a compilation message sub-frame etc. If I remove an editor tab in the editor sub-frame, this doesnt affect the other parts of the master frame. The Emacs ECB package is designed to do all of this in Emacs. It has been discussed for inclusion. It uses lots and lots of advice to achive the sub-frame feature. Recently I did a small review of the code to see if it would be possible for me to remove the advice, by providing suitable hooks in Emacs. It did not apear immediately obvious how to do this. I'm now thinking it would be easier to start by providing a C level interface, and then adjust the ECB to use this interface. Heres what I thought could be done: - Create a new Emacs window object called a sub-frame. This sits between frames and windows. It nominaly provides a list of windows like a frame does and is normaly the same list of windows the frame has. A frame can have several sub-frames, but at the start only one. When no sub-frame features are used, emacs behaves exactly as it does today. - as an example, I now create 2 subframes called left and right. When I'm in the left sub-frame and do other-window, I only jump between windows in the left sub-frame. Likewise for the right sub-frame. When I do delete-other-windows, only other windows in the sub-frame goes away. Again, this is achieved by all window functions looking at the list of windows in the sub-frame structure rather than the frame structure. Moving between sub-frames needs a new function similar to other-frame. Does this sound at all feasible? -- Joakim Verona ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 9:53 ` joakim @ 2008-03-23 10:50 ` martin rudalics 2008-03-23 10:54 ` martin rudalics ` (2 subsequent siblings) 3 siblings, 0 replies; 141+ messages in thread From: martin rudalics @ 2008-03-23 10:50 UTC (permalink / raw) To: joakim; +Cc: emacs-devel joakim@verona.se schrieb: > Juri Linkov <juri@jurta.org> writes: > > >>>>* "Perspectives" are named persistent window configurations. We have >>>>had the window configuration mechanism in GNU Emacs since the >>>>beginning but we have never developed a good user interface to take >>>>advantage of them. Eclipse's user interface seems to be good. > > > Eclipse, and nearly all other IDE:s also have the feature that the main > frame is sub-divided in minor frames that dont affect each other. > > That is, I have an editor sub-frame, and a compilation message sub-frame > etc. If I remove an editor tab in the editor sub-frame, this doesnt > affect the other parts of the master frame. > > The Emacs ECB package is designed to do all of this in Emacs. It has been > discussed for inclusion. It uses lots and lots of advice to achive the > sub-frame feature. Recently I did a small review of the code to see if > it would be possible for me to remove the advice, by providing suitable > hooks in Emacs. It did not apear immediately obvious how to do this. > > I'm now thinking it would be easier to start by providing a C > level interface, and then adjust the ECB to use this interface. > > Heres what I thought could be done: > > - Create a new Emacs window object called a sub-frame. This sits between > frames and windows. It nominaly provides a list of windows like a frame > does and is normaly the same list of windows the frame has. A frame can > have several sub-frames, but at the start only one. When no sub-frame > features are used, emacs behaves exactly as it does today. > > - as an example, I now create 2 subframes called left and right. When > I'm in the left sub-frame and do other-window, I only jump between > windows in the left sub-frame. Likewise for the right sub-frame. When I > do delete-other-windows, only other windows in the sub-frame goes away. > > Again, this is achieved by all window functions looking at the list of > windows in the sub-frame structure rather than the frame structure. > > Moving between sub-frames needs a new function similar to other-frame. > > Does this sound at all feasible? > ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 9:53 ` joakim 2008-03-23 10:50 ` martin rudalics @ 2008-03-23 10:54 ` martin rudalics 2008-03-23 19:35 ` John S. Yates, Jr. 2008-03-24 0:53 ` Stefan Monnier 2008-03-24 0:54 ` Richard Stallman 3 siblings, 1 reply; 141+ messages in thread From: martin rudalics @ 2008-03-23 10:54 UTC (permalink / raw) To: joakim; +Cc: emacs-devel Apologies for the previous mail. > - Create a new Emacs window object called a sub-frame. This sits between > frames and windows. It nominaly provides a list of windows like a frame > does and is normaly the same list of windows the frame has. A frame can > have several sub-frames, but at the start only one. When no sub-frame > features are used, emacs behaves exactly as it does today. > > - as an example, I now create 2 subframes called left and right. When > I'm in the left sub-frame and do other-window, I only jump between > windows in the left sub-frame. Likewise for the right sub-frame. When I > do delete-other-windows, only other windows in the sub-frame goes away. > > Again, this is achieved by all window functions looking at the list of > windows in the sub-frame structure rather than the frame structure. > > Moving between sub-frames needs a new function similar to other-frame. > > Does this sound at all feasible? It wouldn't be difficult, at least. The more hairy aspect is that you probably want to create new subframes below/right or above/left of existing ones. I modified windows.c appropriately to do this for what I call "window combos". In your parlance these are subframes consisting of a left and right (or upper and lower) window only. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 10:54 ` martin rudalics @ 2008-03-23 19:35 ` John S. Yates, Jr. 2008-03-23 19:39 ` Thomas Lord ` (2 more replies) 0 siblings, 3 replies; 141+ messages in thread From: John S. Yates, Jr. @ 2008-03-23 19:35 UTC (permalink / raw) To: emacs-devel Since the subject of buffers, windows, frames and their management is up for a bit of serious brainstorming I want to bring up the great surge of interest in tiling window managers. Thriving examples include dwm http://www.suckless.org/wiki/dwm awesome http://awesome.naquadah.org/ xmonad http://www.xmonad.org/ Drew's OneOnOne efforts have pushed in the direction of moving away from a collection of emacs managed windows within a single frame.But IIUC the model he is pursuing tends towards a bunch of overlapping (cascaded?) shrunk-to-fit frames. Nonetheless, Drew has identified a number of ways in which emacs remains seriously biased toward reusing a small number of windows within a single frame. I suggest that dynamically managed tiling is deeply ingrained in the emacs model. Reaching an accommodation with these tiling window managers could be a liberating event. It would free emacs from having to offer ever richer window management and window layout capabilities. And it would make the wealth of these rapidly evolving window managers available for laying out emacs windows (frames). Further, it would allow other windows that the user might have open to participate in screen layout on an equal footing with those belonging to emacs. /john ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 19:35 ` John S. Yates, Jr. @ 2008-03-23 19:39 ` Thomas Lord 2008-03-23 21:06 ` John S. Yates, Jr. 2008-03-23 19:49 ` Drew Adams 2008-03-25 8:11 ` dtm 2 siblings, 1 reply; 141+ messages in thread From: Thomas Lord @ 2008-03-23 19:39 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: emacs-devel Even better, add a few functions to emacs and turn it into an X11 window manager, extensible in self-documenting lisp. Consider the root window as a frame. "And you're so close..." -- Triple Rock Brewery -t John S. Yates, Jr. wrote: > Since the subject of buffers, windows, frames and their management is up for a > bit of serious brainstorming I want to bring up the great surge of interest in > tiling window managers. Thriving examples include > > dwm http://www.suckless.org/wiki/dwm > awesome http://awesome.naquadah.org/ > xmonad http://www.xmonad.org/ > > Drew's OneOnOne efforts have pushed in the direction of moving away from a > collection of emacs managed windows within a single frame.But IIUC the model > he is pursuing tends towards a bunch of overlapping (cascaded?) shrunk-to-fit > frames. Nonetheless, Drew has identified a number of ways in which emacs > remains seriously biased toward reusing a small number of windows within a > single frame. > > I suggest that dynamically managed tiling is deeply ingrained in the emacs > model. Reaching an accommodation with these tiling window managers could be a > liberating event. It would free emacs from having to offer ever richer window > management and window layout capabilities. And it would make the wealth of > these rapidly evolving window managers available for laying out emacs windows > (frames). Further, it would allow other windows that the user might have open > to participate in screen layout on an equal footing with those belonging to > emacs. > > /john > > > > ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 19:39 ` Thomas Lord @ 2008-03-23 21:06 ` John S. Yates, Jr. 2008-03-23 21:42 ` Thomas Lord 0 siblings, 1 reply; 141+ messages in thread From: John S. Yates, Jr. @ 2008-03-23 21:06 UTC (permalink / raw) To: Thomas Lord; +Cc: emacs-devel Thomas Lord writes: >Even better, add a few functions to emacs and turn it into an >X11 window manager, extensible in self-documenting lisp. >Consider the root window as a frame. Has already been done: http://www.emacswiki.org/cgi-bin/wiki/XWindowEmacsManager The problem is that a few functions alone do not a polished window manager make. Do you honestly believe that the emacs community would find the expertise, the focus and the bandwidth to match any of the projects that I cited? I am sure that it would do a competent job organizing and laying out emacs windows. I have much less confidence that the idiosyncrasies of windows displayed by the full panoply of non-emacs applications would receive comparable attention. There is also an important argument against having emacs at the bottom of the stack. So long as emacs remains single threaded both window and input event management would likely freeze each time emacs became busy. /john ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 21:06 ` John S. Yates, Jr. @ 2008-03-23 21:42 ` Thomas Lord 0 siblings, 0 replies; 141+ messages in thread From: Thomas Lord @ 2008-03-23 21:42 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2742 bytes --] John S. Yates, Jr. wrote: > Thomas Lord writes: > > >> Even better, add a few functions to emacs and turn it into an >> X11 window manager, extensible in self-documenting lisp. >> Consider the root window as a frame. >> > > Has already been done: > > http://www.emacswiki.org/cgi-bin/wiki/XWindowEmacsManager > Thanks for the pointer. That looks like a nice attempt. It's interesting that the author "confesses" uncertainty about how to handle windows from random clients because I think that's one of the areas it's easy to wrong. I'm skeptical of the idea of trying to equivocate a managed client with something like a frame. But yes, that's the general direction. > The problem is that a few functions alone do not a polished window manager > make. Totally true. I have no argument with that. > Do you honestly believe that the emacs community would find the > expertise, the focus and the bandwidth to match any of the projects that I > cited? No, I don't *believe* it might. I honestly *wonder* if it might. It seems plausible to me. > I am sure that it would do a competent job organizing and laying out > emacs windows. I have much less confidence that the idiosyncrasies of windows > displayed by the full panoply of non-emacs applications would receive > comparable attention. > I agree that that's the hard part. I am thinking there are probably several 10s of pages of very tediously detailed code to get right. > There is also an important argument against having emacs at the bottom of the > stack. So long as emacs remains single threaded both window and input event > management would likely freeze each time emacs became busy. > > Yes. That's serious and I'm encouraged that you brought that up. I can think of two architectural approaches that might help with that problem. One approach is to make the "Emacs-as-WM" dedicated to mostly just that. Yes, it might leverage its text-editor functionality in lots of ways, but that isn't the Emacs process that user's use for anything *but* being a WM. It's still single threaded -- but it doesn't ever get "busy". Another approach is that, sure, the WM-Emacs is your main Emacs and yes, it still is annoyingly single threaded with pauses etc.... *but*... window management is driven indirectly. There is some external process that Emacs talks to. That external process is some simple kind of state machine that knows how to move windows around, paint frames in parent windows, etc..... but that is basically "table driven". The parent Emacs asyncronously changes the rules that that other process uses but, meanwhile, that other process is handling X window mgt. without pausing. -t > /john > > > > [-- Attachment #2: Type: text/html, Size: 4120 bytes --] ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Neat features in Eclipse editor 2008-03-23 19:35 ` John S. Yates, Jr. 2008-03-23 19:39 ` Thomas Lord @ 2008-03-23 19:49 ` Drew Adams 2008-03-25 8:11 ` dtm 2 siblings, 0 replies; 141+ messages in thread From: Drew Adams @ 2008-03-23 19:49 UTC (permalink / raw) To: 'John S. Yates, Jr.', 'emacs-devel' > Drew's OneOnOne efforts have pushed in the direction of > moving away from a collection of emacs managed windows > within a single frame. But IIUC the model he is pursuing > tends towards a bunch of overlapping (cascaded?) > shrunk-to-fit frames. Nonetheless, Drew has identified > a number of ways in which emacs remains seriously biased > toward reusing a small number of windows within a > single frame. Thanks for the plug, John. ;-) http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs To be clear, my own preference is for buffers to be displayed in their own frame, _by default_. "By default" means that (1) I still switch buffers in a frame (windows are not all dedicated, as in Stefan's case, IIUC) and (2) I split windows sometimes. IOW, nothing in my approach prevents you from using different buffers in the same frame, and nothing prevents you from having multiple windows in a frame. It's just that, by default, when a buffer is displayed, it gets its own window-manager (wm) window. In the parlance of the sites you cited, this apparently means that I use "floating", as opposed to tiled, wm windows. As those sites recognize, floating wm windows give users and applications the greatest liberty in frame sizing and positioning. Each of the sites you cited apparently supports not only tiled wm windows but floating windows, and two of the sites (which are apparently related) even use floating wm windows by default for some kinds of wm windows ("popup" windows). This indicates that while some people like tiling for some wm windows in some contexts, tiling is apparently not appropriate for all contexts. That's my view too: (1) multiple Emacs windows within a frame are of course tiled, and (2) I provide code for tiling frames across or down your screen (yes, that is not as general as the tiling referred to above). I use frame tiling, for instance, for ediff. My only point wrt Emacs development is that Emacs is biased toward displaying buffers in windows but not in their own frame. This bias manifests itself in temporary buffer displays such as *Help* and *Completions* and in other ways. The single, crude control knob that users have for changing this behavior is option `pop-up-frames'. But simply setting that to non-nil will not give a workable one-buffer-per-frame Emacs. In fact, it will bring you a host of secondary problems - vanilla Emacs just doesn't play very well with non-nil `pop-up-frames'. Some of the problems have to do with frame focus, but not all. Assumptions about UI interactions that are inappropriate for use with one-buffer-per-frame seem to be hard-coded. Hence battles over disposing of unneeded buffers and windows (buffer burying vs killing, view-mode quitting, etc.). It is also true that if you adopt an approach of using wm windows for buffers, then to some extent Emacs loses control and you have to deal with the particular wm you have. Some focus problems are in this category. Anyway, I've been using Emacs this way since the days of Epoch, which also introduced me to a standalone minibuffer frame. I haven't looked back since. I don't recall having had any of the frame-related problems I see in GNU Emacs when I used Epoch - it just worked. But that was a long time ago, and I might simply have forgotten the problems. Also, I was on Unix, not Windows, back then - perhaps that made a difference too. In any case, as they say, "Finie, la Belle Epoque!" ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 19:35 ` John S. Yates, Jr. 2008-03-23 19:39 ` Thomas Lord 2008-03-23 19:49 ` Drew Adams @ 2008-03-25 8:11 ` dtm 2 siblings, 0 replies; 141+ messages in thread From: dtm @ 2008-03-25 8:11 UTC (permalink / raw) To: emacs-devel >>>>> "JSY" == John S Yates, <john@yates-sheets.org> writes: JSY> Since the subject of buffers, windows, frames and their JSY> management is up for a bit of serious brainstorming I want to JSY> bring up the great surge of interest in tiling window managers. JSY> Thriving examples include JSY> dwm http://www.suckless.org/wiki/dwm JSY> awesome http://awesome.naquadah.org/ JSY> xmonad http://www.xmonad.org/ Until I started using a tiling window manager, Emacs frames were mostly useless. Tiling window managers automatically place and size windows. No need to think about where to place new windows (frames)...or where to find them later. They just appear and you continue working. Using a tiling window manager with Emacs frames feels kind of like navigating Emacs windows in a single frame. But navigation is much easier than typing "C-x 5 o" several times. All of the tiling window managers I've used have very good keyboard support. Here's my current setup for creating new frames: (defconst tiling-window-manager-p (and (equal window-system 'x) (if (member (getenv "WM_CMD") '("awesome" "awm" "clfswm" "dwm" "ion" "larswm" "parti" "ratpoison" "stumpwm" "subtle" "tritium" "trswm" "whaw" "wmii" "xmonad")) t)) "Is a tiling window manager being used?") (if tiling-window-manager-p (setq special-display-buffer-names '("*Apropos*" ;; "*Backtrace*" ;; "*Help*" "*compilation*" "*grep*" "*ielm*" "*info*" "*mail*" "*tex-shell*") special-display-regexps '("\\*Man.*\\*" ;; "\\*gud.*\\*" "\\*shell\\*.*" ;; "\\*sldb.*\\*" "\\*slime-repl.*\\*"))) -- dtm ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 9:53 ` joakim 2008-03-23 10:50 ` martin rudalics 2008-03-23 10:54 ` martin rudalics @ 2008-03-24 0:53 ` Stefan Monnier 2008-03-24 0:54 ` Richard Stallman 3 siblings, 0 replies; 141+ messages in thread From: Stefan Monnier @ 2008-03-24 0:53 UTC (permalink / raw) To: joakim; +Cc: emacs-devel > The Emacs ECB package is designed to do all of this in Emacs. It has been > discussed for inclusion. It uses lots and lots of advice to achive the > sub-frame feature. Recently I did a small review of the code to see if > it would be possible for me to remove the advice, by providing suitable > hooks in Emacs. It did not apear immediately obvious how to do this. There are a few packages that like to take control of a frame and display various windows inside. Gnus and gdb-ui come to mind. Similarly, users (and commands by default) often like to control the frame as a whole, without much regard for the various windows already present, assuming that minor changes aren't important as long as the user can adjust them later. ECB's effort in this is very valuable. It would be good to provide some kind of functionality to make ECB's task easier and to make it possible for users to give a sub-part of a frame to Gnus. I'm not sure if that should be provided via a new concept of "subframe", or by making it possible to collocate several frames together (within the same GUI window). Maybe a lightweight approach would be to be able to tag each and every window with a "subframe" property, such that a "subframe" is simply the set of windows with the same "subframe" value. The only problem with all of that, is the added complexity. E.g. Are we going to have a family of functions FOO-BAR-other-subframe? Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-23 9:53 ` joakim ` (2 preceding siblings ...) 2008-03-24 0:53 ` Stefan Monnier @ 2008-03-24 0:54 ` Richard Stallman 2008-03-24 19:02 ` joakim 3 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-24 0:54 UTC (permalink / raw) To: joakim; +Cc: emacs-devel Eclipse, and nearly all other IDE:s also have the feature that the main frame is sub-divided in minor frames that dont affect each other. Could you explain more concretely what these "minor frames" look like, and what "don't affect each other" means? That is, I have an editor sub-frame, and a compilation message sub-frame etc. If I remove an editor tab in the editor sub-frame, this doesnt affect the other parts of the master frame. When I try to relate this to what I saw, it seems that what you call "sub-frames" looked like windows to me. Why do you call them "sub-frames" instead of "windows"? The term "sub-frames" implies a big change. To give each window in its own list of tabs would be a fairly small change in Emacs (assuming that we have tabs at all). Is more than that needed? - Create a new Emacs window object called a sub-frame. This sits between frames and windows. It nominaly provides a list of windows like a frame does and is normaly the same list of windows the frame has. A frame can have several sub-frames, but at the start only one. When no sub-frame features are used, emacs behaves exactly as it does today. This seems like a plausible implementation of a sub-frame feature. Do we really need this feature, or would it be enough to give each window its own list of tabs? When I do delete-other-windows, only other windows in the sub-frame goes away. If most of the windows are dedicated, delete-other-windows would not touch them. Is that sufficient for the job? If not, here's a simple way to take care of that. Emacs windows within a frame form a tree. We could add a way to mark a certain non-leaf window as a "sub-frame", such that when the selected window is a subwindow of that, certain operations including delete-other-windows would be limited to the inside of that sub-frame. This could be a rather simple change to implement sub-frames, if we need the power of sub-frames. Is this enough to implement perspectives? Adding a new data type with new operations is certainly possible, but it is expensive in several ways, so we should do that only if a simpler adequate solution can't be found. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 0:54 ` Richard Stallman @ 2008-03-24 19:02 ` joakim 2008-03-25 1:06 ` Bastien 2008-03-25 1:50 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: joakim @ 2008-03-24 19:02 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > Eclipse, and nearly all other IDE:s also have the feature that the main > frame is sub-divided in minor frames that dont affect each other. > > Could you explain more concretely what these "minor frames" look like, > and what "don't affect each other" means? I will try. Imagine several Emacs frames that are laid out next to each other, for instance like this: +---+-------------+ | 1 | 2 | | | | | | | +---+-------------+ | 3 | +-----------------+ Frame 1 contains the emacs Speedbar, which gives a tree view of code, which is displayed in frame 2. frame 3 shows compilation output. This is similar to what ECB does, and also a common Eclipse perspective. > That is, I have an editor sub-frame, and a compilation message sub-frame > etc. If I remove an editor tab in the editor sub-frame, this doesnt > affect the other parts of the master frame. > > When I try to relate this to what I saw, it seems that what you call > "sub-frames" looked like windows to me. Why do you call them > "sub-frames" instead of "windows"? The term "sub-frames" implies a > big change. > > To give each window in its own list of tabs would be a fairly small > change in Emacs (assuming that we have tabs at all). > > Is more than that needed? Sub-frames are not like windows, they are like frames, because they contain windows and are not affected by what happens in other frames. Tabs are usually complementary to the feature I try describe. > > - Create a new Emacs window object called a sub-frame. This sits between > frames and windows. It nominaly provides a list of windows like a frame > does and is normaly the same list of windows the frame has. A frame can > have several sub-frames, but at the start only one. When no sub-frame > features are used, emacs behaves exactly as it does today. > > This seems like a plausible implementation of a sub-frame feature. Do > we really need this feature, or would it be enough to give each window > its own list of tabs? > > When I > do delete-other-windows, only other windows in the sub-frame goes away. > > If most of the windows are dedicated, delete-other-windows would not > touch them. Is that sufficient for the job? Maybe. I can't recall an Emacs application that uses dedicated windows right now, so I'm not sure how they function in practice. > If not, here's a simple way to take care of that. > > Emacs windows within a frame form a tree. We could add a way to mark > a certain non-leaf window as a "sub-frame", such that when the > selected window is a subwindow of that, certain operations including > delete-other-windows would be limited to the inside of that sub-frame. > > This could be a rather simple change to implement sub-frames, if we > need the power of sub-frames. > > Is this enough to implement perspectives? Sounds plausible. I didnt know Emacs windows existed in a tree structure. > > Adding a new data type with new operations is certainly possible, > but it is expensive in several ways, so we should do that only > if a simpler adequate solution can't be found. I agree of course. -- Joakim Verona ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 19:02 ` joakim @ 2008-03-25 1:06 ` Bastien 2008-03-25 18:31 ` Richard Stallman 2008-03-25 1:50 ` Richard Stallman 1 sibling, 1 reply; 141+ messages in thread From: Bastien @ 2008-03-25 1:06 UTC (permalink / raw) To: joakim; +Cc: rms, emacs-devel joakim@verona.se writes: > Sub-frames are not like windows, they are like frames, because they > contain windows and are not affected by what happens in other frames. (Maybe using "workspace" instead of "sub-frames" might help clarifying things a bit.) > Tabs are usually complementary to the feature I try describe. The first time I talked about "workspaces" was when I tried to explain my use of tabs with elscreen: http://article.gmane.org/gmane.emacs.devel/87765 Sorry for the self-quote, but it sounds like ideas there can help describe a workspace from yet another perspective: ,----[ http://article.gmane.org/gmane.emacs.devel/87765 ] | It seems to me that, in this discussion, we should really talk about | "workspaces" - not "tabs". Or at least we could disambiguate these and | use "tab" for the visual UI feature and "workspace" for the underlying | window configuration (and the properties we would like to attach to it.) | | I use elscreen to easily *cycle* through workspaces and to easily | *create* new ones. | | Having "workspaces" (or whatever you want to call them) would be very | useful for letting variables be local to them. For example I use this: | | (make-variable-buffer-local 'search-ring) | | but this would make more sense in a workspace rather than in a buffer. | | Or see the function `erc-iswitchb': it restricts the list of buffers to | the one that are used by ERC. I've implemented something like this for | Org as well. If you use ERC in a dedicated workspace, then the notion | of "ERC buffers" is really an instance of the more general notion of | "This workspace buffers." `---- -- Bastien ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 1:06 ` Bastien @ 2008-03-25 18:31 ` Richard Stallman 2008-03-25 19:19 ` Rajappa Iyer 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-25 18:31 UTC (permalink / raw) To: Bastien; +Cc: joakim, emacs-devel In Eclipse, a list of tabs is associated with a specific window and each tab selects a buffer in that window. That seems to be the natural feature for tabs. Would someone like to implement window tabs as a UI feature? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 18:31 ` Richard Stallman @ 2008-03-25 19:19 ` Rajappa Iyer 2008-03-26 1:33 ` Stefan Monnier 2008-03-26 4:46 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: Rajappa Iyer @ 2008-03-25 19:19 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > In Eclipse, a list of tabs is associated with a specific window > and each tab selects a buffer in that window. > > That seems to be the natural feature for tabs. > Would someone like to implement window tabs as a UI feature? I might be missing something, but isn't tabbar.el sufficient? http://www.emacswiki.org/cgi-bin/wiki/TabBarMode From tabbar.el: ;; Buffer tabs ;; ----------- ;; ;; The default tab bar implementation provided displays buffers in ;; dedicated tabs. Selecting a tab, switch (mouse-1), or pop ;; (mouse-2), to the buffer it contains. ;; ;; The list of buffers put in tabs is provided by the function ;; specified in the variable `tabbar-buffer-list-function'. The ;; default function: `tabbar-buffer-list', excludes buffers whose name ;; starts with a space, when they are not visiting a file. ;; ;; Buffers are organized in groups, each one represented by a tab set. ;; A buffer can have no group, or belong to more than one group. The ;; function specified by the variable `tabbar-buffer-groups-function' ;; is called for each buffer to obtain the groups it belongs to. The ;; default function provided: `tabbar-buffer-groups' organizes buffers ;; depending on their major mode (see that function for details). ;; ;; The "home" button toggles display of buffer groups on the tab bar, ;; allowing to easily show another buffer group by clicking on the ;; associated tab. rsi ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 19:19 ` Rajappa Iyer @ 2008-03-26 1:33 ` Stefan Monnier 2008-03-26 4:46 ` Richard Stallman 1 sibling, 0 replies; 141+ messages in thread From: Stefan Monnier @ 2008-03-26 1:33 UTC (permalink / raw) To: Rajappa Iyer; +Cc: emacs-devel >> In Eclipse, a list of tabs is associated with a specific window >> and each tab selects a buffer in that window. >> >> That seems to be the natural feature for tabs. >> Would someone like to implement window tabs as a UI feature? > I might be missing something, but isn't tabbar.el sufficient? > http://www.emacswiki.org/cgi-bin/wiki/TabBarMode It might be a good idea to include this in Emacs. We should be able to place a tabbar at any level of the window-tree by placing the tabbars inside their own window. I.e. a frame-level tabbar (to allow switching between different window-configurations) could be obtained by slitting the frame as +-----------------------------+ | single-line tabbar window | +------------+----------------+ | | | | | | | window | other | | | window | | | | | | | +------------+----------------+ Of course, this may require some tweaks to work right: e.g. C-x 1 should not throw away the tabbar. -- Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 19:19 ` Rajappa Iyer 2008-03-26 1:33 ` Stefan Monnier @ 2008-03-26 4:46 ` Richard Stallman 1 sibling, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-26 4:46 UTC (permalink / raw) To: Rajappa Iyer; +Cc: emacs-devel I might be missing something, but isn't tabbar.el sufficient? I don't know. I find its documentation hard to understand, so I am not sure what it does. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 19:02 ` joakim 2008-03-25 1:06 ` Bastien @ 2008-03-25 1:50 ` Richard Stallman 2008-04-18 13:25 ` joakim 1 sibling, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-25 1:50 UTC (permalink / raw) To: joakim; +Cc: emacs-devel Imagine several Emacs frames that are laid out next to each other, for instance like this: +---+-------------+ | 1 | 2 | | | | | | | +---+-------------+ | 3 | +-----------------+ Ok, but why can't 1, 2 and 3 be windows? That would be a much simpler change than adding a new kind of entity. What usage scenario makes it necessary for these to be more than single windows? I am not saying there isn't one. I'm asking to look the intended usage in order to see which solutions are adequate. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 1:50 ` Richard Stallman @ 2008-04-18 13:25 ` joakim 2008-04-19 2:23 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: joakim @ 2008-04-18 13:25 UTC (permalink / raw) To: rms, emacs-devel Richard Stallman <rms@gnu.org> writes: > Imagine several Emacs frames that are laid out next to each other, for > instance like this: > > +---+-------------+ > | 1 | 2 | > | | | > | | | > +---+-------------+ > | 3 | > +-----------------+ > > Ok, but why can't 1, 2 and 3 be windows? > That would be a much simpler change than adding a new > kind of entity. > > What usage scenario makes it necessary for these to be more > than single windows? > > I am not saying there isn't one. I'm asking to look the intended > usage in order to see which solutions are adequate. 1,2,3 can be windows if they have special properties. Heres a simpler example I wanted to code today, but failed because I couldnt find a suitable Emacs feature(maybe there is one) - 1,2 are normal Emacs windows - 3 is a dedicated emacs window, containing a special "frame status" buffer. This buffer is like a mode-line, but contains mode-line entries like date-time, that I dont want to have in every window mode-line. - I dont want other-window to enter window 3, ever. - I dont want delete-other-windows to delete window 3, ever. The ECB basically lets you create windows like 3 above. It does this by using advice on Emacs primitives heavily. Is this example clearer? Are there existing Emacs primitives to achieve this? -- Joakim Verona ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-04-18 13:25 ` joakim @ 2008-04-19 2:23 ` Richard Stallman 0 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-04-19 2:23 UTC (permalink / raw) To: joakim; +Cc: emacs-devel - 3 is a dedicated emacs window, containing a special "frame status" buffer. This buffer is like a mode-line, but contains mode-line entries like date-time, that I dont want to have in every window mode-line. - I dont want other-window to enter window 3, ever. - I dont want delete-other-windows to delete window 3, ever. You want the window to be dedicated, and never selected except explicitly, and never deleted except explicitly. I don't think there are existing features for the latter two, but it should be easy enough to add them at the C level. I think that is the right approach. Perhaps the cleanest way is to give each window a plist to specify whether various operations should consider it. It could have a `delete-other-windows' property and a `select-window' property and a `display-buffer' property, and the values of these properties would control whether those operations can use this window. The new `display-buffer' property could be equivalent to the existing "dedicated" flag. That would mean it affects some other primitives aside from `display-buffer', but that is ok. There is no need to be rigid about the relationship between these properties and primitives they affect. People might find various ways to improve this idea by tweaking details. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:56 ` Chong Yidong ` (2 preceding siblings ...) 2008-03-23 2:27 ` Juri Linkov @ 2008-03-24 0:53 ` Richard Stallman 2008-03-24 18:47 ` paul r 2008-03-25 0:48 ` Bastien 4 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-24 0:53 UTC (permalink / raw) To: Chong Yidong; +Cc: pmr, emacs-devel > * "Perspectives" are named persistent window configurations. We have > had the window configuration mechanism in GNU Emacs since the > beginning but we have never developed a good user interface to take > advantage of them. Eclipse's user interface seems to be good. Well, we already have `C-x r w R' (window-configuration-to-register) and `C-x r f R' (frame-configuration-to-register) for saving window configurations, and `C-x r j R' for restoring them. The difference is subtle but crucial. Selecting a perspective in Eclipse is like selecting a buffer: if you change the buffer contents, the changes are permanent in that buffer. If you switch away and switch back, you see what you last put in that buffer, once again. Likewise, changes you make in the layout of a perspective permanently alter that perspective. The changes persist between sessions too. There are also several initially defined perspectives that are useful for specific purposes. What we have now is a bare-bones feature that isn't really useful. Perspectives are a convenient feature that really is useful. Perhaps there is no "fundamental" difference, but the UI difference is all the difference in the world. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 0:53 ` Richard Stallman @ 2008-03-24 18:47 ` paul r 2008-03-25 1:50 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: paul r @ 2008-03-24 18:47 UTC (permalink / raw) To: rms; +Cc: pmr, Chong Yidong, emacs-devel 2008/3/24, Richard Stallman <rms@gnu.org>: > Likewise, changes you make in the layout of a perspective permanently > alter that perspective. The changes persist between sessions too. > > There are also several initially defined perspectives that are useful > for specific purposes. > > What we have now is a bare-bones feature that isn't really useful. > Perspectives are a convenient feature that really is useful. > Perhaps there is no "fundamental" difference, but the UI difference > is all the difference in the world. > In case of interest, you can find below a very simple package that does basically that. As I tend to use it intensively, I made it so that this operation requires minimal keystrokes. A workspace is a windows configuration. Each workspace is bound to a key. Any char is acceptable for it. So use 'm' for mail, 'e' for elisp, d for documentation ... well up to you. Workspace-goto is bound on C-c C-d by default. A key must follow. - Backspace kills current workspace. - Tab shows workspaces list. - Space swaps workspaces forth and back. - Enter restore current workspace. - Any other key creates this 'key' workspace You might notice that, in order to reduce the noise generated by global functions and global bindings, only variables and functions that constitute the interface are accessible. The rest is enclosed in a closure. This closure currently makes use of CL lexical facilities. We talked a bit about that in the recent "lexbind" thread. You can safely try it, it's easy to use. ;; DEFINITION ;;----------- ;; ;; Multi-workspaces ;; Author : Paul Rivier <paul dot r dot ml at gmail dot com> ;; ;; Load this file, then use C-c C-d [any character] to switch to workspace specified ;; Special keys are : ;; - TAB to show workspaces list ;; - space to swap with last workspace ;; - DEL to kill current workspace ;; - RET to restore current workspace to its saved state ;;;;;;;;;;;;;;;;;; ;; DEPENDENCIES ;; ;;;;;;;;;;;;;;;;;; (eval-when-compile (require 'cl)) ;;;;;;;;;;;;;;; ;; VARIABLES ;; ;;;;;;;;;;;;;;; (defvar current-workspace nil "Workspace you are currently in") (defvar default-workspace ?1 "This workspace will be created at init time. You can not delete this workspace. When killing a workspace, you fallback to default-workspace.") (defvar workspaces-list nil "List of open workspaces") ;;;;;;;;;;;;;;;;;;;;; ;; GLOBAL BINDINGS ;; ;;;;;;;;;;;;;;;;;;;;; (global-set-key "\C-c\C-d" 'workspace-goto) ;;;;;;;;;;;;;;; ;; FUNCTIONS ;; ;;;;;;;;;;;;;;; (lexical-let ((last-workspace default-workspace)) ;; above : vars -- below : functions (labels ((workspaces-list-sort () ;; "Sort list workspaces-list, save and return it." (setq workspaces-list (sort workspaces-list (lambda (a b) (< (car a) (car b)))))) (workspaces-list-add (wsid) ;; "Add current configuration to workspaces list under wsid." (setq workspaces-list (cons (cons wsid (current-window-configuration)) workspaces-list)) (workspaces-list-sort)) (workspace-save-current () ;; "Save current workspace." (workspace-delete current-workspace) (workspaces-list-add current-workspace)) (workspace-delete (wsid) ;; "Delete workspace wsid." (setq workspaces-list (assq-delete-all wsid workspaces-list))) (workspaces-id-list () ;; "Return a list of workspaces ids." (mapcar #'car workspaces-list)) (workspace-create-new (wsid) ;; "Create a new workspace with id wsid." (workspace-goto ?0) (workspaces-list-add wsid) (workspace-goto wsid)) (workspace-kill-current () ;; "kill the workspace you are currently in" (if (not (or (eq current-workspace default-workspace) (eq current-workspace ?0))) (let ((cws current-workspace) (lws last-workspace)) (workspace-goto default-workspace) (workspace-delete cws) (setq last-workspace default-workspace) (concat "\nWorkspace " (char-to-string cws) " killed")) (concat "\nSpecial workspaces " (char-to-string current-workspace) " can not be killed"))) (workspace-exists-p (wsid) ;; "Return t if workspace wsid exists." (when (assoc wsid workspaces-list) t))) ;; externaly bound functions (defun workspaces-init () "Initialize workspaces-list and others" (setq workspaces-list nil) (workspaces-list-add ?0) (setq current-workspace ?0) (workspace-goto-or-create default-workspace)) (defun workspace-goto-or-create (wsid) "If workspace wsid exists, goto it, else create it." (if (workspace-exists-p wsid) (workspace-goto wsid) (workspace-create-new wsid))) (defun workspace-goto (wsid) "Go to another workspace, wsid is workspace identifier. wsid can be any character, except those mentioned below. Workspace 0 is a template workspace, do not use it unless you know what you do. Hit TAB to have workspaces list. You can kill a workspace with 'k', you will fallback on default workspace." (interactive "cTo which workspace do you want to go ? ") (let ((wscfgcons (assoc wsid workspaces-list)) (special "")) (if wscfgcons (progn (unless (eq wsid current-workspace) (workspace-save-current)) (set-window-configuration (cdr wscfgcons)) (unless (or (eq current-workspace ?0) (eq wsid current-workspace)) (setq last-workspace current-workspace)) (setq current-workspace wsid) (when (eq wsid ?0) (setq special "\n!-!-! This is template workspace. New workspaces are based on it."))) ;; Workspace does not exist, it might be a special key (cond ((eq wsid 9) ; 9 is TAB ()) ((eq wsid 13) ; 13 is RET (workspace-goto current-workspace) (workspace-save-current)) ((eq wsid 32) ; 32 is space (workspace-goto last-workspace)) ((eq wsid 127) ; 127 is DEL (backspace) (setq special (workspace-kill-current))) ;; it is not a special key, create workspace (t (when (y-or-n-p "This workspace does not exist, should it be created ? ") (workspace-create-new wsid))))) (message (concat "Now on workspace " (char-to-string current-workspace) "\nWorkspaces list is : " (mapconcat 'char-to-string (remq ?0 (workspaces-id-list)) " ") special)))) )) ;;;;;;;;;;; ;; HOOKS ;; ;;;;;;;;;;; ;; base workspaces 0 and default are created at startup only (unless workspaces-list (workspaces-init)) ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 18:47 ` paul r @ 2008-03-25 1:50 ` Richard Stallman 2008-03-25 3:53 ` Window configuration UI (was: Neat features in Eclipse editor) Stefan Monnier 2008-03-25 10:08 ` Neat features in Eclipse editor paul r 0 siblings, 2 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-25 1:50 UTC (permalink / raw) To: paul r; +Cc: pmr, cyd, emacs-devel When you switch from workspace A to workspace B, does your current window configuration get recorded as workspace A? That is an important aspect of Eclipse perspectives. But just switching between named window configurations is only part of the feature. The configurations should have names, not single letters. And it needs to be possible to get all the right behavior. For instance, we want GUD to be able to take advantage of this, with a predefined "gud" perspective. This predefined "gud" perspective should have a window for displaying source, and windows for displaying other things. Each window should have tabs for switching between the various things you can view in that window. Your code might be the start of this feature, but a convenient smooth perspectives feature would do a lot more than this. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Window configuration UI (was: Neat features in Eclipse editor) 2008-03-25 1:50 ` Richard Stallman @ 2008-03-25 3:53 ` Stefan Monnier 2008-03-25 10:54 ` Window configuration UI Lennart Borgman (gmail) ` (2 more replies) 2008-03-25 10:08 ` Neat features in Eclipse editor paul r 1 sibling, 3 replies; 141+ messages in thread From: Stefan Monnier @ 2008-03-25 3:53 UTC (permalink / raw) To: rms; +Cc: pmr, cyd, paul r, emacs-devel > When you switch from workspace A to workspace B, does your current > window configuration get recorded as workspace A? > That is an important aspect of Eclipse perspectives. Indeed. Try out my naive attempt at it (see attached) immediately bumps into a significant problem: window-configurations are frame-specific, so I can't create a winconf "test1" in a frame and then use it in another frame. > needs to be possible to get all the right behavior. For instance, we > want GUD to be able to take advantage of this, with a predefined "gud" > perspective. This predefined "gud" perspective should have a window This is another problem: window-configurations can't be saved&loaded. I.e. the tool we need is not `window-configuration' but some other object. We can construct it all in Elisp from window-tree, but someone needs to write the code. Stefan ;; Window config management (defvar winconf-alist nil) (defvar winconf-hist nil) (defun switch-to-winconf (conf-name) (interactive (let* ((oldname (frame-parameter nil 'winconf-name)) (comp (remove (assoc oldname winconf-alist) winconf-alist))) (list (completing-read (format "Switch winconf from %s to: " (or oldname "<none>")) comp nil (when winconf-alist 'confirm-only) nil 'winconf-hist)))) (let* ((oldname (frame-parameter nil 'winconf-name)) (oldconf (assoc oldname winconf-alist)) (newconf (assoc conf-name winconf-alist))) (when oldname (if oldconf (setcdr oldconf (current-window-configuration)) (push (cons oldname (current-window-configuration)) winconf-alist))) (if newconf (set-window-configuration (cdr newconf))) (set-frame-parameter nil 'winconf-name conf-name))) ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-25 3:53 ` Window configuration UI (was: Neat features in Eclipse editor) Stefan Monnier @ 2008-03-25 10:54 ` Lennart Borgman (gmail) 2008-03-25 18:13 ` Stefan Monnier 2008-03-26 4:47 ` Window configuration UI (was: Neat features in Eclipse editor) Richard Stallman 2008-03-31 2:41 ` Window configuration UI (was: Neat features in Eclipse editor) Nick Roberts 2 siblings, 1 reply; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-25 10:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: pmr, cyd, paul r, rms, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1060 bytes --] Stefan Monnier wrote: >> When you switch from workspace A to workspace B, does your current >> window configuration get recorded as workspace A? >> That is an important aspect of Eclipse perspectives. > > Indeed. Try out my naive attempt at it (see attached) immediately bumps > into a significant problem: window-configurations are frame-specific, so > I can't create a winconf "test1" in a frame and then use it in > another frame. > >> needs to be possible to get all the right behavior. For instance, we >> want GUD to be able to take advantage of this, with a predefined "gud" >> perspective. This predefined "gud" perspective should have a window > > This is another problem: window-configurations can't be saved&loaded. > I.e. the tool we need is not `window-configuration' but some > other object. We can construct it all in Elisp from window-tree, but > someone needs to write the code. When we last talked about that I wrote the attached file. I have not looked at it or used it for a while so I am not sure if everything works right now. [-- Attachment #2: winsav.el --] [-- Type: text/plain, Size: 21271 bytes --] ;;; winsav.el --- Save and restore window structure ;; ;; Author: Lennart Borgman ;; Created: Sun Jan 14 00:27:19 2007 ;; Version: 0.70 ;; Last-Updated: Wed Jan 09 00:50:22 2008 (3600 +0100) ;; Keywords: ;; Compatibility: ;; ;; Features that might be required by this library: ;; ;; `cl'. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Commentary: ;; ;; This library was orignally written to solve the problem of adding a ;; window to the left of some windows in a frame ;; ;; ___________ ;; | | | ;; | 1 | 2 | ;; |____|____| ;; | | ;; | 3 | ;; |_________| ;; ;; so that the window structure on the frame becomes ;; ;; ___________ ;; | | | | ;; | | 1| 2 | ;; | B|__|___| ;; | A| | ;; | R| 3 | ;; |__|______| ;; ;; ;; This problem can be solved by this library. However the solution in ;; this library is a bit more general: You first copy the window ;; structure and then restore that into another window. To do the ;; above you first copy the window structure in the first frame above ;; with `winsav-get-window-tree'. Then you create windows like this: ;; ;; ___________ ;; | | | ;; | | | ;; | B| | ;; | A| | ;; | R| | ;; |__|______| ;; ;; ;; Finally you use `winsav-put-window-tree' to put the window ;; structure into the right window. (Of course you could have put BAR ;; above, under etc.) ;; ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Bugs and limitations: ;; ;; Juanma Barranquero has pointed out there is a serious limitation in ;; this way of doing it when overlays with 'window properties are ;; used. The problem is that any pointers to windows are made invalid ;; since they are deleted. So in fact any code that relies on saved ;; pointers to windows will have problem if the window is one of those ;; that are involved here. ;; ;; To overcome this problem when doing something like inserting a BAR ;; window (see above) a new window has to be inserted in the existing ;; window tree on a frame in a way that is currently not supported in ;; Emacs. ;; ;; It would be nice to be have primitives to manipulate the window ;; tree more generally from elisp. That requires implementation of ;; them at the C level of course. ;; ;; However it is probably much easier to implement it quite a bit less ;; general. The concept of splitting is maybe then the right level to ;; search for primitives at. ;; ;; My conclusion is that it will take some time to find suitable ;; primitives for this. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Change log: ;; ;; Version 0.71: ;; ;; - Added rotation of window structure. ;; ;; Version 0.70: ;; ;; - Support for save and restore from file. ;; ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; This program is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with this program; see the file COPYING. If not, write to the ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Code: (eval-when-compile (require 'cl)) (defun winsav-upper-left-window(&optional frame w) (let* ((tree (if w w (car (window-tree frame)))) (is-split (not (windowp tree)))) (if (not is-split) tree (winsav-upper-left-window frame (nth 2 tree))))) (defvar winsav-after-get-hooks nil "Hook to run after at the end of `winsav-get-window-tree'. The functions in this hook are called with one parameter which is the same as the return value from the function above.") (defvar winsav-after-put-hooks nil "Hook to run after at the end of `winsav-put-window-tree'. The functions in this hook are called with one parameter which is a list where each element is a list \(old-win new-win) where OLD-WIN are the window from `winsav-get-window-tree' and NEW-WIN is the newly created corresponding window. This list is the same as the return value from the function above.") (defun winsav-get-window-tree(&optional frame) "Get window structure. This returns an object with current windows with values, buffers, points and the selected window. FRAME is the frame to save structure from. If nil use selected. At the very end of this function the hook `winsav-after-get' is run." (let* ((upper-left (winsav-upper-left-window)) (num -1) sel-num) (dolist (w (window-list frame nil upper-left)) (setq num (1+ num)) (when (eq w (selected-window)) (setq sel-num num))) (let ((ret (list sel-num (winsav-get-window-tree-1 frame nil)))) (run-hook-with-args 'winsav-after-get-hooks ret) ret))) (defun winsav-get-window-tree-1(frame w) (let ((tree (if w w (car (window-tree frame))))) (if (windowp tree) (list (window-buffer tree) (format "Buffer: %s" (let ((bn (buffer-file-name (window-buffer tree)))) (if bn bn (window-buffer tree)))) (window-point tree) (window-edges tree) (window-dedicated-p tree) (window-scroll-bars tree) (window-fringes tree) (window-margins tree) (window-hscroll tree) (window-redisplay-end-trigger tree) (window-start tree) tree) (let* ((dir (nth 0 tree)) (split (nth 1 tree)) (wt (cddr tree)) (wsubs (mapcar (lambda(wc) (winsav-get-window-tree-1 nil wc)) wt))) (append (list dir split) wsubs))))) (defun winsav-put-window-tree (saved-tree window &optional copy-win-ovl win-ovl-all-bufs) "Put window structure into WINDOW. Restore a structure SAVED-TREE returned from `winsav-get-window-tree' into window WINDOW. If COPY-WIN-OVL is non-nil then overlays having a 'window property pointing to one of the windows in SAVED-TREE where this window still is shown will be copied to a new overlay with 'window property pointing to the corresponding new window. If WIN-OVL-ALL-BUFS is non-nil then all buffers will be searched for overlays with a 'window property of the kind above. At the very end of this function the hook `winsav-after-put' is run." (let* ((sel-num (nth 0 saved-tree)) (tree (nth 1 saved-tree)) nsiz nh nw osiz oh ow scale-w scale-h first-win winsav-put-return) (unless (or (bufferp (car tree)) (eq 'buffer (car tree))) (setq nsiz (window-edges window)) (setq nh (- (nth 3 nsiz) (nth 1 nsiz))) (setq nw (- (nth 2 nsiz) (nth 0 nsiz))) (setq osiz (cadr tree)) (setq oh (- (nth 3 osiz) (nth 1 osiz))) (setq ow (- (nth 2 osiz) (nth 0 osiz))) (setq scale-w (unless (= ow nw) (/ nw (float ow)))) (setq scale-h (unless (= oh nh) (/ nh (float oh))))) (setq first-win (winsav-put-window-tree-1 tree window scale-w scale-h t 1)) (select-window first-win) (other-window sel-num) (winsav-fix-win-ovl winsav-put-return copy-win-ovl win-ovl-all-bufs) (run-hook-with-args 'winsav-after-put-hooks winsav-put-return) winsav-put-return)) (defun winsav-put-window-tree-1 (saved-tree window scale-w scale-h first-call level) ;;(if (bufferp (car saved-tree)) (if (or (bufferp (car saved-tree)) ;;(not (car saved-tree)) (eq 'buffer (car saved-tree)) ) (let ((buffer (nth 0 saved-tree)) (bufstr (nth 1 saved-tree)) (point (nth 2 saved-tree)) (edges (nth 3 saved-tree)) (dedic (nth 4 saved-tree)) (scroll (nth 5 saved-tree)) (fringe (nth 6 saved-tree)) (margs (nth 7 saved-tree)) (hscroll (nth 8 saved-tree)) (trigger (nth 9 saved-tree)) (start (nth 10 saved-tree)) (ovlwin (nth 11 saved-tree)) scr2 (misbuf " *Winsav information: Buffer is gone*")) (or (windowp ovlwin) (not ovlwin) (error "parameter mismatch, ovlwin not window: %s" ovlwin)) (when first-call (add-to-list 'winsav-put-return (list ovlwin window)) (when (eq 'buffer buffer) (let ((buf-file bufstr)) (setq buf-file (substring buf-file 8)) (setq buffer (winsav-find-file-noselect buf-file)))) (unless (buffer-live-p buffer) (setq buffer (get-buffer-create misbuf)) (with-current-buffer buffer (when (= 0 (length (buffer-string))) (insert "The buffer that this window should show is gone:\n\n") (put-text-property (point-min) (1- (point-max)) 'face 'font-lock-warning-face) (setq buffer-read-only t)) (let ((o (make-overlay (point-max) (point-max)))) (overlay-put o 'window window) (overlay-put o 'before-string bufstr)))) (set-window-buffer window buffer) (set-window-point window point) (set-window-dedicated-p window dedic) ;; Strange incompatibility in scroll args: (setq scr2 (list (nth 0 scroll) (nth 2 scroll) (nth 3 scroll))) (apply 'set-window-scroll-bars (append (list window) scr2)) (apply 'set-window-fringes (append (list window) fringe)) (set-window-margins window (car margs) (cdr margs)) (set-window-hscroll window hscroll) (set-window-redisplay-end-trigger window trigger)) (unless (buffer-live-p buffer) (setq point 1) (setq start 1)) (set-window-start window start) ;; Maybe point got off screen? (when (/= point (window-point window)) (set-window-point window point)) (let* ((nsiz (window-edges window)) (nh (- (nth 3 nsiz) (nth 1 nsiz))) (nw (- (nth 2 nsiz) (nth 0 nsiz))) (osiz edges) ;(nth 2 saved-tree)) (oh (- (nth 3 osiz) (nth 1 osiz))) (ow (- (nth 2 osiz) (nth 0 osiz))) (diff-w (- (if scale-w (round (* scale-w ow)) ow) nw)) (diff-h (- (if scale-h (round (* scale-h oh)) oh) nh))) ;; Avoid rounding naggings: (when (> (abs diff-h) 1) (bw-adjust-window window diff-h nil)) (when (> (abs diff-w) 1) (bw-adjust-window window diff-w t))) window) (let* ((ver (car saved-tree)) (wtree (list (cons window (caddr saved-tree)))) (nwin window) pwin pdelta (first-win nwin)) ;; First split to get it in correct order (when first-call (dolist (subtree (cdddr saved-tree)) (setq pwin nwin) (message "nwin edges=%s, ver=%s" (window-edges nwin) ver) (let ((split-err nil) (window-min-height 1) (window-min-width 1)) (setq nwin (split-window nwin nil (not ver)))) ;; Make the previous window as small as permitted to allow ;; splitting as many times as possible (setq pdelta (- (if ver window-min-height window-min-width) (if ver (window-width pwin) (window-height pwin)))) ;;(message "pwin=%s, edges=%s, pdelta=%s, ver=%s" pwin (window-edges pwin) pdelta ver) ;; No reason to fail here: (condition-case err (adjust-window-trailing-edge pwin pdelta (not ver)) (error ;;(message "awt=>%s" (error-message-string err)) nil )) ;; Add to traverse (add-to-list 'wtree (cons nwin subtree) t))) ;; Now traverse. Sizing is a bit tricky, multiple runs have to ;; be done (as in balance-windows). (let (tried-sizes last-sizes (windows (window-list (selected-frame)))) (while (not (member last-sizes tried-sizes)) (when last-sizes (setq tried-sizes (cons last-sizes tried-sizes))) (setq last-sizes (mapcar (lambda (w) (window-edges w)) windows)) (dolist (wsub (reverse wtree)) (select-window (car wsub)) (winsav-put-window-tree-1 (cdr wsub) (selected-window) scale-w scale-h first-call (1+ level) )) (setq first-call nil) )) first-win))) (defun winsav-fix-win-ovl(win-list copy-win-ovl win-ovl-all-bufs) (let ((oldwins (mapcar (lambda(elt) (car elt)) win-list)) ovlwin window) (let (buffers) (if win-ovl-all-bufs (setq buffers (buffer-list)) (mapc (lambda(w) (when (window-live-p w) (add-to-list 'buffers (window-buffer w)))) oldwins)) (dolist (buf buffers) (with-current-buffer buf (save-restriction (widen) (dolist (overlay (overlays-in (point-min) (point-max))) (when (setq ovlwin (car (memq (overlay-get overlay 'window) oldwins))) (setq window (cadr (assoc ovlwin win-list))) ;; If the old window is still alive then maybe copy ;; overlay, otherwise change the 'window prop. However ;; copy only if COPY-WIN-OVL is non-nil. (if (not (and (window-live-p ovlwin) (window-frame ovlwin))) (overlay-put overlay 'window window) (when copy-win-ovl (let* ((props (overlay-properties overlay)) (start (overlay-start overlay)) (end (overlay-end overlay)) ;; Fix-me: start and end marker props (newovl (make-overlay start end))) (while props (let ((key (car props)) (val (cadr props))) (setq props (cddr props)) (when (eq key 'window) (setq val window)) (overlay-put newovl key val)))))))))))))) ;;; Window rotating and mirroring (defun winsav-rotate (mirror transpose) "Rotate window configuration on selected frame. MIRROR should be either 'mirror-left-right, 'mirror-top-bottom or nil. In the first case the window configuration is mirrored vertically and in the second case horizontally. If MIRROR is nil the configuration is not mirrored. If TRANSPOSE is non-nil then the window structure is transposed along the diagonal from top left to bottom right (in analogy with matrix transosition). If called interactively MIRROR will is 'mirror-left-right by default, but 'mirror-top-bottom if called with prefix. TRANSPOSE is t. This mean that the window configuration will be turned one quarter clockwise (or counter clockwise with prefix)." (interactive (list (if current-prefix-arg 'mirror-left-right 'mirror-top-bottom) t)) (let* ((wintree (winsav-get-window-tree)) (tree (cadr wintree)) (win-config (current-window-configuration))) ;;(winsav-log "old-wintree" wintree) (winsav-transform-1 tree mirror transpose) ;;(winsav-log "new-wintree" wintree) ;; ;; Fix-me: Stay in corresponding window. How? (delete-other-windows) (condition-case err (winsav-put-window-tree wintree (selected-window)) (error (set-window-configuration win-config) (message "Can't rotate: %s" (error-message-string err)))) )) (defun winsav-transform-edges (edges) (let ( (le (nth 0 edges)) (te (nth 1 edges)) (re (nth 2 edges)) (be (nth 3 edges))) (list te le be re))) (defun winsav-transform-1 (tree mirror transpose) (let* ((vertical (nth 0 tree)) (edges (nth 1 tree)) (subtrees (nthcdr 2 tree)) ) ;;(winsav-log "tree 1" tree) (when transpose (cond ((eq vertical nil) (setcar tree t)) ((eq vertical t) (setcar tree nil)) (t (error "Uh? vertical=%S" vertical)))) (setcar (nthcdr 1 tree) (winsav-transform-edges edges)) (dolist (subtree subtrees) (if (bufferp (car subtree)) (when transpose (let ((edges (nth 3 subtree))) ;;(winsav-log "subtree 1" subtree) (setcar (nthcdr 3 subtree) (winsav-transform-edges edges)) ;;(winsav-log "subtree 2" subtree) )) (winsav-transform-1 subtree mirror transpose))) (when (case mirror ('mirror-top-bottom vertical) ('mirror-left-right (not vertical)) (nil) ;; Don't mirror (t (error "Uh? mirror=%s" mirror))) (setcdr (nthcdr 1 tree) (reverse subtrees)) ) )) ;;(global-set-key [f11] 'winsav-rotate) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; winsav+.el ends here ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;; TEST ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; (defun winsav-log-buffer () ;; (get-buffer-create "winsav log buffer")) ;; (defun winsav-log (mark obj) ;; (with-current-buffer (winsav-log-buffer) ;; (insert "=== " mark "===\n" (pp-to-string obj)))) ;; (global-set-key [f2] 'winsav-test-get) ;; (global-set-key [f3] 'winsav-test-put) ;; (defvar winsav-saved-window-tree nil) ;; (defun winsav-test-get() ;; (interactive) ;; (setq winsav-saved-window-tree (winsav-get-window-tree))) ;; (defun winsav-test-put() ;; (interactive) ;; (let ((ret (winsav-put-window-tree winsav-saved-window-tree ;; (selected-window)))) ;; ;;(message "ret=%s" ret) ;; )) (defun winsav-serialize (obj) (prin1-to-string obj)) (defun winsav-de-serialize (str) (save-match-data (let ((read-str (replace-regexp-in-string (rx "#<buffer " (1+ (not (any ">"))) ">") "buffer" str)) obj-last obj last) (setq read-str (replace-regexp-in-string (rx "#<window " (1+ (not (any ">"))) ">") "nil" read-str)) (setq obj-last (read-from-string read-str)) (setq obj (car obj-last)) (setq last (cdr obj-last)) ;; Fix me, maby check there are only spaces left (or trim them above...) obj))) (defun winsav-serialize-to-file (obj file) (with-current-buffer (find-file-noselect file) (erase-buffer) (insert (winsav-serialize obj)) (save-buffer))) (defun winsav-de-serialize-from-file (file) (with-current-buffer (find-file-noselect file) (save-restriction (goto-char (point-min)) (winsav-de-serialize (buffer-substring-no-properties (point-min) (point-max)))))) (defun winsav-save-frame-to-file (file frame) (serialize-to-file (winsav-get-window-tree frame) file)) (defun winsav-restore-from-file (file) (winsav-put-window-tree (winsav-de-serialize-from-file file) (selected-window))) (defun winsav-find-file-noselect (filename) (let ((buf (find-file-noselect filename))) (unless buf (setq buf (generate-new-buffer filename)) (with-current-buffer buf (insert "Winsav could not find the file " filename) (set-buffer-modified-p nil))) buf)) ;; (defun test () ;; (let ((obj (list "a" 1 "b" 2))) ;; (equal (de-serialize (serialize obj)) ;; obj))) (provide 'winsav) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; winsav.el ends here ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-25 10:54 ` Window configuration UI Lennart Borgman (gmail) @ 2008-03-25 18:13 ` Stefan Monnier 0 siblings, 0 replies; 141+ messages in thread From: Stefan Monnier @ 2008-03-25 18:13 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: pmr, cyd, paul r, rms, emacs-devel >>> When you switch from workspace A to workspace B, does your current >>> window configuration get recorded as workspace A? >>> That is an important aspect of Eclipse perspectives. >> >> Indeed. Try out my naive attempt at it (see attached) immediately bumps >> into a significant problem: window-configurations are frame-specific, so >> I can't create a winconf "test1" in a frame and then use it in >> another frame. >> >>> needs to be possible to get all the right behavior. For instance, we >>> want GUD to be able to take advantage of this, with a predefined "gud" >>> perspective. This predefined "gud" perspective should have a window >> >> This is another problem: window-configurations can't be saved&loaded. >> I.e. the tool we need is not `window-configuration' but some >> other object. We can construct it all in Elisp from window-tree, but >> someone needs to write the code. > When we last talked about that I wrote the attached file. I have not looked > at it or used it for a while so I am not sure if everything works right now. That looks interesting. I'm wondering about the window-identity problems: where did they bite? I.e. what caused you to code up all the overlay-hacks? I see there's another problem in the part that saves the data to a file: we need to use `bookmarks' to save the buffer&position. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI (was: Neat features in Eclipse editor) 2008-03-25 3:53 ` Window configuration UI (was: Neat features in Eclipse editor) Stefan Monnier 2008-03-25 10:54 ` Window configuration UI Lennart Borgman (gmail) @ 2008-03-26 4:47 ` Richard Stallman 2008-03-26 9:41 ` Window configuration UI Lennart Borgman (gmail) 2008-03-31 2:41 ` Window configuration UI (was: Neat features in Eclipse editor) Nick Roberts 2 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-26 4:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: pmr, cyd, paul.r.ml, emacs-devel > When you switch from workspace A to workspace B, does your current > window configuration get recorded as workspace A? > That is an important aspect of Eclipse perspectives. Indeed. Try out my naive attempt at it (see attached) immediately bumps into a significant problem: window-configurations are frame-specific, so I can't create a winconf "test1" in a frame and then use it in another frame. Moving window configurations from frame to frame is not necessary for the perspectives feature. Perspectives in Eclipse seem to be part of one frame, although I am not sure of that. > needs to be possible to get all the right behavior. For instance, we > want GUD to be able to take advantage of this, with a predefined "gud" > perspective. This predefined "gud" perspective should have a window This is another problem: window-configurations can't be saved&loaded. That's a real issue, directly related to implementing perspectives. To make perspectives persistent we need a way for Lisp code to get access to the data in them. In 1984 it was crucial for a window configuration to include window objects to make it fast to switch to one. But that may not be necessary now. So we could reimplement window configurations using Lisp objects that hold the data in a transparent way. Would someone like to try this? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-26 4:47 ` Window configuration UI (was: Neat features in Eclipse editor) Richard Stallman @ 2008-03-26 9:41 ` Lennart Borgman (gmail) 2008-03-26 22:26 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-26 9:41 UTC (permalink / raw) To: rms; +Cc: pmr, cyd, paul.r.ml, Stefan Monnier, emacs-devel Richard Stallman wrote: > In 1984 it was crucial for a window configuration to include window > objects to make it fast to switch to one. But that may not be > necessary now. So we could reimplement window configurations > using Lisp objects that hold the data in a transparent way. > > Would someone like to try this? I attached some code a few days ago. Will that code help? (winsav.el) ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-26 9:41 ` Window configuration UI Lennart Borgman (gmail) @ 2008-03-26 22:26 ` Richard Stallman 2008-03-27 2:14 ` Stefan Monnier 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-26 22:26 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: pmr, cyd, paul.r.ml, monnier, emacs-devel I attached some code a few days ago. Will that code help? (winsav.el) It appears to go in the right direction. It would be interesting to try replacing the current window-configuration code with winsav.el, to see if it is fast enough. It seems to me that `winsav-get-window-tree' could be made a lot faster, especially by writing it in C. But I don't know if it needs to be any faster. Could you write some documentation of the format returned by `winsav-get-window-tree'? How does winsav deal with the tree structure of non-leaf windows? I think that it does not know about non-leaf windows; is that correct? If so, it is something we need to fix, and that probably requires changes at the C level. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-26 22:26 ` Richard Stallman @ 2008-03-27 2:14 ` Stefan Monnier 2008-03-27 19:41 ` Richard Stallman 2008-03-29 16:27 ` Michael Sperber 0 siblings, 2 replies; 141+ messages in thread From: Stefan Monnier @ 2008-03-27 2:14 UTC (permalink / raw) To: rms; +Cc: pmr, cyd, paul.r.ml, Lennart Borgman (gmail), emacs-devel > It would be interesting to try replacing the current > window-configuration code with winsav.el, to see if it is fast enough. > It seems to me that `winsav-get-window-tree' could be made a lot > faster, especially by writing it in C. But I don't know if it needs > to be any faster. It doesn't seem to be noticeably slow. But it does not provide a 100% replacement for the window-configuration functions (mostly because of the issue of preserving window-identity vs. creating new windows). Not sure how important it is. IIUC XEmacs has switched to such an Elisp-only implementation of window-configurations so they probably know more about the impact of this incompatibility. > How does winsav deal with the tree structure of non-leaf windows? I > think that it does not know about non-leaf windows; is that correct? > If so, it is something we need to fix, and that probably > requires changes at the C level. It uses `window-tree' so it does know about non-leaf windows. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-27 2:14 ` Stefan Monnier @ 2008-03-27 19:41 ` Richard Stallman 2008-03-29 16:27 ` Michael Sperber 1 sibling, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-27 19:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: pmr, cyd, paul.r.ml, lennart.borgman, emacs-devel It doesn't seem to be noticeably slow. But it does not provide a 100% replacement for the window-configuration functions (mostly because of the issue of preserving window-identity vs. creating new windows). If we make this change, not trying to preserve window identity is almost inevitable. I think we should try it. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-27 2:14 ` Stefan Monnier 2008-03-27 19:41 ` Richard Stallman @ 2008-03-29 16:27 ` Michael Sperber 1 sibling, 0 replies; 141+ messages in thread From: Michael Sperber @ 2008-03-29 16:27 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> It would be interesting to try replacing the current >> window-configuration code with winsav.el, to see if it is fast enough. >> It seems to me that `winsav-get-window-tree' could be made a lot >> faster, especially by writing it in C. But I don't know if it needs >> to be any faster. > > It doesn't seem to be noticeably slow. But it does not provide a 100% > replacement for the window-configuration functions (mostly because of > the issue of preserving window-identity vs. creating new windows). > Not sure how important it is. IIUC XEmacs has switched to such an > Elisp-only implementation of window-configurations so they probably know > more about the impact of this incompatibility. There wasn't a noticeable performance impact, but a small number of packages (used to) depend on preservation of window identity. Most recently, ECB broke on XEmacs 21.5 because of this, but we've since worked out a fix that I expect to apply shortly. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI (was: Neat features in Eclipse editor) 2008-03-25 3:53 ` Window configuration UI (was: Neat features in Eclipse editor) Stefan Monnier 2008-03-25 10:54 ` Window configuration UI Lennart Borgman (gmail) 2008-03-26 4:47 ` Window configuration UI (was: Neat features in Eclipse editor) Richard Stallman @ 2008-03-31 2:41 ` Nick Roberts 2008-03-31 16:25 ` Richard Stallman 2 siblings, 1 reply; 141+ messages in thread From: Nick Roberts @ 2008-03-31 2:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > > needs to be possible to get all the right behavior. For instance, we > > want GUD to be able to take advantage of this, with a predefined "gud" > > perspective. This predefined "gud" perspective should have a window > > This is another problem: window-configurations can't be saved&loaded. > I.e. the tool we need is not `window-configuration' but some > other object. We can construct it all in Elisp from window-tree, but > someone needs to write the code. A bit late and perhaps not related to this specific point but when I tried tabbar.el with gdb-ui I hit a problem with dedicated windows: I couldn't switch buffer by clicking on the tab because the current window was dedicated. Maybe some concept of a window being dedicated to the set of buffers that have tabs for it, i.e., you could switch between tabs but other buffers couldn't switch into it, would be some kind of useful subframe entity. Just a random, possibly ill-conceived, thought. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI (was: Neat features in Eclipse editor) 2008-03-31 2:41 ` Window configuration UI (was: Neat features in Eclipse editor) Nick Roberts @ 2008-03-31 16:25 ` Richard Stallman 2008-04-01 3:00 ` Window configuration UI Stefan Monnier 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-31 16:25 UTC (permalink / raw) To: Nick Roberts; +Cc: monnier, emacs-devel Maybe some concept of a window being dedicated to the set of buffers that have tabs for it, i.e., you could switch between tabs but other buffers couldn't switch into it, would be some kind of useful subframe entity. That sounds like a good idea to me. It could be implemented in tabbar.el; if you click on a tab belonging to a dedicated window, it could un-dedicate the window, switch buffers in it, then re-dedicate it. However, perhaps set-window-buffer should operate normally on dedicated windows. The idea of dedicated windows is that they should not get reused by ...-other-window functions. If you explicitly change the buffer in a dedicated window, why shouldn't that work? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-03-31 16:25 ` Richard Stallman @ 2008-04-01 3:00 ` Stefan Monnier 2008-04-01 21:04 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: Stefan Monnier @ 2008-04-01 3:00 UTC (permalink / raw) To: rms; +Cc: Nick Roberts, emacs-devel > Maybe some concept of a window being dedicated to the set of > buffers that have tabs for it, i.e., you could switch between tabs > but other buffers couldn't switch into it, would be some kind of > useful subframe entity. > That sounds like a good idea to me. It could be implemented in tabbar.el; > if you click on a tab belonging to a dedicated window, it could un-dedicate > the window, switch buffers in it, then re-dedicate it. > However, perhaps set-window-buffer should operate normally on > dedicated windows. The idea of dedicated windows is that they > should not get reused by ...-other-window functions. If you explicitly > change the buffer in a dedicated window, why shouldn't that work? It's also that if the buffer disappears, the window is automatically deleted. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Window configuration UI 2008-04-01 3:00 ` Window configuration UI Stefan Monnier @ 2008-04-01 21:04 ` Richard Stallman 0 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-04-01 21:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: nickrob, emacs-devel It's also that if the buffer disappears, the window is automatically deleted. We could add a feature that the window has a list of preferred buffers, and if its buffer is deleted, it selects one of those. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 1:50 ` Richard Stallman 2008-03-25 3:53 ` Window configuration UI (was: Neat features in Eclipse editor) Stefan Monnier @ 2008-03-25 10:08 ` paul r 2008-03-25 10:55 ` David Reitter 2008-03-25 21:01 ` Richard Stallman 1 sibling, 2 replies; 141+ messages in thread From: paul r @ 2008-03-25 10:08 UTC (permalink / raw) To: rms; +Cc: pmr, cyd, emacs-devel 2008/3/25, Richard Stallman <rms@gnu.org>: > When you switch from workspace A to workspace B, does your current > window configuration get recorded as workspace A? Yes, it does. > The configurations should have names, not single letters. I firstly had an implementation using names. Then I changed it for single letters, because it saves a lot of time when switching. But this can be changed back easily. > This predefined "gud" perspective should have a window > for displaying source, and windows for displaying other things. > Each window should have tabs for switching between the various > things you can view in that window. I often use mode hooks to call `workspace-goto-or-create' before, so that mode-specific automatic windows reorganisation happen in a dedicated workspace. I then use C-c C-d space to swap workspaces. As an example, calendar/diary is hooked so that I'm taken to workspace 'c' before windows reorganisation happens. Concerning the tabs, I'm not sure to see what they are. But if I understand correctly, my opinion is that buffer switching is superior and less intrusive. But, clearly, buffer switching prompt should be dependant of current worspace/window/subframe etc. so that the choice proposed, the order of buffer, the completion mechanism etc make you reach what you are after quickly, and avoid unrelated buffers prompt pollution. > > Your code might be the start of this feature, but a convenient > smooth perspectives feature would do a lot more than this. No doubt. A friend of mine knows eclipse, I'll ask for a demo. I noticed some typo in the previous past of the workspaces code, sorry about that, below is the exact same code with typo corrected. -- Paul ;; DEFINITION ;;----------- ;; ;; Multi-workspaces ;; Author : Paul Rivier <paul dot r dot ml at gmail dot com> ;; ;; Load this file, then use C-c C-d [any character] to switch ;; to workspace specified ;; Special keys are : ;; - TAB to show workspaces list ;; - space to swap with last workspace ;; - DEL to kill current workspace ;; - RET to restore current workspace to its saved state ;;;;;;;;;;;;;;;;;; ;; DEPENDENCIES ;; ;;;;;;;;;;;;;;;;;; (eval-when-compile (require 'cl)) ;;;;;;;;;;;;;;; ;; VARIABLES ;; ;;;;;;;;;;;;;;; (defvar current-workspace nil "Workspace you are currently in") (defvar default-workspace ?1 "This workspace will be created at init time. You can not delete this workspace. When killing a workspace, you fallback to default-workspace.") (defvar workspaces-list nil "List of open workspaces") ;;;;;;;;;;;;;;;;;;;;; ;; GLOBAL BINDINGS ;; ;;;;;;;;;;;;;;;;;;;;; (global-set-key "\C-c\C-d" 'workspace-goto) ;;;;;;;;;;;;;;; ;; FUNCTIONS ;; ;;;;;;;;;;;;;;; (lexical-let ((last-workspace default-workspace)) ;; above : vars -- below : functions (labels ((workspaces-list-sort () ;; "Sort list workspaces-list, save and return it." (setq workspaces-list (sort workspaces-list (lambda (a b) (< (car a) (car b)))))) (workspaces-list-add (wsid) ;; "Add current configuration to workspaces list under wsid." (setq workspaces-list (cons (cons wsid (current-window-configuration)) workspaces-list)) (workspaces-list-sort)) (workspace-save-current () ;; "Save current workspace." (workspace-delete current-workspace) (workspaces-list-add current-workspace)) (workspace-delete (wsid) ;; "Delete workspace wsid." (setq workspaces-list (assq-delete-all wsid workspaces-list))) (workspaces-id-list () ;; "Return a list of workspaces ids." (mapcar #'car workspaces-list)) (workspace-create-new (wsid) ;; "Create a new workspace with id wsid." (workspace-goto ?0) (workspaces-list-add wsid) (workspace-goto wsid)) (workspace-kill-current () ;; "kill the workspace you are currently in" (if (not (or (eq current-workspace default-workspace) (eq current-workspace ?0))) (let ((cws current-workspace) (lws last-workspace)) (workspace-goto default-workspace) (workspace-delete cws) (setq last-workspace default-workspace) (concat "\nWorkspace " (char-to-string cws) " killed")) (concat "\nSpecial workspaces " (char-to-string current-workspace) " can not be killed"))) (workspace-exists-p (wsid) ;; "Return t if workspace wsid exists." (when (assoc wsid workspaces-list) t))) ;; externaly bound functions (defun workspaces-init () "Initialize workspaces-list and others" (setq workspaces-list nil) (workspaces-list-add ?0) (setq current-workspace ?0) (workspace-goto-or-create default-workspace)) (defun workspace-goto-or-create (wsid) "If workspace wsid exists, goto it, else create it." (if (workspace-exists-p wsid) (workspace-goto wsid) (workspace-create-new wsid))) (defun workspace-goto (wsid) "Go to another workspace, wsid is workspace identifier. wsid can be any character, except those mentioned below. Workspace 0 is a template workspace, do not use it unless you know what you do. Special characters are : - TAB to show workspaces list - space to swap with last workspace - DEL to kill current workspace - RET to restore current workspace to its saved state" (interactive "cTo which workspace do you want to go ? ") (let ((wscfgcons (assoc wsid workspaces-list)) (special "")) (if wscfgcons (progn (unless (eq wsid current-workspace) (workspace-save-current)) (set-window-configuration (cdr wscfgcons)) (unless (or (eq current-workspace ?0) (eq wsid current-workspace)) (setq last-workspace current-workspace)) (setq current-workspace wsid) (when (eq wsid ?0) (setq special "\n!-!-! This is template workspace. New workspaces are based on it."))) ;; Workspace does not exist, it might be a special key (cond ((eq wsid 9) ; 9 is TAB ()) ((eq wsid 13) ; 13 is RET (workspace-goto current-workspace) (workspace-save-current)) ((eq wsid 32) ; 32 is space (workspace-goto last-workspace)) ((eq wsid 127) ; 127 is DEL (backspace) (setq special (workspace-kill-current))) ;; it is not a special key, create workspace (t (when (y-or-n-p "This workspace does not exist, should it be created ? ") (workspace-create-new wsid))))) (message (concat "Now on workspace " (char-to-string current-workspace) "\nWorkspaces list is : " (mapconcat 'char-to-string (remq ?0 (workspaces-id-list)) " ") special)))) )) ;;;;;;;;;;; ;; HOOKS ;; ;;;;;;;;;;; ;; base workspaces 0 and default are created at startup only (unless workspaces-list (workspaces-init)) ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 10:08 ` Neat features in Eclipse editor paul r @ 2008-03-25 10:55 ` David Reitter 2008-03-25 11:35 ` paul r 2008-03-25 21:01 ` Richard Stallman 1 sibling, 1 reply; 141+ messages in thread From: David Reitter @ 2008-03-25 10:55 UTC (permalink / raw) To: paul r; +Cc: pmr, cyd, rms, emacs-devel On 25 Mar 2008, at 10:08, paul r wrote: > Concerning the tabs, I'm not sure to see what they are. But if I > understand correctly, my opinion is that buffer switching is superior > and less intrusive. But, clearly, buffer switching prompt should be > dependant of current worspace/window/subframe etc. so that the choice > proposed, the order of buffer, the completion mechanism etc make you > reach what you are after quickly, and avoid unrelated buffers prompt > pollution. That's pretty much what tabs are if implemented nicely. They are window-specific and show a subset of buffers that the user can switch to in the particular window with a single click. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 10:55 ` David Reitter @ 2008-03-25 11:35 ` paul r 2008-03-25 21:00 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: paul r @ 2008-03-25 11:35 UTC (permalink / raw) To: David Reitter; +Cc: pmr, cyd, rms, emacs-devel 2008/3/25, David Reitter <david.reitter@gmail.com>: > That's pretty much what tabs are if implemented nicely. They are > window-specific and show a subset of buffers that the user can switch > to in the particular window with a single click. Ok, thanks. So, could we define what we are talking about when we say "tabs" ? Are we talking about a buffers list subset, specific to current "perspective' ? Therefore, we could just rebind 'C-x b' to switch-to-buffer-local-subframe ? Tabs would be an optionnal graphical representation of this list on top of the subframe. I propose to call it subframe-buffers-list. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 11:35 ` paul r @ 2008-03-25 21:00 ` Richard Stallman 2008-03-25 22:10 ` paul r 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-25 21:00 UTC (permalink / raw) To: paul r; +Cc: david.reitter, cyd, emacs-devel, pmr Ok, thanks. So, could we define what we are talking about when we say "tabs" ? Are we talking about a buffers list subset, specific to current "perspective' ? Therefore, we could just rebind 'C-x b' to switch-to-buffer-local-subframe ? Having a tabs feature for switching buffers should not mean altering C-x b. Those are two different interfaces, and adding one does NOT imply changing the other! ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 21:00 ` Richard Stallman @ 2008-03-25 22:10 ` paul r 2008-03-26 1:50 ` Robert J. Chassell 2008-03-26 22:26 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: paul r @ 2008-03-25 22:10 UTC (permalink / raw) To: rms; +Cc: david.reitter, cyd, emacs-devel, pmr 2008/3/25, Richard Stallman <rms@gnu.org>: > Having a tabs feature for switching buffers should not mean altering > C-x b. Those are two different interfaces, and adding one does NOT > imply changing the other! Sorry, that's not what I meant. What I meant is that tabs are only a graphical representation of the list of privileged buffers for a specific window, right ? So the first part would be to maintain a window-local (or view-local, or perspective local, or subframe-local) list of privileged buffers. Then could come a command to switch buffer that would prompt for a buffer in this local list. Then could come a graphical representation of this list, under the form of tabs. Is that right or do I misunderstand what we are talking about ? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 22:10 ` paul r @ 2008-03-26 1:50 ` Robert J. Chassell 2008-03-26 22:26 ` Richard Stallman 1 sibling, 0 replies; 141+ messages in thread From: Robert J. Chassell @ 2008-03-26 1:50 UTC (permalink / raw) To: emacs-devel What I meant is that tabs are only a graphical representation of the list of privileged buffers for a specific window, right ? No. Buffers may appear in more than one window on more than one frame. The `switch-to-buffer' function switches Emacs attention and editing to a different buffer which may already be shown in another frame, a second frame but not in the first. The different buffer becomes visible in the first frame, so it is visible in two frames. Today's GNU Emacs CVS snapshot, Tue, 2008 Mar 25 20:54 UTC GNU Emacs 23.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.12.5) started with /usr/local/src/emacs/src/emacs -Q -nbc I don't have tabs. Presumably, they would invoke the same command, `switch-to-buffer' as the usual keybinding does, `C-x b'. (The tabs would contain the buffer argument of (switch-to-buffer BUFFER &optional NORECORD) The usual keybinding does not.) (Incidentally, I think that two kinds of command are useful, one evoking `switch-to-buffer' and the other `switch-to-workspace'. These could be evoked as two kinds of tab for those who want that and two keybindings for those who want that.) -- Robert J. Chassell GnuPG Key ID: 004B4AC8 bob@rattlesnake.com bob@gnu.org http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 22:10 ` paul r 2008-03-26 1:50 ` Robert J. Chassell @ 2008-03-26 22:26 ` Richard Stallman 1 sibling, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-26 22:26 UTC (permalink / raw) To: paul r; +Cc: david.reitter, cyd, emacs-devel, pmr What I meant is that tabs are only a graphical representation of the list of privileged buffers for a specific window, right ? So the first part would be to maintain a window-local (or view-local, or perspective local, or subframe-local) list of privileged buffers. Then could come a command to switch buffer that would prompt for a buffer in this local list. Then could come a graphical representation of this list, under the form of tabs. That seems plausible, except that I am not sure we need the command. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 10:08 ` Neat features in Eclipse editor paul r 2008-03-25 10:55 ` David Reitter @ 2008-03-25 21:01 ` Richard Stallman 2008-03-25 21:16 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-25 21:01 UTC (permalink / raw) To: paul r; +Cc: pmr, cyd, emacs-devel > When you switch from workspace A to workspace B, does your current > window configuration get recorded as workspace A? Yes, it does. In that case, it sounds like your code does part of the desired feature. But the other GUI aspects are crucial. I firstly had an implementation using names. Then I changed it for single letters, because it saves a lot of time when switching. But this can be changed back easily. One reason they should be names is that these names should appear on the screen giving users a graphical way to select a perspective. I often use mode hooks to call `workspace-goto-or-create' before, so that mode-specific automatic windows reorganisation happen in a dedicated workspace. I then use C-c C-d space to swap workspaces. As an example, calendar/diary is hooked so that I'm taken to workspace 'c' before windows reorganisation happens. That makes sense. Concerning the tabs, I'm not sure to see what they are. But if I understand correctly, my opinion is that buffer switching is superior and less intrusive. Tabs are a graphical interface for buffer switching. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 21:01 ` Richard Stallman @ 2008-03-25 21:16 ` Lennart Borgman (gmail) 2008-03-25 23:17 ` Mike Mattie ` (3 more replies) 0 siblings, 4 replies; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-25 21:16 UTC (permalink / raw) To: rms; +Cc: pmr, cyd, paul r, emacs-devel > Tabs are a graphical interface for buffer switching. Should tabs perhaps be more general than that in Emacs? Another note about tabs: When considering such features is not that also a good time to consider something like wxwidgets? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 21:16 ` Lennart Borgman (gmail) @ 2008-03-25 23:17 ` Mike Mattie 2008-03-26 2:23 ` Evans Winner ` (2 subsequent siblings) 3 siblings, 0 replies; 141+ messages in thread From: Mike Mattie @ 2008-03-25 23:17 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 608 bytes --] On Tue, 25 Mar 2008 22:16:26 +0100 "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> wrote: > > Tabs are a graphical interface for buffer switching. The tabs seemed like a neat idea, but I wondered if there was a more powerful way to do various kinds of switching. http://mtorus.berlios.de/ This project, though alpha works for me on 23.x with light use. just a FYI for the interested. > Should tabs perhaps be more general than that in Emacs? > > Another note about tabs: When considering such features is not that > also a good time to consider something like wxwidgets? > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 21:16 ` Lennart Borgman (gmail) 2008-03-25 23:17 ` Mike Mattie @ 2008-03-26 2:23 ` Evans Winner 2008-03-26 7:09 ` Jan Djärv 2008-03-26 22:25 ` Richard Stallman 3 siblings, 0 replies; 141+ messages in thread From: Evans Winner @ 2008-03-26 2:23 UTC (permalink / raw) To: emacs-devel For what it's worth, I believe w3m.el implements something like tabs, though I am not sure if it is generalizable to all of Emacs. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 21:16 ` Lennart Borgman (gmail) 2008-03-25 23:17 ` Mike Mattie 2008-03-26 2:23 ` Evans Winner @ 2008-03-26 7:09 ` Jan Djärv 2008-03-26 7:18 ` Drew Adams 2008-03-26 22:25 ` Richard Stallman 3 siblings, 1 reply; 141+ messages in thread From: Jan Djärv @ 2008-03-26 7:09 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: pmr, cyd, paul r, rms, emacs-devel Lennart Borgman (gmail) skrev: >> Tabs are a graphical interface for buffer switching. > > Should tabs perhaps be more general than that in Emacs? > Do you have an example? > Another note about tabs: When considering such features is not that also > a good time to consider something like wxwidgets? > I don't really see how these two are related, but support for tool kit specific tabs should be added. I don't know how tabbar does its tabs. Jan D. ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Neat features in Eclipse editor 2008-03-26 7:09 ` Jan Djärv @ 2008-03-26 7:18 ` Drew Adams 0 siblings, 0 replies; 141+ messages in thread From: Drew Adams @ 2008-03-26 7:18 UTC (permalink / raw) To: 'Jan Djärv', 'Lennart Borgman (gmail)' Cc: pmr, cyd, 'paul r', rms, emacs-devel > ...support for tool kit specific tabs should be added. > I don't know how tabbar does its tabs. It uses a header line. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 21:16 ` Lennart Borgman (gmail) ` (2 preceding siblings ...) 2008-03-26 7:09 ` Jan Djärv @ 2008-03-26 22:25 ` Richard Stallman 2008-03-26 22:38 ` Sebastian Rose 2008-03-27 0:18 ` Lennart Borgman (gmail) 3 siblings, 2 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-26 22:25 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: pmr, cyd, paul.r.ml, emacs-devel Should tabs perhaps be more general than that in Emacs? It would be useful if a tab could run some command so as to create the desired buffer, if the buffer doesn't exist yet. The easiest way to do that would be to have an alist mapping buffer names into the way to create them. Then `get-buffer-create' or `switch-to-bufer' could execute the specified code when it creates a buffer with that name. This would be useful for views that are supposed to display certain automatically-generated data. Do you have any other generalization to suggest? Another note about tabs: When considering such features is not that also a good time to consider something like wxwidgets? Maybe yes. The screens of today's computers are much bigger, so space for the text is no longer at a great premium. So there is no pressing reason not to use toolkit widgets around each window to make it look nicer. We definitely want to get away from the current limit that window sizes must be multiples of a "line height". Whether wxwindows is the right way to do this, I have no opinion, since I don't know much about it. Can wxwindows work with Gtk? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:25 ` Richard Stallman @ 2008-03-26 22:38 ` Sebastian Rose 2008-03-26 22:57 ` paul r ` (2 more replies) 2008-03-27 0:18 ` Lennart Borgman (gmail) 1 sibling, 3 replies; 141+ messages in thread From: Sebastian Rose @ 2008-03-26 22:38 UTC (permalink / raw) To: emacs-devel Mailinglist The nice thing about it is, that it uses the native toolkit of the plattform compiled on. No more ifdefs or anything to compile with Gtk/MFC/MAC. On linux Gtk is the default. Even the event handling, threading and networking are unified. I used wxWidgets for some smaller projects and I think it is the best attempt of a multiplattform lib. Projects created with wxWidgets can be viewed on the projects website. Some use custom widgets (like audacity). ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:38 ` Sebastian Rose @ 2008-03-26 22:57 ` paul r 2008-03-26 23:20 ` Sebastian Rose 2008-03-27 0:22 ` Mike Mattie 2008-03-27 0:17 ` Mike Mattie 2008-03-27 19:41 ` Richard Stallman 2 siblings, 2 replies; 141+ messages in thread From: paul r @ 2008-03-26 22:57 UTC (permalink / raw) To: Sebastian Rose; +Cc: emacs-devel Mailinglist 2008/3/26, Sebastian Rose <sebastian_rose@gmx.de>: > The nice thing about it is, that it uses the native toolkit of the > plattform compiled on. No more ifdefs or anything to compile with > Gtk/MFC/MAC. On linux Gtk is the default. Even the event handling, > threading and networking are unified. I used wxWidgets for some smaller > projects and I think it is the best attempt of a multiplattform lib. > > Projects created with wxWidgets can be viewed on the projects > website. Some use custom widgets (like audacity). > Hi, I have never used wxWidget but I have heard good things about it. One question : I read it is written in C++, with binding for several langages[1]. I can not see C , nor emacs lisp in the list. Is is implicitly usable through C ? Or do you have other plan ? Thanks Paul [1] http://www.wxwidgets.org/wiki/index.php/General_Information > > ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:57 ` paul r @ 2008-03-26 23:20 ` Sebastian Rose 2008-03-27 6:57 ` David Kastrup 2008-03-27 0:22 ` Mike Mattie 1 sibling, 1 reply; 141+ messages in thread From: Sebastian Rose @ 2008-03-26 23:20 UTC (permalink / raw) To: paul r; +Cc: emacs-devel Mailinglist I used it just like I use C++ of which c is subset. Hence using C should be zero problem. Actually, as I wrote it, I did SMALL projects with it. There was not much to worry about and I do not no the emacs c-code. I just use emacs. But I think the applications shown there say everything about the usability. I had no problems using C++ standard template lib in wx (where qt needs some small tricks). The events are handled using ACL's. These are defined using special macros. That looks a little bit like MFC. The only thing I had to handle differently for each platform was the use of ressources used by the programms like icons and so on. But it's now some years ago that I used wx. I was new to C++ by that time and that makes it even better, since I had no problem to get things done. The apps look and feel like any other app on the target plattform and are just as fast and responsive. Big plus if the great documentation. http://docs.wxwidgets.org/stable/ http://wxwidgets.org/docs/hierarchy_stable_image.htm - Framework Diagramm From the Homepage (http://wxwidgets.org/): > wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, > X11, Motif, WinCE, and more using one codebase. It can be used from > languages such as C++, Python, Perl, and C#/.NET. Unlike other > cross-platform toolkits, wxWidgets applications look and feel > native. This is because wxWidgets uses the platform's own native > controls rather than emulating them. It's also extensive, free, > open-source, and mature. Why not give it a try, like many others have? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 23:20 ` Sebastian Rose @ 2008-03-27 6:57 ` David Kastrup 0 siblings, 0 replies; 141+ messages in thread From: David Kastrup @ 2008-03-27 6:57 UTC (permalink / raw) To: Sebastian Rose; +Cc: paul r, emacs-devel Mailinglist Sebastian Rose <sebastian_rose@gmx.de> writes: > I used it just like I use C++ of which c is subset. Hence using C should > be zero problem. C is not a subset of C++ as far as exception handling and memory management are concerned. And C++ draws in a whole slew of portability problems and libraries. If C++ is a requirement for wxWindows, I don't think we want to go there. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:57 ` paul r 2008-03-26 23:20 ` Sebastian Rose @ 2008-03-27 0:22 ` Mike Mattie 1 sibling, 0 replies; 141+ messages in thread From: Mike Mattie @ 2008-03-27 0:22 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1311 bytes --] On Wed, 26 Mar 2008 23:57:50 +0100 "paul r" <paul.r.ml@gmail.com> wrote: > 2008/3/26, Sebastian Rose <sebastian_rose@gmx.de>: > > The nice thing about it is, that it uses the native toolkit of the > > plattform compiled on. No more ifdefs or anything to compile with > > Gtk/MFC/MAC. On linux Gtk is the default. Even the event handling, > > threading and networking are unified. I used wxWidgets for some > > smaller projects and I think it is the best attempt of a > > multiplattform lib. > > > > Projects created with wxWidgets can be viewed on the projects > > website. Some use custom widgets (like audacity). > > > Hi, I have never used wxWidget but I have heard good things about it. > One question : I read it is written in C++, with binding for several > langages[1]. I can not see C , nor emacs lisp in the list. Is is > implicitly usable through C ? Or do you have other plan ? > Thanks It's all pre-stl C++, most of the advanced features of C++ aren't used. You can make a canonical thunk to call C++ from C. namespace "C" { void foo( void ) { bar.method(); } } It's been a while since I kept Stroustrup under my pillow, so the example might be wrong. > Paul > > [1] http://www.wxwidgets.org/wiki/index.php/General_Information > > > > > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:38 ` Sebastian Rose 2008-03-26 22:57 ` paul r @ 2008-03-27 0:17 ` Mike Mattie 2008-03-27 19:41 ` Richard Stallman 2 siblings, 0 replies; 141+ messages in thread From: Mike Mattie @ 2008-03-27 0:17 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1024 bytes --] On Wed, 26 Mar 2008 23:38:54 +0100 Sebastian Rose <sebastian_rose@gmx.de> wrote: > The nice thing about it is, that it uses the native toolkit of the > plattform compiled on. No more ifdefs or anything to compile with > Gtk/MFC/MAC. On linux Gtk is the default. Even the event handling, > threading and networking are unified. I used wxWidgets for some > smaller projects and I think it is the best attempt of a > multiplattform lib. > > Projects created with wxWidgets can be viewed on the projects > website. Some use custom widgets (like audacity). > > last time I coded for WxWidgets it used it's own string class, was pre-stl, was bloated, and generally had accumulated functionality in thick layers. Any design mistakes are at this point pretty much set in stone with the size of the code-base. Seeing this prime example IMHO, of why compat layers can't be clean used in Emacs is not cool to me at least. At least on gentoo I can compile out the joystick support. Cheers, Mike Mattie [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:38 ` Sebastian Rose 2008-03-26 22:57 ` paul r 2008-03-27 0:17 ` Mike Mattie @ 2008-03-27 19:41 ` Richard Stallman 2008-03-27 20:18 ` Sebastian Rose 2 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-27 19:41 UTC (permalink / raw) To: Sebastian Rose; +Cc: emacs-devel The nice thing about it is, that it uses the native toolkit of the plattform compiled on. No more ifdefs or anything to compile with Gtk/MFC/MAC. On linux Gtk is the default. Please note that this system isn't "Linux". See http://www.gnu.org/gnu/gnu-linux-faq.html. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-27 19:41 ` Richard Stallman @ 2008-03-27 20:18 ` Sebastian Rose 0 siblings, 0 replies; 141+ messages in thread From: Sebastian Rose @ 2008-03-27 20:18 UTC (permalink / raw) To: emacs-devel Mailinglist Yepp, sorry, new to this part of the universe :) I meant plattforms not running MFC nor MAC (what is it on MAC???), but Gtk. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-26 22:25 ` Richard Stallman 2008-03-26 22:38 ` Sebastian Rose @ 2008-03-27 0:18 ` Lennart Borgman (gmail) 1 sibling, 0 replies; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-27 0:18 UTC (permalink / raw) To: rms; +Cc: pmr, cyd, paul.r.ml, emacs-devel Richard Stallman wrote: > Do you have any other generalization to suggest? Yes, I was thinking more of the graphical (or maybe hierarchical) aspect. To me tabs are something that can be placed just under frames or subframes. > Another note about tabs: When considering such features is not that also > a good time to consider something like wxwidgets? > > Maybe yes. The screens of today's computers are much bigger, so space > for the text is no longer at a great premium. So there is no pressing > reason not to use toolkit widgets around each window to make it look > nicer. We definitely want to get away from the current limit that window > sizes must be multiples of a "line height". > > Whether wxwindows is the right way to do this, I have no opinion, since > I don't know much about it. Can wxwindows work with Gtk? See Stephen's reply here: http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01170.html ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:56 ` Chong Yidong ` (3 preceding siblings ...) 2008-03-24 0:53 ` Richard Stallman @ 2008-03-25 0:48 ` Bastien 4 siblings, 0 replies; 141+ messages in thread From: Bastien @ 2008-03-25 0:48 UTC (permalink / raw) To: Chong Yidong; +Cc: Paul Michael Reilly, rms, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Richard Stallman <rms@gnu.org> writes: > >> * "Perspectives" are named persistent window configurations. We have >> had the window configuration mechanism in GNU Emacs since the >> beginning but we have never developed a good user interface to take >> advantage of them. Eclipse's user interface seems to be good. > > Well, we already have `C-x r w R' (window-configuration-to-register) > and `C-x r f R' (frame-configuration-to-register) for saving window > configurations, and `C-x r j R' for restoring them. > > Though it's true that this could certainly be more user-friendly. Last month I coded this, which lets you list registers: http://lumiere.ens.fr/~guerry/u/register-list.el M-x register-list RET creates a list of registers. Then `W' will list only [W]indow configurations. Since I use window configurations I find this useful. (It is also useful to "merge" the content of registers containing strings and to edit rectangles while taking care of the rectangles width.) -- Bastien ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:45 Neat features in Eclipse editor Richard Stallman 2008-03-22 21:56 ` Chong Yidong @ 2008-03-24 1:51 ` Dan Nicolaescu 2008-03-24 12:29 ` Richard Stallman 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov 2 siblings, 1 reply; 141+ messages in thread From: Dan Nicolaescu @ 2008-03-24 1:51 UTC (permalink / raw) To: rms; +Cc: Paul Michael Reilly, emacs-devel Richard Stallman <rms@gnu.org> writes: > I just got a demo of the Eclipse editor and saw these features > which we should have in Emacs. > > * Having tabs above a window to switch buffers in it. > > * "Perspectives" are named persistent window configurations. We have > had the window configuration mechanism in GNU Emacs since the > beginning but we have never developed a good user interface to take > advantage of them. Eclipse's user interface seems to be good. There are (at least) 2 key features that make Eclipse's perspectives very useful: - the UI to select/switch them - the fact that there's a predefined set of perspectives that are useful for specific tasks, and it's easy to teach users about how to perform certain tasks using them. > * Imenu could be extended into a file-structure browsing mechanism > using code like that of customize-groups. Doesn't `speedbar' already provide something very similar to (if not exactly) that? > * Display something in the margin on lines that have compilation > errors. > > * Compilation error navigation bar, parallel to the scroll bar, > indicating where in the buffer there are compilation errors. > Perhaps we could arrange to display these error indications on top > of the scroll bar itself. That depends on to what extent toolkit > scroll bars are extensible. It can also be done with another fringe (and what Eclipse uses seems to be more like a fringe). More interesting things that Eclipse provides by default: - something very similar to `show-paren-mode' - inserting pairs of parenthesis, quotes, etc. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 1:51 ` Dan Nicolaescu @ 2008-03-24 12:29 ` Richard Stallman 2008-03-24 18:24 ` joakim 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-03-24 12:29 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: pmr, emacs-devel > * Imenu could be extended into a file-structure browsing mechanism > using code like that of customize-groups. Doesn't `speedbar' already provide something very similar to (if not exactly) that? I don't know. I have never used speedbar. Perhaps it will do this job. In practice, the crucial question is whether it works smoothly. In Eclipse, these features are very visible and they "just work". It would be good if that were true in Emacs also. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 12:29 ` Richard Stallman @ 2008-03-24 18:24 ` joakim 2008-03-25 1:50 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: joakim @ 2008-03-24 18:24 UTC (permalink / raw) To: rms; +Cc: pmr, Dan Nicolaescu, emacs-devel Richard Stallman <rms@gnu.org> writes: > > * Imenu could be extended into a file-structure browsing mechanism > > using code like that of customize-groups. > > Doesn't `speedbar' already provide something very similar to (if > not exactly) that? > > I don't know. I have never used speedbar. > Perhaps it will do this job. > > In practice, the crucial question is whether it works smoothly. > In Eclipse, these features are very visible and they "just work". > It would be good if that were true in Emacs also. > The ECB (Emacs Code Browser) provides several gui features very similar to what Eclipse provides(within the limitations of emacs). The ECB is furthermore a client of Cedet (collection of Emacs development tools), which makes it possible for ECB to provide windows with code browsing facilities etc. Theres lots of screenshots and explanations at http://ecb.sourceforge.net/ and http://cedet.sourceforge.net/ (Both tools have been discussed previously for inclusion in Emacs) I know several readers of the Emacs list dislikes going to a web page for information, but I know no better way at this time. -- Joakim Verona ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-24 18:24 ` joakim @ 2008-03-25 1:50 ` Richard Stallman 0 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-25 1:50 UTC (permalink / raw) To: joakim; +Cc: pmr, dann, emacs-devel The ECB (Emacs Code Browser) provides several gui features very similar to what Eclipse provides(within the limitations of emacs). Can you describe what they look like to use? I am concerned that "similar within the limitations of Emacs" means that they don't come anywhere near making the grade. What we need is not something "similar within the limitations of Emacs". What we need is to implement the features that are mising so we can add a feature that really does the job. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Tab bar (was: Neat features in Eclipse editor) 2008-03-22 21:45 Neat features in Eclipse editor Richard Stallman 2008-03-22 21:56 ` Chong Yidong 2008-03-24 1:51 ` Dan Nicolaescu @ 2008-04-06 20:52 ` Juri Linkov 2008-04-06 23:07 ` Tab bar David Koppelman ` (3 more replies) 2 siblings, 4 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-06 20:52 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 443 bytes --] I just created a small experimental Emacs Lisp library that emulates the tab bar feature provided by most modern web browsers, file managers and editors. Tabs are very popular nowadays mostly due to their ability to group units equivalent to Emacs frames into one frame and providing handles to switch them quickly inside one frame without having to switch top-level frames. Below is a screenshot how this feature currently looks in Emacs: [-- Attachment #2: EmacsTabBar --] [-- Type: image/png, Size: 8562 bytes --] [-- Attachment #3: Type: text/plain, Size: 993 bytes --] A graphical tab bar has two special buttons: on the left side to create a new tab, and on the right side to close the current tab. Between them there is a row of tabs that represent different window configurations. The name of the tab is the name of the current buffer (just as the name of the current frame is the name of the current buffer), but a full list of names of all buffers in a window configuration is displayed in a pop-up window over the tab. Clicking the left mouse button switches between displayed tabs. The current tab is disabled since there is no sense to clink it, and also this provides the visual feedback for the currently selected tab. There is also a menu "Tabs" that duplicates the tab bar and can be used on non-graphical terminals. It binds `C-z t' to the command that creates a new tab, and `C-z c' to the command that closes the current tab. `C-z' with a number selects the corresponding tab. The original command `suspend-frame' is rebound to `C-z C-z'. [-- Attachment #4: EmacsTabBarMenu --] [-- Type: image/png, Size: 15611 bytes --] [-- Attachment #5: Type: text/plain, Size: 527 bytes --] So far I'm satisfied with this feature because it implements the intuitive and natural behavior expected from the modern tab bar. As for details of the implementation, it currently depends on the availability of the external program `convert' used to render the tab bar elements. I hope it could be replaced with a separate bar similar to the tool-bar. I think we should do this as soon as possible because this single feature can improve Emacs usability for most users that expect a tab bar is a standard editor feature. [-- Attachment #6: tab-bar.el --] [-- Type: application/emacs-lisp, Size: 8548 bytes --] [-- Attachment #7: Type: text/plain, Size: 45 bytes --] -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov @ 2008-04-06 23:07 ` David Koppelman 2008-04-06 23:48 ` Juri Linkov 2008-04-07 1:37 ` Tab bar (was: Neat features in Eclipse editor) Drew Adams ` (2 subsequent siblings) 3 siblings, 1 reply; 141+ messages in thread From: David Koppelman @ 2008-04-06 23:07 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel I frequently work with new users of Emacs and perhaps their biggest frustration is switching between buffers (or even just knowing that's what they need to do). If the tab bar by default provided one tab per buffer that would be great for such users. OTOH I'd leave it turned off. Juri Linkov <juri@jurta.org> writes: > I just created a small experimental Emacs Lisp library that emulates the > tab bar feature provided by most modern web browsers, file managers and > editors. Tabs are very popular nowadays mostly due to their ability > to group units equivalent to Emacs frames into one frame and providing > handles to switch them quickly inside one frame without having to switch > top-level frames. > > Below is a screenshot how this feature currently looks in Emacs: ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-06 23:07 ` Tab bar David Koppelman @ 2008-04-06 23:48 ` Juri Linkov 2008-04-07 0:05 ` David Koppelman 2008-04-07 14:59 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-06 23:48 UTC (permalink / raw) To: David Koppelman; +Cc: emacs-devel > I frequently work with new users of Emacs and perhaps their biggest > frustration is switching between buffers (or even just knowing that's > what they need to do). > > If the tab bar by default provided one tab per buffer that would be > great for such users. It is not unusual to have tens or even hundreds buffers in Emacs. Can you imagine a tab bar with hundreds tabs? It would occupy the whole screen. But really switching between buffers is not a problem, because Emacs already provides many different ways to do this: the top-level menu "Buffers", <C-mouse-1> pop-up menu, `C-x b' key, several packages like buff-menu.el, ebuff-menu.el, ibuffer.el, iswitchb.el, ido.el, etc. What Emacs still misses is a feature to group several frames, window configurations, work areas, perspectives (these are different names for almost the same thing) in the tab bar. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-06 23:48 ` Juri Linkov @ 2008-04-07 0:05 ` David Koppelman 2008-04-07 0:32 ` Juri Linkov 2008-04-07 14:59 ` Richard Stallman 1 sibling, 1 reply; 141+ messages in thread From: David Koppelman @ 2008-04-07 0:05 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel For new users a tab bar with one tab per buffer (and perhaps showing the n most recent) would be a great help, they can get to work without immediately having to learn how to switch buffers or for that matter learning what a buffer is. I'd suggest taking such users into account when designing the tab bar though without compromising the features for organization that experienced users might want. Juri Linkov <juri@jurta.org> writes: >> I frequently work with new users of Emacs and perhaps their biggest >> frustration is switching between buffers (or even just knowing that's >> what they need to do). >> >> If the tab bar by default provided one tab per buffer that would be >> great for such users. > > It is not unusual to have tens or even hundreds buffers in Emacs. > Can you imagine a tab bar with hundreds tabs? It would occupy > the whole screen. > > But really switching between buffers is not a problem, because Emacs > already provides many different ways to do this: the top-level menu > "Buffers", <C-mouse-1> pop-up menu, `C-x b' key, several packages like > buff-menu.el, ebuff-menu.el, ibuffer.el, iswitchb.el, ido.el, etc. > > What Emacs still misses is a feature to group several frames, > window configurations, work areas, perspectives (these are > different names for almost the same thing) in the tab bar. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 0:05 ` David Koppelman @ 2008-04-07 0:32 ` Juri Linkov 2008-04-07 14:59 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-07 0:32 UTC (permalink / raw) To: David Koppelman; +Cc: emacs-devel > For new users a tab bar with one tab per buffer (and perhaps showing the > n most recent) would be a great help, they can get to work without > immediately having to learn how to switch buffers or for that matter > learning what a buffer is. > > I'd suggest taking such users into account when designing the tab bar > though without compromising the features for organization that > experienced users might want. Just as web browsers provide an option to choose between opening pages in a new tab or in the same tab, and similarly to the Emacs option `pop-up-frames', we could create a new user option `pop-up-tabs' whose non-nil value will always display a new buffer in a new tab, and we could even set it to non-nil by default for the convenience of new users. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 0:32 ` Juri Linkov @ 2008-04-07 14:59 ` Richard Stallman 2008-04-07 23:27 ` Juri Linkov 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-07 14:59 UTC (permalink / raw) To: Juri Linkov; +Cc: koppel, emacs-devel Just as web browsers provide an option to choose between opening pages in a new tab or in the same tab, and similarly to the Emacs option `pop-up-frames', we could create a new user option `pop-up-tabs' whose non-nil value will always display a new buffer in a new tab, and we could even set it to non-nil by default for the convenience of new users. This idea makes no sense to me. If the default usage of the tab bar is to switch buffers in the selected window, then every new buffer will inevitably get a "new tab" regardless of how it is displayed. So what question are you talking about? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 14:59 ` Richard Stallman @ 2008-04-07 23:27 ` Juri Linkov 2008-04-08 15:35 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-07 23:27 UTC (permalink / raw) To: rms; +Cc: emacs-devel > Just as web browsers provide an option to choose between opening pages > in a new tab or in the same tab, and similarly to the Emacs option > `pop-up-frames', we could create a new user option `pop-up-tabs' whose > non-nil value will always display a new buffer in a new tab, and we > could even set it to non-nil by default for the convenience of new users. > > This idea makes no sense to me. Is this because you don't use web browsers? In most modern web browsers a tab displays a web page, but the same tab can switch between different web pages (so web pages are equivalent to Emacs buffers). When the user wants to visit a new page, then depending on such option, the browser can either open it in the same tab or create a new tab. Often this preference can't be defined in advance, so there are special keys to choose between these options, e.g. simply clicking <mouse-1> on a link opens a web page in the same tab, but <C-mouse-1> opens it in a new tab. > If the default usage of the tab bar is to switch buffers in the > selected window, then every new buffer will inevitably get a "new tab" > regardless of how it is displayed. So what question are you > talking about? Of course, selecting a tab to switch buffers should not create a new tab (internally this can be implemented using functions like `switch-to-buffer' that don't create a new window or a new tab), but if the user invokes a command that calls `display-buffer' then a new option `pop-up-tabs' makes sense to allow displaying it in a new tab just as `pop-up-frames' allows displaying it in a new frame. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 23:27 ` Juri Linkov @ 2008-04-08 15:35 ` Richard Stallman 2008-04-08 15:50 ` Jason Rumney 0 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-08 15:35 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Is this because you don't use web browsers? In most modern web browsers a tab displays a web page, but the same tab can switch between different web pages (so web pages are equivalent to Emacs buffers). When the user wants to visit a new page, then depending on such option, the browser can either open it in the same tab or create a new tab. Now I see what you mean. In effect, the new buffer can replace the old one in the tab bar, or it can add to the tab bar. If a window has a list of preferred buffers, and normally generates its list of tabs from that, these two options would be (1) the new buffer replaces the old buffer in the list of preferred buffers, or (2) the new buffer is added to the list of preferred buffers. It makes sense. My only doubt is whether we could find room in the keys and buttons for these two options. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 15:35 ` Richard Stallman @ 2008-04-08 15:50 ` Jason Rumney 2008-04-08 16:58 ` Drew Adams 2008-04-09 10:33 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: Jason Rumney @ 2008-04-08 15:50 UTC (permalink / raw) To: rms; +Cc: Juri Linkov, emacs-devel Richard Stallman wrote: > It makes sense. My only doubt is whether we could find room > in the keys and buttons for these two options. > Users who want to use tabs will probably use them instead of frames (in my experience, there is little overlap between users who want everything in one frame with tabs to select between them, and users who want a separate frame for everything), so sharing keybindings with C-x 5 may be an acceptable solution if we cannot find free keys. Something like: if the current window or its containing frame is already tabbed, or if the user or mode has expressed a preference for a tabbed UI, then C-x 5 C-f creates a new tab, and C-u C-x 5 C-f creates a new frame. Otherwise the behaviour of C-x 5 bindings are reversed. ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Tab bar 2008-04-08 15:50 ` Jason Rumney @ 2008-04-08 16:58 ` Drew Adams 2008-04-09 10:33 ` Richard Stallman 1 sibling, 0 replies; 141+ messages in thread From: Drew Adams @ 2008-04-08 16:58 UTC (permalink / raw) To: 'Jason Rumney', rms; +Cc: 'Juri Linkov', emacs-devel > > It makes sense. My only doubt is whether we could find room > > in the keys and buttons for these two options. > > Users who want to use tabs will probably use them instead of > frames (in my experience, there is little overlap between users > who want everything in one frame with tabs to select between them, > and users who want a separate frame for everything), I probably use separate frames as much as anyone, and that doesn't hold for me. I use a tab bar also. I can't characterize my use well, but I guess I use it to cut down on the number of visible frames or to group related buffers. To me, the overlap is more with buffer-menu or the Buffers menu than with frames. With the wrinkle that tab bars for me are effectively[*] per frame, so they also provide buffer groups per frame. And tabbar.el, at least, groups the buffers in a tab bar further into sets based on their type (e.g. mode). So a tab bar, while doing something similar to what a buffer menu or a set of iconified frames does, is different, and offers its own benefits. [*] Since I typically (but not always) have one window per frame, tabbar.el's tab-bar-per-window is effectively tab-bar-per-frame, for me. I use all of these: separate frames, iconified (actually thumbnail) frames, and tab bars. And I sometimes use multiple windows in a frame. You could use some of these systematically as replacements for others, but I somehow find a way to use them together that suits me. The point is that we should avoid assumptions based on generalizations such as "users who want everything in one frame" and "users who want a separate frame for everything". I, at least, am in neither of those extreme camps. Better to remove such "everything" suppositions from the UI design, and provide also for users who are not at such spectrum extremes. (You can use both C-x b and C-x C-b, even though someone could argue that one is enough and one key binding should suffice.) > so sharing > keybindings with C-x 5 may be an acceptable solution if we cannot > find free keys. Something like: if the current window or its > containing frame is already tabbed, or if the > user or mode has expressed a preference for a tabbed UI, then > C-x 5 C-f creates a new tab, and C-u C-x 5 C-f creates a new frame. > Otherwise the behaviour of C-x 5 bindings are reversed. I don't have much to say now about the possible key bindings, and I'm not sure we should start with that. Wait and see how users (or at least developers) use the features first. You might be right that a general preference, plus `C-u' to temporarily reverse the preference, would be a good way to handle this, but I don't think that needs to be decided up front. One thing that would be useful, I think, would be providing ways (e.g. keys or mouse clicks) to change the representation. You might first put some buffers in their own frames, but later want to group them using a tab bar, or vice versa. Likewise, for a buffer's own tab vs a shared tab. Likewise for movement of buffers (or whatever) among different tab bars or different tab-bar sets (a la tabbar.el). For example, be able to easily: . Break a buffer (or whatever) out of one tab and into its own window, frame or another tab. This is analogous to `mouse-tear-off-window'. . The opposite: merge the buffers of two tabs into one tab. Push a buffer into an existing tab, removing it from other display locations (other frame, other tab). And, whatever we do in the way of adding tabs etc., we will need to also deal with the removal of their elements (e.g. buffers). I'm thinking of `q' as in `quit-window'. We should keep things simple for this, and not repeat the fiasco of the thousand-and-one View-mode quitting dances. Killing a buffer, for instance, should simply remove it from all tabs - it should not replace it with some other buffer (as happens today for Emacs windows). Finally, as is often the case with Emacs, although we can plan use cases for certain features, we cannot really foresee how they might be used together in novel and useful ways. The more we can keep the implementation of a new feature such as tab bars in Lisp (vs C), the more users will be able to discover and invent useful UI patterns that take advantage of and extend the feature. Emacs has that potent advantage. Adding tab bars should open doors to new, creative UI patterns and features - vs simply hard-coding tab behavior copied from web browsers. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 15:50 ` Jason Rumney 2008-04-08 16:58 ` Drew Adams @ 2008-04-09 10:33 ` Richard Stallman 2008-04-09 23:27 ` Juri Linkov 1 sibling, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-09 10:33 UTC (permalink / raw) To: Jason Rumney; +Cc: juri, emacs-devel Users who want to use tabs will probably use them instead of frames (in my experience, there is little overlap between users who want everything in one frame with tabs to select between them, and users who want a separate frame for everything), so sharing keybindings with C-x 5 may be an acceptable solution if we cannot find free keys. That sounds plausible to me. Something like: if the current window or its containing frame is already tabbed, or if the user or mode has expressed a preference for a tabbed UI, then C-x 5 C-f creates a new tab, and C-u C-x 5 C-f creates a new frame. Otherwise the behaviour of C-x 5 bindings are reversed. This convention might be problematical, especially if some of the commands already use the prefix arg for something else. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 10:33 ` Richard Stallman @ 2008-04-09 23:27 ` Juri Linkov 0 siblings, 0 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-09 23:27 UTC (permalink / raw) To: rms; +Cc: emacs-devel, Jason Rumney > Something like: if > the current window or its containing frame is already tabbed, or if the > user or mode has expressed a preference for a tabbed UI, then C-x 5 C-f > creates a new tab, and C-u C-x 5 C-f creates a new frame. Otherwise the > behaviour of C-x 5 bindings are reversed. > > This convention might be problematical, especially if some of the commands > already use the prefix arg for something else. Maybe then create a separate key prefix map for tab operation keys: C-x 7 0 delete-tab C-x 7 1 delete-other-tabs C-x 7 2 make-tab-command C-x 7 b switch-to-buffer-other-tab C-x 7 C-f find-file-other-tab (`C-x 6' prefix is already occupied by 2C-two-columns, but `C-x 7' is free). -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-06 23:48 ` Juri Linkov 2008-04-07 0:05 ` David Koppelman @ 2008-04-07 14:59 ` Richard Stallman 2008-04-07 15:33 ` Lennart Borgman (gmail) ` (2 more replies) 1 sibling, 3 replies; 141+ messages in thread From: Richard Stallman @ 2008-04-07 14:59 UTC (permalink / raw) To: Juri Linkov; +Cc: koppel, emacs-devel > If the tab bar by default provided one tab per buffer that would be > great for such users. It is not unusual to have tens or even hundreds buffers in Emacs. Can you imagine a tab bar with hundreds tabs? It would occupy the whole screen. Perhaps beginning users at that stage won't have so many buffers that they can't all fit in the tab bar. And by the time the user starts to work with so many buffers, she will have learned about C-h b. Meanwhile, if the tab bar normally shows the most recently used buffers, MOST OF THE TIME the buffer you want will be visible there But really switching between buffers is not a problem, because Emacs already provides many different ways to do this: the top-level menu "Buffers", <C-mouse-1> pop-up menu, `C-x b' key, several packages like buff-menu.el, ebuff-menu.el, ibuffer.el, iswitchb.el, ido.el, etc. Yes, but the tab bar is the most convenient and self-evident interface for doing this, and many people are accustomed to it, so Emacs should support it. What Emacs still misses is a feature to group several frames, window configurations, work areas, perspectives (these are different names for almost the same thing) in the tab bar. It would be good to have a tab bar of perspectives, too. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 14:59 ` Richard Stallman @ 2008-04-07 15:33 ` Lennart Borgman (gmail) 2008-04-07 23:31 ` Juri Linkov 2008-04-08 13:58 ` Andrew W. Nosenko 2008-04-07 16:09 ` Drew Adams 2008-04-07 23:28 ` Juri Linkov 2 siblings, 2 replies; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-04-07 15:33 UTC (permalink / raw) To: rms; +Cc: Juri Linkov, koppel, emacs-devel Richard Stallman wrote: > Perhaps beginning users at that stage won't have so many buffers that > they can't all fit in the tab bar. Why not handle this like for example Firefox handles it? All the tabs are in one row but all tabs are not visible at once. I think that is how the system tab widgets handles it. > And by the time the user starts to > work with so many buffers, she will have learned about C-h b. The tabs as above can be combined with for example the way Ido let you narrow the available list of buffers. The set of visible tabs could be narrowed the same way. I imagine that the user first press C-tab and then by pressing a second key gets into that "ido-like state". Perhaps a quick press of C-tab again should enter that state. (Entering that state autmatically would be confusing for a new user since that is not the way tabs normally function.) Another note: You wrote in another message that tabs are most important for windows. If there is a special set of buffers for a window then it makes sense to me with a special tab row for that window. Otherwise it makes more sense to me to have one tab row per frame and that this affects the selected window. > Meanwhile, if the tab bar normally shows the most recently used > buffers, MOST OF THE TIME the buffer you want will be visible there .. > It would be good to have a tab bar of perspectives, too. I am not sure how that could work and look. One important thing about tabs IMO is the ability to use C-tab/C-S-tab to switch tab. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 15:33 ` Lennart Borgman (gmail) @ 2008-04-07 23:31 ` Juri Linkov 2008-04-08 0:21 ` Drew Adams 2008-04-08 2:06 ` Stefan Monnier 2008-04-08 13:58 ` Andrew W. Nosenko 1 sibling, 2 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-07 23:31 UTC (permalink / raw) To: lennart.borgman; +Cc: emacs-devel > I imagine that the user first press C-tab and then by pressing a second > key gets into that "ido-like state". Perhaps a quick press of C-tab again > should enter that state. (Entering that state autmatically would be > confusing for a new user since that is not the way tabs > normally function.) Do you know about the Firefox addon `iswitchb-tabs'? It imitates the Emacs iswitchb-mode in Firefox and lets switching between tabs by typing part of the tab name. > Another note: You wrote in another message that tabs are most important > for windows. If there is a special set of buffers for a window then it > makes sense to me with a special tab row for that window. Otherwise it > makes more sense to me to have one tab row per frame and that this affects > the selected window. I agree, this makes sense in Eclipse only because it attaches a special set of buffers for a window. > I am not sure how that could work and look. One important thing about tabs > IMO is the ability to use C-tab/C-S-tab to switch tab. There is also a feature that after pressing <C-tab> it displays a list of all tabs, <tab> navigates to the next tab in this temporarily displayed list while you still hold the Ctrl key, and releasing the Ctrl key switches to the selected tab. It seems this is not possible to implement in Emacs, since it requires distinguishing between key press and release events. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Tab bar 2008-04-07 23:31 ` Juri Linkov @ 2008-04-08 0:21 ` Drew Adams 2008-04-08 2:06 ` Stefan Monnier 1 sibling, 0 replies; 141+ messages in thread From: Drew Adams @ 2008-04-08 0:21 UTC (permalink / raw) To: 'Juri Linkov', lennart.borgman; +Cc: emacs-devel > > I am not sure how that could work and look. One important > > thing about tabs IMO is the ability to use C-tab/C-S-tab > > to switch tab. > > There is also a feature that after pressing <C-tab> it > displays a list of all tabs, <tab> navigates to the next > tab in this temporarily displayed list while you still > hold the Ctrl key, and releasing the Ctrl key switches > to the selected tab. It seems this is not possible > to implement in Emacs, since it requires distinguishing > between key press and release events. Thank goodness. In any case, possible or not, count me as one voice against giving yet another interpretation to TAB (C-TAB, C-S-TAB, ...) in Emacs. Enough already. It doesn't matter if other programs have found 187 other "standard" uses for TAB - TAB has enough behaviors in Emacs. We should save use of modifiers with TAB for things closely related to TAB's existing behaviors. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 23:31 ` Juri Linkov 2008-04-08 0:21 ` Drew Adams @ 2008-04-08 2:06 ` Stefan Monnier 2008-04-08 22:11 ` Juri Linkov 1 sibling, 1 reply; 141+ messages in thread From: Stefan Monnier @ 2008-04-08 2:06 UTC (permalink / raw) To: Juri Linkov; +Cc: lennart.borgman, emacs-devel > It seems this is not possible to implement in Emacs, since it requires > distinguishing between key press and release events. It's not like it can't be added, tho, Stefan "who implemented just that at some point" ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 2:06 ` Stefan Monnier @ 2008-04-08 22:11 ` Juri Linkov 2008-04-09 2:00 ` Stefan Monnier 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-08 22:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: lennart.borgman, emacs-devel >> It seems this is not possible to implement in Emacs, since it requires >> distinguishing between key press and release events. > > It's not like it can't be added, tho, > > Stefan "who implemented just that at some point" Did you implement this using the syntax of mouse button events, i.e. something like <C-down-tab>? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 22:11 ` Juri Linkov @ 2008-04-09 2:00 ` Stefan Monnier 2008-04-09 8:45 ` Juri Linkov 0 siblings, 1 reply; 141+ messages in thread From: Stefan Monnier @ 2008-04-09 2:00 UTC (permalink / raw) To: Juri Linkov; +Cc: lennart.borgman, emacs-devel >>> It seems this is not possible to implement in Emacs, since it requires >>> distinguishing between key press and release events. >> >> It's not like it can't be added, tho, >> >> Stefan "who implemented just that at some point" > Did you implement this using the syntax of mouse button events, > i.e. something like <C-down-tab>? I can't remember the details, but yes, pretty much, except I think that the events generated were along the lines of: control C-tab C-up-tab C-up-control the last one is a bit odd, but it's just how it turned out. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 2:00 ` Stefan Monnier @ 2008-04-09 8:45 ` Juri Linkov 2008-04-09 9:34 ` Paul R 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-09 8:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: lennart.borgman, emacs-devel >>>> It seems this is not possible to implement in Emacs, since it requires >>>> distinguishing between key press and release events. >>> >>> It's not like it can't be added, tho, >>> >>> Stefan "who implemented just that at some point" > >> Did you implement this using the syntax of mouse button events, >> i.e. something like <C-down-tab>? > > I can't remember the details, but yes, pretty much, except I think that > the events generated were along the lines of: > > control C-tab C-up-tab C-up-control > > the last one is a bit odd, but it's just how it turned out. It would be nice to have this in Emacs. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 8:45 ` Juri Linkov @ 2008-04-09 9:34 ` Paul R 2008-04-09 14:12 ` Stefan Monnier 0 siblings, 1 reply; 141+ messages in thread From: Paul R @ 2008-04-09 9:34 UTC (permalink / raw) To: Juri Linkov; +Cc: lennart.borgman, Stefan Monnier, emacs-devel Juri Linkov <juri@jurta.org> writes: > It would be nice to have this in Emacs. I, too, think a lot of usability improvements can be derived from such a facility. At least, I'd be very happy to be able to play with that. Stefan, do you think your work is ready to go into the trunk ? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 9:34 ` Paul R @ 2008-04-09 14:12 ` Stefan Monnier 0 siblings, 0 replies; 141+ messages in thread From: Stefan Monnier @ 2008-04-09 14:12 UTC (permalink / raw) To: Paul R; +Cc: Juri Linkov, lennart.borgman, emacs-devel >> It would be nice to have this in Emacs. > I, too, think a lot of usability improvements can be derived from such > a facility. I'm not sure which ones, really. Especially considering that it won't be available under ttys, and that it has some downsides as well (e.g. C-h k and C-h l) and introduces several minor incompatibilities which require changes in Elisp, but since they're minor and non-obvious you have to wait for someone to bump into it before you know it needs to be fixed. > At least, I'd be very happy to be able to play with that. > Stefan, do you think your work is ready to go into the trunk ? For some reason I scrapped most of it. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 15:33 ` Lennart Borgman (gmail) 2008-04-07 23:31 ` Juri Linkov @ 2008-04-08 13:58 ` Andrew W. Nosenko 2008-04-08 14:21 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 141+ messages in thread From: Andrew W. Nosenko @ 2008-04-08 13:58 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: Juri Linkov, koppel, rms, emacs-devel On Mon, Apr 7, 2008 at 6:33 PM, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote: > I am not sure how that could work and look. One important thing about tabs > IMO is the ability to use C-tab/C-S-tab to switch tab. No, please! First: standard (at least standard GTK+) bindings for tab switching are C-PageDown (next tab) and C-PageUp (prev tab). Second: I (personally) use C-tab for 'other-window', which is more convenient for me than 'C-x o' and already tired to combat with fc-cache (ord-mode ocupies C-tab also, but it lives not so deep and more simple to re-bind anything). Thererefore, please, consider do not touching C-tab at all, please. -- Andrew W. Nosenko <andrew.w.nosenko@gmail.com> ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 13:58 ` Andrew W. Nosenko @ 2008-04-08 14:21 ` Lennart Borgman (gmail) 2008-04-08 15:55 ` Paul R 0 siblings, 1 reply; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-04-08 14:21 UTC (permalink / raw) To: Andrew W. Nosenko; +Cc: Juri Linkov, koppel, rms, emacs-devel Andrew W. Nosenko wrote: > On Mon, Apr 7, 2008 at 6:33 PM, Lennart Borgman (gmail) > <lennart.borgman@gmail.com> wrote: >> I am not sure how that could work and look. One important thing about tabs >> IMO is the ability to use C-tab/C-S-tab to switch tab. > > No, please! > > First: standard (at least standard GTK+) bindings for tab switching > are C-PageDown (next tab) and C-PageUp (prev tab). > > Second: I (personally) use C-tab for 'other-window', which is more > convenient for me than 'C-x o' and already tired to combat with > fc-cache (ord-mode ocupies C-tab also, but it lives not so deep and > more simple to re-bind anything). Thererefore, please, consider do > not touching C-tab at all, please. So GTK choosed another binding than the default one on w32? That is trouble of course. On w32 I can't remember any application that does not use C-Tab to switch tab. What does Firefox do on GNU/Linux? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 14:21 ` Lennart Borgman (gmail) @ 2008-04-08 15:55 ` Paul R 2008-04-08 16:04 ` Dan Nicolaescu 2008-04-08 16:50 ` Ehud Karni 0 siblings, 2 replies; 141+ messages in thread From: Paul R @ 2008-04-08 15:55 UTC (permalink / raw) To: Lennart Borgman (gmail) Cc: Juri Linkov, koppel, rms, Andrew W. Nosenko, emacs-devel "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: > (...). What does Firefox do on GNU/Linux? C-PageUp , C-PageDown. -- Paul ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 15:55 ` Paul R @ 2008-04-08 16:04 ` Dan Nicolaescu 2008-04-08 16:24 ` Paul R 2008-04-08 16:25 ` Andrew W. Nosenko 2008-04-08 16:50 ` Ehud Karni 1 sibling, 2 replies; 141+ messages in thread From: Dan Nicolaescu @ 2008-04-08 16:04 UTC (permalink / raw) To: Paul R Cc: rms, Lennart Borgman (gmail), Andrew W. Nosenko, emacs-devel, Juri Linkov, koppel Paul R <paul.r.ml@gmail.com> writes: > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: > > > (...). What does Firefox do on GNU/Linux? > > C-PageUp , C-PageDown. C-TAB, C-S-TAB work just fine in Firefox. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 16:04 ` Dan Nicolaescu @ 2008-04-08 16:24 ` Paul R 2008-04-08 16:25 ` Andrew W. Nosenko 1 sibling, 0 replies; 141+ messages in thread From: Paul R @ 2008-04-08 16:24 UTC (permalink / raw) To: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > C-TAB, C-S-TAB work just fine in Firefox. Right, I did not know. They do work as well. GTK, on the other hand only catch C-PgDn and C-PgUp ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 16:04 ` Dan Nicolaescu 2008-04-08 16:24 ` Paul R @ 2008-04-08 16:25 ` Andrew W. Nosenko 2008-04-08 20:10 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 141+ messages in thread From: Andrew W. Nosenko @ 2008-04-08 16:25 UTC (permalink / raw) To: emacs-devel; +Cc: Juri Linkov, koppel, Paul R, Lennart Borgman (gmail), rms On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote: > > Paul R <paul.r.ml@gmail.com> writes: > > > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: > > > > > (...). What does Firefox do on GNU/Linux? > > > > C-PageUp , C-PageDown. > > C-TAB, C-S-TAB work just fine in Firefox. > But not under Galeon or Epiphany. They use C-PageUp and C-PageDown (again). -- Andrew W. Nosenko <andrew.w.nosenko@gmail.com> ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 16:25 ` Andrew W. Nosenko @ 2008-04-08 20:10 ` Lennart Borgman (gmail) 2008-04-08 21:16 ` David De La Harpe Golden 0 siblings, 1 reply; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-04-08 20:10 UTC (permalink / raw) To: Andrew W. Nosenko; +Cc: Juri Linkov, koppel, Paul R, rms, emacs-devel Andrew W. Nosenko wrote: > On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote: >> Paul R <paul.r.ml@gmail.com> writes: >> >> > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: >> > >> > > (...). What does Firefox do on GNU/Linux? >> > >> > C-PageUp , C-PageDown. >> >> C-TAB, C-S-TAB work just fine in Firefox. >> > > But not under Galeon or Epiphany. They use C-PageUp and C-PageDown (again). What is Galeon and Epiphany? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 20:10 ` Lennart Borgman (gmail) @ 2008-04-08 21:16 ` David De La Harpe Golden 2008-04-08 21:47 ` Lennart Borgman (gmail) 2008-04-08 22:09 ` Juri Linkov 0 siblings, 2 replies; 141+ messages in thread From: David De La Harpe Golden @ 2008-04-08 21:16 UTC (permalink / raw) To: Lennart Borgman (gmail) Cc: rms, Andrew W. Nosenko, emacs-devel, Juri Linkov, koppel, Paul R Lennart Borgman (gmail) wrote: > Andrew W. Nosenko wrote: >> On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote: >>> Paul R <paul.r.ml@gmail.com> writes: >>> >>> > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: >>> > >>> > > (...). What does Firefox do on GNU/Linux? >>> > >>> > C-PageUp , C-PageDown. >>> >>> C-TAB, C-S-TAB work just fine in Firefox. >>> >> >> But not under Galeon or Epiphany. They use C-PageUp and C-PageDown >> (again). > > What is Galeon and Epiphany? > Web browsers* in the Gtk+/GNOME camp, GNOMEfied Mozilla Gecko (i.e. like firefox) engine. Though apparently Epiphany are moving to a WebKit engine (i.e. Like safari) (which is funny, given WebKit started as a fork of KDE's Khtml engine...) *Epiphany started as a fork of Galeon. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 21:16 ` David De La Harpe Golden @ 2008-04-08 21:47 ` Lennart Borgman (gmail) 2008-04-09 2:50 ` David De La Harpe Golden ` (2 more replies) 2008-04-08 22:09 ` Juri Linkov 1 sibling, 3 replies; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-04-08 21:47 UTC (permalink / raw) To: David De La Harpe Golden Cc: rms, Andrew W. Nosenko, emacs-devel, Juri Linkov, koppel, Paul R David De La Harpe Golden wrote: > Lennart Borgman (gmail) wrote: >> Andrew W. Nosenko wrote: >>> On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote: >>>> Paul R <paul.r.ml@gmail.com> writes: >>>> >>>> > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: >>>> > >>>> > > (...). What does Firefox do on GNU/Linux? >>>> > >>>> > C-PageUp , C-PageDown. >>>> >>>> C-TAB, C-S-TAB work just fine in Firefox. >>>> >>> But not under Galeon or Epiphany. They use C-PageUp and C-PageDown >>> (again). >> What is Galeon and Epiphany? >> > > Web browsers* in the Gtk+/GNOME camp, GNOMEfied Mozilla Gecko > (i.e. like firefox) engine. Though apparently Epiphany > are moving to a WebKit engine (i.e. Like safari) (which is funny, given > WebKit started as a fork of KDE's Khtml engine...) > > *Epiphany started as a fork of Galeon. Thanks David. I can't understand this. Why are they fighting a (rather) well established standard on w32 instead of using it to their favor to get new users? Our problem here is of course a bit different. Emacs is a big keyboard short cut eater. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 21:47 ` Lennart Borgman (gmail) @ 2008-04-09 2:50 ` David De La Harpe Golden 2008-04-09 8:50 ` Juri Linkov 2008-04-09 7:55 ` Jason Rumney 2008-04-09 10:34 ` Richard Stallman 2 siblings, 1 reply; 141+ messages in thread From: David De La Harpe Golden @ 2008-04-09 2:50 UTC (permalink / raw) To: Lennart Borgman (gmail) Cc: rms, Andrew W. Nosenko, Emacs developers, Juri Linkov, koppel, Paul R Lennart Borgman (gmail) wrote: > Thanks David. > > I can't understand this. Why are they fighting a (rather) well > established standard on w32 instead of using it to their favor to get > new users? > Not sure you can take for granted that developers - and users - of other desktop guis (or even w32) are as familiar with w32 as you might be. :-) I myself have relatively seldom used w32 (amiga->gnu/linux in 1990s...), and of w32 users I know, most aren't at a skill level where they'd use many keyboard shortcuts to navigate... So, I had no idea C-TAB did that on windows, and on gnu/linux I'm used to C-PgUp/Dn - turns out I've been missing out, Tk notebooks use C-TAB, I just didn't discover that until now. Anyway, you can't be significantly better than w32 by just imitating w32. :-) I'd say it's way more important that the shortcuts are vaguely consistent intra-platform than inter-platform - mac shortcuts quite often differ from w32 too... ... of course, they're _not_ always consistent intra-platform on gnu/linux X11 desktops, but within a single toolkit/desktop-environment application family you've some hope. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 2:50 ` David De La Harpe Golden @ 2008-04-09 8:50 ` Juri Linkov 0 siblings, 0 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-09 8:50 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: emacs-devel >> I can't understand this. Why are they fighting a (rather) well >> established standard on w32 instead of using it to their favor to get >> new users? > > Not sure you can take for granted that developers - and users - of other > desktop guis (or even w32) are as familiar with w32 as you might be. :-) > I myself have relatively seldom used w32 (amiga->gnu/linux in 1990s...), > and of w32 users I know, most aren't at a skill level where they'd use > many keyboard shortcuts to navigate... So, I had no idea C-TAB > did that on windows, and on gnu/linux I'm used to C-PgUp/Dn - turns out > I've been missing out, Tk notebooks use C-TAB, I just didn't discover > that until now. Tabs were first introduced by CUA for notebook pages, and CUA was most widely used on w32 applications. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 21:47 ` Lennart Borgman (gmail) 2008-04-09 2:50 ` David De La Harpe Golden @ 2008-04-09 7:55 ` Jason Rumney 2008-04-09 10:34 ` Richard Stallman 2 siblings, 0 replies; 141+ messages in thread From: Jason Rumney @ 2008-04-09 7:55 UTC (permalink / raw) To: Lennart Borgman (gmail) Cc: rms, David De La Harpe Golden, Andrew W. Nosenko, emacs-devel, Juri Linkov, koppel, Paul R Lennart Borgman (gmail) wrote: > I can't understand this. Why are they fighting a (rather) well > established standard on w32 instead of using it to their favor to get > new users? I'm not sure they are. C-tab is the standard keybinding for switching between child windows in an application, not for switching between tabs. What do Windows applications that have both tiled windows and tabs do (eg MSVC)? Do some applications just use C-tab in addition to C-pagedown because there are no child windows and C-tab is otherwise available? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 21:47 ` Lennart Borgman (gmail) 2008-04-09 2:50 ` David De La Harpe Golden 2008-04-09 7:55 ` Jason Rumney @ 2008-04-09 10:34 ` Richard Stallman 2008-04-09 14:59 ` Lennart Borgman (gmail) 2 siblings, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-09 10:34 UTC (permalink / raw) To: Lennart Borgman (gmail) Cc: david, andrew.w.nosenko, emacs-devel, juri, koppel, paul.r.ml I can't understand this. Why are they fighting a (rather) well established standard on w32 instead of using it to their favor to get new users? Please let's NOT discuss that question here. It is a distraction and a waste of time. Those who want to discuss it, please take it elsewhere. The discussion of which commands are used by various browsers is also mostly a distraction. If you want to make a real contribution to Emacs, discussing side issues will tend to get in the way. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 10:34 ` Richard Stallman @ 2008-04-09 14:59 ` Lennart Borgman (gmail) 0 siblings, 0 replies; 141+ messages in thread From: Lennart Borgman (gmail) @ 2008-04-09 14:59 UTC (permalink / raw) To: rms; +Cc: david, andrew.w.nosenko, emacs-devel, juri, koppel, paul.r.ml Richard Stallman wrote: > I can't understand this. Why are they fighting a (rather) well > established standard on w32 instead of using it to their favor to get > new users? > > Please let's NOT discuss that question here. It is a distraction > and a waste of time. Those who want to discuss it, please > take it elsewhere. Yes, I will try to avoid it. Anyway I searched a bit on the net and maybe this summary can be useful: http://userfriendly.free.fr/christopher/en/index.php?2006/02/21/4-standard-keyboard-shortcuts Obviously the author have been struggling with the same kind of problems that we have here. We need not at all agree with his points, but he have some useful links. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 21:16 ` David De La Harpe Golden 2008-04-08 21:47 ` Lennart Borgman (gmail) @ 2008-04-08 22:09 ` Juri Linkov 2008-04-09 8:12 ` Andreas Schwab 1 sibling, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-08 22:09 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: emacs-devel >>>> > > (...). What does Firefox do on GNU/Linux? >>>> > >>>> > C-PageUp , C-PageDown. >>>> >>>> C-TAB, C-S-TAB work just fine in Firefox. >>> >>> But not under Galeon or Epiphany. They use C-PageUp and C-PageDown >>> (again). >> >> What is Galeon and Epiphany? > > Web browsers* in the Gtk+/GNOME camp, GNOMEfied Mozilla Gecko > (i.e. like firefox) engine. Though apparently Epiphany > are moving to a WebKit engine (i.e. Like safari) (which is funny, given > WebKit started as a fork of KDE's Khtml engine...) And Konqueror uses yet another variant of keys to switch tabs: C-[ and C-]. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 22:09 ` Juri Linkov @ 2008-04-09 8:12 ` Andreas Schwab 2008-04-09 8:52 ` Juri Linkov 0 siblings, 1 reply; 141+ messages in thread From: Andreas Schwab @ 2008-04-09 8:12 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel, David De La Harpe Golden Juri Linkov <juri@jurta.org> writes: > And Konqueror uses yet another variant of keys to switch tabs: > C-[ and C-]. It's fully configurable. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 8:12 ` Andreas Schwab @ 2008-04-09 8:52 ` Juri Linkov 0 siblings, 0 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-09 8:52 UTC (permalink / raw) To: Andreas Schwab; +Cc: emacs-devel, David De La Harpe Golden >> And Konqueror uses yet another variant of keys to switch tabs: >> C-[ and C-]. > > It's fully configurable. I see, its default keys C-[ C-] C-, C-. can be rebound to C-TAB and C-S-TAB because these keys are free and not bound to something else. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 15:55 ` Paul R 2008-04-08 16:04 ` Dan Nicolaescu @ 2008-04-08 16:50 ` Ehud Karni 1 sibling, 0 replies; 141+ messages in thread From: Ehud Karni @ 2008-04-08 16:50 UTC (permalink / raw) To: paul.r.ml; +Cc: juri, lennart.borgman, emacs-devel On Tue, 08 Apr 2008 17:55:04 +0200, Paul R wrote: > > "Lennart Borgman (gmail)" writes: > > > (...). What does Firefox do on GNU/Linux? > > C-PageUp , C-PageDown. > > -- Paul The C-PgUp, C-PgDn works in Firefox on M$Windows too. Ehud. -- Ehud Karni Tel: +972-3-7966-561 /"\ Mivtach - Simon Fax: +972-3-7966-667 \ / ASCII Ribbon Campaign Insurance agencies (USA) voice mail and X Against HTML Mail http://www.mvs.co.il FAX: 1-815-5509341 / \ GnuPG: 98EA398D <http://www.keyserver.net/> Better Safe Than Sorry ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Tab bar 2008-04-07 14:59 ` Richard Stallman 2008-04-07 15:33 ` Lennart Borgman (gmail) @ 2008-04-07 16:09 ` Drew Adams 2008-04-07 16:52 ` Stefan Monnier 2008-04-07 23:28 ` Juri Linkov 2 siblings, 1 reply; 141+ messages in thread From: Drew Adams @ 2008-04-07 16:09 UTC (permalink / raw) To: rms, 'Juri Linkov'; +Cc: koppel, emacs-devel > It would be good to have a tab bar of perspectives, too. Especially if you are talking about having multiple tab bars of different types, using something narrow, such as a header line, is better than using huge tabs, such as were shown. I don't care one way or the other about tabbar.el itself (I like it, but I'm not suggesting that is the only way to go), but I think its design of using a header line is a good one. With such an approach, we can easily have more than one header line, with, for example, different backgrounds or whatever, to distinguish the different tab types (buffers, perspectives, ...). On the other hand, tabbar.el has a different way of dealing with different types of tab bar: They are all present in the same header line, but only one is shown at a time. The first thing in the header line is a button that cycles among the tab-bar types ("tab sets"). That is very handy, and reduces space. But it can also be helpful sometimes to see more than one tab set at the same time (e.g. two header lines, of different tab type), so having that as an option would be good. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 16:09 ` Drew Adams @ 2008-04-07 16:52 ` Stefan Monnier 2008-04-07 23:35 ` Juri Linkov 2008-04-08 15:36 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: Stefan Monnier @ 2008-04-07 16:52 UTC (permalink / raw) To: Drew Adams; +Cc: 'Juri Linkov', koppel, rms, emacs-devel >> It would be good to have a tab bar of perspectives, too. > Especially if you are talking about having multiple tab bars of > different types, using something narrow, such as a header line, is > better than using huge tabs, such as were shown. All the current Elisp-based tabbars I've seen might be good proofs-of-concept but are not appropriate implementations: they either hijack the toolbar, or the header-line, neither of which is acceptable. Also they both have the corresponding limitation: tabbar.el cannot be used for perspectives because header lines are "per-window", and tab-bar.el cannot be used for buffers because toolbars are "per-frame". I think a good implementation for a tabbar would be to use a whole window (and buffer) for the tabbar (set mode-line-format to nil and window-min-height to 1 or 2). This would allow placing it anywhere in the window tree, and hence all both "one per frame" and "one per window". Of course, to make it work well, we probably need some changes at the C level in order to treat those windows specially, although we can probably kludge around it in an Elisp-only proof-of-concept. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 16:52 ` Stefan Monnier @ 2008-04-07 23:35 ` Juri Linkov 2008-04-08 15:36 ` Richard Stallman 1 sibling, 0 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-07 23:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > All the current Elisp-based tabbars I've seen might be good > proofs-of-concept but are not appropriate implementations: they either > hijack the toolbar, or the header-line, neither of which is acceptable. Yes, I agree that all there PoC implementations are abuses of the header line and the toolbar, and neither of them treats correctly modes that use the header line and the toolbar in the intended way (like e.g. info.el that overwrites them with its own data). > Also they both have the corresponding limitation: tabbar.el cannot be > used for perspectives because header lines are "per-window", and > tab-bar.el cannot be used for buffers because toolbars are "per-frame". There is also a third variant implemented by elscreen.el: it uses the header line to switch between window configurations, but often it exhibits a weird behavior when it tries to keep the header line with tabs only in the top window. > I think a good implementation for a tabbar would be to use a whole > window (and buffer) for the tabbar (set mode-line-format to nil and > window-min-height to 1 or 2). Also we need to disable the fringes and the scroll bar, but I don't see how to do this in a single window. > This would allow placing it anywhere in the window tree, and hence all > both "one per frame" and "one per window". Of course, to make it work > well, we probably need some changes at the C level in order to treat > those windows specially, although we can probably kludge around it in > an Elisp-only proof-of-concept. Unless it will be possible to implement native tabbars, using a special window seems to be a good compromise. It would even allow creating arbitrary tabbar configurations, e.g. a vertical top-down tabbar on the right side of the frame like I use in Firefox that is allowed by the flexibility of the Gecko layout engine. I wish Emacs having enough primitives to implement arbitrary layouts for the tabbar and also a compilation error navigation bar, parallel to the scroll bar, that Richard wants to add to Emacs. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 16:52 ` Stefan Monnier 2008-04-07 23:35 ` Juri Linkov @ 2008-04-08 15:36 ` Richard Stallman 2008-04-09 1:56 ` Stefan Monnier 1 sibling, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-08 15:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: juri, koppel, drew.adams, emacs-devel I think a good implementation for a tabbar would be to use a whole window (and buffer) for the tabbar (set mode-line-format to nil and window-min-height to 1 or 2). This would allow placing it anywhere in the window tree, and hence all both "one per frame" and "one per window". Of course, to make it work well, we probably need some changes at the C level in order to treat those windows specially, Once we make changes at the C level, there should be no need for the overhead of a separate window for the tabs. It would be easiest and most convenient to generate the tabs directly from an alist. If each normal window has a tool bar, it would be a pain in the neck to have to make a second window (for the tool bar) for each normal window. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 15:36 ` Richard Stallman @ 2008-04-09 1:56 ` Stefan Monnier 2008-04-09 10:34 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: Stefan Monnier @ 2008-04-09 1:56 UTC (permalink / raw) To: rms; +Cc: juri, koppel, drew.adams, emacs-devel > I think a good implementation for a tabbar would be to use a whole > window (and buffer) for the tabbar (set mode-line-format to nil and > window-min-height to 1 or 2). This would allow placing it anywhere in > the window tree, and hence all both "one per frame" and "one per > window". Of course, to make it work well, we probably need some changes > at the C level in order to treat those windows specially, > Once we make changes at the C level, there should be no need for the > overhead of a separate window for the tabs. It would be easiest and > most convenient to generate the tabs directly from an alist. > If each normal window has a tool bar, it would be a pain in the neck > to have to make a second window (for the tool bar) for each normal window. I want to be able to place a tabbar with each window and/or with each frame. Or really, anywhere along the window-tree. I'm not wedded to the idea of having a separate window for each tabbar, it's just an idea for how to create a more flexible tabbar entirely in Elisp. Once/if we implement this at the C level we may want a completely different approach indeed. Stefan ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 1:56 ` Stefan Monnier @ 2008-04-09 10:34 ` Richard Stallman 0 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-04-09 10:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: juri, koppel, drew.adams, emacs-devel I'm not wedded to the idea of having a separate window for each tabbar, it's just an idea for how to create a more flexible tabbar entirely in Elisp. This must be implemented in C, so that we can adjust its appearance to make it look right. Given that, I think other half-baked implementations are not very useful effort. What we need is for someone to implement tabs in C, using toolkit widgets for toolkits that provide them. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 14:59 ` Richard Stallman 2008-04-07 15:33 ` Lennart Borgman (gmail) 2008-04-07 16:09 ` Drew Adams @ 2008-04-07 23:28 ` Juri Linkov 2 siblings, 0 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-07 23:28 UTC (permalink / raw) To: rms; +Cc: emacs-devel > Meanwhile, if the tab bar normally shows the most recently used > buffers, MOST OF THE TIME the buffer you want will be visible there I think this is not the most useful order, and web browsers arrange tabs by the order of their creation (although they have an option to switch tabs by the order of recency, so in the tabbar where tabs are arranged by the order of creation, C-tab navigates to the last visited tab and so on, by the order of recency of their visiting time). > What Emacs still misses is a feature to group several frames, > window configurations, work areas, perspectives (these are > different names for almost the same thing) in the tab bar. > > It would be good to have a tab bar of perspectives, too. Yes, as Eclipse has both types of tab bars: a tab bar of perspectives equivalent to Emacs window configurations or Emacs frames, and a tab bar of parts equivalent to Emacs buffers. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Tab bar (was: Neat features in Eclipse editor) 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov 2008-04-06 23:07 ` Tab bar David Koppelman @ 2008-04-07 1:37 ` Drew Adams 2008-04-07 14:59 ` Richard Stallman 2008-04-07 23:33 ` Tab bar Juri Linkov 2008-04-07 15:00 ` Tab bar (was: Neat features in Eclipse editor) Richard Stallman 2008-04-07 23:59 ` Tab bar David De La Harpe Golden 3 siblings, 2 replies; 141+ messages in thread From: Drew Adams @ 2008-04-07 1:37 UTC (permalink / raw) To: 'Juri Linkov', emacs-devel [-- Attachment #1: Type: text/plain, Size: 915 bytes --] > I just created a small experimental Emacs Lisp library that > emulates the tab bar feature provided by most modern web > browsers, file managers and editors. Tabs are very popular > nowadays mostly due to their ability to group units > equivalent to Emacs frames into one frame and providing > handles to switch them quickly inside one frame without > having to switch top-level frames. How does it compare with tabbar.el? I use that, and generally like it. > Below is a screenshot how this feature currently looks in Emacs Unsolicited feedback: Too much wasted horizontal space. See tabbar.el, for example: there is no horizontal space between the tabs (other than their borders). I customized the default tabbar.el faces, however - the default faces are unreadable on Windows, IMO. Attached is a screenshot showing the faces I use, to give you an idea of what I mean about the horizontal space. HTH. [-- Attachment #2: throw-tabbar.png --] [-- Type: image/png, Size: 11288 bytes --] ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar (was: Neat features in Eclipse editor) 2008-04-07 1:37 ` Tab bar (was: Neat features in Eclipse editor) Drew Adams @ 2008-04-07 14:59 ` Richard Stallman 2008-04-07 16:09 ` Drew Adams 2008-04-07 23:33 ` Tab bar Juri Linkov 1 sibling, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-07 14:59 UTC (permalink / raw) To: Drew Adams; +Cc: juri, emacs-devel > Below is a screenshot how this feature currently looks in Emacs Unsolicited feedback: Too much wasted horizontal space. For the traditional Emacs mode of use, you're probably right. But if we connect this with a (small) list of preferred buffers for each window, there will not need to be many tabs in one window. Then this "wasted" space could be a good thing. ^ permalink raw reply [flat|nested] 141+ messages in thread
* RE: Tab bar (was: Neat features in Eclipse editor) 2008-04-07 14:59 ` Richard Stallman @ 2008-04-07 16:09 ` Drew Adams 2008-04-07 23:35 ` Mathias Dahl 0 siblings, 1 reply; 141+ messages in thread From: Drew Adams @ 2008-04-07 16:09 UTC (permalink / raw) To: rms; +Cc: juri, emacs-devel > > Below is a screenshot how this feature currently looks in Emacs > > Unsolicited feedback: Too much wasted horizontal space. > > For the traditional Emacs mode of use, you're probably right. > But if we connect this with a (small) list of preferred buffers > for each window, there will not need to be many tabs in one window. > Then this "wasted" space could be a good thing. I don't see why. For what reason would the wasted space (vertical, as well as horizontal) be a good thing? I don't think it matters much how many tabs there are - even if there is only one tab, the same vertical space is lost. What is gained by having huge tabs widely separated from each other? ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar (was: Neat features in Eclipse editor) 2008-04-07 16:09 ` Drew Adams @ 2008-04-07 23:35 ` Mathias Dahl 0 siblings, 0 replies; 141+ messages in thread From: Mathias Dahl @ 2008-04-07 23:35 UTC (permalink / raw) To: Drew Adams; +Cc: juri, rms, emacs-devel > What is gained by having huge tabs > widely separated from each other? Readability, maybe. More easy on the eyes when stuff is not crammed together. However, I also reacted to the screenshot and thought the tabs was a little bit too far from each other. But hey, it is a prototype. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 1:37 ` Tab bar (was: Neat features in Eclipse editor) Drew Adams 2008-04-07 14:59 ` Richard Stallman @ 2008-04-07 23:33 ` Juri Linkov 1 sibling, 0 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-07 23:33 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel >> I just created a small experimental Emacs Lisp library that >> emulates the tab bar feature provided by most modern web >> browsers, file managers and editors. Tabs are very popular >> nowadays mostly due to their ability to group units >> equivalent to Emacs frames into one frame and providing >> handles to switch them quickly inside one frame without >> having to switch top-level frames. > > How does it compare with tabbar.el? I use that, and generally like it. In tabbar.el the tab bar belongs to one window, but in tab-bar.el that I presented it belongs to a frame. >> Below is a screenshot how this feature currently looks in Emacs > > Unsolicited feedback: Too much wasted horizontal space. This is a restriction from the implementation of the tool-bar reused by tab-bar.el. I don't know why the tool-bar inserts extra space between icons. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar (was: Neat features in Eclipse editor) 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov 2008-04-06 23:07 ` Tab bar David Koppelman 2008-04-07 1:37 ` Tab bar (was: Neat features in Eclipse editor) Drew Adams @ 2008-04-07 15:00 ` Richard Stallman 2008-04-07 23:59 ` Tab bar David De La Harpe Golden 3 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-04-07 15:00 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel A graphical tab bar has two special buttons: on the left side to create a new tab, and on the right side to close the current tab. Between them there is a row of tabs that represent different window configurations. Does the tab bar belong to one window or does it belong to a frame? You say that a tab represents a "window configuration". That seems to suggest that the tabs belong to a frame. What we need most, in regard to tabs, is a row of tabs that belongs to a window, with each tab specifying something to display in that window. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov ` (2 preceding siblings ...) 2008-04-07 15:00 ` Tab bar (was: Neat features in Eclipse editor) Richard Stallman @ 2008-04-07 23:59 ` David De La Harpe Golden 2008-04-08 22:06 ` Juri Linkov 3 siblings, 1 reply; 141+ messages in thread From: David De La Harpe Golden @ 2008-04-07 23:59 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Juri Linkov wrote: > I think we should do this as soon as possible because > this single feature can improve Emacs usability for most users that expect > a tab bar is a standard editor feature. > > I think someone's already mentioned this several threads ago: there needs to be some clear separation of concerns regarding "tab bars" tabs in tab bars themselves are just gui widgets nothing more - Indeed much like icons in tool bars, just drawn a bit differently. I don't see why emacs shouldn't support a tab bar GUI widget or multiple widgets (say toplevel tab bar for each toplevel frame, and tab bars for each window (emacs window), perhaps with configurable positions) But people keep talking about various other editors' features that are "hung off" tabs kind of as if they _are_ what tabs are - such features, while perhaps exposed to the user through tab widgets, should be clearly separated from the tab GUI widget itself. e.g. in some editors and browsers, clicking on tab-shaped GUI widgets might well switch between top-level-frame-like things/ intra-app subwindow configurations, perspectives... or they may just tab through several pages of toolbars with tiny little icons (gah! I hate that), or just switch buffers (therefore being considered attached to the subwindow not the toplevel), or whatever. They tend to be for switching between stuff as a matter of convention, but what they switch between varies. (Personally I've always considered the top-level-frame-switcher sort of tab bar rightly a tabbing WM's job (e.g. pwm), really, but that's not the way people went for the most part, presumably since you don't see tabbing WMs on windows/mac - but if you're using a tabbing WM, then multiple emacs toplevel frames can _already_ be tabbed between in the "one" window system window, and the advent of browser "tabs" was pretty uninteresting too...) ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-07 23:59 ` Tab bar David De La Harpe Golden @ 2008-04-08 22:06 ` Juri Linkov 2008-04-09 1:07 ` David De La Harpe Golden 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-08 22:06 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: emacs-devel > I think someone's already mentioned this several threads ago: there > needs to be some clear separation of concerns regarding "tab bars" > > tabs in tab bars themselves are just gui widgets nothing more - Indeed > much like icons in tool bars, just drawn a bit differently. I don't > see why emacs shouldn't support a tab bar GUI widget or multiple widgets We already have a suitable infrastructure of graphical primitives to implement a tab bar on top of it. It is required to have graphical areas attached to window edges that can contain a row of bitmaps bound to some commands. This functionality is already supported by the header line and window fringes. It seems what we need is to improve them to attach arbitrary number of header lines and fringes to a window, and to render text (tab names) using specified fonts on these graphical elements. > (say toplevel tab bar for each toplevel frame, and tab bars for each > window (emacs window), perhaps with configurable positions) Since we need both types, maybe we should implement also the frame header line and frame fringes? > (Personally I've always considered the top-level-frame-switcher sort of > tab bar rightly a tabbing WM's job (e.g. pwm), really, but that's not > the way people went for the most part, presumably since you don't see > tabbing WMs on windows/mac - but if you're using a tabbing WM, then > multiple emacs toplevel frames can _already_ be tabbed between in the > "one" window system window, and the advent of browser "tabs" was pretty > uninteresting too...) I think tab bars are popular because they contain only elements of the current program without stuff from other programs in their lists. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-08 22:06 ` Juri Linkov @ 2008-04-09 1:07 ` David De La Harpe Golden 2008-04-09 8:48 ` Juri Linkov 0 siblings, 1 reply; 141+ messages in thread From: David De La Harpe Golden @ 2008-04-09 1:07 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Juri Linkov wrote: > We already have a suitable infrastructure of graphical primitives to > implement a tab bar on top of it. It is required to have graphical > areas attached to window edges that can contain a row of bitmaps > bound to some commands. This functionality is already supported by the > header line and window fringes. It seems what we need is to improve > them to attach arbitrary number of header lines and fringes to a window, > and to render text (tab names) using specified fonts on these > graphical elements. however, toolkits like gtk+ do have tab widgets, like they have tool bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll bars" and "toolkit tool bars" and "toolkit menu bars" in emacs? > > I think tab bars are popular because they contain only elements of the > current program without stuff from other programs in their lists. > Trying to understand that, at least re tabbed wm vs. intraprogram-implemented tabbing - are you suggesting the window-attached tab bars in a tabbed wm *would* have stuff from other programs in their lists? Now, granted they _could_, but typically,other applications' windows would have to be manually dragged into the tabbed window, whereas new windows from existing applications could e.g. default to the tabbed window their last window went into. (just screenshots of windows with multiple tabs under a couple of tabbed window managers, no I'm not doing it ascii art, sorry). http://modeemi.fi/~tuomov/ion/pwm/screenshots/pwm-3.jpg http://fluxbox.sourceforge.net/features/tabs.php ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 1:07 ` David De La Harpe Golden @ 2008-04-09 8:48 ` Juri Linkov 2008-04-09 9:24 ` David Kastrup 2008-04-09 9:45 ` Paul R 0 siblings, 2 replies; 141+ messages in thread From: Juri Linkov @ 2008-04-09 8:48 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: emacs-devel >> We already have a suitable infrastructure of graphical primitives to >> implement a tab bar on top of it. It is required to have graphical >> areas attached to window edges that can contain a row of bitmaps >> bound to some commands. This functionality is already supported by the >> header line and window fringes. It seems what we need is to improve >> them to attach arbitrary number of header lines and fringes to a window, >> and to render text (tab names) using specified fonts on these >> graphical elements. > > however, toolkits like gtk+ do have tab widgets, like they have tool > bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll > bars" and "toolkit tool bars" and "toolkit menu bars" in emacs? Then should we have two versions of tab widgets: Gtk and non-Gtk? >> I think tab bars are popular because they contain only elements of the >> current program without stuff from other programs in their lists. > > Trying to understand that, at least re tabbed wm vs. > intraprogram-implemented tabbing - are you suggesting the > window-attached tab bars in a tabbed wm *would* have stuff from other > programs in their lists? Now, granted they _could_, but typically,other > applications' windows would have to be manually dragged into the tabbed > window, whereas new windows from existing applications could e.g. > default to the tabbed window their last window went into. The main disadvantage of tabbed WMs is that they can't provide program-specific functionality like e.g. a command to undo tab closing, etc. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 8:48 ` Juri Linkov @ 2008-04-09 9:24 ` David Kastrup 2008-04-09 23:28 ` Juri Linkov 2008-04-09 9:45 ` Paul R 1 sibling, 1 reply; 141+ messages in thread From: David Kastrup @ 2008-04-09 9:24 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel, David De La Harpe Golden Juri Linkov <juri@jurta.org> writes: >>> We already have a suitable infrastructure of graphical primitives to >>> implement a tab bar on top of it. It is required to have graphical >>> areas attached to window edges that can contain a row of bitmaps >>> bound to some commands. This functionality is already supported by the >>> header line and window fringes. It seems what we need is to improve >>> them to attach arbitrary number of header lines and fringes to a window, >>> and to render text (tab names) using specified fonts on these >>> graphical elements. >> >> however, toolkits like gtk+ do have tab widgets, like they have tool >> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll >> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs? > > Then should we have two versions of tab widgets: Gtk and non-Gtk? Why wouldn't we? (Actually, I don't think we'd stop at two). We use the native widgets for other stuff, too. XEmacs doesn't and looks quaint everywhere in comparison. -- David Kastrup ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 9:24 ` David Kastrup @ 2008-04-09 23:28 ` Juri Linkov 2008-04-10 6:11 ` Jan Djärv 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-09 23:28 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel, David De La Harpe Golden >>> however, toolkits like gtk+ do have tab widgets, like they have tool >>> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll >>> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs? >> >> Then should we have two versions of tab widgets: Gtk and non-Gtk? > > Why wouldn't we? (Actually, I don't think we'd stop at two). We use the > native widgets for other stuff, too. XEmacs doesn't and looks quaint > everywhere in comparison. Do other toolkits used in Emacs provide tab bar widgets? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 23:28 ` Juri Linkov @ 2008-04-10 6:11 ` Jan Djärv 2008-04-10 7:31 ` Jason Rumney 2008-04-10 15:31 ` Richard Stallman 0 siblings, 2 replies; 141+ messages in thread From: Jan Djärv @ 2008-04-10 6:11 UTC (permalink / raw) To: Juri Linkov; +Cc: David De La Harpe Golden, emacs-devel Juri Linkov skrev: >>>> however, toolkits like gtk+ do have tab widgets, like they have tool >>>> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll >>>> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs? >>> Then should we have two versions of tab widgets: Gtk and non-Gtk? >> Why wouldn't we? (Actually, I don't think we'd stop at two). We use the >> native widgets for other stuff, too. XEmacs doesn't and looks quaint >> everywhere in comparison. > > Do other toolkits used in Emacs provide tab bar widgets? Not Lucid (a.k.a native). And not X11 (i.e. no toolkit, just libX11). Jan D. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-10 6:11 ` Jan Djärv @ 2008-04-10 7:31 ` Jason Rumney 2008-04-10 7:44 ` Jason Rumney 2008-04-10 8:08 ` Jan Djärv 2008-04-10 15:31 ` Richard Stallman 1 sibling, 2 replies; 141+ messages in thread From: Jason Rumney @ 2008-04-10 7:31 UTC (permalink / raw) To: Jan Djärv; +Cc: Juri Linkov, emacs-devel, David De La Harpe Golden Jan Djärv wrote: > > Juri Linkov skrev: >> >> Do other toolkits used in Emacs provide tab bar widgets? > > Not Lucid (a.k.a native). And not X11 (i.e. no toolkit, just libX11). Nor W32. Which leaves Mac (likely) and Motif (unlikely). ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-10 7:31 ` Jason Rumney @ 2008-04-10 7:44 ` Jason Rumney 2008-04-10 8:08 ` Jan Djärv 1 sibling, 0 replies; 141+ messages in thread From: Jason Rumney @ 2008-04-10 7:44 UTC (permalink / raw) To: Jan Djärv; +Cc: Juri Linkov, David De La Harpe Golden, emacs-devel Jason Rumney wrote: > Jan Djärv wrote: >> >> Juri Linkov skrev: >>> >>> Do other toolkits used in Emacs provide tab bar widgets? >> >> Not Lucid (a.k.a native). And not X11 (i.e. no toolkit, just libX11). > > Nor W32 I take that back, I was looking in the wrong header, they are available along with native toolbars in the common control library (which we already use for the scroll bar). ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-10 7:31 ` Jason Rumney 2008-04-10 7:44 ` Jason Rumney @ 2008-04-10 8:08 ` Jan Djärv 1 sibling, 0 replies; 141+ messages in thread From: Jan Djärv @ 2008-04-10 8:08 UTC (permalink / raw) To: Jason Rumney; +Cc: Juri Linkov, David De La Harpe Golden, emacs-devel Jason Rumney skrev: > Jan Djärv wrote: >> >> Juri Linkov skrev: >>> >>> Do other toolkits used in Emacs provide tab bar widgets? >> >> Not Lucid (a.k.a native). And not X11 (i.e. no toolkit, just libX11). > > Nor W32. Which leaves Mac (likely) and Motif (unlikely). Actually Motif 2.0 introduced the Notebook widget. The name is the same in Gtk+. Both are tabbar-like widgets. Motif can also have tabs on the side (vertically) and a spiral look on the other side to make it look more like a book. Jan D. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-10 6:11 ` Jan Djärv 2008-04-10 7:31 ` Jason Rumney @ 2008-04-10 15:31 ` Richard Stallman 2008-04-10 23:11 ` Juri Linkov 1 sibling, 1 reply; 141+ messages in thread From: Richard Stallman @ 2008-04-10 15:31 UTC (permalink / raw) To: Jan Djärv; +Cc: juri, emacs-devel, david > Do other toolkits used in Emacs provide tab bar widgets? Not Lucid (a.k.a native). And not X11 (i.e. no toolkit, just libX11). These configurations could use the code used for ttys if nobody wants to implement anything else. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-10 15:31 ` Richard Stallman @ 2008-04-10 23:11 ` Juri Linkov 2008-04-12 0:10 ` Richard Stallman 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-10 23:11 UTC (permalink / raw) To: rms; +Cc: Jan Djärv, emacs-devel, david > > Do other toolkits used in Emacs provide tab bar widgets? > > Not Lucid (a.k.a native). And not X11 (i.e. no toolkit, just libX11). > > These configurations could use the code used for ttys > if nobody wants to implement anything else. Do you mean we need tab bars for ttys as well. I can't imagine how this could look. Maybe, like a tty menu bar is currently implemented? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-10 23:11 ` Juri Linkov @ 2008-04-12 0:10 ` Richard Stallman 0 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-04-12 0:10 UTC (permalink / raw) To: Juri Linkov; +Cc: jan.h.d, emacs-devel, david > These configurations could use the code used for ttys > if nobody wants to implement anything else. Do you mean we need tab bars for ttys as well. I can't imagine how this could look. Maybe, like a tty menu bar is currently implemented? I think someone asked for tab bars on ttys too, but I am not sure we _need_ them. I don't see that there would be any harm in not supporting tab bars on terminals. It would be somewhat of a shame not to support tab bars with the Lucid toolkit, though. And the mouse does work on some terminals, so the user could use the tab bar with it. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 8:48 ` Juri Linkov 2008-04-09 9:24 ` David Kastrup @ 2008-04-09 9:45 ` Paul R 2008-04-09 23:29 ` Juri Linkov 1 sibling, 1 reply; 141+ messages in thread From: Paul R @ 2008-04-09 9:45 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel, David De La Harpe Golden Juri Linkov <juri@jurta.org> writes: > Then should we have two versions of tab widgets: Gtk and non-Gtk? In any case, are we planning to have tabs only for X toolkit ? What about emacs -nw ? I agree Tabs will shine as an intuitive way to change what emacs displays (be it buffers or views) by clicking on them. But should this feature simply disappear when emacs is in text-mode ? -- paul ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 9:45 ` Paul R @ 2008-04-09 23:29 ` Juri Linkov 2008-04-10 8:09 ` Paul R 0 siblings, 1 reply; 141+ messages in thread From: Juri Linkov @ 2008-04-09 23:29 UTC (permalink / raw) To: Paul R; +Cc: emacs-devel, David De La Harpe Golden >> Then should we have two versions of tab widgets: Gtk and non-Gtk? > > In any case, are we planning to have tabs only for X toolkit ? What > about emacs -nw ? I agree Tabs will shine as an intuitive way to > change what emacs displays (be it buffers or views) by clicking on > them. But should this feature simply disappear when emacs is in > text-mode ? Do users of emacs -nw complain that there are no toolbars, no scrollbars, and no other toolkit widgets when Emacs is in text-only mode? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Tab bar 2008-04-09 23:29 ` Juri Linkov @ 2008-04-10 8:09 ` Paul R 0 siblings, 0 replies; 141+ messages in thread From: Paul R @ 2008-04-10 8:09 UTC (permalink / raw) To: Juri Linkov; +Cc: David De La Harpe Golden, emacs-devel Juri Linkov <juri@jurta.org> writes: > Do users of emacs -nw complain that there are no toolbars, no scrollbars, > and no other toolkit widgets when Emacs is in text-only mode? Let's see what form will Tabs take. If it takes the form of a list of clickable butons for "switch-to-buffer", then we can call it "interface candy" which is, indeed, not required in emacs -nw. ^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor
@ 2008-03-28 1:49 Josh Gilbert
2008-03-28 23:54 ` Richard Stallman
0 siblings, 1 reply; 141+ messages in thread
From: Josh Gilbert @ 2008-03-28 1:49 UTC (permalink / raw)
To: emacs-devel
Richard Stallman <address@hidden> writes:
> I might be missing something, but isn't tabbar.el sufficient?
>
> I don't know. I find its documentation hard to understand,
> so I am not sure what it does.
I, too, found tabbar.el difficult to understand. I use a different package,
elscreen.el, to perform the same function. Because elcreen.el uses
essentially the same interface as GNU Screen (with C-z as the command prefix
rather than C-a as used in screen) I was able to use it immediately. It's
really a brilliant piece of software that I'd love to see incorporated into
Emacs proper. Another nice feature of ElScreen is that it works flawlessly on
Windows. It's one of the first packages I install when I set up a new Emacs
instance.
http://www.emacswiki.org/cgi-bin/wiki/ElScreen
Josh
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-28 1:49 Neat features in Eclipse editor Josh Gilbert @ 2008-03-28 23:54 ` Richard Stallman 0 siblings, 0 replies; 141+ messages in thread From: Richard Stallman @ 2008-03-28 23:54 UTC (permalink / raw) To: Josh Gilbert; +Cc: emacs-devel I, too, found tabbar.el difficult to understand. I use a different package, elscreen.el, to perform the same function. elscreen.el may be useful, but the topic here is implementing tabs. ^ permalink raw reply [flat|nested] 141+ messages in thread
end of thread, other threads:[~2008-04-19 2:23 UTC | newest] Thread overview: 141+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-22 21:45 Neat features in Eclipse editor Richard Stallman 2008-03-22 21:56 ` Chong Yidong 2008-03-22 21:36 ` Tom Tromey 2008-03-22 23:09 ` Leo 2008-03-23 14:18 ` William Xu 2008-03-23 2:27 ` Juri Linkov 2008-03-23 9:53 ` joakim 2008-03-23 10:50 ` martin rudalics 2008-03-23 10:54 ` martin rudalics 2008-03-23 19:35 ` John S. Yates, Jr. 2008-03-23 19:39 ` Thomas Lord 2008-03-23 21:06 ` John S. Yates, Jr. 2008-03-23 21:42 ` Thomas Lord 2008-03-23 19:49 ` Drew Adams 2008-03-25 8:11 ` dtm 2008-03-24 0:53 ` Stefan Monnier 2008-03-24 0:54 ` Richard Stallman 2008-03-24 19:02 ` joakim 2008-03-25 1:06 ` Bastien 2008-03-25 18:31 ` Richard Stallman 2008-03-25 19:19 ` Rajappa Iyer 2008-03-26 1:33 ` Stefan Monnier 2008-03-26 4:46 ` Richard Stallman 2008-03-25 1:50 ` Richard Stallman 2008-04-18 13:25 ` joakim 2008-04-19 2:23 ` Richard Stallman 2008-03-24 0:53 ` Richard Stallman 2008-03-24 18:47 ` paul r 2008-03-25 1:50 ` Richard Stallman 2008-03-25 3:53 ` Window configuration UI (was: Neat features in Eclipse editor) Stefan Monnier 2008-03-25 10:54 ` Window configuration UI Lennart Borgman (gmail) 2008-03-25 18:13 ` Stefan Monnier 2008-03-26 4:47 ` Window configuration UI (was: Neat features in Eclipse editor) Richard Stallman 2008-03-26 9:41 ` Window configuration UI Lennart Borgman (gmail) 2008-03-26 22:26 ` Richard Stallman 2008-03-27 2:14 ` Stefan Monnier 2008-03-27 19:41 ` Richard Stallman 2008-03-29 16:27 ` Michael Sperber 2008-03-31 2:41 ` Window configuration UI (was: Neat features in Eclipse editor) Nick Roberts 2008-03-31 16:25 ` Richard Stallman 2008-04-01 3:00 ` Window configuration UI Stefan Monnier 2008-04-01 21:04 ` Richard Stallman 2008-03-25 10:08 ` Neat features in Eclipse editor paul r 2008-03-25 10:55 ` David Reitter 2008-03-25 11:35 ` paul r 2008-03-25 21:00 ` Richard Stallman 2008-03-25 22:10 ` paul r 2008-03-26 1:50 ` Robert J. Chassell 2008-03-26 22:26 ` Richard Stallman 2008-03-25 21:01 ` Richard Stallman 2008-03-25 21:16 ` Lennart Borgman (gmail) 2008-03-25 23:17 ` Mike Mattie 2008-03-26 2:23 ` Evans Winner 2008-03-26 7:09 ` Jan Djärv 2008-03-26 7:18 ` Drew Adams 2008-03-26 22:25 ` Richard Stallman 2008-03-26 22:38 ` Sebastian Rose 2008-03-26 22:57 ` paul r 2008-03-26 23:20 ` Sebastian Rose 2008-03-27 6:57 ` David Kastrup 2008-03-27 0:22 ` Mike Mattie 2008-03-27 0:17 ` Mike Mattie 2008-03-27 19:41 ` Richard Stallman 2008-03-27 20:18 ` Sebastian Rose 2008-03-27 0:18 ` Lennart Borgman (gmail) 2008-03-25 0:48 ` Bastien 2008-03-24 1:51 ` Dan Nicolaescu 2008-03-24 12:29 ` Richard Stallman 2008-03-24 18:24 ` joakim 2008-03-25 1:50 ` Richard Stallman 2008-04-06 20:52 ` Tab bar (was: Neat features in Eclipse editor) Juri Linkov 2008-04-06 23:07 ` Tab bar David Koppelman 2008-04-06 23:48 ` Juri Linkov 2008-04-07 0:05 ` David Koppelman 2008-04-07 0:32 ` Juri Linkov 2008-04-07 14:59 ` Richard Stallman 2008-04-07 23:27 ` Juri Linkov 2008-04-08 15:35 ` Richard Stallman 2008-04-08 15:50 ` Jason Rumney 2008-04-08 16:58 ` Drew Adams 2008-04-09 10:33 ` Richard Stallman 2008-04-09 23:27 ` Juri Linkov 2008-04-07 14:59 ` Richard Stallman 2008-04-07 15:33 ` Lennart Borgman (gmail) 2008-04-07 23:31 ` Juri Linkov 2008-04-08 0:21 ` Drew Adams 2008-04-08 2:06 ` Stefan Monnier 2008-04-08 22:11 ` Juri Linkov 2008-04-09 2:00 ` Stefan Monnier 2008-04-09 8:45 ` Juri Linkov 2008-04-09 9:34 ` Paul R 2008-04-09 14:12 ` Stefan Monnier 2008-04-08 13:58 ` Andrew W. Nosenko 2008-04-08 14:21 ` Lennart Borgman (gmail) 2008-04-08 15:55 ` Paul R 2008-04-08 16:04 ` Dan Nicolaescu 2008-04-08 16:24 ` Paul R 2008-04-08 16:25 ` Andrew W. Nosenko 2008-04-08 20:10 ` Lennart Borgman (gmail) 2008-04-08 21:16 ` David De La Harpe Golden 2008-04-08 21:47 ` Lennart Borgman (gmail) 2008-04-09 2:50 ` David De La Harpe Golden 2008-04-09 8:50 ` Juri Linkov 2008-04-09 7:55 ` Jason Rumney 2008-04-09 10:34 ` Richard Stallman 2008-04-09 14:59 ` Lennart Borgman (gmail) 2008-04-08 22:09 ` Juri Linkov 2008-04-09 8:12 ` Andreas Schwab 2008-04-09 8:52 ` Juri Linkov 2008-04-08 16:50 ` Ehud Karni 2008-04-07 16:09 ` Drew Adams 2008-04-07 16:52 ` Stefan Monnier 2008-04-07 23:35 ` Juri Linkov 2008-04-08 15:36 ` Richard Stallman 2008-04-09 1:56 ` Stefan Monnier 2008-04-09 10:34 ` Richard Stallman 2008-04-07 23:28 ` Juri Linkov 2008-04-07 1:37 ` Tab bar (was: Neat features in Eclipse editor) Drew Adams 2008-04-07 14:59 ` Richard Stallman 2008-04-07 16:09 ` Drew Adams 2008-04-07 23:35 ` Mathias Dahl 2008-04-07 23:33 ` Tab bar Juri Linkov 2008-04-07 15:00 ` Tab bar (was: Neat features in Eclipse editor) Richard Stallman 2008-04-07 23:59 ` Tab bar David De La Harpe Golden 2008-04-08 22:06 ` Juri Linkov 2008-04-09 1:07 ` David De La Harpe Golden 2008-04-09 8:48 ` Juri Linkov 2008-04-09 9:24 ` David Kastrup 2008-04-09 23:28 ` Juri Linkov 2008-04-10 6:11 ` Jan Djärv 2008-04-10 7:31 ` Jason Rumney 2008-04-10 7:44 ` Jason Rumney 2008-04-10 8:08 ` Jan Djärv 2008-04-10 15:31 ` Richard Stallman 2008-04-10 23:11 ` Juri Linkov 2008-04-12 0:10 ` Richard Stallman 2008-04-09 9:45 ` Paul R 2008-04-09 23:29 ` Juri Linkov 2008-04-10 8:09 ` Paul R -- strict thread matches above, loose matches on Subject: below -- 2008-03-28 1:49 Neat features in Eclipse editor Josh Gilbert 2008-03-28 23:54 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).