* Re: Neat features in Eclipse editor
@ 2008-03-28 1:49 Josh Gilbert
2008-03-28 23:54 ` Richard Stallman
0 siblings, 1 reply; 59+ 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] 59+ 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; 59+ 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] 59+ messages in thread
* Neat features in Eclipse editor @ 2008-03-22 21:45 Richard Stallman 2008-03-22 21:56 ` Chong Yidong 2008-03-24 1:51 ` Dan Nicolaescu 0 siblings, 2 replies; 59+ 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] 59+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:45 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 1 sibling, 5 replies; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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 10:08 ` paul r 0 siblings, 1 reply; 59+ 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] 59+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 1:50 ` Richard Stallman @ 2008-03-25 10:08 ` paul r 2008-03-25 10:55 ` David Reitter 2008-03-25 21:01 ` Richard Stallman 0 siblings, 2 replies; 59+ 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] 59+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 10:08 ` 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-25 10:08 ` 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ messages in thread
* Re: Neat features in Eclipse editor 2008-03-22 21:45 Richard Stallman 2008-03-22 21:56 ` Chong Yidong @ 2008-03-24 1:51 ` Dan Nicolaescu 2008-03-24 12:29 ` Richard Stallman 1 sibling, 1 reply; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ 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; 59+ 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] 59+ messages in thread
end of thread, other threads:[~2008-04-19 2:23 UTC | newest] Thread overview: 59+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-28 1:49 Neat features in Eclipse editor Josh Gilbert 2008-03-28 23:54 ` Richard Stallman -- strict thread matches above, loose matches on Subject: below -- 2008-03-22 21:45 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 10:08 ` 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.