Neat features in Eclipse editor

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

[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

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

[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

[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

[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

[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

[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

[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

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

    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

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

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]

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

[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

[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

[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

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

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

[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

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

Window configuration UI (was: Neat features in Eclipse editor)

[Stefan Monnier]

> When you switch from workspace A to workspace B, does your current
> window configuration get recorded as workspace A?
> That is an important aspect of Eclipse perspectives.

Indeed.  Try out my naive attempt at it (see attached) immediately bumps
into a significant problem: window-configurations are frame-specific, so
I can't create a winconf "test1" in a frame and then use it in
another frame.

> needs to be possible to get all the right behavior.  For instance, we
> want GUD to be able to take advantage of this, with a predefined "gud"
> perspective.  This predefined "gud" perspective should have a window

This is another problem: window-configurations can't be saved&loaded.
I.e. the tool we need is not `window-configuration' but some
other object.  We can construct it all in Elisp from window-tree, but
someone needs to write the code.


        Stefan


;; Window config management

(defvar winconf-alist nil)
(defvar winconf-hist nil)

(defun switch-to-winconf (conf-name)
  (interactive
   (let* ((oldname (frame-parameter nil 'winconf-name))
          (comp (remove (assoc oldname winconf-alist) winconf-alist)))
     (list (completing-read (format "Switch winconf from %s to: "
                                    (or oldname "<none>"))
                            comp nil (when winconf-alist 'confirm-only)
                            nil 'winconf-hist))))
  (let* ((oldname (frame-parameter nil 'winconf-name))
         (oldconf (assoc oldname winconf-alist))
         (newconf (assoc conf-name winconf-alist)))
    (when oldname
      (if oldconf
          (setcdr oldconf (current-window-configuration))
        (push (cons oldname (current-window-configuration)) winconf-alist)))
    (if newconf (set-window-configuration (cdr newconf)))
    (set-frame-parameter nil 'winconf-name conf-name)))

Re: Window configuration UI

[Lennart Borgman (gmail)]

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

Stefan Monnier wrote:
>> When you switch from workspace A to workspace B, does your current
>> window configuration get recorded as workspace A?
>> That is an important aspect of Eclipse perspectives.
> 
> Indeed.  Try out my naive attempt at it (see attached) immediately bumps
> into a significant problem: window-configurations are frame-specific, so
> I can't create a winconf "test1" in a frame and then use it in
> another frame.
> 
>> needs to be possible to get all the right behavior.  For instance, we
>> want GUD to be able to take advantage of this, with a predefined "gud"
>> perspective.  This predefined "gud" perspective should have a window
> 
> This is another problem: window-configurations can't be saved&loaded.
> I.e. the tool we need is not `window-configuration' but some
> other object.  We can construct it all in Elisp from window-tree, but
> someone needs to write the code.


When we last talked about that I wrote the attached file. I have not 
looked at it or used it for a while so I am not sure if everything works 
right now.

[-- Attachment #2: winsav.el --]
[-- Type: text/plain, Size: 21271 bytes --]

;;; winsav.el --- Save and restore window structure
;;
;; Author: Lennart Borgman
;; Created: Sun Jan 14 00:27:19 2007
;; Version: 0.70
;; Last-Updated: Wed Jan 09 00:50:22 2008 (3600 +0100)
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   `cl'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; This library was orignally written to solve the problem of adding a
;; window to the left of some windows in a frame
;;
;; ___________
;; |    |    |
;; | 1  | 2  |
;; |____|____|
;; |         |
;; |    3    |
;; |_________|
;;
;; so that the window structure on the frame becomes
;;
;; ___________
;; |  |  |   |
;; |  | 1| 2 |
;; | B|__|___|
;; | A|      |
;; | R|  3   |
;; |__|______|
;;
;;
;; This problem can be solved by this library. However the solution in
;; this library is a bit more general: You first copy the window
;; structure and then restore that into another window. To do the
;; above you first copy the window structure in the first frame above
;; with `winsav-get-window-tree'. Then you create windows like this:
;;
;; ___________
;; |  |      |
;; |  |      |
;; | B|      |
;; | A|      |
;; | R|      |
;; |__|______|
;;
;;
;; Finally you use `winsav-put-window-tree' to put the window
;; structure into the right window. (Of course you could have put BAR
;; above, under etc.)
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Bugs and limitations:
;;
;; Juanma Barranquero has pointed out there is a serious limitation in
;; this way of doing it when overlays with 'window properties are
;; used. The problem is that any pointers to windows are made invalid
;; since they are deleted. So in fact any code that relies on saved
;; pointers to windows will have problem if the window is one of those
;; that are involved here.
;;
;; To overcome this problem when doing something like inserting a BAR
;; window (see above) a new window has to be inserted in the existing
;; window tree on a frame in a way that is currently not supported in
;; Emacs.
;;
;; It would be nice to be have primitives to manipulate the window
;; tree more generally from elisp.  That requires implementation of
;; them at the C level of course.
;;
;; However it is probably much easier to implement it quite a bit less
;; general. The concept of splitting is maybe then the right level to
;; search for primitives at.
;;
;; My conclusion is that it will take some time to find suitable
;; primitives for this.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;; Version 0.71:
;;
;; - Added rotation of window structure.
;;
;; Version 0.70:
;;
;; - Support for save and restore from file.
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:


(eval-when-compile (require 'cl))

(defun winsav-upper-left-window(&optional frame w)
  (let* ((tree (if w w (car (window-tree frame))))
         (is-split (not (windowp tree))))
    (if (not is-split)
        tree
      (winsav-upper-left-window frame (nth 2 tree)))))


(defvar winsav-after-get-hooks nil
  "Hook to run after at the end of `winsav-get-window-tree'.
The functions in this hook are called with one parameter which is
the same as the return value from the function above.")

(defvar winsav-after-put-hooks nil
  "Hook to run after at the end of `winsav-put-window-tree'.
The functions in this hook are called with one parameter which is
a list where each element is a list \(old-win new-win) where
OLD-WIN are the window from `winsav-get-window-tree' and NEW-WIN
is the newly created corresponding window. This list is the same
as the return value from the function above.")

(defun winsav-get-window-tree(&optional frame)
  "Get window structure.
This returns an object with current windows with values, buffers,
points and the selected window.

FRAME is the frame to save structure from. If nil use selected.

At the very end of this function the hook `winsav-after-get' is
run."
  (let* ((upper-left (winsav-upper-left-window))
         (num -1)
         sel-num)
    (dolist (w (window-list frame nil upper-left))
      (setq num (1+ num))
      (when (eq w (selected-window))
        (setq sel-num num)))
    (let ((ret (list sel-num
                     (winsav-get-window-tree-1 frame nil))))
      (run-hook-with-args 'winsav-after-get-hooks ret)
      ret)))

(defun winsav-get-window-tree-1(frame w)
  (let ((tree (if w w (car (window-tree frame)))))
    (if (windowp tree)
        (list (window-buffer tree)
              (format "Buffer: %s"
                      (let ((bn (buffer-file-name (window-buffer tree))))
                        (if bn
                            bn
                          (window-buffer tree))))
              (window-point tree)
              (window-edges tree)
              (window-dedicated-p tree)
              (window-scroll-bars tree)
              (window-fringes tree)
              (window-margins tree)
              (window-hscroll tree)
              (window-redisplay-end-trigger tree)
              (window-start tree)
              tree)
      (let* ((dir (nth 0 tree))
             (split (nth 1 tree))
             (wt (cddr tree))
             (wsubs (mapcar (lambda(wc)
                              (winsav-get-window-tree-1 nil wc))
                            wt)))
        (append (list dir split) wsubs)))))

(defun winsav-put-window-tree (saved-tree window &optional copy-win-ovl win-ovl-all-bufs)
  "Put window structure into WINDOW.
Restore a structure SAVED-TREE returned from
`winsav-get-window-tree' into window WINDOW.

If COPY-WIN-OVL is non-nil then overlays having a 'window
property pointing to one of the windows in SAVED-TREE where this
window still is shown will be copied to a new overlay with
'window property pointing to the corresponding new window.

If WIN-OVL-ALL-BUFS is non-nil then all buffers will be searched
for overlays with a 'window property of the kind above.

At the very end of this function the hook `winsav-after-put' is
run."
  (let* ((sel-num (nth 0 saved-tree))
         (tree    (nth 1 saved-tree))
         nsiz
         nh
         nw
         osiz
         oh
         ow
         scale-w
         scale-h
         first-win
         winsav-put-return)
    (unless (or (bufferp (car tree))
                (eq 'buffer (car tree)))
      (setq nsiz (window-edges window))
      (setq nh (- (nth 3 nsiz) (nth 1 nsiz)))
      (setq nw (- (nth 2 nsiz) (nth 0 nsiz)))
      (setq osiz (cadr tree))
      (setq oh (- (nth 3 osiz) (nth 1 osiz)))
      (setq ow (- (nth 2 osiz) (nth 0 osiz)))
      (setq scale-w (unless (= ow nw) (/ nw (float ow))))
      (setq scale-h (unless (= oh nh) (/ nh (float oh)))))
    (setq first-win (winsav-put-window-tree-1 tree window scale-w scale-h t 1))
    (select-window first-win)
    (other-window sel-num)
    (winsav-fix-win-ovl winsav-put-return copy-win-ovl win-ovl-all-bufs)
    (run-hook-with-args 'winsav-after-put-hooks winsav-put-return)
    winsav-put-return))

(defun winsav-put-window-tree-1 (saved-tree window scale-w scale-h first-call level)
  ;;(if (bufferp (car saved-tree))
  (if (or (bufferp (car saved-tree))
          ;;(not (car saved-tree))
          (eq 'buffer (car saved-tree))
          )
      (let ((buffer  (nth 0 saved-tree))
            (bufstr  (nth 1 saved-tree))
            (point   (nth 2 saved-tree))
            (edges   (nth 3 saved-tree))
            (dedic   (nth 4 saved-tree))
            (scroll  (nth 5 saved-tree))
            (fringe  (nth 6 saved-tree))
            (margs   (nth 7 saved-tree))
            (hscroll (nth 8 saved-tree))
            (trigger (nth 9 saved-tree))
            (start   (nth 10 saved-tree))
            (ovlwin  (nth 11 saved-tree))
            scr2
            (misbuf  " *Winsav information: Buffer is gone*"))
        (or (windowp ovlwin)
            (not ovlwin)
          (error "parameter mismatch, ovlwin not window: %s" ovlwin))
        (when first-call
          (add-to-list 'winsav-put-return (list ovlwin window))
          (when (eq 'buffer buffer)
            (let ((buf-file bufstr))
              (setq buf-file (substring buf-file 8))
              (setq buffer (winsav-find-file-noselect buf-file))))
          (unless (buffer-live-p buffer)
            (setq buffer (get-buffer-create misbuf))
            (with-current-buffer buffer
              (when (= 0 (length (buffer-string)))
                (insert "The buffer that this window should show is gone:\n\n")
                (put-text-property (point-min) (1- (point-max))
                                   'face 'font-lock-warning-face)
                (setq buffer-read-only t))
              (let ((o (make-overlay (point-max) (point-max))))
                (overlay-put o 'window window)
                (overlay-put o 'before-string bufstr))))
          (set-window-buffer window buffer)
          (set-window-point window point)
          (set-window-dedicated-p window dedic)
          ;; Strange incompatibility in scroll args:
          (setq scr2 (list (nth 0 scroll) (nth 2 scroll) (nth 3 scroll)))
          (apply 'set-window-scroll-bars (append (list window) scr2))
          (apply 'set-window-fringes (append (list window) fringe))
          (set-window-margins window (car margs) (cdr margs))
          (set-window-hscroll window hscroll)
          (set-window-redisplay-end-trigger window trigger))
        (unless (buffer-live-p buffer)
          (setq point 1)
          (setq start 1))
        (set-window-start window start)
        ;; Maybe point got off screen?
        (when (/= point (window-point window))
          (set-window-point window point))
        (let* ((nsiz (window-edges window))
               (nh (- (nth 3 nsiz) (nth 1 nsiz)))
               (nw (- (nth 2 nsiz) (nth 0 nsiz)))
               (osiz edges) ;(nth 2 saved-tree))
               (oh (- (nth 3 osiz) (nth 1 osiz)))
               (ow (- (nth 2 osiz) (nth 0 osiz)))
               (diff-w (- (if scale-w
                              (round (* scale-w ow))
                            ow)
                          nw))
               (diff-h (- (if scale-h
                              (round (* scale-h oh))
                            oh)
                          nh)))
          ;; Avoid rounding naggings:
          (when (> (abs diff-h) 1)
            (bw-adjust-window window diff-h nil))
          (when (> (abs diff-w) 1)
            (bw-adjust-window window diff-w t)))
        window)
    (let* ((ver (car saved-tree))
           (wtree (list (cons window (caddr saved-tree))))
           (nwin window)
           pwin
           pdelta
           (first-win nwin))
      ;; First split to get it in correct order
      (when first-call
        (dolist (subtree (cdddr saved-tree))
          (setq pwin nwin)
          (message "nwin edges=%s, ver=%s" (window-edges nwin) ver)
          (let ((split-err nil)
                (window-min-height 1)
                (window-min-width 1))
            (setq nwin (split-window nwin nil (not ver))))
          ;; Make the previous window as small as permitted to allow
          ;; splitting as many times as possible
          (setq pdelta (-
                        (if ver
                            window-min-height
                          window-min-width)
                        (if ver
                            (window-width pwin)
                          (window-height pwin))))
          ;;(message "pwin=%s, edges=%s, pdelta=%s, ver=%s" pwin (window-edges pwin) pdelta ver)
          ;; No reason to fail here:
          (condition-case err
              (adjust-window-trailing-edge pwin pdelta (not ver))
            (error
             ;;(message "awt=>%s" (error-message-string err))
             nil
             ))
          ;; Add to traverse
          (add-to-list 'wtree
                       (cons nwin subtree)
                       t)))
      ;; Now traverse. Sizing is a bit tricky, multiple runs have to
      ;; be done (as in balance-windows).
      (let (tried-sizes
            last-sizes
            (windows (window-list (selected-frame))))
        (while (not (member last-sizes tried-sizes))
          (when last-sizes (setq tried-sizes (cons last-sizes tried-sizes)))
          (setq last-sizes (mapcar (lambda (w)
                                     (window-edges w))
                                   windows))
          (dolist (wsub (reverse wtree))
            (select-window (car wsub))
            (winsav-put-window-tree-1 (cdr wsub) (selected-window)
                                      scale-w scale-h
                                      first-call
                                      (1+ level)
                                      ))
          (setq first-call nil)
          ))
      first-win)))

(defun winsav-fix-win-ovl(win-list copy-win-ovl win-ovl-all-bufs)
  (let ((oldwins (mapcar (lambda(elt)
                           (car elt))
                         win-list))
        ovlwin
        window)
    (let (buffers)
      (if win-ovl-all-bufs
          (setq buffers (buffer-list))
        (mapc (lambda(w)
                (when (window-live-p w)
                  (add-to-list 'buffers (window-buffer w))))
              oldwins))
      (dolist (buf buffers)
        (with-current-buffer buf
          (save-restriction
            (widen)
            (dolist (overlay (overlays-in (point-min) (point-max)))
              (when (setq ovlwin (car (memq (overlay-get overlay 'window) oldwins)))
                (setq window (cadr (assoc ovlwin win-list)))
                ;; If the old window is still alive then maybe copy
                ;; overlay, otherwise change the 'window prop. However
                ;; copy only if COPY-WIN-OVL is non-nil.
                (if (not (and (window-live-p ovlwin)
                              (window-frame ovlwin)))
                    (overlay-put overlay 'window window)
                  (when copy-win-ovl
                    (let* ((props (overlay-properties overlay))
                           (start (overlay-start overlay))
                           (end   (overlay-end   overlay))
                           ;; Fix-me: start and end marker props
                           (newovl (make-overlay start end)))
                      (while props
                        (let ((key (car props))
                              (val (cadr props)))
                          (setq props (cddr props))
                          (when (eq key 'window)
                            (setq val window))
                          (overlay-put newovl key val))))))))))))))


;;; Window rotating and mirroring

(defun winsav-rotate (mirror transpose)
  "Rotate window configuration on selected frame.
MIRROR should be either 'mirror-left-right, 'mirror-top-bottom or
nil.  In the first case the window configuration is mirrored
vertically and in the second case horizontally. If MIRROR is nil
the configuration is not mirrored.

If TRANSPOSE is non-nil then the window structure is transposed
along the diagonal from top left to bottom right (in analogy with
matrix transosition).

If called interactively MIRROR will is 'mirror-left-right by
default, but 'mirror-top-bottom if called with prefix.  TRANSPOSE
is t. This mean that the window configuration will be turned one
quarter clockwise (or counter clockwise with prefix)."
  (interactive (list
                (if current-prefix-arg
                    'mirror-left-right
                  'mirror-top-bottom)
                t))
  (let* ((wintree (winsav-get-window-tree))
         (tree (cadr wintree))
         (win-config (current-window-configuration)))
    ;;(winsav-log "old-wintree" wintree)
    (winsav-transform-1 tree mirror transpose)
    ;;(winsav-log "new-wintree" wintree)
    ;;
    ;; Fix-me: Stay in corresponding window. How?
    (delete-other-windows)
    (condition-case err
        (winsav-put-window-tree wintree (selected-window))
      (error
       (set-window-configuration win-config)
       (message "Can't rotate: %s" (error-message-string err))))
    ))

(defun winsav-transform-edges (edges)
  (let (
        (le (nth 0 edges))
        (te (nth 1 edges))
        (re (nth 2 edges))
        (be (nth 3 edges)))
    (list te le be re)))

(defun winsav-transform-1 (tree mirror transpose)
  (let* ((vertical (nth 0 tree))
         (edges    (nth 1 tree))
         (subtrees (nthcdr 2 tree))
         )
    ;;(winsav-log "tree 1" tree)
    (when transpose
      (cond
       ((eq vertical nil)
        (setcar tree t))
       ((eq vertical t)
        (setcar tree nil))
       (t
        (error "Uh? vertical=%S" vertical))))
    (setcar (nthcdr 1 tree) (winsav-transform-edges edges))
    (dolist (subtree subtrees)
      (if (bufferp (car subtree))
          (when transpose
            (let ((edges    (nth 3 subtree)))
              ;;(winsav-log "subtree 1" subtree)
              (setcar (nthcdr 3 subtree) (winsav-transform-edges edges))
              ;;(winsav-log "subtree 2" subtree)
              ))
        (winsav-transform-1 subtree mirror transpose)))
    (when (case mirror
            ('mirror-top-bottom vertical)
            ('mirror-left-right (not vertical))
            (nil) ;; Don't mirror
            (t
             (error "Uh? mirror=%s" mirror)))
      (setcdr (nthcdr 1 tree) (reverse subtrees))
      )
    ))

;;(global-set-key [f11] 'winsav-rotate)


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; winsav+.el ends here

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;; TEST ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; (defun winsav-log-buffer ()
;;   (get-buffer-create "winsav log buffer"))

;; (defun winsav-log (mark obj)
;;   (with-current-buffer (winsav-log-buffer)
;;     (insert "=== " mark "===\n" (pp-to-string obj))))

;; (global-set-key [f2] 'winsav-test-get)
;; (global-set-key [f3] 'winsav-test-put)
;; (defvar winsav-saved-window-tree nil)

;; (defun winsav-test-get()
;;   (interactive)
;;   (setq winsav-saved-window-tree (winsav-get-window-tree)))

;; (defun winsav-test-put()
;;   (interactive)
;;   (let ((ret (winsav-put-window-tree winsav-saved-window-tree
;;                                      (selected-window))))
;;     ;;(message "ret=%s" ret)
;;     ))

(defun winsav-serialize (obj)
  (prin1-to-string obj))

(defun winsav-de-serialize (str)
  (save-match-data
    (let ((read-str
           (replace-regexp-in-string (rx "#<buffer "
                                         (1+ (not (any ">")))
                                         ">")
                                     "buffer"
                                     str))
          obj-last
          obj
          last)
      (setq read-str
            (replace-regexp-in-string (rx "#<window "
                                          (1+ (not (any ">")))
                                          ">")
                                      "nil"
                                      read-str))
      (setq obj-last (read-from-string read-str))
      (setq obj (car obj-last))
      (setq last (cdr obj-last))
      ;; Fix me, maby check there are only spaces left (or trim them above...)
      obj)))

(defun winsav-serialize-to-file (obj file)
  (with-current-buffer (find-file-noselect file)
    (erase-buffer)
    (insert (winsav-serialize obj))
    (save-buffer)))

(defun winsav-de-serialize-from-file (file)
  (with-current-buffer (find-file-noselect file)
    (save-restriction
      (goto-char (point-min))
      (winsav-de-serialize (buffer-substring-no-properties (point-min) (point-max))))))

(defun winsav-save-frame-to-file (file frame)
  (serialize-to-file
   (winsav-get-window-tree frame)
   file))

(defun winsav-restore-from-file (file)
  (winsav-put-window-tree
   (winsav-de-serialize-from-file file)
   (selected-window)))

(defun winsav-find-file-noselect (filename)
  (let ((buf (find-file-noselect filename)))
    (unless buf
      (setq buf (generate-new-buffer filename))
      (with-current-buffer buf
        (insert "Winsav could not find the file " filename)
        (set-buffer-modified-p nil)))
    buf))

;; (defun test ()
;;   (let ((obj (list "a" 1 "b" 2)))
;;     (equal (de-serialize (serialize obj))
;;            obj)))

(provide 'winsav)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; winsav.el ends here

Re: Window configuration UI

[Stefan Monnier]

>>> When you switch from workspace A to workspace B, does your current
>>> window configuration get recorded as workspace A?
>>> That is an important aspect of Eclipse perspectives.
>> 
>> Indeed.  Try out my naive attempt at it (see attached) immediately bumps
>> into a significant problem: window-configurations are frame-specific, so
>> I can't create a winconf "test1" in a frame and then use it in
>> another frame.
>> 
>>> needs to be possible to get all the right behavior.  For instance, we
>>> want GUD to be able to take advantage of this, with a predefined "gud"
>>> perspective.  This predefined "gud" perspective should have a window
>> 
>> This is another problem: window-configurations can't be saved&loaded.
>> I.e. the tool we need is not `window-configuration' but some
>> other object.  We can construct it all in Elisp from window-tree, but
>> someone needs to write the code.


> When we last talked about that I wrote the attached file. I have not looked
> at it or used it for a while so I am not sure if everything works right now.

That looks interesting.  I'm wondering about the window-identity
problems: where did they bite?  I.e. what caused you to code up all the
overlay-hacks?

I see there's another problem in the part that saves the data to a file:
we need to use `bookmarks' to save the buffer&position.


        Stefan

Re: Window configuration UI (was: 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.

    Indeed.  Try out my naive attempt at it (see attached) immediately bumps
    into a significant problem: window-configurations are frame-specific, so
    I can't create a winconf "test1" in a frame and then use it in
    another frame.

Moving window configurations from frame to frame is not necessary
for the perspectives feature.  Perspectives in Eclipse seem to be
part of one frame, although I am not sure of that.

    > needs to be possible to get all the right behavior.  For instance, we
    > want GUD to be able to take advantage of this, with a predefined "gud"
    > perspective.  This predefined "gud" perspective should have a window

    This is another problem: window-configurations can't be saved&loaded.

That's a real issue, directly related to implementing perspectives.
To make perspectives persistent we need a way for Lisp code to get
access to the data in them.

In 1984 it was crucial for a window configuration to include window
objects to make it fast to switch to one.  But that may not be
necessary now.  So we could reimplement window configurations
using Lisp objects that hold the data in a transparent way.

Would someone like to try this?

Re: Window configuration UI

[Lennart Borgman (gmail)]

Richard Stallman wrote:
> In 1984 it was crucial for a window configuration to include window
> objects to make it fast to switch to one.  But that may not be
> necessary now.  So we could reimplement window configurations
> using Lisp objects that hold the data in a transparent way.
> 
> Would someone like to try this?


I attached some code a few days ago. Will that code help? (winsav.el)

Re: Window configuration UI

[Richard Stallman]

    I attached some code a few days ago. Will that code help? (winsav.el)

It appears to go in the right direction.

It would be interesting to try replacing the current
window-configuration code with winsav.el, to see if it is fast enough.
It seems to me that `winsav-get-window-tree' could be made a lot
faster, especially by writing it in C.  But I don't know if it
needs to be any faster.

Could you write some documentation of the format returned
by `winsav-get-window-tree'?

How does winsav deal with the tree structure of non-leaf windows?  I
think that it does not know about non-leaf windows; is that correct?
If so, it is something we need to fix, and that probably
requires changes at the C level.

Re: Window configuration UI

[Stefan Monnier]

> It would be interesting to try replacing the current
> window-configuration code with winsav.el, to see if it is fast enough.
> It seems to me that `winsav-get-window-tree' could be made a lot
> faster, especially by writing it in C.  But I don't know if it needs
> to be any faster.

It doesn't seem to be noticeably slow.  But it does not provide a 100%
replacement for the window-configuration functions (mostly because of
the issue of preserving window-identity vs. creating new windows).
Not sure how important it is.  IIUC XEmacs has switched to such an
Elisp-only implementation of window-configurations so they probably know
more about the impact of this incompatibility.

> How does winsav deal with the tree structure of non-leaf windows?  I
> think that it does not know about non-leaf windows; is that correct?
> If so, it is something we need to fix, and that probably
> requires changes at the C level.

It uses `window-tree' so it does know about non-leaf windows.


        Stefan

Re: Window configuration UI

[Richard Stallman]

    It doesn't seem to be noticeably slow.  But it does not provide a 100%
    replacement for the window-configuration functions (mostly because of
    the issue of preserving window-identity vs. creating new windows).

If we make this change, not trying to preserve window identity is almost
inevitable.  I think we should try it.

Re: Window configuration UI

[Michael Sperber]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It would be interesting to try replacing the current
>> window-configuration code with winsav.el, to see if it is fast enough.
>> It seems to me that `winsav-get-window-tree' could be made a lot
>> faster, especially by writing it in C.  But I don't know if it needs
>> to be any faster.
>
> It doesn't seem to be noticeably slow.  But it does not provide a 100%
> replacement for the window-configuration functions (mostly because of
> the issue of preserving window-identity vs. creating new windows).
> Not sure how important it is.  IIUC XEmacs has switched to such an
> Elisp-only implementation of window-configurations so they probably know
> more about the impact of this incompatibility.

There wasn't a noticeable performance impact, but a small number of
packages (used to) depend on preservation of window identity.  Most
recently, ECB broke on XEmacs 21.5 because of this, but we've since
worked out a fix that I expect to apply shortly.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: Window configuration UI (was: Neat features in Eclipse editor)

[Nick Roberts]

 > > needs to be possible to get all the right behavior.  For instance, we
 > > want GUD to be able to take advantage of this, with a predefined "gud"
 > > perspective.  This predefined "gud" perspective should have a window
 > 
 > This is another problem: window-configurations can't be saved&loaded.
 > I.e. the tool we need is not `window-configuration' but some
 > other object.  We can construct it all in Elisp from window-tree, but
 > someone needs to write the code.

A bit late and perhaps not related to this specific point but when I tried
tabbar.el with gdb-ui I hit a problem with dedicated windows: I couldn't switch
buffer by clicking on the tab because the current window was dedicated.

Maybe some concept of a window being dedicated to the set of buffers that have
tabs for it, i.e., you could switch between tabs but other buffers couldn't
switch into it, would be some kind of useful subframe entity.

Just a random, possibly ill-conceived, thought.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Window configuration UI (was: Neat features in Eclipse editor)

[Richard Stallman]

    Maybe some concept of a window being dedicated to the set of buffers that have
    tabs for it, i.e., you could switch between tabs but other buffers couldn't
    switch into it, would be some kind of useful subframe entity.

That sounds like a good idea to me.  It could be implemented in tabbar.el;
if you click on a tab belonging to a dedicated window, it could un-dedicate
the window, switch buffers in it, then re-dedicate it.

However, perhaps set-window-buffer should operate normally on
dedicated windows.  The idea of dedicated windows is that they
should not get reused by ...-other-window functions.  If you explicitly
change the buffer in a dedicated window, why shouldn't that work?

Re: Window configuration UI

[Stefan Monnier]

>     Maybe some concept of a window being dedicated to the set of
>     buffers that have tabs for it, i.e., you could switch between tabs
>     but other buffers couldn't switch into it, would be some kind of
>     useful subframe entity.

> That sounds like a good idea to me.  It could be implemented in tabbar.el;
> if you click on a tab belonging to a dedicated window, it could un-dedicate
> the window, switch buffers in it, then re-dedicate it.

> However, perhaps set-window-buffer should operate normally on
> dedicated windows.  The idea of dedicated windows is that they
> should not get reused by ...-other-window functions.  If you explicitly
> change the buffer in a dedicated window, why shouldn't that work?

It's also that if the buffer disappears, the window is
automatically deleted.


        Stefan

Re: Window configuration UI

[Richard Stallman]

    It's also that if the buffer disappears, the window is
    automatically deleted.

We could add a feature that the window has a list of preferred buffers,
and if its buffer is deleted, it selects one of those.

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]

    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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

Tab bar (was: Neat features in Eclipse editor)

[Juri Linkov]

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

I just created a small experimental Emacs Lisp library that emulates the
tab bar feature provided by most modern web browsers, file managers and
editors.  Tabs are very popular nowadays mostly due to their ability
to group units equivalent to Emacs frames into one frame and providing
handles to switch them quickly inside one frame without having to switch
top-level frames.

Below is a screenshot how this feature currently looks in Emacs:


[-- Attachment #2: EmacsTabBar --]
[-- Type: image/png, Size: 8562 bytes --]

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


A graphical tab bar has two special buttons: on the left side to create
a new tab, and on the right side to close the current tab.  Between them
there is a row of tabs that represent different window configurations.
The name of the tab is the name of the current buffer (just as the name
of the current frame is the name of the current buffer), but a full list
of names of all buffers in a window configuration is displayed in
a pop-up window over the tab.  Clicking the left mouse button switches
between displayed tabs.  The current tab is disabled since there is no
sense to clink it, and also this provides the visual feedback for the
currently selected tab.

There is also a menu "Tabs" that duplicates the tab bar and can be used
on non-graphical terminals.  It binds `C-z t' to the command that
creates a new tab, and `C-z c' to the command that closes the current tab.
`C-z' with a number selects the corresponding tab.  The original command
`suspend-frame' is rebound to `C-z C-z'.


[-- Attachment #4: EmacsTabBarMenu --]
[-- Type: image/png, Size: 15611 bytes --]

[-- Attachment #5: Type: text/plain, Size: 527 bytes --]


So far I'm satisfied with this feature because it implements the
intuitive and natural behavior expected from the modern tab bar.

As for details of the implementation, it currently depends on the
availability of the external program `convert' used to render the tab
bar elements.  I hope it could be replaced with a separate bar similar
to the tool-bar.  I think we should do this as soon as possible because
this single feature can improve Emacs usability for most users that expect
a tab bar is a standard editor feature.


[-- Attachment #6: tab-bar.el --]
[-- Type: application/emacs-lisp, Size: 8548 bytes --]

[-- Attachment #7: Type: text/plain, Size: 45 bytes --]


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[David Koppelman]

I frequently work with new users of Emacs and perhaps their biggest
frustration is switching between buffers (or even just knowing that's
what they need to do).

If the tab bar by default provided one tab per buffer that would be
great for such users.

OTOH I'd leave it turned off.



Juri Linkov <juri@jurta.org> writes:

> I just created a small experimental Emacs Lisp library that emulates the
> tab bar feature provided by most modern web browsers, file managers and
> editors.  Tabs are very popular nowadays mostly due to their ability
> to group units equivalent to Emacs frames into one frame and providing
> handles to switch them quickly inside one frame without having to switch
> top-level frames.
>
> Below is a screenshot how this feature currently looks in Emacs:

Re: Tab bar

[Juri Linkov]

> I frequently work with new users of Emacs and perhaps their biggest
> frustration is switching between buffers (or even just knowing that's
> what they need to do).
>
> If the tab bar by default provided one tab per buffer that would be
> great for such users.

It is not unusual to have tens or even hundreds buffers in Emacs.
Can you imagine a tab bar with hundreds tabs?  It would occupy
the whole screen.

But really switching between buffers is not a problem, because Emacs
already provides many different ways to do this: the top-level menu
"Buffers", <C-mouse-1> pop-up menu, `C-x b' key, several packages like
buff-menu.el, ebuff-menu.el, ibuffer.el, iswitchb.el, ido.el, etc.

What Emacs still misses is a feature to group several frames,
window configurations, work areas, perspectives (these are
different names for almost the same thing) in the tab bar.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[David Koppelman]

For new users a tab bar with one tab per buffer (and perhaps showing the
n most recent) would be a great help, they can get to work without
immediately having to learn how to switch buffers or for that matter
learning what a buffer is.

I'd suggest taking such users into account when designing the tab bar
though without compromising the features for organization that
experienced users might want.

Juri Linkov <juri@jurta.org> writes:

>> I frequently work with new users of Emacs and perhaps their biggest
>> frustration is switching between buffers (or even just knowing that's
>> what they need to do).
>>
>> If the tab bar by default provided one tab per buffer that would be
>> great for such users.
>
> It is not unusual to have tens or even hundreds buffers in Emacs.
> Can you imagine a tab bar with hundreds tabs?  It would occupy
> the whole screen.
>
> But really switching between buffers is not a problem, because Emacs
> already provides many different ways to do this: the top-level menu
> "Buffers", <C-mouse-1> pop-up menu, `C-x b' key, several packages like
> buff-menu.el, ebuff-menu.el, ibuffer.el, iswitchb.el, ido.el, etc.
>
> What Emacs still misses is a feature to group several frames,
> window configurations, work areas, perspectives (these are
> different names for almost the same thing) in the tab bar.

Re: Tab bar

[Juri Linkov]

> For new users a tab bar with one tab per buffer (and perhaps showing the
> n most recent) would be a great help, they can get to work without
> immediately having to learn how to switch buffers or for that matter
> learning what a buffer is.
>
> I'd suggest taking such users into account when designing the tab bar
> though without compromising the features for organization that
> experienced users might want.

Just as web browsers provide an option to choose between opening pages
in a new tab or in the same tab, and similarly to the Emacs option
`pop-up-frames', we could create a new user option `pop-up-tabs' whose
non-nil value will always display a new buffer in a new tab, and we
could even set it to non-nil by default for the convenience of new users.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Richard Stallman]

    Just as web browsers provide an option to choose between opening pages
    in a new tab or in the same tab, and similarly to the Emacs option
    `pop-up-frames', we could create a new user option `pop-up-tabs' whose
    non-nil value will always display a new buffer in a new tab, and we
    could even set it to non-nil by default for the convenience of new users.

This idea makes no sense to me.  If the default usage of the tab bar
is to switch buffers in the selected window, then every new buffer
will inevitably get a "new tab" regardless of how it is displayed.
So what question are you talking about?

Re: Tab bar

[Juri Linkov]

>     Just as web browsers provide an option to choose between opening pages
>     in a new tab or in the same tab, and similarly to the Emacs option
>     `pop-up-frames', we could create a new user option `pop-up-tabs' whose
>     non-nil value will always display a new buffer in a new tab, and we
>     could even set it to non-nil by default for the convenience of new users.
>
> This idea makes no sense to me.

Is this because you don't use web browsers?  In most modern web browsers
a tab displays a web page, but the same tab can switch between different
web pages (so web pages are equivalent to Emacs buffers).  When the user
wants to visit a new page, then depending on such option, the browser
can either open it in the same tab or create a new tab.  Often this
preference can't be defined in advance, so there are special keys
to choose between these options, e.g. simply clicking <mouse-1> on
a link opens a web page in the same tab, but <C-mouse-1> opens it
in a new tab.

> If the default usage of the tab bar is to switch buffers in the
> selected window, then every new buffer will inevitably get a "new tab"
> regardless of how it is displayed.  So what question are you
> talking about?

Of course, selecting a tab to switch buffers should not create a new tab
(internally this can be implemented using functions like `switch-to-buffer'
that don't create a new window or a new tab), but if the user invokes
a command that calls `display-buffer' then a new option `pop-up-tabs'
makes sense to allow displaying it in a new tab just as `pop-up-frames'
allows displaying it in a new frame.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Richard Stallman]

    Is this because you don't use web browsers?  In most modern web browsers
    a tab displays a web page, but the same tab can switch between different
    web pages (so web pages are equivalent to Emacs buffers).  When the user
    wants to visit a new page, then depending on such option, the browser
    can either open it in the same tab or create a new tab.

Now I see what you mean.  In effect, the new buffer can replace
the old one in the tab bar, or it can add to the tab bar.

If a window has a list of preferred buffers, and normally generates
its list of tabs from that, these two options would be (1) the new
buffer replaces the old buffer in the list of preferred buffers, or
(2) the new buffer is added to the list of preferred buffers.

It makes sense.  My only doubt is whether we could find room
in the keys and buttons for these two options.

Re: Tab bar

[Jason Rumney]

Richard Stallman wrote:
> It makes sense.  My only doubt is whether we could find room
> in the keys and buttons for these two options.
>   

Users who want to use tabs will probably use them instead of frames (in 
my experience, there is little overlap between users who want everything 
in one frame with tabs to select between them, and users who want a 
separate frame for everything), so sharing keybindings with C-x 5 may be 
an acceptable solution if we cannot find free keys. Something like: if 
the current window or its containing frame is already tabbed, or if the 
user or mode has expressed a preference for a tabbed UI, then C-x 5 C-f 
creates a new tab, and C-u C-x 5 C-f creates a new frame. Otherwise the 
behaviour of C-x 5 bindings are reversed.

RE: Tab bar

[Drew Adams]

> > It makes sense.  My only doubt is whether we could find room
> > in the keys and buttons for these two options.
> 
> Users who want to use tabs will probably use them instead of 
> frames (in my experience, there is little overlap between users
> who want everything in one frame with tabs to select between them,
> and users who want a separate frame for everything),

I probably use separate frames as much as anyone, and that doesn't hold for me.
I use a tab bar also. 

I can't characterize my use well, but I guess I use it to cut down on the number
of visible frames or to group related buffers. To me, the overlap is more with
buffer-menu or the Buffers menu than with frames. 

With the wrinkle that tab bars for me are effectively[*] per frame, so they also
provide buffer groups per frame. And tabbar.el, at least, groups the buffers in
a tab bar further into sets based on their type (e.g. mode). So a tab bar, while
doing something similar to what a buffer menu or a set of iconified frames does,
is different, and offers its own benefits.

[*] Since I typically (but not always) have one window per frame, tabbar.el's
tab-bar-per-window is effectively tab-bar-per-frame, for me.

I use all of these: separate frames, iconified (actually thumbnail) frames, and
tab bars. And I sometimes use multiple windows in a frame. You could use some of
these systematically as replacements for others, but I somehow find a way to use
them together that suits me.

The point is that we should avoid assumptions based on generalizations such as
"users who want everything in one frame" and "users who want a separate frame
for everything". I, at least, am in neither of those extreme camps. Better to
remove such "everything" suppositions from the UI design, and provide also for
users who are not at such spectrum extremes. (You can use both C-x b and C-x
C-b, even though someone could argue that one is enough and one key binding
should suffice.)

> so sharing
> keybindings with C-x 5 may be an acceptable solution if we cannot
> find free keys. Something like: if the current window or its
> containing frame is already tabbed, or if the 
> user or mode has expressed a preference for a tabbed UI, then 
> C-x 5 C-f creates a new tab, and C-u C-x 5 C-f creates a new frame. 
> Otherwise the behaviour of C-x 5 bindings are reversed.

I don't have much to say now about the possible key bindings, and I'm not sure
we should start with that. Wait and see how users (or at least developers) use
the features first. You might be right that a general preference, plus `C-u' to
temporarily reverse the preference, would be a good way to handle this, but I
don't think that needs to be decided up front.

One thing that would be useful, I think, would be providing ways (e.g. keys or
mouse clicks) to change the representation. You might first put some buffers in
their own frames, but later want to group them using a tab bar, or vice versa.
Likewise, for a buffer's own tab vs a shared tab. Likewise for movement of
buffers (or whatever) among different tab bars or different tab-bar sets (a la
tabbar.el). For example, be able to easily:

. Break a buffer (or whatever) out of one tab and into its own window, frame or
another tab. This is analogous to `mouse-tear-off-window'.

. The opposite: merge the buffers of two tabs into one tab. Push a buffer into
an existing tab, removing it from other display locations (other frame, other
tab).

And, whatever we do in the way of adding tabs etc., we will need to also deal
with the removal of their elements (e.g. buffers). I'm thinking of `q' as in
`quit-window'. We should keep things simple for this, and not repeat the fiasco
of the thousand-and-one View-mode quitting dances. Killing a buffer, for
instance, should simply remove it from all tabs - it should not replace it with
some other buffer (as happens today for Emacs windows).

Finally, as is often the case with Emacs, although we can plan use cases for
certain features, we cannot really foresee how they might be used together in
novel and useful ways. The more we can keep the implementation of a new feature
such as tab bars in Lisp (vs C), the more users will be able to discover and
invent useful UI patterns that take advantage of and extend the feature. Emacs
has that potent advantage. Adding tab bars should open doors to new, creative UI
patterns and features - vs simply hard-coding tab behavior copied from web
browsers.

Re: Tab bar

[Richard Stallman]

    Users who want to use tabs will probably use them instead of frames (in 
    my experience, there is little overlap between users who want everything 
    in one frame with tabs to select between them, and users who want a 
    separate frame for everything), so sharing keybindings with C-x 5 may be 
    an acceptable solution if we cannot find free keys.

That sounds plausible to me.

							Something like: if 
    the current window or its containing frame is already tabbed, or if the 
    user or mode has expressed a preference for a tabbed UI, then C-x 5 C-f 
    creates a new tab, and C-u C-x 5 C-f creates a new frame. Otherwise the 
    behaviour of C-x 5 bindings are reversed.

This convention might be problematical, especially if some of the commands
already use the prefix arg for something else.

Re: Tab bar

[Juri Linkov]

> 							Something like: if
>     the current window or its containing frame is already tabbed, or if the
>     user or mode has expressed a preference for a tabbed UI, then C-x 5 C-f
>     creates a new tab, and C-u C-x 5 C-f creates a new frame. Otherwise the
>     behaviour of C-x 5 bindings are reversed.
>
> This convention might be problematical, especially if some of the commands
> already use the prefix arg for something else.

Maybe then create a separate key prefix map for tab operation keys:

C-x 7 0         delete-tab
C-x 7 1         delete-other-tabs
C-x 7 2         make-tab-command
C-x 7 b         switch-to-buffer-other-tab
C-x 7 C-f       find-file-other-tab

(`C-x 6' prefix is already occupied by 2C-two-columns, but `C-x 7' is free).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Richard Stallman]

    > If the tab bar by default provided one tab per buffer that would be
    > great for such users.

    It is not unusual to have tens or even hundreds buffers in Emacs.
    Can you imagine a tab bar with hundreds tabs?  It would occupy
    the whole screen.

Perhaps beginning users at that stage won't have so many buffers that
they can't all fit in the tab bar.  And by the time the user starts to
work with so many buffers, she will have learned about C-h b.

Meanwhile, if the tab bar normally shows the most recently used
buffers, MOST OF THE TIME the buffer you want will be visible there

    But really switching between buffers is not a problem, because Emacs
    already provides many different ways to do this: the top-level menu
    "Buffers", <C-mouse-1> pop-up menu, `C-x b' key, several packages like
    buff-menu.el, ebuff-menu.el, ibuffer.el, iswitchb.el, ido.el, etc.

Yes, but the tab bar is the most convenient and self-evident interface
for doing this, and many people are accustomed to it, so Emacs should
support it.

    What Emacs still misses is a feature to group several frames,
    window configurations, work areas, perspectives (these are
    different names for almost the same thing) in the tab bar.

It would be good to have a tab bar of perspectives, too.

Re: Tab bar

[Lennart Borgman (gmail)]

Richard Stallman wrote:
> Perhaps beginning users at that stage won't have so many buffers that
> they can't all fit in the tab bar.

Why not handle this like for example Firefox handles it? All the tabs 
are in one row but all tabs are not visible at once. I think that is how 
the system tab widgets handles it.

> And by the time the user starts to
> work with so many buffers, she will have learned about C-h b.

The tabs as above can be combined with for example the way Ido let you 
narrow the available list of buffers. The set of visible tabs could be 
narrowed the same way.

I imagine that the user first press C-tab and then by pressing a second 
key gets into that "ido-like state". Perhaps a quick press of C-tab 
again should enter that state. (Entering that state autmatically would 
be confusing for a new user since that is not the way tabs normally 
function.)

Another note: You wrote in another message that tabs are most important 
for windows. If there is a special set of buffers for a window then it 
makes sense to me with a special tab row for that window. Otherwise it 
makes more sense to me to have one tab row per frame and that this 
affects the selected window.

> Meanwhile, if the tab bar normally shows the most recently used
> buffers, MOST OF THE TIME the buffer you want will be visible there
..
> It would be good to have a tab bar of perspectives, too.

I am not sure how that could work and look. One important thing about 
tabs IMO is the ability to use C-tab/C-S-tab to switch tab.

Re: Tab bar

[Juri Linkov]

> I imagine that the user first press C-tab and then by pressing a second
> key gets into that "ido-like state". Perhaps a quick press of C-tab again
> should enter that state. (Entering that state autmatically would be
> confusing for a new user since that is not the way tabs
> normally function.)

Do you know about the Firefox addon `iswitchb-tabs'?  It imitates the
Emacs iswitchb-mode in Firefox and lets switching between tabs by typing
part of the tab name.

> Another note: You wrote in another message that tabs are most important
> for windows. If there is a special set of buffers for a window then it
> makes sense to me with a special tab row for that window. Otherwise it
> makes more sense to me to have one tab row per frame and that this affects
> the selected window.

I agree, this makes sense in Eclipse only because it attaches a special
set of buffers for a window.

> I am not sure how that could work and look. One important thing about tabs
> IMO is the ability to use C-tab/C-S-tab to switch tab.

There is also a feature that after pressing <C-tab> it displays a list of
all tabs, <tab> navigates to the next tab in this temporarily displayed
list while you still hold the Ctrl key, and releasing the Ctrl key
switches to the selected tab.  It seems this is not possible to implement
in Emacs, since it requires distinguishing between key press and release
events.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Tab bar

[Drew Adams]

> > I am not sure how that could work and look. One important 
> > thing about tabs IMO is the ability to use C-tab/C-S-tab
> > to switch tab.
> 
> There is also a feature that after pressing <C-tab> it 
> displays a list of all tabs, <tab> navigates to the next
> tab in this temporarily displayed list while you still
> hold the Ctrl key, and releasing the Ctrl key switches
> to the selected tab.  It seems this is not possible 
> to implement in Emacs, since it requires distinguishing
> between key press and release events.

Thank goodness.

In any case, possible or not, count me as one voice against giving yet another
interpretation to TAB (C-TAB, C-S-TAB, ...) in Emacs. Enough already. 

It doesn't matter if other programs have found 187 other "standard" uses for TAB
- TAB has enough behaviors in Emacs. We should save use of modifiers with TAB
for things closely related to TAB's existing behaviors.

Re: Tab bar

[Stefan Monnier]

> It seems this is not possible to implement in Emacs, since it requires
> distinguishing between key press and release events.

It's not like it can't be added, tho,


        Stefan "who implemented just that at some point"

Re: Tab bar

[Juri Linkov]

>> It seems this is not possible to implement in Emacs, since it requires
>> distinguishing between key press and release events.
>
> It's not like it can't be added, tho,
>
>         Stefan "who implemented just that at some point"

Did you implement this using the syntax of mouse button events,
i.e. something like <C-down-tab>?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Stefan Monnier]

>>> It seems this is not possible to implement in Emacs, since it requires
>>> distinguishing between key press and release events.
>> 
>> It's not like it can't be added, tho,
>> 
>> Stefan "who implemented just that at some point"

> Did you implement this using the syntax of mouse button events,
> i.e. something like <C-down-tab>?

I can't remember the details, but yes, pretty much, except I think that
the events generated were along the lines of:

   control C-tab C-up-tab C-up-control

the last one is a bit odd, but it's just how it turned out.


        Stefan

Re: Tab bar

[Juri Linkov]

>>>> It seems this is not possible to implement in Emacs, since it requires
>>>> distinguishing between key press and release events.
>>>
>>> It's not like it can't be added, tho,
>>>
>>> Stefan "who implemented just that at some point"
>
>> Did you implement this using the syntax of mouse button events,
>> i.e. something like <C-down-tab>?
>
> I can't remember the details, but yes, pretty much, except I think that
> the events generated were along the lines of:
>
>    control C-tab C-up-tab C-up-control
>
> the last one is a bit odd, but it's just how it turned out.

It would be nice to have this in Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Paul R]

Juri Linkov <juri@jurta.org> writes:


> It would be nice to have this in Emacs.

I, too, think a lot of usability improvements can be derived from such
a facility. At least, I'd be very happy to be able to play with that.
Stefan, do you think your work is ready to go into the trunk ?

Re: Tab bar

[Stefan Monnier]

>> It would be nice to have this in Emacs.
> I, too, think a lot of usability improvements can be derived from such
> a facility.

I'm not sure which ones, really.  Especially considering that it won't
be available under ttys, and that it has some downsides as well
(e.g. C-h k and C-h l) and introduces several minor incompatibilities
which require changes in Elisp, but since they're minor and non-obvious
you have to wait for someone to bump into it before you know it needs to
be fixed.

> At least, I'd be very happy to be able to play with that.
> Stefan, do you think your work is ready to go into the trunk ?

For some reason I scrapped most of it.


        Stefan

Re: Tab bar

[Andrew W. Nosenko]

On Mon, Apr 7, 2008 at 6:33 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:
>  I am not sure how that could work and look. One important thing about tabs
> IMO is the ability to use C-tab/C-S-tab to switch tab.

No, please!

First: standard (at least standard GTK+) bindings for tab switching
are C-PageDown (next tab) and C-PageUp (prev tab).

Second: I (personally) use C-tab for 'other-window', which is more
convenient for me than 'C-x o' and already tired to combat with
fc-cache (ord-mode ocupies C-tab also, but it lives not so deep and
more simple to re-bind anything).  Thererefore, please, consider do
not touching C-tab at all, please.

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: Tab bar

[Lennart Borgman (gmail)]

Andrew W. Nosenko wrote:
> On Mon, Apr 7, 2008 at 6:33 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
>>  I am not sure how that could work and look. One important thing about tabs
>> IMO is the ability to use C-tab/C-S-tab to switch tab.
> 
> No, please!
> 
> First: standard (at least standard GTK+) bindings for tab switching
> are C-PageDown (next tab) and C-PageUp (prev tab).
> 
> Second: I (personally) use C-tab for 'other-window', which is more
> convenient for me than 'C-x o' and already tired to combat with
> fc-cache (ord-mode ocupies C-tab also, but it lives not so deep and
> more simple to re-bind anything).  Thererefore, please, consider do
> not touching C-tab at all, please.

So GTK choosed another binding than the default one on w32? That is 
trouble of course. On w32 I can't remember any application that does not 
use C-Tab to switch tab. What does Firefox do on GNU/Linux?

Re: Tab bar

[Paul R]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> (...). What does Firefox do on GNU/Linux?

C-PageUp , C-PageDown.

-- Paul

Re: Tab bar

[Dan Nicolaescu]

Paul R <paul.r.ml@gmail.com> writes:

  > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
  > 
  > > (...). What does Firefox do on GNU/Linux?
  > 
  > C-PageUp , C-PageDown.

C-TAB,  C-S-TAB work just fine in Firefox.

Re: Tab bar

[Paul R]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> C-TAB,  C-S-TAB work just fine in Firefox.

Right, I did not know. They do work as well. GTK, on the other hand
only catch C-PgDn and C-PgUp 

Re: Tab bar

[Andrew W. Nosenko]

On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>
> Paul R <paul.r.ml@gmail.com> writes:
>
>   > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>   >
>   > > (...). What does Firefox do on GNU/Linux?
>   >
>   > C-PageUp , C-PageDown.
>
>  C-TAB,  C-S-TAB work just fine in Firefox.
>

But not under Galeon or Epiphany.  They use C-PageUp and C-PageDown (again).


-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: Tab bar

[Lennart Borgman (gmail)]

Andrew W. Nosenko wrote:
> On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>> Paul R <paul.r.ml@gmail.com> writes:
>>
>>   > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>   >
>>   > > (...). What does Firefox do on GNU/Linux?
>>   >
>>   > C-PageUp , C-PageDown.
>>
>>  C-TAB,  C-S-TAB work just fine in Firefox.
>>
> 
> But not under Galeon or Epiphany.  They use C-PageUp and C-PageDown (again).

What is Galeon and Epiphany?

Re: Tab bar

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:
> Andrew W. Nosenko wrote:
>> On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>>> Paul R <paul.r.ml@gmail.com> writes:
>>>
>>>   > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>   >
>>>   > > (...). What does Firefox do on GNU/Linux?
>>>   >
>>>   > C-PageUp , C-PageDown.
>>>
>>>  C-TAB,  C-S-TAB work just fine in Firefox.
>>>
>>
>> But not under Galeon or Epiphany.  They use C-PageUp and C-PageDown
>> (again).
> 
> What is Galeon and Epiphany?
> 

Web browsers* in the Gtk+/GNOME camp, GNOMEfied Mozilla Gecko
(i.e. like firefox) engine. Though apparently Epiphany
are moving to a WebKit engine (i.e. Like safari) (which is funny, given
WebKit started as a fork of KDE's Khtml engine...)

*Epiphany started as a fork of Galeon.

Re: Tab bar

[Lennart Borgman (gmail)]

David De La Harpe Golden wrote:
> Lennart Borgman (gmail) wrote:
>> Andrew W. Nosenko wrote:
>>> On Tue, Apr 8, 2008 at 7:04 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>>>> Paul R <paul.r.ml@gmail.com> writes:
>>>>
>>>>   > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>>   >
>>>>   > > (...). What does Firefox do on GNU/Linux?
>>>>   >
>>>>   > C-PageUp , C-PageDown.
>>>>
>>>>  C-TAB,  C-S-TAB work just fine in Firefox.
>>>>
>>> But not under Galeon or Epiphany.  They use C-PageUp and C-PageDown
>>> (again).
>> What is Galeon and Epiphany?
>>
> 
> Web browsers* in the Gtk+/GNOME camp, GNOMEfied Mozilla Gecko
> (i.e. like firefox) engine. Though apparently Epiphany
> are moving to a WebKit engine (i.e. Like safari) (which is funny, given
> WebKit started as a fork of KDE's Khtml engine...)
> 
> *Epiphany started as a fork of Galeon.


Thanks David.

I can't understand this. Why are they fighting a (rather) well 
established standard on w32 instead of using it to their favor to get 
new users?

Our problem here is of course a bit different. Emacs is a big keyboard 
short cut eater.

Re: Tab bar

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:


> Thanks David.
> 
> I can't understand this. Why are they fighting a (rather) well
> established standard on w32 instead of using it to their favor to get
> new users?
>

Not sure you can take for granted that developers - and users - of other
desktop guis (or even w32) are as familiar with w32 as you might be. :-)
I myself have relatively seldom used w32 (amiga->gnu/linux in 1990s...),
and of w32 users I know, most aren't at a skill level where they'd use
many keyboard shortcuts to navigate...  So, I had no idea C-TAB
did that on windows, and on gnu/linux I'm used to C-PgUp/Dn - turns out
I've been missing out, Tk notebooks use C-TAB, I just didn't discover
that until now.

Anyway, you can't be significantly better than w32 by just imitating
w32. :-)  I'd say it's way more important that the shortcuts are vaguely
consistent intra-platform than inter-platform - mac shortcuts
quite often differ from w32 too...

... of course, they're _not_ always consistent intra-platform on
gnu/linux X11 desktops, but within a single toolkit/desktop-environment
application family you've some hope.

Re: Tab bar

[Juri Linkov]

>> I can't understand this. Why are they fighting a (rather) well
>> established standard on w32 instead of using it to their favor to get
>> new users?
>
> Not sure you can take for granted that developers - and users - of other
> desktop guis (or even w32) are as familiar with w32 as you might be. :-)
> I myself have relatively seldom used w32 (amiga->gnu/linux in 1990s...),
> and of w32 users I know, most aren't at a skill level where they'd use
> many keyboard shortcuts to navigate...  So, I had no idea C-TAB
> did that on windows, and on gnu/linux I'm used to C-PgUp/Dn - turns out
> I've been missing out, Tk notebooks use C-TAB, I just didn't discover
> that until now.

Tabs were first introduced by CUA for notebook pages, and CUA was most
widely used on w32 applications.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> I can't understand this. Why are they fighting a (rather) well 
> established standard on w32 instead of using it to their favor to get 
> new users?

I'm not sure they are. C-tab is the standard keybinding for switching 
between child windows in an application, not for switching between tabs. 
What do Windows applications that have both tiled windows and tabs do 
(eg MSVC)? Do some applications just use C-tab in addition to C-pagedown 
because there are no child windows and C-tab is otherwise available?

Re: Tab bar

[Richard Stallman]

    I can't understand this. Why are they fighting a (rather) well 
    established standard on w32 instead of using it to their favor to get 
    new users?

Please let's NOT discuss that question here.  It is a distraction
and a waste of time.  Those who want to discuss it, please
take it elsewhere.

The discussion of which commands are used by various browsers is also
mostly a distraction.

If you want to make a real contribution to Emacs, discussing side
issues will tend to get in the way.

Re: Tab bar

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     I can't understand this. Why are they fighting a (rather) well 
>     established standard on w32 instead of using it to their favor to get 
>     new users?
> 
> Please let's NOT discuss that question here.  It is a distraction
> and a waste of time.  Those who want to discuss it, please
> take it elsewhere.


Yes, I will try to avoid it. Anyway I searched a bit on the net and 
maybe this summary can be useful:

http://userfriendly.free.fr/christopher/en/index.php?2006/02/21/4-standard-keyboard-shortcuts

Obviously the author have been struggling with the same kind of problems 
that we have here. We need not at all agree with his points, but he have 
some useful links.

Re: Tab bar

[Juri Linkov]

>>>>   > > (...). What does Firefox do on GNU/Linux?
>>>>   >
>>>>   > C-PageUp , C-PageDown.
>>>>
>>>>  C-TAB,  C-S-TAB work just fine in Firefox.
>>>
>>> But not under Galeon or Epiphany.  They use C-PageUp and C-PageDown
>>> (again).
>> 
>> What is Galeon and Epiphany?
>
> Web browsers* in the Gtk+/GNOME camp, GNOMEfied Mozilla Gecko
> (i.e. like firefox) engine. Though apparently Epiphany
> are moving to a WebKit engine (i.e. Like safari) (which is funny, given
> WebKit started as a fork of KDE's Khtml engine...)

And Konqueror uses yet another variant of keys to switch tabs:
C-[ and C-].

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> And Konqueror uses yet another variant of keys to switch tabs:
> C-[ and C-].

It's fully configurable.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Tab bar

[Juri Linkov]

>> And Konqueror uses yet another variant of keys to switch tabs:
>> C-[ and C-].
>
> It's fully configurable.

I see, its default keys C-[ C-] C-, C-. can be rebound to C-TAB and C-S-TAB
because these keys are free and not bound to something else.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Ehud Karni]

On Tue, 08 Apr 2008 17:55:04 +0200, Paul R wrote:
>
> "Lennart Borgman (gmail)" writes:
>
> > (...). What does Firefox do on GNU/Linux?
>
> C-PageUp , C-PageDown.
>
> -- Paul

The C-PgUp, C-PgDn works in Firefox on M$Windows too.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

RE: Tab bar

[Drew Adams]

> It would be good to have a tab bar of perspectives, too.

Especially if you are talking about having multiple tab bars of different types,
using something narrow, such as a header line, is better than using huge tabs,
such as were shown.

I don't care one way or the other about tabbar.el itself (I like it, but I'm not
suggesting that is the only way to go), but I think its design of using a header
line is a good one.

With such an approach, we can easily have more than one header line, with, for
example, different backgrounds or whatever, to distinguish the different tab
types (buffers, perspectives, ...).

On the other hand, tabbar.el has a different way of dealing with different types
of tab bar: They are all present in the same header line, but only one is shown
at a time. The first thing in the header line is a button that cycles among the
tab-bar types ("tab sets"). That is very handy, and reduces space.

But it can also be helpful sometimes to see more than one tab set at the same
time (e.g. two header lines, of different tab type), so having that as an option
would be good.

Re: Tab bar

[Stefan Monnier]

>> It would be good to have a tab bar of perspectives, too.

> Especially if you are talking about having multiple tab bars of
> different types, using something narrow, such as a header line, is
> better than using huge tabs, such as were shown.

All the current Elisp-based tabbars I've seen might be good
proofs-of-concept but are not appropriate implementations: they either
hijack the toolbar, or the header-line, neither of which is acceptable.
Also they both have the corresponding limitation: tabbar.el cannot be
used for perspectives because header lines are "per-window", and
tab-bar.el cannot be used for buffers because toolbars are "per-frame".

I think a good implementation for a tabbar would be to use a whole
window (and buffer) for the tabbar (set mode-line-format to nil and
window-min-height to 1 or 2).  This would allow placing it anywhere in
the window tree, and hence all both "one per frame" and "one per
window".  Of course, to make it work well, we probably need some changes
at the C level in order to treat those windows specially, although we
can probably kludge around it in an Elisp-only proof-of-concept.


        Stefan

Re: Tab bar

[Juri Linkov]

> All the current Elisp-based tabbars I've seen might be good
> proofs-of-concept but are not appropriate implementations: they either
> hijack the toolbar, or the header-line, neither of which is acceptable.

Yes, I agree that all there PoC implementations are abuses of the header
line and the toolbar, and neither of them treats correctly modes that
use the header line and the toolbar in the intended way (like e.g.
info.el that overwrites them with its own data).

> Also they both have the corresponding limitation: tabbar.el cannot be
> used for perspectives because header lines are "per-window", and
> tab-bar.el cannot be used for buffers because toolbars are "per-frame".

There is also a third variant implemented by elscreen.el: it uses
the header line to switch between window configurations, but often
it exhibits a weird behavior when it tries to keep the header line
with tabs only in the top window.

> I think a good implementation for a tabbar would be to use a whole
> window (and buffer) for the tabbar (set mode-line-format to nil and
> window-min-height to 1 or 2).

Also we need to disable the fringes and the scroll bar, but I don't see
how to do this in a single window.

> This would allow placing it anywhere in the window tree, and hence all
> both "one per frame" and "one per window".  Of course, to make it work
> well, we probably need some changes at the C level in order to treat
> those windows specially, although we can probably kludge around it in
> an Elisp-only proof-of-concept.

Unless it will be possible to implement native tabbars, using a special
window seems to be a good compromise.  It would even allow creating
arbitrary tabbar configurations, e.g. a vertical top-down tabbar on the
right side of the frame like I use in Firefox that is allowed by the
flexibility of the Gecko layout engine.  I wish Emacs having enough
primitives to implement arbitrary layouts for the tabbar and also
a compilation error navigation bar, parallel to the scroll bar, that
Richard wants to add to Emacs.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Richard Stallman]

    I think a good implementation for a tabbar would be to use a whole
    window (and buffer) for the tabbar (set mode-line-format to nil and
    window-min-height to 1 or 2).  This would allow placing it anywhere in
    the window tree, and hence all both "one per frame" and "one per
    window".  Of course, to make it work well, we probably need some changes
    at the C level in order to treat those windows specially,

Once we make changes at the C level, there should be no need for the
overhead of a separate window for the tabs.  It would be easiest and
most convenient to generate the tabs directly from an alist.

If each normal window has a tool bar, it would be a pain in the neck
to have to make a second window (for the tool bar) for each normal window.

Re: Tab bar

[Stefan Monnier]

>     I think a good implementation for a tabbar would be to use a whole
>     window (and buffer) for the tabbar (set mode-line-format to nil and
>     window-min-height to 1 or 2).  This would allow placing it anywhere in
>     the window tree, and hence all both "one per frame" and "one per
>     window".  Of course, to make it work well, we probably need some changes
>     at the C level in order to treat those windows specially,

> Once we make changes at the C level, there should be no need for the
> overhead of a separate window for the tabs.  It would be easiest and
> most convenient to generate the tabs directly from an alist.

> If each normal window has a tool bar, it would be a pain in the neck
> to have to make a second window (for the tool bar) for each normal window.

I want to be able to place a tabbar with each window and/or with
each frame.  Or really, anywhere along the window-tree.
I'm not wedded to the idea of having a separate window for each tabbar,
it's just an idea for how to create a more flexible tabbar entirely
in Elisp.  Once/if we implement this at the C level we may want
a completely different approach indeed.


        Stefan

Re: Tab bar

[Richard Stallman]

    I'm not wedded to the idea of having a separate window for each tabbar,
    it's just an idea for how to create a more flexible tabbar entirely
    in Elisp.

This must be implemented in C, so that we can adjust its appearance to
make it look right.  Given that, I think other half-baked
implementations are not very useful effort.  What we need is for
someone to implement tabs in C, using toolkit widgets for
toolkits that provide them.

Re: Tab bar

[Juri Linkov]

> Meanwhile, if the tab bar normally shows the most recently used
> buffers, MOST OF THE TIME the buffer you want will be visible there

I think this is not the most useful order, and web browsers arrange tabs
by the order of their creation (although they have an option to switch
tabs by the order of recency, so in the tabbar where tabs are arranged
by the order of creation, C-tab navigates to the last visited tab
and so on, by the order of recency of their visiting time).

>     What Emacs still misses is a feature to group several frames,
>     window configurations, work areas, perspectives (these are
>     different names for almost the same thing) in the tab bar.
>
> It would be good to have a tab bar of perspectives, too.

Yes, as Eclipse has both types of tab bars: a tab bar of perspectives
equivalent to Emacs window configurations or Emacs frames,
and a tab bar of parts equivalent to Emacs buffers.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Tab bar (was: Neat features in Eclipse editor)

[Drew Adams]

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

> I just created a small experimental Emacs Lisp library that 
> emulates the tab bar feature provided by most modern web
> browsers, file managers and editors.  Tabs are very popular
> nowadays mostly due to their ability to group units
> equivalent to Emacs frames into one frame and providing
> handles to switch them quickly inside one frame without 
> having to switch top-level frames.

How does it compare with tabbar.el? I use that, and generally like it.

> Below is a screenshot how this feature currently looks in Emacs

Unsolicited feedback: Too much wasted horizontal space. 

See tabbar.el, for example: there is no horizontal space between the tabs (other
than their borders).

I customized the default tabbar.el faces, however - the default faces are
unreadable on Windows, IMO. Attached is a screenshot showing the faces I use, to
give you an idea of what I mean about the horizontal space.

HTH.


[-- Attachment #2: throw-tabbar.png --]
[-- Type: image/png, Size: 11288 bytes --]

Re: Tab bar (was: Neat features in Eclipse editor)

[Richard Stallman]

    > Below is a screenshot how this feature currently looks in Emacs

    Unsolicited feedback: Too much wasted horizontal space. 

For the traditional Emacs mode of use, you're probably right.
But if we connect this with a (small) list of preferred buffers
for each window, there will not need to be many tabs in one window.
Then this "wasted" space could be a good thing.

RE: Tab bar (was: Neat features in Eclipse editor)

[Drew Adams]

>     > Below is a screenshot how this feature currently looks in Emacs
> 
>     Unsolicited feedback: Too much wasted horizontal space. 
> 
> For the traditional Emacs mode of use, you're probably right.
> But if we connect this with a (small) list of preferred buffers
> for each window, there will not need to be many tabs in one window.
> Then this "wasted" space could be a good thing.

I don't see why. For what reason would the wasted space (vertical, as well as
horizontal) be a good thing? 

I don't think it matters much how many tabs there are - even if there is only
one tab, the same vertical space is lost. What is gained by having huge tabs
widely separated from each other?

Re: Tab bar (was: Neat features in Eclipse editor)

[Mathias Dahl]

>  What is gained by having huge tabs
>  widely separated from each other?

Readability, maybe. More easy on the eyes when stuff is not crammed
together. However, I also reacted to the screenshot and thought the
tabs was a little bit too far from each other. But hey, it is a
prototype.

Re: Tab bar

[Juri Linkov]

>> I just created a small experimental Emacs Lisp library that
>> emulates the tab bar feature provided by most modern web
>> browsers, file managers and editors.  Tabs are very popular
>> nowadays mostly due to their ability to group units
>> equivalent to Emacs frames into one frame and providing
>> handles to switch them quickly inside one frame without
>> having to switch top-level frames.
>
> How does it compare with tabbar.el? I use that, and generally like it.

In tabbar.el the tab bar belongs to one window, but in tab-bar.el
that I presented it belongs to a frame.

>> Below is a screenshot how this feature currently looks in Emacs
>
> Unsolicited feedback: Too much wasted horizontal space.

This is a restriction from the implementation of the tool-bar
reused by tab-bar.el.  I don't know why the tool-bar inserts
extra space between icons.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar (was: Neat features in Eclipse editor)

[Richard Stallman]

    A graphical tab bar has two special buttons: on the left side to create
    a new tab, and on the right side to close the current tab.  Between them
    there is a row of tabs that represent different window configurations.

Does the tab bar belong to one window
or does it belong to a frame?
You say that a tab represents a "window configuration".
That seems to suggest that the tabs belong to a frame.

What we need most, in regard to tabs, is a row of tabs
that belongs to a window, with each tab specifying something
to display in that window.

Re: Tab bar

[David De La Harpe Golden]

Juri Linkov wrote:


>  I think we should do this as soon as possible because
> this single feature can improve Emacs usability for most users that expect
> a tab bar is a standard editor feature.
> 
> 


I think someone's already mentioned this several threads ago: there
needs to be some clear separation of concerns regarding "tab bars"

tabs in tab bars themselves are just gui widgets nothing more -  Indeed
much like icons in tool bars, just drawn a bit differently.  I don't
see why emacs shouldn't support a tab bar GUI widget or multiple widgets
(say toplevel tab bar for each toplevel frame, and tab bars for each
window (emacs window), perhaps with configurable positions)

But people keep talking about various other editors' features that are
"hung off" tabs kind of as if they _are_ what tabs are - such features,
while perhaps exposed to the user through tab widgets, should be clearly
separated from the tab GUI widget itself.

e.g. in some editors and browsers, clicking on tab-shaped GUI widgets
might well switch between top-level-frame-like things/ intra-app
subwindow configurations, perspectives... or they may just tab through
several pages of toolbars with tiny little icons (gah! I hate that), or
just switch buffers (therefore being considered attached to the
subwindow not the toplevel), or whatever.   They tend to be for
switching between stuff as a matter of convention, but what they switch
between varies.

(Personally I've always considered the top-level-frame-switcher sort of
tab bar rightly a tabbing WM's job (e.g. pwm), really, but that's not
the way people went for the most part, presumably since you don't see
tabbing WMs on windows/mac -  but if you're using a tabbing WM, then
multiple emacs toplevel frames can _already_ be tabbed between in the
"one" window system window, and the advent of browser "tabs" was pretty
uninteresting too...)

Re: Tab bar

[Juri Linkov]

> I think someone's already mentioned this several threads ago: there
> needs to be some clear separation of concerns regarding "tab bars"
>
> tabs in tab bars themselves are just gui widgets nothing more -  Indeed
> much like icons in tool bars, just drawn a bit differently.  I don't
> see why emacs shouldn't support a tab bar GUI widget or multiple widgets

We already have a suitable infrastructure of graphical primitives to
implement a tab bar on top of it.  It is required to have graphical
areas attached to window edges that can contain a row of bitmaps
bound to some commands.  This functionality is already supported by the
header line and window fringes.  It seems what we need is to improve
them to attach arbitrary number of header lines and fringes to a window,
and to render text (tab names) using specified fonts on these
graphical elements.

> (say toplevel tab bar for each toplevel frame, and tab bars for each
> window (emacs window), perhaps with configurable positions)

Since we need both types, maybe we should implement also the frame
header line and frame fringes?

> (Personally I've always considered the top-level-frame-switcher sort of
> tab bar rightly a tabbing WM's job (e.g. pwm), really, but that's not
> the way people went for the most part, presumably since you don't see
> tabbing WMs on windows/mac -  but if you're using a tabbing WM, then
> multiple emacs toplevel frames can _already_ be tabbed between in the
> "one" window system window, and the advent of browser "tabs" was pretty
> uninteresting too...)

I think tab bars are popular because they contain only elements of the
current program without stuff from other programs in their lists.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[David De La Harpe Golden]

Juri Linkov wrote:

> We already have a suitable infrastructure of graphical primitives to
> implement a tab bar on top of it.  It is required to have graphical
> areas attached to window edges that can contain a row of bitmaps
> bound to some commands.  This functionality is already supported by the
> header line and window fringes.  It seems what we need is to improve
> them to attach arbitrary number of header lines and fringes to a window,
> and to render text (tab names) using specified fonts on these
> graphical elements.

however, toolkits like gtk+ do have tab widgets, like they have tool
bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll
bars" and "toolkit tool bars" and "toolkit menu bars" in emacs?

> 
> I think tab bars are popular because they contain only elements of the
> current program without stuff from other programs in their lists.
> 

Trying to understand that, at least re tabbed wm vs.
intraprogram-implemented tabbing  - are you suggesting the
window-attached tab bars in a tabbed wm *would* have stuff from other
programs in their lists? Now, granted they _could_, but typically,other
applications' windows would have to be manually dragged into the tabbed
window, whereas new windows from existing applications could e.g.
default to the tabbed window their last window went into.

(just screenshots of windows with multiple tabs under a couple of
tabbed window managers, no I'm not doing it ascii art, sorry).
http://modeemi.fi/~tuomov/ion/pwm/screenshots/pwm-3.jpg
http://fluxbox.sourceforge.net/features/tabs.php

Re: Tab bar

[Juri Linkov]

>> We already have a suitable infrastructure of graphical primitives to
>> implement a tab bar on top of it.  It is required to have graphical
>> areas attached to window edges that can contain a row of bitmaps
>> bound to some commands.  This functionality is already supported by the
>> header line and window fringes.  It seems what we need is to improve
>> them to attach arbitrary number of header lines and fringes to a window,
>> and to render text (tab names) using specified fonts on these
>> graphical elements.
>
> however, toolkits like gtk+ do have tab widgets, like they have tool
> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll
> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs?

Then should we have two versions of tab widgets: Gtk and non-Gtk?

>> I think tab bars are popular because they contain only elements of the
>> current program without stuff from other programs in their lists.
>
> Trying to understand that, at least re tabbed wm vs.
> intraprogram-implemented tabbing  - are you suggesting the
> window-attached tab bars in a tabbed wm *would* have stuff from other
> programs in their lists? Now, granted they _could_, but typically,other
> applications' windows would have to be manually dragged into the tabbed
> window, whereas new windows from existing applications could e.g.
> default to the tabbed window their last window went into.

The main disadvantage of tabbed WMs is that they can't provide
program-specific functionality like e.g. a command to undo tab closing,
etc.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> We already have a suitable infrastructure of graphical primitives to
>>> implement a tab bar on top of it.  It is required to have graphical
>>> areas attached to window edges that can contain a row of bitmaps
>>> bound to some commands.  This functionality is already supported by the
>>> header line and window fringes.  It seems what we need is to improve
>>> them to attach arbitrary number of header lines and fringes to a window,
>>> and to render text (tab names) using specified fonts on these
>>> graphical elements.
>>
>> however, toolkits like gtk+ do have tab widgets, like they have tool
>> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll
>> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs?
>
> Then should we have two versions of tab widgets: Gtk and non-Gtk?

Why wouldn't we? (Actually, I don't think we'd stop at two).  We use the
native widgets for other stuff, too.  XEmacs doesn't and looks quaint
everywhere in comparison.

-- 
David Kastrup

Re: Tab bar

[Juri Linkov]

>>> however, toolkits like gtk+ do have tab widgets, like they have tool
>>> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll
>>> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs?
>>
>> Then should we have two versions of tab widgets: Gtk and non-Gtk?
>
> Why wouldn't we? (Actually, I don't think we'd stop at two).  We use the
> native widgets for other stuff, too.  XEmacs doesn't and looks quaint
> everywhere in comparison.

Do other toolkits used in Emacs provide tab bar widgets?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Jan Djärv]

Juri Linkov skrev:
>>>> however, toolkits like gtk+ do have tab widgets, like they have tool
>>>> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll
>>>> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs?
>>> Then should we have two versions of tab widgets: Gtk and non-Gtk?
>> Why wouldn't we? (Actually, I don't think we'd stop at two).  We use the
>> native widgets for other stuff, too.  XEmacs doesn't and looks quaint
>> everywhere in comparison.
> 
> Do other toolkits used in Emacs provide tab bar widgets?

Not Lucid (a.k.a native).  And not X11 (i.e. no toolkit, just libX11).

	Jan D.

Re: Tab bar

[Jason Rumney]

Jan Djärv wrote:
>
> Juri Linkov skrev:
>>
>> Do other toolkits used in Emacs provide tab bar widgets?
>
> Not Lucid (a.k.a native).  And not X11 (i.e. no toolkit, just libX11).

Nor W32. Which leaves Mac (likely) and Motif (unlikely).

Re: Tab bar

[Jason Rumney]

Jason Rumney wrote:
> Jan Djärv wrote:
>>
>> Juri Linkov skrev:
>>>
>>> Do other toolkits used in Emacs provide tab bar widgets?
>>
>> Not Lucid (a.k.a native).  And not X11 (i.e. no toolkit, just libX11).
>
> Nor W32

I take that back, I was looking in the wrong header, they are available 
along with native toolbars in the common control library (which we 
already use for the scroll bar).

Re: Tab bar

[Jan Djärv]

Jason Rumney skrev:
> Jan Djärv wrote:
>>
>> Juri Linkov skrev:
>>>
>>> Do other toolkits used in Emacs provide tab bar widgets?
>>
>> Not Lucid (a.k.a native).  And not X11 (i.e. no toolkit, just libX11).
> 
> Nor W32. Which leaves Mac (likely) and Motif (unlikely).

Actually Motif 2.0 introduced the Notebook widget.  The name is the same in 
Gtk+.  Both are tabbar-like widgets.  Motif can also have tabs on the side 
(vertically) and a spiral look on the other side to make it look more like a book.

	Jan D.

Re: Tab bar

[Richard Stallman]

    > Do other toolkits used in Emacs provide tab bar widgets?

    Not Lucid (a.k.a native).  And not X11 (i.e. no toolkit, just libX11).

These configurations could use the code used for ttys
if nobody wants to implement anything else.

Re: Tab bar

[Juri Linkov]

>     > Do other toolkits used in Emacs provide tab bar widgets?
>
>     Not Lucid (a.k.a native).  And not X11 (i.e. no toolkit, just libX11).
>
> These configurations could use the code used for ttys
> if nobody wants to implement anything else.

Do you mean we need tab bars for ttys as well.  I can't imagine how this
could look.  Maybe, like a tty menu bar is currently implemented?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Richard Stallman]

    > These configurations could use the code used for ttys
    > if nobody wants to implement anything else.

    Do you mean we need tab bars for ttys as well.  I can't imagine how this
    could look.  Maybe, like a tty menu bar is currently implemented?

I think someone asked for tab bars on ttys too, but I am not sure we
_need_ them.  I don't see that there would be any harm in not
supporting tab bars on terminals.

It would be somewhat of a shame not to support tab bars with the Lucid
toolkit, though.  And the mouse does work on some terminals, so the
user could use the tab bar with it.

Re: Tab bar

[Paul R]

Juri Linkov <juri@jurta.org> writes:


> Then should we have two versions of tab widgets: Gtk and non-Gtk?

In any case, are we planning to have tabs only for X toolkit ? What
about emacs -nw ? I agree Tabs will shine as an intuitive way to
change what emacs displays (be it buffers or views) by clicking on
them. But should this feature simply disappear when emacs is in
text-mode ?

-- paul

Re: Tab bar

[Juri Linkov]

>> Then should we have two versions of tab widgets: Gtk and non-Gtk?
>
> In any case, are we planning to have tabs only for X toolkit ? What
> about emacs -nw ? I agree Tabs will shine as an intuitive way to
> change what emacs displays (be it buffers or views) by clicking on
> them. But should this feature simply disappear when emacs is in
> text-mode ?

Do users of emacs -nw complain that there are no toolbars, no scrollbars,
and no other toolkit widgets when Emacs is in text-only mode?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Tab bar

[Paul R]

Juri Linkov <juri@jurta.org> writes:

> Do users of emacs -nw complain that there are no toolbars, no scrollbars,
> and no other toolkit widgets when Emacs is in text-only mode?

Let's see what form will Tabs take. If it takes the form of a list of
clickable butons for "switch-to-buffer", then we can call it
"interface candy" which is, indeed, not required in emacs -nw.