Re: Neat features in Eclipse editor

Re: Neat features in Eclipse editor

[Tom Tromey]

>>>>> "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

Neat features in Eclipse editor

[Richard Stallman]

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.

Re: Neat features in Eclipse editor

[Chong Yidong]

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?

Re: Neat features in Eclipse editor

[Leo]

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/

Re: Neat features in Eclipse editor

[Juri Linkov]

[-- 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/

Re: Neat features in Eclipse editor

[joakim]

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

Re: Neat features in Eclipse editor

[martin rudalics]

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? 
> 

Re: Neat features in Eclipse editor

[martin rudalics]

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.

Re: Neat features in Eclipse editor

[William Xu]

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

       点绛唇
                王禹
雨恨云愁，江南依旧称佳丽。
水村渔市，一缕孤烟细。
天际征鸿，遥认行如缀。
平生事，此时凝睇，谁会恁栏意！

Re: Neat features in Eclipse editor

[John S. Yates, Jr.]

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

Re: Neat features in Eclipse editor

[Thomas Lord]

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
>
>
>
>   

RE: Neat features in Eclipse editor

[Drew Adams]

> 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!"

Re: Neat features in Eclipse editor

[John S. Yates, Jr.]

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

Re: Neat features in Eclipse editor

[Thomas Lord]

[-- 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 --]

Re: Neat features in Eclipse editor

[Stefan Monnier]

> 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

Re: Neat features in Eclipse editor

[Richard Stallman]

    > * "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.

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[Dan Nicolaescu]

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.

Re: Neat features in Eclipse editor

[Richard Stallman]

      > * 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.

Re: Neat features in Eclipse editor

[joakim]

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

Re: Neat features in Eclipse editor

[paul r]

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))

Re: Neat features in Eclipse editor

[joakim]

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

Re: Neat features in Eclipse editor

[Bastien]

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

Re: Neat features in Eclipse editor

[Bastien]

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

Re: Neat features in Eclipse editor

[Richard Stallman]

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.

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[dtm]

>>>>> "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

Re: Neat features in Eclipse editor

[paul r]

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))

Re: Neat features in Eclipse editor

[David Reitter]

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.

Re: Neat features in Eclipse editor

[paul r]

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.

Re: Neat features in Eclipse editor

[Richard Stallman]

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?

Re: Neat features in Eclipse editor

[Rajappa Iyer]

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

Re: Neat features in Eclipse editor

[Richard Stallman]

    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!

Re: Neat features in Eclipse editor

[Richard Stallman]

    > 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.

Re: Neat features in Eclipse editor

[Lennart Borgman (gmail)]

> 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?

Re: Neat features in Eclipse editor

[paul r]

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 ?

Re: Neat features in Eclipse editor

[Mike Mattie]

[-- 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 --]

Re: Neat features in Eclipse editor

[Stefan Monnier]

>> 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

Re: Neat features in Eclipse editor

[Robert J. Chassell]

    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

Re: Neat features in Eclipse editor

[Evans Winner]

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.

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[Jan Djärv]

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.

RE: Neat features in Eclipse editor

[Drew Adams]

> ...support for tool kit specific tabs should be added.
> I don't know how tabbar does its tabs.

It uses a header line.

Re: Neat features in Eclipse editor

[Richard Stallman]

    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?

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[Sebastian Rose]

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).

Re: Neat features in Eclipse editor

[paul r]

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
>
>

Re: Neat features in Eclipse editor

[Sebastian Rose]

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? 

Re: Neat features in Eclipse editor

[Mike Mattie]

[-- 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 --]

Re: Neat features in Eclipse editor

[Lennart Borgman (gmail)]

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

Re: Neat features in Eclipse editor

[Mike Mattie]

[-- 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 --]

Re: Neat features in Eclipse editor

[David Kastrup]

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

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[Sebastian Rose]

Yepp, sorry, new to this part of the universe :)

I meant plattforms not running MFC nor MAC (what is it on MAC???), but Gtk.

Re: Neat features in Eclipse editor

[Josh Gilbert]

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

Re: Neat features in Eclipse editor

[Richard Stallman]

    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.

Re: Neat features in Eclipse editor

[joakim]

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

Re: Neat features in Eclipse editor

[Richard Stallman]

    - 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.