Re: Gtk tabs in emacs, new branch

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Jan D. wrote:
> Hello.
>
>
> I've published a new branch...

I have build that, but when I start Emacs, I don't 'see' any tabs. How 
can we enable those? I have a desktop file which opens several file when 
I start Emacs, so I would expect to see them in tabs! :-)

Perhaps we need something like 'M-x tabs-mode' (by default possibly! :-))

When I use 'M-x tab-new', I see a single buffer in two tabs. After 
closing the tabs, switching buffer as usually, with mouse-1/-3 on mode 
line, Emas becomes very slow, perhaps it hangs...

Anyway, thanks a lot for this new 'era' in Emacs!

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev 2010-04-01 18.52:
> Jan D. wrote:
>> Hello.
>>
>>
>> I've published a new branch...
>
> I have build that, but when I start Emacs, I don't 'see' any tabs. How
> can we enable those? I have a desktop file which opens several file when
> I start Emacs, so I would expect to see them in tabs! :-)

I don't think that is a good idea in general.  I have desktopfiles with over 
50 files.  50 tabs isn't manageable.

>
> Perhaps we need something like 'M-x tabs-mode' (by default possibly! :-))
>
> When I use 'M-x tab-new', I see a single buffer in two tabs.

Yes, it tries to do the same as C-x 5 2, i.e. show the buffer you came from.

> After
> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode
> line, Emas becomes very slow, perhaps it hangs...

Hmm, I don't use the mode line to switch buffers, so I haven't seen that. 
I'll check it out.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>> can we enable those? I have a desktop file which opens several file when
>> I start Emacs, so I would expect to see them in tabs! :-)
>
> I don't think that is a good idea in general.

If someone wants to do this, we could provide a variable `pop-up-tabs'
that is like `pop-up-frames'.

> I have desktopfiles with over 50 files.  50 tabs isn't manageable.

I think desktop.el should save and restore the tabs configurations,
i.e. in what tabs what buffers were displayed.

Is it currently possible to get a list of Gtk tabs and their
window configurations from Lisp?

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

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Juri Linkov skrev 2010-04-01 20.03:
>>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>>> can we enable those? I have a desktop file which opens several file when
>>> I start Emacs, so I would expect to see them in tabs! :-)
>>
>> I don't think that is a good idea in general.
>
> If someone wants to do this, we could provide a variable `pop-up-tabs'
> that is like `pop-up-frames'.

The idea has merit.
I still think we should have a limit on how many tabs that gets created 
automatically, for example by desktop.el.

>
>> I have desktopfiles with over 50 files.  50 tabs isn't manageable.
>
> I think desktop.el should save and restore the tabs configurations,
> i.e. in what tabs what buffers were displayed.
>
> Is it currently possible to get a list of Gtk tabs and their
> window configurations from Lisp?


Not presently.  I just added the bare minimum.  It is very easy to do though. 
  But in that case, tabs should be a proper lisp type, like windows.
Currently they aren't.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Jan Djärv skrev:
> 
> 
> Juri Linkov skrev 2010-04-01 20.03:
>>
>> Is it currently possible to get a list of Gtk tabs and their
>> window configurations from Lisp?
> 
> 
> Not presently.  I just added the bare minimum.  It is very easy to do 
> though. 

But for the purpose of saving stuff by desktop.el, window configrations aren't 
good.  You really can't do anything with them except restore them on the same 
running Emacs you saved them in.  The output from window-tree together with 
buffer information would be better.

And then there is frame-configuration which I haven't done anything to.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 01/04/2010 19.45, Jan Djärv ha scritto:
>
>
> Angelo Graziosi skrev 2010-04-01 18.52:
>> Jan D. wrote:
>>> Hello.
>>>
>>>
>>> I've published a new branch...
>>
>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>> can we enable those? I have a desktop file which opens several file when
>> I start Emacs, so I would expect to see them in tabs! :-)
>
> I don't think that is a good idea in general. I have desktopfiles with
> over 50 files. 50 tabs isn't manageable.

Obviously (20 files in my case). Beside a minimum number, the tabs 
should be 'collapsed' with an 'arrow' pointing to the 'collapsing'.

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

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

Angelo Graziosi skrev:
> Il 01/04/2010 19.45, Jan Djärv ha scritto:
>>
>>
>> Angelo Graziosi skrev 2010-04-01 18.52:
>>> Jan D. wrote:
>>>> Hello.
>>>>
>>>>
>>>> I've published a new branch...
>>>
>>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>>> can we enable those? I have a desktop file which opens several file when
>>> I start Emacs, so I would expect to see them in tabs! :-)
>>
>> I don't think that is a good idea in general. I have desktopfiles with
>> over 50 files. 50 tabs isn't manageable.
> 
> Obviously (20 files in my case). Beside a minimum number, the tabs 
> should be 'collapsed' with an 'arrow' pointing to the 'collapsing'.
> 

I don't know exactly what you mean by collapsed, but Gtk+ adds arrows on the 
sides when the tabs are too many to fit.  Not exactly pretty, but it works.

	Jan D.


[-- Attachment #2: tabs2.png --]
[-- Type: image/png, Size: 26309 bytes --]

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 02/04/2010 8.49, Jan Djärv ha scritto:

> I don't know exactly what you mean by collapsed, but Gtk+ adds arrows on
> the sides when the tabs are too many to fit.

Exactly that! :-)

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Stephen J. Turnbull]

Jan Djärv writes:

 > > I have build that, but when I start Emacs, I don't 'see' any tabs. How
 > > can we enable those? I have a desktop file which opens several file when
 > > I start Emacs, so I would expect to see them in tabs! :-)
 > 
 > I don't think that is a good idea in general.  I have desktopfiles with over 
 > 50 files.  50 tabs isn't manageable.

XEmacs's tabs by default group files by mode (cc-mode, make-mode,
LaTeX-mode), and the tabs list the top N according to "buffer-list".
I *do not* think this is optimal, and wrote a proof-of-concept
"group-by-project" mode.  Nobody uses that, everybody uses the default
mode, and nobody complains (although people typically respond
enthusiastically when somebody suggests alternative uses of the tabs,
that itch has for some reason never been scratched despite
availability of proof-of-concept).

In XEmacs, buffer-list gives a frame-specific grouping, which works
well.

Bottom line: put a limit on the number of tabs, and use the first N in
buffer-list (perhaps filtered by mode).  This is good enough to start
with (Jan himself might opt to turn them off, but I bet most users
will find this mode a usability improvement).

You do need a way to turn off tabs, some people don't like them, some
app-specific frames shouldn't have them.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Stephen J. Turnbull skrev:

> Bottom line: put a limit on the number of tabs, and use the first N in
> buffer-list (perhaps filtered by mode).  This is good enough to start
> with (Jan himself might opt to turn them off, but I bet most users
> will find this mode a usability improvement).
> 

I would use it, I use desktop files a lot, and having files in tabs when Emacs 
starts would be a bonus.  But for restoring desktop files, I'd rather have 
tabs on the N last visited files, i.e. from file-name-history.  That could be 
an option in desktop.el I guess.

> You do need a way to turn off tabs, some people don't like them, some
> app-specific frames shouldn't have them.

I didn't think of that, thanks.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:

> 
> When I use 'M-x tab-new', I see a single buffer in two tabs. After 
> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode 
> line, Emas becomes very slow, perhaps it hangs...
> 

It may be timing related, I can't reproduce it.  Does it always happen?  Do 
you have a recepie for it?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

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

Il 02/04/2010 8.53, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>
>>
>> When I use 'M-x tab-new', I see a single buffer in two tabs. After
>> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode
>> line, Emas becomes very slow, perhaps it hangs...
>>
>
> It may be timing related, I can't reproduce it. Does it always happen?
> Do you have a recepie for it?

At the moment, I can't reproduce too! So I haven't a clean recipe.

By the way, I want to flag that on Cygwin, the active tab shows a sort 
of 'focus' rectangle which should not be expected (see 'sp_test.f90' in 
the attached figure).

Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by default 
if you prefer, but that we can customize in the .emacs file.

Another thing. Clicking on the tab's 'X', should not close the file? It 
deletes only the tab, the buffer being still 'visited' by Emacs. (I do 
not remember a similar behavior with other applications using tabs.)

Ciao,
Angelo.

[-- Attachment #2: cygtest.png --]
[-- Type: image/png, Size: 29793 bytes --]

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Il 02/04/2010 8.53, Jan Djärv ha scritto:
>> Angelo Graziosi skrev:
>>
>>>
>>> When I use 'M-x tab-new', I see a single buffer in two tabs. After
>>> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode
>>> line, Emas becomes very slow, perhaps it hangs...
>>>
>>
>> It may be timing related, I can't reproduce it. Does it always happen?
>> Do you have a recepie for it?
> 
> At the moment, I can't reproduce too! So I haven't a clean recipe.
> 
> By the way, I want to flag that on Cygwin, the active tab shows a sort 
> of 'focus' rectangle which should not be expected (see 'sp_test.f90' in 
> the attached figure).

It is a Gtk+ thing (i.e. focus border).  I have pushed a new version that 
doesn't have it.  For other additions, see README.TABS th the root of the tree.

> 
> Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by default 
> if you prefer, but that we can customize in the .emacs file.

I'm not sure if it is a mode.  It is kind of outside that.
You can now disable tab creation entirely by specifying disable-tabs in frame 
parameters at frame creation.

> 
> Another thing. Clicking on the tab's 'X', should not close the file? It 
> deletes only the tab, the buffer being still 'visited' by Emacs. (I do 
> not remember a similar behavior with other applications using tabs.)

I don't think so.  After all, closing a frame doesn't close files.  The file 
may still be visible in other frames or tabs.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 02/04/2010 17.10, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by
>> default if you prefer, but that we can customize in the .emacs file.
>
> I'm not sure if it is a mode. It is kind of outside that.
> You can now disable tab creation entirely by specifying disable-tabs in
> frame parameters at frame creation.

What I want to say is that we need a sort of option (customizable in 
.emacs or reaching it in the Options menu) that show/hide tabs, 
likewise, if you prefer, the option which show/hide the scroll bar.

Perhaps I am missing something: If I have many buffers, HOW can I see 
them in tabs? I do not want each time: M-x tab-new, mouse-3,...

We need also that restarting Emacs, desktop will be restored with all 
the tabs of previous session.

Thanks,
Angelo.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Still some observation...

Suppose one starts Emacs, a single frame with 38 lines (Emacs.geometry: 
80x40-0+0 in .Xdefaults, for example). Now suppose one creates some 
tabs: M-x tab-new. The lines now are 37 because one line is that of tabs 
and the frame has the same size (height). If, now, one deletes the tabs, 
the lines remain at 37 but the frame has the height shorter by one line. 
Repeating this procedure the lines become 36, 35,... and the frame 
shorter, shorter...

Is this to be the right thing? My opinion is that the frame should have 
always the same height and the line should be 38 (N) or 37 (N-1) if the 
tabs are visible.

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Still some observation...
> 
> Suppose one starts Emacs, a single frame with 38 lines (Emacs.geometry: 
> 80x40-0+0 in .Xdefaults, for example). Now suppose one creates some 
> tabs: M-x tab-new. The lines now are 37 because one line is that of tabs 
> and the frame has the same size (height). If, now, one deletes the tabs, 
> the lines remain at 37 but the frame has the height shorter by one line. 
> Repeating this procedure the lines become 36, 35,... and the frame 
> shorter, shorter...
> 
> Is this to be the right thing? My opinion is that the frame should have 
> always the same height and the line should be 38 (N) or 37 (N-1) if the 
> tabs are visible.

Emacs tries to keep the frame size so an integral number of lines just fits. 
But tabs aren't (in general) exactly one or two lines high, so some resize 
will occur.  I made some fix.

I also made tab-mode a minor mode so it can be turned off by customize.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 10/04/2010 14.44, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> Still some observation...
>>
>> Suppose one starts Emacs, a single frame with 38 lines
>> (Emacs.geometry: 80x40-0+0 in .Xdefaults, for example). Now suppose
>> one creates some tabs: M-x tab-new. The lines now are 37 because one
>> line is that of tabs and the frame has the same size (height). If,
>> now, one deletes the tabs, the lines remain at 37 but the frame has
>> the height shorter by one line. Repeating this procedure the lines
>> become 36, 35,... and the frame shorter, shorter...
>>
>> Is this to be the right thing? My opinion is that the frame should
>> have always the same height and the line should be 38 (N) or 37 (N-1)
>> if the tabs are visible.
>
> Emacs tries to keep the frame size so an integral number of lines just
> fits. But tabs aren't (in general) exactly one or two lines high, so
> some resize will occur. I made some fix.
>
> I also made tab-mode a minor mode so it can be turned off by customize.

Good to hear! but I can't yet test it because bootstrapping rev. 99648 
(gtk-tabs branch) fails as follows:

[...]
make[3]: Entering directory `/tmp/emacs-gtk-tabs/build/lisp'
Compiling /tmp/emacs/src/../lisp/term/w32-win.el
Compiling /tmp/emacs/src/../lisp/emacs-lisp/easymenu.el
Wrote /tmp/emacs/lisp/term/w32-win.elc
Wrote /tmp/emacs/lisp/emacs-lisp/easymenu.elc
make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp'
make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp'
rm -f ../etc/DOC
../lib-src/make-docfile -d /tmp/emacs/src dosfns.o msdos.o xterm.o 
xfns.o[...]
/lisp/jka-cmpr-hook.elc ../lisp/ediff-hook.elc ../lisp/epa-hook.elc 
../lisp/widget.elc ../lisp/window.elc ../lisp/version.el
LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path (/tmp/emacs/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version.el (source)...
[...]
Loading tool-bar...
Loading font-setting...
Loading native-tabs.el (source)...
Attempt to autoload define-minor-mode while preparing to dump
make[2]: *** [emacs.exe] Error 255
make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build'
make: *** [bootstrap] Error 2

This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same 
manner.


Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Loading native-tabs.el (source)...
> Attempt to autoload define-minor-mode while preparing to dump
> make[2]: *** [emacs.exe] Error 255
> make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src'
> make[1]: *** [src] Error 2
> make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build'
> make: *** [bootstrap] Error 2
> 
> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same 
> manner.

Hmm, I have pushed a new version where the autoload is removed.  The problem 
is, then C-h f tab-mode doesn't show anything.

Anybody knows why this happens?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 10/04/2010 20.03, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same
>> manner.
>
> Hmm, I have pushed a new version where the autoload is removed. The
> problem is, then C-h f tab-mode doesn't show anything.

I have tried also with rev. 99649, but same problem. :(

Angelo

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Did you make sure native-tabs.el is byte-compiled? Also do make clean  
and then make again.

        Jan D.

11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>:

> Il 10/04/2010 20.03, Jan Djärv ha scritto:
>> Angelo Graziosi skrev:
>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the  
>>> same
>>> manner.
>>
>> Hmm, I have pushed a new version where the autoload is removed. The
>> problem is, then C-h f tab-mode doesn't show anything.
>
> I have tried also with rev. 99649, but same problem. :(
>
> Angelo
>
>

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

As I have flagged sometime on this list, I do ALWAYS clean build of 
Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)

So, perhaps, that branch has other problems. For example,

$ grep native /tmp/emacs-gtk-tabs/src/Makefile.in

is empty in rev. 99648 and 99649.

The last useful build is with rev. 99645.

Ciao,
Angelo.


Il 11/04/2010 7.45, Jan Djärv ha scritto:
> Did you make sure native-tabs.el is byte-compiled? Also do make clean
> and then make again.
>
> Jan D.
>
> 11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>:
>
>> Il 10/04/2010 20.03, Jan Djärv ha scritto:
>>> Angelo Graziosi skrev:
>>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same
>>>> manner.
>>>
>>> Hmm, I have pushed a new version where the autoload is removed. The
>>> problem is, then C-h f tab-mode doesn't show anything.
>>
>> I have tried also with rev. 99649, but same problem. :(
>>
>> Angelo
>>
>>

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> As I have flagged sometime on this list, I do ALWAYS clean build of 
> Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)
> 
> So, perhaps, that branch has other problems. For example,
> 
> $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in
> 
> is empty in rev. 99648 and 99649.
> 
> The last useful build is with rev. 99645.
> 

Ah, so lisp files goes in there now, I didn't know.
I pushed a fix.

Thanks,

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 11/04/2010 12.52, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> As I have flagged sometime on this list, I do ALWAYS clean build of
>> Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)
>>
>> So, perhaps, that branch has other problems. For example,
>>
>> $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in
>>
>> is empty in rev. 99648 and 99649.
>>
>> The last useful build is with rev. 99645.
>>
>
> Ah, so lisp files goes in there now, I didn't know.
> I pushed a fix.

Indeed, now it builds :-)

Observations: I see that in Options | Show/Hide Tabs are on by default 
(good!), but when I start Emacs I do not see any tabs. I still need 'M-x 
tab-new' to see some tab. I would expect that, if Tabs are on by 
default, starting Emacs shows desktop buffers in tabs, at least 
compatibly with the starting 'geometry' of Emacs.

So (sorry :( ), I still miss a short way to see desktop buffers in tabs. 
Probably, you are only thinking how to implement that...

Thanks for your efforts,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:

> Indeed, now it builds :-)

Great.

> 
> Observations: I see that in Options | Show/Hide Tabs are on by default 
> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x 
> tab-new' to see some tab. I would expect that, if Tabs are on by 
> default, starting Emacs shows desktop buffers in tabs, at least 
> compatibly with the starting 'geometry' of Emacs.
> 
> So (sorry :( ), I still miss a short way to see desktop buffers in tabs. 
> Probably, you are only thinking how to implement that...
> 

Yes.  A generic window configuration can be complex, and saving an reading 
that into a file isn't that easy.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> Observations: I see that in Options | Show/Hide Tabs are on by default
> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
> tab-new' to see some tab. I would expect that, if Tabs are on by default,
> starting Emacs shows desktop buffers in tabs, at least compatibly with the
> starting 'geometry' of Emacs.

I implemented a new command line argument, so a command:

  emacs --tabs file1 file2 file3

will open each file in a new tab.  And

  emacsclient --create-tab

creates a new tab on the current Emacs frame.

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

Re: Gtk tabs in emacs, new branch

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Observations: I see that in Options | Show/Hide Tabs are on by default
>> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
>> tab-new' to see some tab. I would expect that, if Tabs are on by default,
>> starting Emacs shows desktop buffers in tabs, at least compatibly with the
>> starting 'geometry' of Emacs.
>
> I implemented a new command line argument, so a command:
>
>   emacs --tabs file1 file2 file3
>
> will open each file in a new tab.

That should be the default in a tab-capable Emacs when more than one
file is specified.

> And
>
>   emacsclient --create-tab
>
> creates a new tab on the current Emacs frame.

Again, I don't see a necessity for a new option.  If Emacs is configured
to open a new frame, all given files should appear in tabs of this
frame.  If not, all given files should appear in tabs in the existing
selected frame, in front of existing tabs.

-- 
David Kastrup

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>>   emacs --tabs file1 file2 file3
>>
>> will open each file in a new tab.
>
> That should be the default in a tab-capable Emacs when more than one
> file is specified.

This seems better than splitting the window and displaying the
buffer list, as it currently does.  Tabs also have another
advantage: the startup screen is displayed in a separate tab,
so it does not interfere with editing input files.

But what if some users might prefer the old behavior?
Maybe to add a command line argument `--no-tabs'?

>>   emacsclient --create-tab
>>
>> creates a new tab on the current Emacs frame.
>
> Again, I don't see a necessity for a new option.  If Emacs is configured
> to open a new frame, all given files should appear in tabs of this
> frame.  If not, all given files should appear in tabs in the existing
> selected frame, in front of existing tabs.

Like Forefox having command line arguments `new-tab' and `new-window',
I think Emacs should allow the user to choose whether to display the
file in the selected window, a new frame or a new tab.

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

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> But what if some users might prefer the old behavior?
>> Maybe to add a command line argument `--no-tabs'?
>
> We could assume the user will always want the same, so we could give him
> some way to write down his preference in a file.  We could that
> "~/.emacs", for example.  WDYT?

Exactly like `pop-up-frames' defines whether `display-buffer'
should make a separate frame, a new implemented option `pop-up-tabs'
makes a separate tab when it is non-nil.  It can be defined in ~/.emacs.

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

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Juri Linkov skrev 2010-04-22 10.16:
>>> But what if some users might prefer the old behavior?
>>> Maybe to add a command line argument `--no-tabs'?
>>
>> We could assume the user will always want the same, so we could give him
>> some way to write down his preference in a file.  We could that
>> "~/.emacs", for example.  WDYT?
>
> Exactly like `pop-up-frames' defines whether `display-buffer'
> should make a separate frame, a new implemented option `pop-up-tabs'
> makes a separate tab when it is non-nil.  It can be defined in ~/.emacs.
>

What if both pop-up-tabs and pop-up-frames are set?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> Exactly like `pop-up-frames' defines whether `display-buffer'
>> should make a separate frame, a new implemented option `pop-up-tabs'
>> makes a separate tab when it is non-nil.  It can be defined in ~/.emacs.
>
> What if both pop-up-tabs and pop-up-frames are set?

Then pop-up-frames takes priority over pop-up-tabs and creates a new frame
(with a single tab in it).

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

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

All is useful, but my opinion is that the main way should be something 
like 'M-x tabs-mode', so that one can visit buffers in tabs in a fast way.

Usually I start Emacs with a link on desktop...

Thanks,
Angelo.


Il 21/04/2010 10.55, Juri Linkov ha scritto:
>> Observations: I see that in Options | Show/Hide Tabs are on by default
>> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
>> tab-new' to see some tab. I would expect that, if Tabs are on by default,
>> starting Emacs shows desktop buffers in tabs, at least compatibly with the
>> starting 'geometry' of Emacs.
>
> I implemented a new command line argument, so a command:
>
>    emacs --tabs file1 file2 file3
>
> will open each file in a new tab.  And
>
>    emacsclient --create-tab
>
> creates a new tab on the current Emacs frame.
>

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

I also implemented C functions to save window configurations
in Lisp expressions that could be used later to save tabs
in the desktop file.  For example,

(current-window-configuration-to-sexp)
=>
(window-configuration
 (frame-cols . 80)
 (frame-lines . 41)
 (frame-menu-bar-lines . 1)
 (frame-tool-bar-lines . 4)
 (frame-tab-bar-lines . 4)
 (current-buffer . "*scratch*")
 (minibuf-scroll-window)
 (minibuf-selected-window)
 (saved-windows
  . (saved-window
     (current-window . t)
     (buffer . "*scratch*")
     (left-col . 0)
     (top-line . 5)
     (total-cols . 86)
     (total-lines . 35)
     (hscroll . 0)
     (min-hscroll . 0)
     (display-table)
     (orig-top-line)
     (orig-total-lines)
     (left-margin-cols)
     (right-margin-cols)
     (left-fringe-width)
     (right-fringe-width)
     (fringes-outside-margins)
     (scroll-bar-width)
     (vertical-scroll-bar-type . t)
     (dedicated)
     (resize-proportionally)
     (pointm . 236)
     (start . 1)
     (start-at-line-beg . t)
     (mark . 192)
     (next
      . (saved-window
         (buffer . " *Minibuf-0*")
         (left-col . 0)
         (top-line . 40)
         (total-cols . 86)
         (total-lines . 1)
         (hscroll . 0)
         (min-hscroll . 0)
         (display-table)
         (orig-top-line)
         (orig-total-lines)
         (left-margin-cols)
         (right-margin-cols)
         (left-fringe-width)
         (right-fringe-width)
         (fringes-outside-margins)
         (scroll-bar-width)
         (vertical-scroll-bar-type . t)
         (dedicated)
         (resize-proportionally)
         (pointm . 1)
         (start . 1)
         (start-at-line-beg))))))

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

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

This is good.  But I suspect the restore part is the more difficult work.

	Jan D.


Juri Linkov skrev 2010-04-21 17.45:
> I also implemented C functions to save window configurations
> in Lisp expressions that could be used later to save tabs
> in the desktop file.  For example,
>
> (current-window-configuration-to-sexp)
> =>
> (window-configuration
>   (frame-cols . 80)
>   (frame-lines . 41)
>   (frame-menu-bar-lines . 1)
>   (frame-tool-bar-lines . 4)
>   (frame-tab-bar-lines . 4)
>   (current-buffer . "*scratch*")
>   (minibuf-scroll-window)
>   (minibuf-selected-window)
>   (saved-windows
>    . (saved-window
>       (current-window . t)
>       (buffer . "*scratch*")
>       (left-col . 0)
>       (top-line . 5)
>       (total-cols . 86)
>       (total-lines . 35)
>       (hscroll . 0)
>       (min-hscroll . 0)
>       (display-table)
>       (orig-top-line)
>       (orig-total-lines)
>       (left-margin-cols)
>       (right-margin-cols)
>       (left-fringe-width)
>       (right-fringe-width)
>       (fringes-outside-margins)
>       (scroll-bar-width)
>       (vertical-scroll-bar-type . t)
>       (dedicated)
>       (resize-proportionally)
>       (pointm . 236)
>       (start . 1)
>       (start-at-line-beg . t)
>       (mark . 192)
>       (next
>        . (saved-window
>           (buffer . " *Minibuf-0*")
>           (left-col . 0)
>           (top-line . 40)
>           (total-cols . 86)
>           (total-lines . 1)
>           (hscroll . 0)
>           (min-hscroll . 0)
>           (display-table)
>           (orig-top-line)
>           (orig-total-lines)
>           (left-margin-cols)
>           (right-margin-cols)
>           (left-fringe-width)
>           (right-fringe-width)
>           (fringes-outside-margins)
>           (scroll-bar-width)
>           (vertical-scroll-bar-type . t)
>           (dedicated)
>           (resize-proportionally)
>           (pointm . 1)
>           (start . 1)
>           (start-at-line-beg))))))
>

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> This is good.  But I suspect the restore part is the more difficult work.

Yes, the restore part is more difficult.  I've committed the initial workable
version of `set-window-configuration-from-sexp' to the x-tabs branch.
At least, it restores window configurations saved in another session.

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

Re: Gtk tabs in emacs, new branch

[Juanma Barranquero]

On Thu, Apr 22, 2010 at 10:14, Juri Linkov <juri@jurta.org> wrote:

> I've committed the initial workable
> version of `set-window-configuration-from-sexp' to the x-tabs branch.
> At least, it restores window configurations saved in another session.

This is generally useful, i.e., if it works it should perhaps go to the trunk.

    Juanma

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> I've committed the initial workable
>> version of `set-window-configuration-from-sexp' to the x-tabs branch.
>> At least, it restores window configurations saved in another session.
>
> This is generally useful, i.e., if it works it should perhaps go to the trunk.

Before moving it to the trunk, I'd like first to make sure that saving
tabs to the desktop works reliably.  For example, I realized that
functions `current-window-configuration-to-sexp' and
`set-window-configuration-from-sexp' are not suitable to save tabs
because their window configurations are kept in #<window-configuration>.

There should be another set of functions like
`(window-configuration-to-sexp #<window-configuration>)' and
`(window-configuration-from-sexp sexp)' that returns #<window-configuration>.
This means that the returned Lisp expression will contain a list of windows
(where `parent' and `prev' refer to the index of the window in this list)
instead of the window hierarchy.  Maybe this is a good thing.  E.g.

(window-configuration-to-sexp (current-window-configuration))
=>
(window-configuration
 (frame-cols . 196)
 (frame-lines . 77)
 (frame-menu-bar-lines . 1)
 (frame-tool-bar-lines . 4)
 (frame-tab-bar-lines . 0)
 (minibuf-scroll-window)
 (minibuf-selected-window)
 (saved-windows
  (window
   (left-col . 0)
   (top-line . 5)
   (total-cols . 202)
   (total-lines . 71)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 0)
   (left-col . 0)
   (top-line . 5)
   (total-cols . 101)
   (total-lines . 71)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 1)
   (buffer . "*scratch*")
   (left-col . 0)
   (top-line . 5)
   (total-cols . 101)
   (total-lines . 35)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 1)
   (prev . 2)
   (buffer . "*Messages*")
   (left-col . 0)
   (top-line . 40)
   (total-cols . 101)
   (total-lines . 36)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 0)
   (prev . 1)
   (buffer . "*info*")
   (left-col . 101)
   (top-line . 5)
   (total-cols . 101)
   (total-lines . 71)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (prev . 0)
   (window . " *Minibuf-0*")
   (left-col . 0)
   (top-line . 76)
   (total-cols . 202)
   (total-lines . 1)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))))

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> From: Juri Linkov
> I also implemented C functions to save window configurations
> in Lisp expressions that could be used later to save tabs
> in the desktop file.  For example,
> 
> (current-window-configuration-to-sexp)
> =>
> (window-configuration
>  (frame-cols . 80)
>  (frame-lines . 41)
>  (frame-menu-bar-lines . 1)
>  (frame-tool-bar-lines . 4)
>  (frame-tab-bar-lines . 4)
...

Is the intention to be able to save and restore all current window & frame
configurations?

That is what I would like to see, to be able to save and restore an Emacs state
as completely as possible wrt frames and windows.

[That would of course mean saving all frame parameters that can be restored. I
would even like to see the ability for users to hook into such a feature, so
that user-defined frame parameters could be handled also. E.g. for a
user-defined frame parameter `foo', a user could specify how it can be saved and
restored, so that frame-config saving & restoring would then DTRT wrt it.]

Lennart made a stab at saving/restoring frame and window configs, but his code
didn't work when I tested it (there were apparently some dependencies on his
EmacsW32 etc.). Perhaps you and he could put together something general. It
seems like you're both close.

I would like to see the ability to save & restore each of the following
independently, in such a way that you could use them separately or together (to
save and restore various combinations): desktops, window configs, frame configs.

IOW, we should not couple any of them in such a way that you could no longer
save only a desktop (without also saving frame configs) or only the current
frame & window configs, etc.  E.g., a saved desktop should not necessarily
include frame and window configs, but you should also be able to save all at
once.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> Is the intention to be able to save and restore all current window & frame
> configurations?

Yes, I've implemented the task to save and restore frame and
window configurations in the desktop file.

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Is the intention to be able to save and restore all current 
> > window & frame configurations?
> 
> Yes, I've implemented the task to save and restore frame and
> window configurations in the desktop file.

Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If
so, is it documented? If it's in the pretest I would like to try it.

Can users save such frame & window configs independently of desktops - and vice
versa? Can they save individual frame/window configs as well as all configs
together? See the rest of my previous mail.

A desktop saves some variables, buffers, etc. Users should be able to save just
frame/window state or just the vars+bufs state, as well as being able to save
everything together at once. It doesn't matter whether this new feature is in a
separate library (which might be more modular) or is in desktop.el, but
frame/window saving/restoration should be separable from the traditional use of
desktops to save/restore buffers and vars.

Also, desktop.el has a big limitation (which I would like to see removed): it
assumes only one desktop file per directory. I would not like to see such a
gross limitation extended to the saving and restoring of frame and window
configs. There is no reason for that.

Please see the rest of my previous mail. Can users hook into this to handle
user-defined frame parameters also? The feature should be open and not limited
to a predefined set of parameters.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> Yes, I've implemented the task to save and restore frame and
>> window configurations in the desktop file.
>
> Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If
> so, is it documented? If it's in the pretest I would like to try it.

This feature is part of the x-tabs branch.

> Can users save such frame & window configs independently of desktops - and vice
> versa? Can they save individual frame/window configs as well as all configs
> together?

If you want to save frame and window configurations independently of desktops,
you can easily do this using the same functions that desktop.el now uses.

> A desktop saves some variables, buffers, etc. Users should be able to save just
> frame/window state or just the vars+bufs state, as well as being able to save
> everything together at once.

There is a new variable `desktop-save-frame-configuration' that defines
whether to save frame and window configurations to the desktop.
It is nil by default.

> Also, desktop.el has a big limitation (which I would like to see removed): it
> assumes only one desktop file per directory.

It's a separate task to implement named desktops.

I imagine that named desktops should be an object above frames
in the hierarchy of screen objects:

 - desktop
  - frame
   - tab
    - window configuration
     - window

So switching desktops could be like switching frames:

  M-x select-desktop-by-name RET

will read a desktop name, delete old frames by calling `desktop-clear',
and create a new desktop by calling `desktop-read' with the selected name.

> Can users hook into this to handle user-defined frame parameters also?
> The feature should be open and not limited to a predefined set
> of parameters.

Yes, there is a new variable `desktop-frame-parameters-to-save'.

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Can users save such frame & window configs independently of 
> > desktops - and vice versa? Can they save individual
> > frame/window configs as well as all configs
> > together?
> 
> If you want to save frame and window configurations 
> independently of desktops, you can easily do this using the
> same functions that desktop.el now uses.

So is that confirmation or not that one can save desktops without frame+win
configs and one can also save frame configs or window configs or both
independently of desktops (the traditional desktop info)?

And can users do that interactively out of the box, or are you saying only that
someone is free to create some user commands to do that using existing desktop
functions?

> > A desktop saves some variables, buffers, etc. Users should 
> > be able to save just frame/window state or just the
> > vars+bufs state, as well as being able to save
> > everything together at once.
> 
> There is a new variable `desktop-save-frame-configuration' 
> that defines whether to save frame and window configurations
> to the desktop. It is nil by default.

You don't also say that there is a way to save frame and window configs without
saving them to a desktop file. Or whether there is a way to save them without
also saving the other desktop info (buffers, vars etc.). 

It sounds like frame+win are optionally part of a desktop, but not the contrary
as well. That is different from them being separate things that can optionally
be combined.

I don't care much about the names - whether, for instance, "desktop" applies to
what it means now (buffers, vars, etc.) or it is changed to apply to everything,
including frames and windows. What I am concerned about is being able to easily
save & restore the different kinds of things separately.

> > Also, desktop.el has a big limitation (which I would like 
> > to see removed): it assumes only one desktop file per directory.
> 
> It's a separate task to implement named desktops.
> 
> I imagine that named desktops should be an object above frames
> in the hierarchy of screen objects:
>  - desktop - frame - tab - window configuration - window
> So switching desktops could be like switching frames:
>   M-x select-desktop-by-name RET
> will read a desktop name, delete old frames by calling 
> `desktop-clear', and create a new desktop by calling
> `desktop-read' with the selected name.

I do not really want to see desktops and frames coupled that way. Again, the
names don't matter to me much - what I want is to be able to save & restore such
different things together or separately.

I did not mention "named desktops". I asked to be able to have more than one
desktop file per directory. Currently, the desktop functions assume you can have
only one desktop file per dir.

I would like the basic desktop functions to accept an optional FILE arg that
tells them where the desktop file is. (If no such arg is passed, then they could
do as they do now: look to `desktop-dirname' to find the file.) That would
permit other code to pass a FILE arg to directly specify a desktop file to use.

I have desktop bookmarks, for instance. Because the desktop.el code does not
allow a caller to specify the file to use, my code jumps through a few extra
hoops.

Look at `desktop-change-dir' and `desktop-read'. They just change to the desktop
represented by a particular desktop file. But they assume one file per dir, so
they accept only a dir as arg. You would expect that you could explicitly pass a
desktop file to read, but you cannot.

The desktop.el code seems to be oriented toward a particular interaction between
users and its basic features. That's the problem, as I see it. It has general
features of saving and restoring a desktop to/from a file, but the functions
that perform those basic operations are cobbled by making them assume a
particular UI. That makes them less general (less useful) than they could be.

IOW, there is not enough separation between the basic desktop functions and the
UI that uses them - the UI design bleeds down into the basic functions
themselves.

We need not change the desktop UI. (But we could do that, to let users use
multiple files per dir interactively as well.) The basic desktop functions could
still assume that the desktop file they need is in the `desktop-dirname' dir by
default. All I'm suggesting is that these functions should allow an optional
parameter that provides the desktop file location. 

Other changes to the code (e.g. locking) might also be necessary to allow use of
multiple files per dir - dunno. I'm guessing that the reason behind the original
one-desktop-file-per-dir design had to do with locking (multiple users etc.). I
don't know what all might be involved in trying to remove this limitation (maybe
allow multiple lock files per dir?). For my use of desktop files for bookmarks,
I want to let users save desktop files anywhere, and I don't use the locking.

I brought up this point because you seem to be coupling persistence of frame and
window configs with desktop files - and hence extending the limitation of one
such file per dir to the new feature as well. That means users cannot have
multiple frame-config files per dir etc.

Don't get me wrong. I'm very glad you're working on this, and I don't pretend to
be an expert on desktops or the desktop.el code. I just would like things to be
modular - separable and combinable, and I would like the basic save-&-restore
functions to handle multiple state-saving files per dir.

> > Can users hook into this to handle user-defined frame 
> > parameters also? The feature should be open and not limited to
> > a predefined set of parameters.
> 
> Yes, there is a new variable `desktop-frame-parameters-to-save'.

Very good.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> And can users do that interactively out of the box, or are you saying
> only that someone is free to create some user commands to do that
> using existing desktop functions?

Sorry, this is too abstract and premature.  You are asking for
generalization, but there is nothing to generalize yet, because
even saving to the desktop file is not ready yet.  Please wait
until it's ready, try it and then come up with concrete propositions:
what additional functions do you need, etc.  Or help to finish the task
of saving to the desktop file.

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> Sorry, this is too abstract and premature.  You are asking for
> generalization, but there is nothing to generalize yet, because
> even saving to the desktop file is not ready yet.  Please wait
> until it's ready, try it and then come up with concrete propositions:
> what additional functions do you need, etc.  Or help to 
> finish the task of saving to the desktop file.

I asked specific (not only abstract) questions about the _design_ of the new
feature you're proposing. You're telling me that you cannot discuss the design,
that I should just wait until the implementation is finished before raising
questions about what it should do. That's an "interesting" attitude.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> I asked specific (not only abstract) questions about the _design_ of
> the new feature you're proposing. You're telling me that you cannot
> discuss the design, that I should just wait until the implementation
> is finished before raising questions about what it should do.

Of course, you are welcome to discuss the design.  Currently the design
is at the stage of deciding what format is better to represent the
window configuration.  There are two options: a window tree and
a plain list of windows.  I am inclined to the second option
since when saved it would be more compact.

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

Re: Gtk tabs in emacs, new branch

[martin rudalics]

 > ... Currently the design
 > is at the stage of deciding what format is better to represent the
 > window configuration.  There are two options: a window tree and
 > a plain list of windows.  I am inclined to the second option
 > since when saved it would be more compact.

There's absolutely no need to make window configurations saved by
`current-window-configuration' (I call them CWCs here) and window
configurations saved for later reconstruction in a possibly different
session (called EWCs) save the same states of things.

CWCs are needed to restore the appearance of a frame after a short
excursion or because some error occurred.  They are heavily overused in
that respect (for example, every time you drag a window's modeline with
the mouse up or down by one line, Emacs saves and discards the current
window configuration twice) but certain aspects might be needed to keep
the appearance coherent like, for example, `hscroll' related entries.

EWCs should IMHO strip window configurations to the absolutely needed
bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
more harm than good in EWCs (BTW, I've completely done away with these
in my rewrite of window.c) as all other minibuffer related information.
Also hscroll and min-hscroll should not be stored.

Whether margin, fringe and scrollbar information should be stored in
EWCs depends on whether the appropriate settings for frames and the
buffer local values are stored and orderly processed as well - otherwise
they make few sense.  I'm afraid we'd have to store/restore all of them,
although I'm also quite sure that hardly anyone could tell how their
final appearance on screen is determined.

Coordinates should probably be rather stored as fractions instead of
absolute lines and columns.  This would make it easier to (1) eventually
switch to pixel based coordinates and (2) put an EWC into an Emacs
window (that is, put an Emacs frame into an Emacs window) as some IDE
advocats mentioned earlier.

Since I suppose you're running `split-window' to restore configurations
you'd probably also want to remember whether a "split" was a vertical or
a horizontal one in EWCs.  Note that CWCs don't do this since they need
to restore the configuration from the stored "coordinates" anyway, but
the design is a bit awkward as code like

  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))

in `set-window-configuration' shows.

That said, the *entire* coordinate information of a particular window in
an EWC would consist of (1) whether it is a horizontal or a vertical
combination and (2) the proportional space - either a float or the
fraction of "some largest integer" - occupied by the window wrt to its
parent window.  Anything else would be pure overkill.

BTW in the earlier example structure you posted here I'm missing entries
for window-point, window-start, ...  Was that intentional?

martin

Window configurations (was: Gtk tabs in emacs, new branch)

[Juri Linkov]

>> ... Currently the design
>> is at the stage of deciding what format is better to represent the
>> window configuration.  There are two options: a window tree and
>> a plain list of windows.  I am inclined to the second option
>> since when saved it would be more compact.
>
> There's absolutely no need to make window configurations saved by
> `current-window-configuration' (I call them CWCs here) and window
> configurations saved for later reconstruction in a possibly different
> session (called EWCs) save the same states of things.

Yes.  That's why I added a new argument `live-p' to
`current-window-configuration-to-sexp'.  When non-nil, it adds live data
(window objects, buffer objects, markers, etc.) that are necessary
when its Lisp expression will be used in the same session.  When nil,
it returns bare minimum necessary to save and restore in another session.

> EWCs should IMHO strip window configurations to the absolutely needed
> bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
> more harm than good in EWCs (BTW, I've completely done away with these
> in my rewrite of window.c)

Do you plan to create a branch for your rewrite of window.c?
It would be very interesting to look at it.

> Coordinates should probably be rather stored as fractions instead of
> absolute lines and columns.  This would make it easier to (1) eventually
> switch to pixel based coordinates and (2) put an EWC into an Emacs
> window (that is, put an Emacs frame into an Emacs window) as some IDE
> advocats mentioned earlier.

There are no problems with storing coordinates as absolute lines and
columns.  After restoring absolute coordinates `set-window-configuration'
resizes the frame thus keeping original relative sizes unchanged.

> Since I suppose you're running `split-window' to restore configurations
> you'd probably also want to remember whether a "split" was a vertical or
> a horizontal one in EWCs.  Note that CWCs don't do this since they need
> to restore the configuration from the stored "coordinates" anyway, but
> the design is a bit awkward as code like
>
>  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
>
> in `set-window-configuration' shows.

No, I don't use `split-window'.  I use exactly the same algorithm as in
`set-window-configuration', and additionally make new windows.
In my tests, this works correctly.

> That said, the *entire* coordinate information of a particular window in
> an EWC would consist of (1) whether it is a horizontal or a vertical
> combination and (2) the proportional space - either a float or the
> fraction of "some largest integer" - occupied by the window wrt to its
> parent window.

Currently `set-window-configuration-from-sexp' works without these
parameters.  But maybe they would be useful for user-defined window
configurations.

> BTW in the earlier example structure you posted here I'm missing entries
> for window-point, window-start, ...  Was that intentional?

There are entries `pointm' and `start' in the output of of the really
working function `current-window-configuration-to-sexp'.

But the example of the output of `window-configuration-to-sexp' is for
demonstration purposes only.  It doesn't work yet, because I'm not sure yet
whether it's better than `current-window-configuration-to-sexp'.

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

Re: Window configurations

[martin rudalics]

 > Do you plan to create a branch for your rewrite of window.c?
 > It would be very interesting to look at it.

I have to catch up with recent developments on the trunk - currently I'm
at revision 99248.  And I yet have to write Change Logs.

 > No, I don't use `split-window'.  I use exactly the same algorithm as in
 > `set-window-configuration', and additionally make new windows.
 > In my tests, this works correctly.

That's what I intended to do when I first looked into this.  Making new
windows essentially has the problem that when, for whatever reason,
coordinates are garbled, you end up with a distorted frame and, in the
worst case, crash Emacs.  Checking window edges is simple with an
existing window tree.  But if you build the entire tree from scatch, you
also have to provide a safe way to GC windows you made just in case they
don't fit.  With `split-window' you always add one window at a time and
you never make a new one unless you're sure it fits.

By no means I want to talk you out of this ;-) but `split-window' is a
socially well-established function.  Saved window configurations will
hardly ever get used that much.  And we'll already have a hard time to
maintain compatibility, for example, when you want to restore a
configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa).

 >> That said, the *entire* coordinate information of a particular window in
 >> an EWC would consist of (1) whether it is a horizontal or a vertical
 >> combination and (2) the proportional space - either a float or the
 >> fraction of "some largest integer" - occupied by the window wrt to its
 >> parent window.
 >
 > Currently `set-window-configuration-from-sexp' works without these
 > parameters.  But maybe they would be useful for user-defined window
 > configurations.

Users "define" window configurations by splitting and deleting windows.
They have no idea of the underlying window tree.  But if you don't use
`split-window' storing the type of window combinations doesn't make
sense anyway.  It's just that current window configurations have lots of
redundancy: For a vertical combination, the widths of all subwindows are
the same as that of the parent window, top-lines can be calculated on
the fly by adding the top-line of the left sibling to its height, ...

Anyway, the greatest problem IMO is to get windows correlate with their
buffers.  I don't think that restoring ediff configurations will become
ever feasible (unless you build this into the ediff code) and I'm also
pessimistic about Info buffers - in particular cloned ones.  And
obviously we'll fail to handle code based on window objects or overlays
with a window property.

But for merely "normal" buffers the integrity of buffer-local variables
affecting size and appearance of windows displaying them must be
preserved.  For example, when a buffer has `window-size-fixed' non-nil,
any frame resizing step in your `set-window-configuration' should keep
the size of the window fixed.

martin

Re: Window configurations

[Juri Linkov]

> By no means I want to talk you out of this ;-) but `split-window' is a
> socially well-established function.  Saved window configurations will
> hardly ever get used that much.  And we'll already have a hard time to
> maintain compatibility, for example, when you want to restore a
> configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa).

I agree that when designing this feature, we should think about the future.
Let's imagine that Emacs 27 will switch from the tiling window manager
to an overlapping window manager.  Then `split-window' in window
configurations will make no sense.  This suggests that for the generality
window configurations should be defined as a list of windows with their
parameters, i.e. very much like frames are defined now.  Frame parameters
to define the frame geometry are `left', `top', `height', and `width'.
Window parameters to define the window geometry are `left-col', `top-line',
`total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
they should be in pixels.

> Users "define" window configurations by splitting and deleting windows.
> They have no idea of the underlying window tree.  But if you don't use
> `split-window' storing the type of window combinations doesn't make
> sense anyway.  It's just that current window configurations have lots of
> redundancy: For a vertical combination, the widths of all subwindows are
> the same as that of the parent window, top-lines can be calculated on
> the fly by adding the top-line of the left sibling to its height, ...

Yes, currently window coordinates are redundant because of the
limitations of the tiling window manager.  So we have to find a minimal
set of window parameters to define the window location.  I agree that
a window tree is an implementation detail and users have no idea of the
underlying window tree.

Another variant is to define window geometry relative to the neighbor
windows, e.g. `left-window', `right-window' in terms of the package
windmove.el.  Such window configurations would be easy to define for users.

> Anyway, the greatest problem IMO is to get windows correlate with their
> buffers.  I don't think that restoring ediff configurations will become
> ever feasible (unless you build this into the ediff code)

I see no problems with window-to-buffer relations.  They can be defined
using buffer names.  This works successfully with desktop.el from the
x-tabs branch by saving and restoring window configurations in the
desktop file.

> and I'm also pessimistic about Info buffers

Window configurations with Info buffers are saved and restored
successfully in the desktop file as well.

> - in particular cloned ones.

What problems do you see with cloned Info buffers?

> And obviously we'll fail to handle code based on window objects
> or overlays with a window property.

Maybe a package that uses window overlays should use a new hook
to restore window overlays after a new window is created from
a window configuration.

> But for merely "normal" buffers the integrity of buffer-local variables
> affecting size and appearance of windows displaying them must be
> preserved.  For example, when a buffer has `window-size-fixed' non-nil,
> any frame resizing step in your `set-window-configuration' should keep
> the size of the window fixed.

It seems the frame resizing step in `set-window-configuration' already
keeps the size of the window fixed.

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

Re: Window configurations

[martin rudalics]

 > This suggests that for the generality
 > window configurations should be defined as a list of windows with their
 > parameters, i.e. very much like frames are defined now.  Frame parameters
 > to define the frame geometry are `left', `top', `height', and `width'.
 > Window parameters to define the window geometry are `left-col', `top-line',
 > `total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
 > they should be in pixels.

Sounds reasonable.  If we apply this idea today, the restore-from-sexp
step would decide how to rebuild the window tree from these geometry
parameters - that means how to nest windows into each others.

 > Yes, currently window coordinates are redundant because of the
 > limitations of the tiling window manager.  So we have to find a minimal
 > set of window parameters to define the window location.  I agree that
 > a window tree is an implementation detail and users have no idea of the
 > underlying window tree.

Some window managers are tiling window managers, even Windows XP has one
built in.  So even if Emacs permits overlapping windows it will probably
still offer tiled frames too.

 > Another variant is to define window geometry relative to the neighbor
 > windows, e.g. `left-window', `right-window' in terms of the package
 > windmove.el.  Such window configurations would be easy to define for users.

Hmm ... windmove never helped me that much.  I rewrote the core function
for my own purposes because there are windows I never want to select
interactively but the window behind such an unselectable one (or on the
left or right of it) is the window I really want.

 > I see no problems with window-to-buffer relations.  They can be defined
 > using buffer names.  This works successfully with desktop.el from the
 > x-tabs branch by saving and restoring window configurations in the
 > desktop file.

I have one buffer type which gets killed as soon as it's not shown in
any window.  Another one gets its name from the name of the window it's
shown in.  But I admit that in most cases the problematic issue is not
the buffer itself but the major or minor mode a window's buffer is in.

I suppose the solution is to (1) make the mode take care of saving the
relevant information and (2) untie buffer and window management in some
way.  How this would work for edebug, GDB, or diff sessions is currently
beyond my imagination.  Note that all I'm concerned here is that we now
should probably fix the order in which the restoring steps are perfomed
and what impact that has on restoring window configurations.  Whether
and how modes can be fully restored would be left to their designers.

 > Window configurations with Info buffers are saved and restored
 > successfully in the desktop file as well.
 >> - in particular cloned ones.
 >
 > What problems do you see with cloned Info buffers?

I never looked into this but I'm surprised that Info buffer would work
out of the box.  Do help buffers work well too?

 > Maybe a package that uses window overlays should use a new hook
 > to restore window overlays after a new window is created from
 > a window configuration.

I recall that Lennart tried to do that.  Currently, overlays can be a
mess after reverting a buffer so I think there are more important things
to do first.  Maybe we could try to handle this by giving windows fairly
unique print names.

 > It seems the frame resizing step in `set-window-configuration' already
 > keeps the size of the window fixed.

Probably at the expense of deleting windows when the frame gets too
small.  But my point was only that we have to process buffer-local
variables _before_ resizing frames.

martin

Re: Window configurations

[Juri Linkov]

>> This suggests that for the generality
>> window configurations should be defined as a list of windows with their
>> parameters, i.e. very much like frames are defined now.  Frame parameters
>> to define the frame geometry are `left', `top', `height', and `width'.
>> Window parameters to define the window geometry are `left-col', `top-line',
>> `total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
>> they should be in pixels.
>
> Sounds reasonable.  If we apply this idea today, the restore-from-sexp
> step would decide how to rebuild the window tree from these geometry
> parameters - that means how to nest windows into each others.

For an overlapping window manager there is no need to rebuild the window
tree from geometry parameters.  And for the current tiling window manager
you said that window coordinates are redundant.  That's why I proposed
non-redundant and easy-to-define relative parameters.  I think it would
be sufficient to have two relative position parameters `left-window' and
`top-window' (that point to the left/top neighbor window) and two relative
size parameters `width' and `height' (fractions relative to the frame size).
I guess it would be possible to rebuild the window tree from this minimal
set of window parameters.

> Some window managers are tiling window managers, even Windows XP has one
> built in.  So even if Emacs permits overlapping windows it will probably
> still offer tiled frames too.

But none of these window managers define tiled windows as a split
window tree.  So probably an Emacs' overlapping window manager
will not be based on window trees.

> Hmm ... windmove never helped me that much.  I rewrote the core function
> for my own purposes because there are windows I never want to select
> interactively but the window behind such an unselectable one (or on the
> left or right of it) is the window I really want.

This looks like a new "intangible" window property discussed in the
window-group threads.  Have you implemented this in your rewrite of
window.c?

>> What problems do you see with cloned Info buffers?
>
> I never looked into this but I'm surprised that Info buffer would work
> out of the box.  Do help buffers work well too?

No, help buffers don't have an addressing scheme like in Info
with (info "(file)node").  Recently I proposed to display
Help information in the Info reader.  This will save and restore
buffers with Help information in the desktop file.

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

Info buffers in Desktop

[Juri Linkov]

Currently desktop.el doesn't save virtual Info buffers,
but most of them are very fast to restore.  This patch allows
desktop.el to save virtual Info buffers except when their
definition has a new property `desktop-not-to-save'.
`info-apropos' is very slow to create its output node,
so it has this property:

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-04-22 18:08:17 +0000
+++ lisp/info.el	2010-04-27 19:45:27 +0000
@@ -3202,25 +3217,15 @@
 	       (toc-nodes . Info-apropos-toc-nodes)
 	       (find-file . Info-apropos-find-file)
 	       (find-node . Info-apropos-find-node)
+	       (desktop-not-to-save . t)
 	       ))
 
 (defvar Info-apropos-file "*Apropos*"
@@ -4863,7 +4869,8 @@
 
 (defun Info-desktop-buffer-misc-data (desktop-dirname)
   "Auxiliary information to be saved in desktop file."
-  (unless (Info-virtual-file-p Info-current-file)
+  (unless (Info-virtual-fun 'desktop-not-to-save
+			    Info-current-file Info-current-node)
     (list Info-current-file Info-current-node)))
 
 (defun Info-restore-desktop-buffer (desktop-buffer-file-name

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

Re: Window configurations

[martin rudalics]

 >> Sounds reasonable.  If we apply this idea today, the restore-from-sexp
 >> step would decide how to rebuild the window tree from these geometry
 >> parameters - that means how to nest windows into each others.
 >
 > For an overlapping window manager there is no need to rebuild the window
 > tree from geometry parameters.  And for the current tiling window manager
 > you said that window coordinates are redundant.

That's what I said earlier.  But if we eventually do need them for an
overlapping window manager, we could build them into the current tiling
manager.  Just that (IMO) the tiling manager needs internal windows to
work correctly.  So the common format would be your four standard
parameters left column, top line, height and width for _all_ windows
including internal ones.

The restore step for the current tiling manager would have to process
the internal windows and reconstruct the nesting by comparing their
coordinates with those of the leaf windows - just like the current
`set-window-configuration' does in

	      if (!NILP (w->parent))
		{
		  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
		    {
		      XWINDOW (w->parent)->vchild = p->window;
		      XWINDOW (w->parent)->hchild = Qnil;
		    }
		  else
		    {
		      XWINDOW (w->parent)->hchild = p->window;
		      XWINDOW (w->parent)->vchild = Qnil;
		    }

where it sets the vertical / horizontal child of a parent window
according to whether the number of its columns equals that of its child
windows (this work by virtue of Emacs's ability to collapse matryoshka
windows although it might not harm much if for such windows the split
direction would be inverted).

The restore step for the overlapping manager would simply ignore
internal windows.  So we could restore configurations stored by a tiling
manager in an overlapping manager.

 > That's why I proposed
 > non-redundant and easy-to-define relative parameters.  I think it would
 > be sufficient to have two relative position parameters `left-window' and
 > `top-window' (that point to the left/top neighbor window) and two relative
 > size parameters `width' and `height' (fractions relative to the frame size).
 > I guess it would be possible to rebuild the window tree from this minimal
 > set of window parameters.

Do you mean left would point to the left neighbor and top to the
neighbor above?  How would you assign them for a four window
configuration like this:

  -----
|1 |2 |
|-----|
|3 |4 |
  -----

Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows.  How
would you convey that information with relative parameters?

 > This looks like a new "intangible" window property discussed in the
 > window-group threads.  Have you implemented this in your rewrite of
 > window.c?

It's virtually impossible to do that in a strict sense (unless you go
for a `post-command-hook').  Note that you can always do a thing like
(select-window (minibuffer-window)).

What I've done is to make `other-window' by default not select certain
window types.  That default can be overridden by window parameters.  And
I wrote a `window-in-direction' function which does this for the window
in a given direction (I need this because I never use C-x o).

martin

Re: Window configurations

[Juri Linkov]

> The restore step for the overlapping manager would simply ignore
> internal windows.  So we could restore configurations stored by a tiling
> manager in an overlapping manager.

I agree that in a tiling manager internal windows should have coordinates,
and an overlapping manager should ignore windows that don't display buffers
(if a window manager will support displaying windows without buffers
then window definitions should include a new window parameter for them).

> Do you mean left would point to the left neighbor and top to the
> neighbor above?

Yes.

> How would you assign them for a four window configuration like this:
>
>  -----
> |1 |2 |
> |-----|
> |3 |4 |
>  -----
>
> Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows.  How
> would you convey that information with relative parameters?

This is easy to do.  Since split window trees are order-dependent,
a list of windows that defines the window configuration in the tiling
manager should be order-dependent too.  Thus

  (window 1
    (buffer . 1))
  (window 2
    (buffer . 2)
    (left-window . 1))
  (window 3
    (buffer . 3)
    (top-window . 1))
  (window 4
    (buffer . 4)
    (top-window . 2)
    (left-window . 3))

will create 1+2 and 3+4, and

  (window 1
    (buffer . 1))
  (window 3
    (buffer . 3)
    (top-window . 1))
  (window 2
    (buffer . 2)
    (left-window . 1))
  (window 4
    (buffer . 4)
    (top-window . 2)
    (left-window . 3))

will create 1+3 and 2+4.

>> This looks like a new "intangible" window property discussed in the
>> window-group threads.  Have you implemented this in your rewrite of
>> window.c?
>
> It's virtually impossible to do that in a strict sense (unless you go
> for a `post-command-hook').  Note that you can always do a thing like
> (select-window (minibuffer-window)).

This is right that primitives should be able to do this, and
user commands should take restrictions from additional parameters.

> What I've done is to make `other-window' by default not select certain
> window types.  That default can be overridden by window parameters.  And
> I wrote a `window-in-direction' function which does this for the window
> in a given direction (I need this because I never use C-x o).

Ok, I'll wait until you publish a Bzr branch to look at this.

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

Re: Window configurations

[Davis Herring]

> Users "define" window configurations by splitting and deleting windows.
> They have no idea of the underlying window tree.

I'm not sure that's right.  While users certainly don't know about
`frame-root-window' windows, the tree is otherwise readily apparent
(since, for instance, resizing or deleting a window distinguishes

+-+-+     +-+-+
|A|B|     |A|B|
+-|-+ and +---+
|C|D|     |C|D|
+-+-+     +-+-+

in an immediately obvious fashion).  Why not store a configuration as a
(resolution-independent) tree:

subtree = window | tree ;
tree = "(", horiz, subtree, split, { split }, ")" ;
split = fraction, subtree ;
horiz = nil | t ;            (* t for C-x 3 *)
fraction = ? float ? ;
window = ? ... ? ;           (* the hard part *)

very much like (window-tree)?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Window configurations

[martin rudalics]

 >> Users "define" window configurations by splitting and deleting windows.
 >> They have no idea of the underlying window tree.
 >
 > I'm not sure that's right.  While users certainly don't know about
 > `frame-root-window' windows, the tree is otherwise readily apparent
 > (since, for instance, resizing or deleting a window distinguishes
 >
 > +-+-+     +-+-+
 > |A|B|     |A|B|
 > +-|-+ and +---+
 > |C|D|     |C|D|
 > +-+-+     +-+-+
 >
 > in an immediately obvious fashion).

Yes.  But by merey looking at these configuration you can't tell the
difference.

 > Why not store a configuration as a
 > (resolution-independent) tree:
 >
 > subtree = window | tree ;
 > tree = "(", horiz, subtree, split, { split }, ")" ;
 > split = fraction, subtree ;
 > horiz = nil | t ;            (* t for C-x 3 *)
 > fraction = ? float ? ;
 > window = ? ... ? ;           (* the hard part *)

That's more or less what I proposed earlier: All I need for the current,
tiling window-manager based on window-trees is the type of the split
(horizontal or vertical) and the fraction occupied by a window wrt to
its parent window.  This implies, however, that an overlapping manager
processing such a structure must be able to understand window trees.

martin

Re: Window configurations

[Stefan Monnier]

> That's more or less what I proposed earlier: All I need for the current,
> tiling window-manager based on window-trees is the type of the split
> (horizontal or vertical) and the fraction occupied by a window wrt to
> its parent window.  This implies, however, that an overlapping manager
> processing such a structure must be able to understand window trees.

I think we should not pay attention to overlapping-windows for the
format.  If we ever add overlapping-windows, it'll be very easy then to
add backward-compatibility support for the tree format.  So a simple
tree with direction+fraction will work just fine.


        Stefan

Re: Window configurations

[Juri Linkov]

> Why not store a configuration as a (resolution-independent) tree:
>
> subtree = window | tree ;
> tree = "(", horiz, subtree, split, { split }, ")" ;
> split = fraction, subtree ;
> horiz = nil | t ;            (* t for C-x 3 *)
> fraction = ? float ? ;
> window = ? ... ? ;           (* the hard part *)
>
> very much like (window-tree)?

A window-tree format is good for androids.  But for human beings it is
too complicated.  Please see how ECB defines window configurations as
a plain list of function calls because it is more simple and convenient
for human users:

  (ecb-set-directories-buffer)
  (ecb-split-ver 0.3)
  (ecb-set-sources-buffer)
  (ecb-split-ver 0.5)
  (ecb-set-methods-buffer)
  (select-window (previous-window))
  (ecb-split-hor 0.5)
  (ecb-set-history-buffer)

But this format has one drawback - it is procedural.

Using a declarative, more general and future-proof format:

  (window A
    (buffer . A))
  (window B
    (buffer . B)
    (left-window . A))
  (window C
    (buffer . C)
    (top-window . A))
  (window D
    (buffer . D)
    (top-window . B)
    (left-window . C))

will create

  +-+-+
  |A|B|
  +---+
  |C|D|
  +-+-+

and with a different order of window definitions:

  (window A
    (buffer . A))
  (window C
    (buffer . C)
    (top-window . A))
  (window B
    (buffer . B)
    (left-window . A))
  (window D
    (buffer . D)
    (top-window . B)
    (left-window . C))

will create

  +-+-+
  |A|B|
  +-|-+
  |C|D|
  +-+-+

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

Re: Window configurations

[Davis Herring]

> A window-tree format is good for androids.  But for human beings it is
> too complicated.  Please see how ECB defines window configurations as
> a plain list of function calls because it is more simple and convenient
> for human users:
>
>   (ecb-set-directories-buffer)
>   (ecb-split-ver 0.3)
>   (ecb-set-sources-buffer)
>   (ecb-split-ver 0.5)
>   (ecb-set-methods-buffer)
>   (select-window (previous-window))
>   (ecb-split-hor 0.5)
>   (ecb-set-history-buffer)

Perhaps then I am an android.  I look at that code and it takes me quite a
while to decide that the window-tree it produces (as I defined it) is (I
think)

(nil #<methods> 0.15 #<sources> 0.3 (t #<history> 0.5 #<directories>))

...assuming that ecb-split-{ver,hor} is just C-x {2,3} with the divide
placed the argument fraction of the way {down,right} the original window. 
On the other hand I find interpreting the window-tree easy because I can
just read it rather than tracing through it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Window configurations

[Juri Linkov]

> Perhaps then I am an android.  I look at that code and it takes me quite a
> while to decide that the window-tree it produces (as I defined it) is (I
> think)
>
> (nil #<methods> 0.15 #<sources> 0.3 (t #<history> 0.5 #<directories>))

The problem is that the internal structure with the window configuration
is a list.  So when exposed to Lisp, it should be a Lisp list.

It you want a tree, it's possible to write a Lisp function
that converts a window list to a window tree, e.g.

  (window-configuration-to-tree
    (window-configuration-to-list
      (current-window-configuration)))

where `window-configuration-to-list' is a C function that
exposes #<window-configuration> to Lisp as a list like

  (window-configuration
   (frame-cols . 194)
   (frame-lines . 77)
   (root-window . #<window 16>)
   (windows
     (window
      (window . #<window 16>)
      (left-col . 0)
      (top-line . 5)
      (total-cols . 200)
      (total-lines . 71))
     (window
      (window . #<window 3 on *scratch*>)
      (parent . 0)
      (left-col . 0)
      (top-line . 5)
      (total-cols . 100)
      (total-lines . 71))
     (window
      (window . #<window 18>)
      (parent . 0)
      (prev . 1)
      (left-col . 100)
      (top-line . 5)
      (total-cols . 100)
      (total-lines . 71))
     (window
      (window . #<window 17 on *info*>)
      (parent . 2)
      (left-col . 100)
      (top-line . 5)
      (total-cols . 100)
      (total-lines . 35))
     (window
      (window . #<window 19 on *Messages*>)
      (parent . 2)
      (prev . 3)
      (left-col . 100)
      (top-line . 40)
      (total-cols . 100)
      (total-lines . 36))
     (window
      (window . #<window 4 on  *Minibuf-0*>)
      (prev . 0)
      (left-col . 0)
      (top-line . 76)
      (total-cols . 200)
      (total-lines . 1))))

and `window-configuration-to-tree' is a Lisp function that converts it
to a window-tree.

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

Re: Window configurations (was: Gtk tabs in emacs, new branch)

[Ken Hori]

Juri,

Could we add as an extra `buffer-file-name' alist element in the sexp
of a window-configuration or is that a bad idea? (I was just tring to
reconstruct a window-configuration after an emacs reboot but quickly
found out filenames weren't just there.)


On Sun, Apr 25, 2010 at 11:33 AM, Juri Linkov <juri@jurta.org> wrote:
>>> ... Currently the design
>>> is at the stage of deciding what format is better to represent the
>>> window configuration.  There are two options: a window tree and
>>> a plain list of windows.  I am inclined to the second option
>>> since when saved it would be more compact.
>>
>> There's absolutely no need to make window configurations saved by
>> `current-window-configuration' (I call them CWCs here) and window
>> configurations saved for later reconstruction in a possibly different
>> session (called EWCs) save the same states of things.
>
> Yes.  That's why I added a new argument `live-p' to
> `current-window-configuration-to-sexp'.  When non-nil, it adds live data
> (window objects, buffer objects, markers, etc.) that are necessary
> when its Lisp expression will be used in the same session.  When nil,
> it returns bare minimum necessary to save and restore in another session.
>
>> EWCs should IMHO strip window configurations to the absolutely needed
>> bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
>> more harm than good in EWCs (BTW, I've completely done away with these
>> in my rewrite of window.c)
>
> Do you plan to create a branch for your rewrite of window.c?
> It would be very interesting to look at it.
>
>> Coordinates should probably be rather stored as fractions instead of
>> absolute lines and columns.  This would make it easier to (1) eventually
>> switch to pixel based coordinates and (2) put an EWC into an Emacs
>> window (that is, put an Emacs frame into an Emacs window) as some IDE
>> advocats mentioned earlier.
>
> There are no problems with storing coordinates as absolute lines and
> columns.  After restoring absolute coordinates `set-window-configuration'
> resizes the frame thus keeping original relative sizes unchanged.
>
>> Since I suppose you're running `split-window' to restore configurations
>> you'd probably also want to remember whether a "split" was a vertical or
>> a horizontal one in EWCs.  Note that CWCs don't do this since they need
>> to restore the configuration from the stored "coordinates" anyway, but
>> the design is a bit awkward as code like
>>
>>  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
>>
>> in `set-window-configuration' shows.
>
> No, I don't use `split-window'.  I use exactly the same algorithm as in
> `set-window-configuration', and additionally make new windows.
> In my tests, this works correctly.
>
>> That said, the *entire* coordinate information of a particular window in
>> an EWC would consist of (1) whether it is a horizontal or a vertical
>> combination and (2) the proportional space - either a float or the
>> fraction of "some largest integer" - occupied by the window wrt to its
>> parent window.
>
> Currently `set-window-configuration-from-sexp' works without these
> parameters.  But maybe they would be useful for user-defined window
> configurations.
>
>> BTW in the earlier example structure you posted here I'm missing entries
>> for window-point, window-start, ...  Was that intentional?
>
> There are entries `pointm' and `start' in the output of of the really
> working function `current-window-configuration-to-sexp'.
>
> But the example of the output of `window-configuration-to-sexp' is for
> demonstration purposes only.  It doesn't work yet, because I'm not sure yet
> whether it's better than `current-window-configuration-to-sexp'.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>
>
>

Re: Window configurations

[Stefan Monnier]

> Could we add as an extra `buffer-file-name' alist element in the sexp
> of a window-configuration or is that a bad idea? (I was just tring to
> reconstruct a window-configuration after an emacs reboot but quickly
> found out filenames weren't just there.)

For saving/restoring, we'll probably need to save the same info used
by bookmark.el or desktop.el (unifying the two might also be a good
idea, BTW).


        Stefan

Re: Window configurations

[Juri Linkov]

>> Could we add as an extra `buffer-file-name' alist element in the sexp
>> of a window-configuration or is that a bad idea? (I was just tring to
>> reconstruct a window-configuration after an emacs reboot but quickly
>> found out filenames weren't just there.)
>
> For saving/restoring, we'll probably need to save the same info used
> by bookmark.el or desktop.el (unifying the two might also be a good
> idea, BTW).

Since bookmark.el is conceptually more low-level than desktop.el,
the latter could use a subset of services provided by bookmarks.

There is one problem of using bookmark records for desktop.el.
Some bookmarks take too much time to restore when reading from the desktop
file.  So packages will need to distinguish between making a bookmark for
bookmark.el or desktop.el to not save some bookmarks in the desktop file.
Maybe `bookmark-make-record-function' will require a new argument for that.

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

RE: Window configurations

[Drew Adams]

> >> Could we add as an extra `buffer-file-name' alist element
> >> in the sexp of a window-configuration or is that a bad idea?
> >> (I was just tring to reconstruct a window-configuration
> >> after an emacs reboot but quickly found out filenames
> >> weren't just there.)
> >
> > For saving/restoring, we'll probably need to save the same info used
> > by bookmark.el or desktop.el (unifying the two might also be a good
> > idea, BTW).
> 
> Since bookmark.el is conceptually more low-level than desktop.el,
> the latter could use a subset of services provided by bookmarks.
> 
> There is one problem of using bookmark records for desktop.el.
> Some bookmarks take too much time to restore when reading 
> from the desktop file.  So packages will need to distinguish
> between making a bookmark for bookmark.el or desktop.el to not
> save some bookmarks in the desktop file. Maybe
> `bookmark-make-record-function' will require a new argument for that.

Sigh. I really wish you guys wouldn't mess with this. Put what you want in a
window config, but please do not try "unifying" bookmarks and desktops (and
window configs).

If anything, bookmarks are more general and higher-level (not lower-level) than
desktops. Why? Because you can save/restore many different types of things as
bookmarks, each in its own way. Each can have its own handler.

Anything can be bookmarked. A desktop records one type of thing: a desktop, no
matter what you might want to stuff into a desktop, no matter how complex it is.

If you want to add handlers or other bells and whistles to desktops, go for it,
but please do not try to merge bookmarks and desktops as if they were the same
thing or one were an instance or a subset of the other. They both record state
persistently and restore it; that's all. There is no reason to confuse the
concepts or merge the code.

On the other hand, a desktop can be targeted as one kind of bookmark - a
bookmark can restore a desktop just as it can restore an Info node. That is the
case in bookmark+.el, for example. But it does not make sense to record all of
the info for a desktop directly in the bookmark (and thus in a bookmark file,
which can contain _lots_ of bookmarks).

What makes sense is for a desktop bookmark to simply refer to a particular
desktop file, which records the desktop info. Likewise, for a window-config
bookmark. (I'm still hoping you will not hard-couple window-configs and desktops
- each can be used independently of the other, as well as together.)

Nor does it make much sense to add bookmark records to a desktop file. I don't
know what kind of bookmark "info" or bookmark "services" you think would be
required by desktops. Do you plan on adding handlers to desktops? Whatever. Add
whatever you must to window-config records or desktop records, but please keep
bookmarks separate from them both.

Keep things simple and separate, so users and programmers can easily combine
them at will in various ways. Just give us a way to save and restore window
configs, and we can always combine that (or not) with saving and restoring
desktops. And we can always create a bookmark to either.

Please do not start "unifying" everything into one big ball of knots.

Wrt generalizing and improving _bookmarking_, which is a different topic from
making window configs persistent and restorable, see bookmark+.el. All of that
improvement could be added to Emacs, as a patch to bookmark.el. (No, I don't
want to argue about it. If you don't want it, that's fine.)
http://www.emacswiki.org/emacs/BookmarkPlus

Bookmarking is about saving and restoring something - anything. It is therefore
about handling different kinds of stateful things differently. To improve
bookmarking, work on making it easy for users to distinguish and access the
various types, provide type-specific UI features and help, and so on.

Forget about constructing the uber unifying
bookmark-cum-desktop-cum-window-config cathedral. Please. The goal should be
separate Lego blocks of different shapes that fit together, not a big wad of
fused plastic.

Re: Window configurations

[Stefan Monnier]

>> There is one problem of using bookmark records for desktop.el.
>> Some bookmarks take too much time to restore when reading
>> from the desktop file.

Juri, do you have more details on this?  I don't know of this problem.

> Sigh. I really wish you guys wouldn't mess with this. Put what you want in a
> window config, but please do not try "unifying" bookmarks and desktops (and
> window configs).

Noone's trying to unify the two: desktop.el uses internally
a representation of "the content and position of a given buffer" to be
able to reproduce it later, and as it turns out, this is the exact same
problem that bookmark tries to solve.  So it might make sense for
desktop.el to use bookmarks for that internal thingy.

I'm not 100% positive it does since the purpose is slightly different
(e.g. a bookmark is expected to be useful for a potentially long period
of time during which the file referenced might be modified many times,
so bookmark doesn't just record the buffer position but also some
context so as to find the same spot even if it's not at the same line
number any more.  It's probably less important for desktop.el).


        Stefan

Re: Window configurations

[Juri Linkov]

>>> There is one problem of using bookmark records for desktop.el.
>>> Some bookmarks take too much time to restore when reading
>>> from the desktop file.
>
> Juri, do you have more details on this?  I don't know of this problem.

Currently, Info mode doesn't save/restore virtual Info nodes to the
desktop file at all.  Even `dir' is not saved (which is a virtual file now).

The patch I sent on 2010-04-27 allows Info-desktop-buffer-misc-data
to save all virtual nodes to the desktop, except Info-apropos.
Info-apropos takes too much time to create a node with the search results.
So restoring an Info-apropos node from the desktop file would be
unacceptably slow.

One variant is to save the apropos search results as text in the desktop file,
but then it will grow too big.

There is no such problem for bookmarks because when the user decides
to restore a bookmark for an Info-apropos node, then the user is ready
to wait until this Info node is created and displayed.

> Noone's trying to unify the two: desktop.el uses internally
> a representation of "the content and position of a given buffer" to be
> able to reproduce it later, and as it turns out, this is the exact same
> problem that bookmark tries to solve.  So it might make sense for
> desktop.el to use bookmarks for that internal thingy.
>
> I'm not 100% positive it does since the purpose is slightly different
> (e.g. a bookmark is expected to be useful for a potentially long period
> of time during which the file referenced might be modified many times,
> so bookmark doesn't just record the buffer position but also some
> context so as to find the same spot even if it's not at the same line
> number any more.  It's probably less important for desktop.el).

There is another package that could benefit from the functionality of
bookmark.el - saveplace.el that saves places in files.  For instance,
when I put point on the `* Elisp: (elisp)' line in `dir', kill the
*info* buffer, and type `C-h i' again, then I'd like if point was
on the same `* Elisp: (elisp)' line.

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

Re: Window configurations

[Stefan Monnier]

> The patch I sent on 2010-04-27 allows Info-desktop-buffer-misc-data
> to save all virtual nodes to the desktop, except Info-apropos.
> Info-apropos takes too much time to create a node with the search results.
> So restoring an Info-apropos node from the desktop file would be
> unacceptably slow.
[...]
> There is no such problem for bookmarks because when the user decides
> to restore a bookmark for an Info-apropos node, then the user is ready
> to wait until this Info node is created and displayed.

Thanks, that makes sense.  So maybe the bookmark data should include
some `slow' tag of some sort if we want to use it for desktop.el.

> There is another package that could benefit from the functionality of
> bookmark.el - saveplace.el that saves places in files.  For instance,
> when I put point on the `* Elisp: (elisp)' line in `dir', kill the
> *info* buffer, and type `C-h i' again, then I'd like if point was
> on the same `* Elisp: (elisp)' line.

Of course.  The stack of *Help* topics is another one that could use it.


        Stefan

Re: Window configurations

[Juri Linkov]

>> There is no such problem for bookmarks because when the user decides
>> to restore a bookmark for an Info-apropos node, then the user is ready
>> to wait until this Info node is created and displayed.
>
> Thanks, that makes sense.  So maybe the bookmark data should include
> some `slow' tag of some sort if we want to use it for desktop.el.

A `slow' tag in the bookmark record would be useful not only for
desktop.el.  `bookmark-jump' could warn the user that restoring
the bookmark might take some time.

>> There is another package that could benefit from the functionality of
>> bookmark.el - saveplace.el that saves places in files.  For instance,
>> when I put point on the `* Elisp: (elisp)' line in `dir', kill the
>> *info* buffer, and type `C-h i' again, then I'd like if point was
>> on the same `* Elisp: (elisp)' line.
>
> Of course.  The stack of *Help* topics is another one that could use it.

And `Info-history' as well.  (Info and Help are another candidates for
unification.)

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

Re: Window configurations

[Stephen J. Turnbull]

Juri Linkov writes:

 > A `slow' tag in the bookmark record would be useful not only for
 > desktop.el.

Isn't the usual term for this "lazy", as in "lazy evaluation"?

Re: Window configurations

[Stefan Monnier]

>> A `slow' tag in the bookmark record would be useful not only for
>> desktop.el.
> Isn't the usual term for this "lazy", as in "lazy evaluation"?

I don't think so.  At least the the way I intend this `slow' to work: it
would simply indicate that fetching the corresponding bookmark can take
an unusually high amount of time.

Now, the users of that bookmark (e.g. desktop.el or the user) can then
make their own decision about how to handle such bookmarks, maybe
desktop could try and fetch them lazily indeed (e.g. delay fetching them
until the corresponding buffer is displayed).


        Stefan

Re: Window configurations

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >> A `slow' tag in the bookmark record would be useful not only for
 > >> desktop.el.
 > > Isn't the usual term for this "lazy", as in "lazy evaluation"?
 > 
 > I don't think so.  At least the the way I intend this `slow' to work: it
 > would simply indicate that fetching the corresponding bookmark can take
 > an unusually high amount of time.

Ah, so it's a measure of cost to do a certain "primitive" operation.
That makes sense.

Re: Window configurations

[Juri Linkov]

>> Thanks, that makes sense.  So maybe the bookmark data should include
>> some `slow' tag of some sort if we want to use it for desktop.el.
>
> A `slow' tag in the bookmark record would be useful not only for
> desktop.el.  `bookmark-jump' could warn the user that restoring
> the bookmark might take some time.

I added a `slow' tag to the desktop record (not to the bookmark record yet)
as the first step.

Unifying desktop.el and bookmark.el has more problems:

1. Backward compatibility, i.e. existing desktop files should still load
fine even when newer desktop files will contain bookmark records.

2. Data duplication: the bookmark record contains `position' and
the desktop record has the same info for `point'.  (I suppose
the bookmark record should go to the 8-th element of the desktop data,
i.e. to the `desktop-save-buffer' element).

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

Re: Window configurations

[Juri Linkov]

> Could we add as an extra `buffer-file-name' alist element in the sexp
> of a window-configuration or is that a bad idea? (I was just tring to
> reconstruct a window-configuration after an emacs reboot but quickly
> found out filenames weren't just there.)

I think that information about file names is redundant.

To restore file buffers in windows of the saved window configuration,
you can prepare buffers (open files, call packages that create special
buffers, etc.), keep their buffer objects and use them later during
restoring the saved window configuration.  For instance,

(setq buffer1 (find-file-noselect "file1.txt"))
(setq buffer2 (find-file-noselect "file2.txt"))

(set-window-configuration-from-list
  '(window-configuration
     (frame-cols . 80)
     (frame-lines . 41)
     (window
       (buffer . buffer1)
       (left-col . 0)
       (top-line . 5)
       (total-cols . 86)
       (total-lines . 35)
       ...)
     (window
       (buffer . buffer2)
       (left-col . 0)
       (top-line . 5)
       (total-cols . 86)
       (total-lines . 35)
       ...)))

This is basically what desktop.el does: it restores buffers, and later
it can restore window configurations using restored buffer names.

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

Re: Window configurations

[Ken Hori]

Juri,

My point was that you wound't be able to open a file without
knowing buffer-file-name once emacs gets closed. In particular,
if a window-configuration-sexp doesn't contain such a thing as
buffer-file-name, you wound't be able to reconstruct

> (setq buffer1 (find-file-noselect "<file-path>"))

since <file-path> gets lost upon exit. Of course you can
store <file-path> for each file buffer "somewhere", but I
thought the point of having window-configuration-sexp's is to
save that kind of extra work and provide a canonical way of
restoring frame states.

I was hoping that ideally emacs would hold buffer-file-name's in
the sexp and let the user specify a "buffer-recovery-function" to
recover a frame state as well as buffers, so that, hypothetically,

(restore-window-configuration-from-sexp
  a-window-configuration-sexp 'live-p  #'find-file-noselect)

would restore buffers as well as a window configuration.


On Sun, May 2, 2010 at 1:28 PM, Juri Linkov <juri@jurta.org> wrote:
>> Could we add as an extra `buffer-file-name' alist element in the sexp
>> of a window-configuration or is that a bad idea? (I was just tring to
>> reconstruct a window-configuration after an emacs reboot but quickly
>> found out filenames weren't just there.)
>
> I think that information about file names is redundant.
>
> To restore file buffers in windows of the saved window configuration,
> you can prepare buffers (open files, call packages that create special
> buffers, etc.), keep their buffer objects and use them later during
> restoring the saved window configuration.  For instance,
>
> (setq buffer1 (find-file-noselect "file1.txt"))
> (setq buffer2 (find-file-noselect "file2.txt"))
>
> (set-window-configuration-from-list
>  '(window-configuration
>     (frame-cols . 80)
>     (frame-lines . 41)
>     (window
>       (buffer . buffer1)
>       (left-col . 0)
>       (top-line . 5)
>       (total-cols . 86)
>       (total-lines . 35)
>       ...)
>     (window
>       (buffer . buffer2)
>       (left-col . 0)
>       (top-line . 5)
>       (total-cols . 86)
>       (total-lines . 35)
>       ...)))
>
> This is basically what desktop.el does: it restores buffers, and later
> it can restore window configurations using restored buffer names.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>

Re: Window configurations

[Juri Linkov]

> My point was that you wound't be able to open a file without
> knowing buffer-file-name once emacs gets closed. In particular,
> if a window-configuration-sexp doesn't contain such a thing as
> buffer-file-name, you wound't be able to reconstruct
>
>> (setq buffer1 (find-file-noselect "<file-path>"))
>
> since <file-path> gets lost upon exit. Of course you can
> store <file-path> for each file buffer "somewhere", but I
> thought the point of having window-configuration-sexp's is to
> save that kind of extra work and provide a canonical way of
> restoring frame states.

The point of set-window-configuration-from-sexp is to restore the
configuration of windows, not to duplicate the functionality of desktop.el.

> I was hoping that ideally emacs would hold buffer-file-name's in
> the sexp and let the user specify a "buffer-recovery-function" to
> recover a frame state as well as buffers, so that, hypothetically,
>
> (restore-window-configuration-from-sexp
>   a-window-configuration-sexp 'live-p  #'find-file-noselect)
>
> would restore buffers as well as a window configuration.

It is the purpose of desktop.el to save and restore buffers.
It provides a special "hook" `desktop-save-buffer' where packages
can save their buffer info to be able to restore them later.

If you don't want to use desktop.el, perhaps you could take a look
at bookmark.el.

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

Re: Window configurations

[martin rudalics]

 > The point of set-window-configuration-from-sexp is to restore the
 > configuration of windows, not to duplicate the functionality of desktop.el.

That's true from a theoretical point of view.  It separates concerns in
a clear way and gives clean semantics.  Hence I fully agree with you.

Unfortunately, in personal practice, I'm suffering from a quite similar
problem.  In particular, I display eldoc output on a per-window basis in
a one-line window below the code window (I hate eldoc output in the echo
area, I don't like it in the header line, and I very much hate tooltips.
Ideally, there would be a bottom-line right above the mode-line where I
could put it, but ...).

Now I'm killing such an eldoc-buffer as soon as it is no more shown in
its eldoc-window.  But when (1) a `save-window-excursion' restores the
saved configuration and (2) it has to restore a former eldoc-window that
was deleted within the body of `save-window-excursion', I get the first
buffer from `buffer-list' shown in that window which is downright silly.

I solved my problem by killing such stale eldoc-windows after the
configuration gets restored in a `window-configuration-change-hook'.
This is, however, a slight redisplay pain, in particular with such
niceties as (save-window-excursion (info)) in `info-lookup'.  I maybe
could come up with a satisfactory solution, but deleting and creating
windows in `window-configuration-change-hook' is error-prone :-(

So if we could hook into this in some way, for example by providing a
window parameter that tells `set-window-configuration(-from-sexp)' what
to do if the buffer no longer exists, that might not be a bad idea.

If the buffer had a `buffer-file-name', we could try to regenerate it
automatically from that name.  If the file was deleted in the meantime
(or is remote or hard to find), some warning message could be displayed
in a temporary buffer in the restored window.  Looking up a file via
bookmarks could happen here as well.

If the buffer was not associated with a file, we could try to regenerate
it based on the old name stored in the parameter.  For killed *info* and
*help* buffers probably more information would be required.  All this
would happen independently from desktop.el in the session version and in
the sexp version.

And, as noted above, this idea is not based on clean semantics but on
running into practical issues.

martin

Re: Window configurations

[Juri Linkov]

> But when (1) a `save-window-excursion' restores the saved
> configuration and (2) it has to restore a former eldoc-window that was
> deleted within the body of `save-window-excursion', I get the first
> buffer from `buffer-list' shown in that window which is
> downright silly.

I agree that displaying a random buffer (that happens to be the first
in `buffer-list') is silly.  This problem becomes more evident when
switching window configuration using tabs.

Let's summarize options we have to display when the buffer saved in
a window configuration is gone:

0. Display the first buffer from `buffer-list'.  Yes, this is silly.

1. Add a bookmark record (that may include `buffer-file-name' and other
   additional data from packages via `bookmark-make-record-function')
   to the window parameters in the window-configuration structure.
   After restoring the window configuration, try to regenerate it.

   I think this is a bad idea, because when the user deletes the buffer,
   and after switching to another window configuration this buffer
   automagically comes back, it would be annoying.

2. Delete the buffer's window after restoring the saved window configuration.

   Do you see any problem with doing this in `set-window-configuration'
   instead of `window-configuration-change-hook'?

3. Delete the buffer's window in the saved window configuration
   before restoring it.

   This looks good if it won't break other windows in the same
   window configuration.

4. Display some warning message in a temporary buffer in the
   restored window.

   This is good too.  It keeps the original window configuration unchanged,
   and provides information about the deleted buffers.


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

Re: Window configurations

[martin rudalics]

 > 2. Delete the buffer's window after restoring the saved window configuration.
 >
 >    Do you see any problem with doing this in `set-window-configuration'
 >    instead of `window-configuration-change-hook'?

Since window configurations store coordinates it would have to be done
just before the place where `window-configuration-change-hook' is called
in `set-window-configuration'.  So the effect would be roughly the same.
It's not perfect since the windows showing deleted buffers might take up
the entire frame.

 > 3. Delete the buffer's window in the saved window configuration
 >    before restoring it.
 >
 >    This looks good if it won't break other windows in the same
 >    window configuration.

Hardly doable.  Note that we might also have to delete internal windows,
adjust coordinates or fractions ...

 > 4. Display some warning message in a temporary buffer in the
 >    restored window.
 >
 >    This is good too.  It keeps the original window configuration unchanged,
 >    and provides information about the deleted buffers.

Suitable for user created windows.  Not suitable for windows created
automatically.

What I really want is some sort of function `set-window-configuration'
could call whenever it encounters a window with a dead buffer.  As a
fallback it then would try your (2) first and (4) if the window can't be
deleted.

martin

Re: Window configurations

[Juri Linkov]

> What I really want is some sort of function `set-window-configuration'
> could call whenever it encounters a window with a dead buffer.  As a
> fallback it then would try your (2) first and (4) if the window can't be
> deleted.

Yes, a new function would be good.  If it can't delete the window,
then it could display a virtual buffer with the text like
"The buffer `kilroy.el' was here" and a button to restore
the killed buffer.

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

Re: Window configurations

[Juri Linkov]

> What I really want is some sort of function `set-window-configuration'
> could call whenever it encounters a window with a dead buffer.  As a
> fallback it then would try your (2) first and (4) if the window can't be
> deleted.

Thinking more about this, I believe now this function should be
like `view-mode-exit':

  (view-mode-exit &optional RETURN-TO-ALIST EXIT-ACTION ALL-WIN)

  Exit View mode in various ways, depending on optional arguments.
  RETURN-TO-ALIST, EXIT-ACTION and ALL-WIN determine what to do
  after exit.  EXIT-ACTION is nil or a function that is called with
  current buffer as argument.

  RETURN-TO-ALIST is an alist that, for some of the windows
  displaying the current buffer, maintains information on what to
  do when exiting those windows.  If ALL-WIN is non-nil or the
  variable `view-exits-all-viewing-windows' is non-nil,
  view-mode-exit attempts to restore all windows showing the
  current buffer to their old state.  Otherwise, only the selected
  window is affected (provided it is on RETURN-TO-ALIST).

  Elements of RETURN-TO-ALIST must have the format
    (WINDOW OLD-WINDOW . OLD-BUF-INFO) where

  WINDOW is a window displaying the current buffer and OLD-WINDOW
  is either nil or a window to select after viewing.  OLD-BUF-INFO
  provides information on what to do with WINDOW and may be one of:
  1) nil            Do nothing.
  2) t              Delete WINDOW and, if it is the only window and
                    `view-remove-frame-by-deleting' is non-nil, its
                    frame.
  3) (OLD-BUF START POINT)  Display buffer OLD-BUF with displayed text
                    starting at START and point at POINT in WINDOW.
  4) quit-window    Do `quit-window' in WINDOW.
  5) keep-frame     Like case 2) but do not delete the frame.

  If one of the WINDOW in RETURN-TO-ALIST is the selected window
  and the corresponding OLD-WINDOW is a live window, then select
  OLD-WINDOW.

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

Re: Window configurations

[martin rudalics]

 > Thinking more about this, I believe now this function should be
 > like `view-mode-exit':

I had something like this in mind.  BTW, I have rewritten this code in
the meantime using a window parameter called `quit-restore'.  From a
preliminary description ...

    The `quit-restore' parameter tells how to proceed with a window when
the user "quits" it by invoking `quit-restore-window', see *Note
Displaying Buffers::.  The following non-`nil' values of this parameter
have a special meaning.

`t'
      This means to delete the associated window.  By default, `t' is
      used for a "temporary" window that was obtained by splitting an
      existing window.

`frame'
      This means to delete the associated window's frame.  This value
      indicates that the associated windows was obtained by popping up a
      new frame showing just this window.  If the window is no more
      needed, it should be deleted together with the containing frame.

A list
      This option is useful when the associated window was borrowed to
      temporarily display some buffer and quitting shall "restore" the
      previous contents of the window.  The first three elements of the
      list must specify a buffer, a window start position, and a window
      point.  Quitting the window will then try to display the indicated
      buffer with the given start position and point in that window.

      The fourth element, if non-`nil', must denote a live buffer.  If
      specified, quitting will restore the previous window contents if
      and only if the buffer shown in the window is the buffer named by
      this element.

      The fifth element, if non-`nil', should specify the desired height
      of the window when its buffer is restored.  This value is applied
      if the buffer temporarily shown in the window was in
      `temp-buffer-resize-mode' to restore the original height of the
      window.

... and the description of `quit-restore-window' goes like ...

    The command described next allows to quit the window chosen by
`display-buffer' and restore the previous state without undoing changes
to the window configuration that happend _after_ `display-buffer' was
called.  A more drastic solution is to save the window configuration
before calling `display-buffer' and eventually restoring the saved
configuration, *Note Window Configurations::.  That solution sometimes
has the undesirable side-effect that all changes that happened after
the configuration was saved are undone too.

  -- Command: quit-restore-window &optional window kill
      This command "quits" WINDOW restoring its previous contents if
      possible.  The argument WINDOW must be a live window and defaults
      to the selected one.  This function always returns `nil'.

      According to information stored in WINDOW's `quit-restore' window
      parameter (*note Window Parameters::) this function performs one
      of the following actions.

         * Delete WINDOW and its frame.  This action is useful when
           WINDOW was created on a standalone frame and there are other
           frames left.

         * Delete WINDOW.  This action is usually taken when WINDOW was
           obtained by splitting some existing window.

         * Restore the buffer previously displayed in WINDOW.  This
           action is taken when WINDOW was temporarily reused for
           displaying some other buffer.

         * Make WINDOW display some other buffer.  This action is usually
           taken when the three preceding ones are not applicable.

      If its value was non-`nil', this function resets WINDOW's
      `quit-restore' parameter to `nil'.

      If the optional argument KILL is non-`nil', this means in addition
      kill WINDOW's buffer.  If KILL is `nil', this simply puts WINDOW's
      buffer at the end of the buffer list.  Interactively, KILL is the
      prefix argument.

... where `quit-restore-window' here replaces `quit-window' which has
too obscure semantics for my taste.  And obviously, exiting `view-mode'
calls `quit-restore-window' here too.

However, restoring a window configuration is a more primitive operation
than exiting `view-mode'.  One of the most hairy situation occurs when
you kill a buffer: There's a window of vulnerability when the
`kill-buffer' routine calls `replace_buffer_in_all_windows' and the
latter, for some reason, doesn't do what it has been told, for example,
because a `window-configuration-change-hook' shows the buffer to be
killed in some other window.  Obviously, doing things like that in a
configuration change hook is foolish as in

(get-buffer-create "*foo*")

(defun foo-lish ()
   (let (window-configuration-change-hook)
     (set-window-buffer (frame-first-window) "*foo*")))

(add-hook 'window-configuration-change-hook 'foo-lish)

and now doing (kill-buffer "*foo*").  But I'm not sure whether there are
useful things a `window-configuration-change-hook' could do along these
lines.

martin

Re: Window configurations

[Juri Linkov]

> ... where `quit-restore-window' here replaces `quit-window' which has
> too obscure semantics for my taste.  And obviously, exiting `view-mode'
> calls `quit-restore-window' here too.

Yes, `quit-window' is useless because it doesn't help to avoid the mess
that occurs after killing buffers.  Please look at two examples:

1.

+---------+---------+
|         |         |
| dired 1 | dired 2 |
|         |         |
|         |         |
+---------+---------+

Now view a file in dired 1, select the second window, view another file
in dired 2, select the first window, quit view-mode with `q',
select the second window, quit view-mode with `q':

  `v  C-x o  v  C-x o  q  C-x o  q'

The window configuration is exactly as was before - very good.

Now do the same without using `view-mode' - visit a file in dired 1 with
RET, select the second window, visit another file in dired 2, select the
first window, kill the buffer, select the second window, kill the buffer:

  `RET  C-x o  RET  C-x o  C-x k  C-x o  C-x k'

The window configuration is broken with original buffers exchanged
their windows:

+---------+---------+
|         |         |
| dired 2 | dired 1 |
|         |         |
|         |         |
+---------+---------+

2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.


It seems your implementation of `quit-restore-window' will fix this problem,
but I don't see how it will work without a window history as a list?
This list could be saved as a window parameter `window-history' where each
element is like you implemented for the `quit-restore' parameter.

Then every switch-to-buffer could add a `quit-restore' element to the
window history parameter, and every kill-buffer could remove it from the
history stack (and call its function at the same time).

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

Re: Window configurations

[martin rudalics]

 >> ... where `quit-restore-window' here replaces `quit-window' which has
 >> too obscure semantics for my taste.  And obviously, exiting `view-mode'
 >> calls `quit-restore-window' here too.
 >
 > Yes, `quit-window' is useless because it doesn't help to avoid the mess
 > that occurs after killing buffers.

You don't mean buffers killed by `quit-window' but by some standalone
`kill-buffer' I suppose?

 > Now do the same without using `view-mode' - visit a file in dired 1 with
 > RET, select the second window, visit another file in dired 2, select the
 > first window, kill the buffer, select the second window, kill the buffer:
 >
 >   `RET  C-x o  RET  C-x o  C-x k  C-x o  C-x k'
 >
 > The window configuration is broken with original buffers exchanged
 > their windows:
 >
 > +---------+---------+
 > |         |         |
 > | dired 2 | dired 1 |
 > |         |         |
 > |         |         |
 > +---------+---------+

The culprit here is the `other-buffer' call when unshowing the buffer.
Practically all occurrences of `other-buffer' in window handling code
are harmful.  Their original purpose was to make sure that the same
buffer isn't displayed twice on a frame I suppose.

 > 2. Another example - visit the same buffer in two windows, and put point
 > at different positions of the same buffer.
 >
 > +---------+---------+
 > |         |         |
 > | dired 1 | dired 1 |
 > |         |         |
 > |         |         |
 > +---------+---------+
 >
 > Now view a file in the first window, and quit: `v q'.
 > The window configuration is correctly restored
 > (without using `set-window-configuration') - good.
 >
 > Now do the same without `view-mode': `RET C-x k'.
 > Instead of the original buffer, some random buffer is displayed
 > in this window.

That's probably the most annoying instance of this.  For some magic
reason Emacs assumes that people never want to simultaneously look at
two distinct portions of the same buffer ;-)

 > It seems your implementation of `quit-restore-window' will fix this problem,
 > but I don't see how it will work without a window history as a list?

It doesn't solve any of these problems yet because `dired-find-file'
uses `switch-to-buffer' and in `switch-to-buffer' I don't record any
information about the dired buffer.  I obviously could do so easily but
we'd have to find a general agreement first.

And, for lack of a history, it works only for the last `display-buffer'
action which is sufficient for view mode purposes (by reverting to the
last buffer displayed before view mode was entered).

 > This list could be saved as a window parameter `window-history' where each
 > element is like you implemented for the `quit-restore' parameter.

Yes.  We have to agree that we pay for the costs of this though.

 > Then every switch-to-buffer could add a `quit-restore' element to the
 > window history parameter,

We'd have to enumerate all actions that would add such an element.

 > and every kill-buffer could remove it from the
 > history stack (and call its function at the same time).

`kill-buffer' would probably scan all live windows' history stacks.

But are we sure that a stack (a deque, rather) is sufficient?

martin

Re: Window configurations

[Juri Linkov]

>>> ... where `quit-restore-window' here replaces `quit-window' which has
>>> too obscure semantics for my taste.  And obviously, exiting `view-mode'
>>> calls `quit-restore-window' here too.
>>
>> Yes, `quit-window' is useless because it doesn't help to avoid the mess
>> that occurs after killing buffers.
>
> You don't mean buffers killed by `quit-window' but by some standalone
> `kill-buffer' I suppose?

I mean `quit-window' with non-nil argument KILL.  When its argument KILL
is nil (when the buffer is buried), the problem is the same.

> The culprit here is the `other-buffer' call when unshowing the buffer.
> Practically all occurrences of `other-buffer' in window handling code
> are harmful.  Their original purpose was to make sure that the same
> buffer isn't displayed twice on a frame I suppose.

Yes, and occurrences of `(car (buffer-list))' are harmful too.

> It doesn't solve any of these problems yet because `dired-find-file'
> uses `switch-to-buffer' and in `switch-to-buffer' I don't record any
> information about the dired buffer.  I obviously could do so easily but
> we'd have to find a general agreement first.
>
> And, for lack of a history, it works only for the last `display-buffer'
> action which is sufficient for view mode purposes (by reverting to the
> last buffer displayed before view mode was entered).

It is sufficient because it stores this information in the buffer-local
variable `view-return-to-alist'.  I don't think a similar variable
would help for other non-view buffers because it is specific to windows,
not to buffers.  So it seems a window parameter is more suitable.

>> Then every switch-to-buffer could add a `quit-restore' element to the
>> window history parameter,
>
> We'd have to enumerate all actions that would add such an element.

I think it should be every action that changes the window's buffer.

>> and every kill-buffer could remove it from the
>> history stack (and call its function at the same time).
>
> `kill-buffer' would probably scan all live windows' history stacks.

No need to scan all windows' history stacks.  During restoring the saved
state from the stack, we could drop elements with killed buffers and
continue popping the stack until we find an element with a live buffer.

> But are we sure that a stack (a deque, rather) is sufficient?

I think this window parameter should be treated like the frame parameter
`buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
instead of the global buffer list, etc.

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

Re: Window configurations

[martin rudalics]

 >> The culprit here is the `other-buffer' call when unshowing the buffer.
 >> Practically all occurrences of `other-buffer' in window handling code
 >> are harmful.  Their original purpose was to make sure that the same
 >> buffer isn't displayed twice on a frame I suppose.
 >
 > Yes, and occurrences of `(car (buffer-list))' are harmful too.

Obviously.  It just makes it more difficult grepping them.

 > It is sufficient because it stores this information in the buffer-local
 > variable `view-return-to-alist'.  I don't think a similar variable
 > would help for other non-view buffers because it is specific to windows,
 > not to buffers.  So it seems a window parameter is more suitable.

What I meant is this: With view-mode the variable is useful in the sense
that when I exit view-mode I get the last non-view-mode buffer shown in
that window.  For commands like "show me the last meaningful view-mode
buffer when I'm already in view mode" or "show me the last meaningful
non-view-mode buffer when I'm not in view-mode" I need a stack where to
pop that buffer from.

 >>> Then every switch-to-buffer could add a `quit-restore' element to the
 >>> window history parameter,
 >> We'd have to enumerate all actions that would add such an element.
 >
 > I think it should be every action that changes the window's buffer.

And these should all boil down to `set-window-buffer' calls.

 > No need to scan all windows' history stacks.  During restoring the saved
 > state from the stack, we could drop elements with killed buffers and
 > continue popping the stack until we find an element with a live buffer.

OK.  If we put an upper limit on the size of such stacks, stale entries
will get removed automatically after some time.

 > I think this window parameter should be treated like the frame parameter
 > `buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
 > instead of the global buffer list, etc.

We'd have to specify the meaning of "prefers" here.

martin

Re: Window configurations

[Juri Linkov]

>> I think this window parameter should be treated like the frame parameter
>> `buffer-list'.  E.g. `other-buffer' prefers selected frame's buffer list
>> instead of the global buffer list, etc.
>
> We'd have to specify the meaning of "prefers" here.

In the functions `buffer-list' and `other-buffer' the buffers in the
selected frame's `buffer-list' come first, followed by the rest of the
buffers from the global value of `buffer-list', and buffers from the
selected frame's parameters `buried-buffer-list' come last.

Doing the same for the window-local parameter `buffer-list',
i.e. when `buffer-list' will return a list composed of

 window-local buffer-list
 frame-local buffer-list
 global buffer-list
 frame-local buried-buffer-list
 window-local buried-buffer-list

then `quit-window' and all occurrences of `other-buffer'
in window handling code should do the right thing like
`view-return-to-alist' does (i.e. to get the right buffer).

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

Re: Window configurations

[martin rudalics]

 > Doing the same for the window-local parameter `buffer-list',
 > i.e. when `buffer-list' will return a list composed of
 >
 >  window-local buffer-list
 >  frame-local buffer-list
 >  global buffer-list
 >  frame-local buried-buffer-list
 >  window-local buried-buffer-list
 >
 > then `quit-window' and all occurrences of `other-buffer'
 > in window handling code should do the right thing like
 > `view-return-to-alist' does (i.e. to get the right buffer).

So I need a window-local buried-buffer-list too.  And obviously no more
stack semantics.

martin

Re: Window configurations

[Juri Linkov]

>> Doing the same for the window-local parameter `buffer-list',
>> i.e. when `buffer-list' will return a list composed of
>>
>>  window-local buffer-list
>>  frame-local buffer-list
>>  global buffer-list
>>  frame-local buried-buffer-list
>>  window-local buried-buffer-list
>>
>> then `quit-window' and all occurrences of `other-buffer'
>> in window handling code should do the right thing like
>> `view-return-to-alist' does (i.e. to get the right buffer).
>
> So I need a window-local buried-buffer-list too.  And obviously no more
> stack semantics.

Do you see a problem with that?

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

Re: Window configurations

[martin rudalics]

 >> So I need a window-local buried-buffer-list too.  And obviously no more
 >> stack semantics.
 >
 > Do you see a problem with that?

Not yet.  Just that I wouldn't store this as a window parameter but
right in the window structure.  I have to review `bury-buffer' anyway.
Currently it adds its argument to the buried-buffer-list of the selected
frame even if that buffer never appeared on it.

martin

Re: Window configurations

[martin rudalics]

 > In the functions `buffer-list' and `other-buffer' the buffers in the
 > selected frame's `buffer-list' come first, followed by the rest of the
 > buffers from the global value of `buffer-list', and buffers from the
 > selected frame's parameters `buried-buffer-list' come last.
 >
 > Doing the same for the window-local parameter `buffer-list',
 > i.e. when `buffer-list' will return a list composed of
 >
 >  window-local buffer-list
 >  frame-local buffer-list
 >  global buffer-list
 >  frame-local buried-buffer-list
 >  window-local buried-buffer-list
 >
 > then `quit-window' and all occurrences of `other-buffer'
 > in window handling code should do the right thing like
 > `view-return-to-alist' does (i.e. to get the right buffer).

I've been looking into this now.  `buffer-list' and `other-buffer' are
currently in pretty bad shape so it's occasionally difficult to tell
what they are supposed to do.  Anyway, the three major obstacles to your
approach seem:

(1) All calls to `other-buffer' for determining which buffer to show in
a window have the second argument nil.  So if a buffer is already shown
in another window it's against some unwritten rule to show it in the
window in question again.  If I follow that rule, then working with two
windows showing the same buffer remains just as tedious as it is now.

(2) The length of frame-local buffer-lists is unbound.  For a one-frame
user this already doubles the consing and maintenance overhead of buffer
lists without any gain.  If we add window-local buffer-lists, we'd
double the current overhead once more for one window/one frame users.

(3) For each buffer on the window-local buffer-list I'd have to maintain
its old point and its old window start position as markers.  Otherwise
restoring the buffer would either get me a silly position if the buffer
was modified in the meantime (a rare case probably, but unacceptable
nevertheless) or a useless position like `point' (which would usually
coincide with `window-point' of some other window showing that buffer).
This means that for each buffer we get as many additional markers as
there are live windows in which the buffer was shown (times two).

martin

Re: Window configurations

[Stefan Monnier]

> (1) All calls to `other-buffer' for determining which buffer to show in
> a window have the second argument nil.  So if a buffer is already shown
> in another window it's against some unwritten rule to show it in the
> window in question again.  If I follow that rule, then working with two
> windows showing the same buffer remains just as tedious as it is now.

Yes, the window handling code currently considers that the most likely
thing the user wants is to see a buffer that's not currently shown.
[ I'm not sure if it's careful to distinguish "shown on the current
terminal" from "shown in some other terminal, miles away from here",
which it should. ]
This seems like a good default rule, so if we/you want to not follow
this rule in some cases, we should think about how we can tell which is
the better choice in a given situation.

> (2) The length of frame-local buffer-lists is unbound.  For a one-frame
> user this already doubles the consing and maintenance overhead of buffer
> lists without any gain.  If we add window-local buffer-lists, we'd
> double the current overhead once more for one window/one frame users.

Is this overhead really significant?  Say the list is 100 buffers long,
that's 1 or 2 KB, right?  Isn't this lost in the noise?

> (3) For each buffer on the window-local buffer-list I'd have to maintain
> its old point and its old window start position as markers.  Otherwise
> restoring the buffer would either get me a silly position if the buffer
> was modified in the meantime (a rare case probably, but unacceptable
> nevertheless) or a useless position like `point' (which would usually
> coincide with `window-point' of some other window showing that buffer).
> This means that for each buffer we get as many additional markers as
> there are live windows in which the buffer was shown (times two).

The use of `point' for that has not brought many complaints over the
many years it's been used.  Any reason to think it's a bad choice?


        Stefan "who coded up a hack for doc-view which preserves
                window-specific buffer-positions"

Re: Window configurations

[Lennart Borgman]

On Mon, May 31, 2010 at 8:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> The use of `point' for that has not brought many complaints over the
> many years it's been used.  Any reason to think it's a bad choice?

Could that be because people are using winpoint.el instead of
complaining. At least that is what I do.

But I really think Emacs should solve this internally by using
window-point instead of point. winpoint is nice but does not solve the
whole problem (and it may interfere badly with other code for window
configuration, perhaps).

Re: Window configurations

[Juri Linkov]

>> The use of `point' for that has not brought many complaints over the
>> many years it's been used.  Any reason to think it's a bad choice?
>
> Could that be because people are using winpoint.el instead of
> complaining. At least that is what I do.

Yes, it seems people are using various tricks to workaround
this limitation (I prefer a view.el-like trick).

> But I really think Emacs should solve this internally by using
> window-point instead of point. winpoint is nice but does not solve the
> whole problem (and it may interfere badly with other code for window
> configuration, perhaps).

Is winpoint.el too intrusive?  I think we should try storing window point
positions in the window-local buffer list.

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

Re: Window configurations

[martin rudalics]

 >> The use of `point' for that has not brought many complaints over the
 >> many years it's been used.  Any reason to think it's a bad choice?
 >
 > Could that be because people are using winpoint.el instead of
 > complaining. At least that is what I do.

And the rest probably uses `pointback-mode' ;-)

martin

Re: Window configurations

[Juri Linkov]

>> (1) All calls to `other-buffer' for determining which buffer to show in
>> a window have the second argument nil.  So if a buffer is already shown
>> in another window it's against some unwritten rule to show it in the
>> window in question again.  If I follow that rule, then working with two
>> windows showing the same buffer remains just as tedious as it is now.
>
> Yes, the window handling code currently considers that the most likely
> thing the user wants is to see a buffer that's not currently shown.
> [ I'm not sure if it's careful to distinguish "shown on the current
> terminal" from "shown in some other terminal, miles away from here",
> which it should. ]
> This seems like a good default rule, so if we/you want to not follow
> this rule in some cases, we should think about how we can tell which is
> the better choice in a given situation.

It's a good default rule for some cases like switching to another
buffer with e.g. `C-x b', for other cases (like killing a buffer
and finding another buffer to show in its place) a better rule
would be to not see if that buffer is currently shown.

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

Re: Window configurations

[Stefan Monnier]

> It's a good default rule for some cases like switching to another
> buffer with e.g. `C-x b', for other cases (like killing a buffer
> and finding another buffer to show in its place) a better rule
> would be to not see if that buffer is currently shown.

Even in the kill-buffer case, it's very common for the "prefer
a non-shown buffer" to be a good/better default.
I think the only case where we might want to overlook the fact that
buffer is already displayed is in cases where we "go back to a previous
state", so we'd need to mark that somehow.


        Stefan

Re: Window configurations

[martin rudalics]

 > Even in the kill-buffer case, it's very common for the "prefer
 > a non-shown buffer" to be a good/better default.
 > I think the only case where we might want to overlook the fact that
 > buffer is already displayed is in cases where we "go back to a previous
 > state", so we'd need to mark that somehow.

As I noted earlier we could easily make this customizable.

martin

Re: Window configurations

[Stefan Monnier]

>> Even in the kill-buffer case, it's very common for the "prefer
>> a non-shown buffer" to be a good/better default.
>> I think the only case where we might want to overlook the fact that
>> buffer is already displayed is in cases where we "go back to a previous
>> state", so we'd need to mark that somehow.
> As I noted earlier we could easily make this customizable.

But it's a cop-out.


        Stefan

Re: Window configurations

[martin rudalics]

 >> (1) All calls to `other-buffer' for determining which buffer to show in
 >> a window have the second argument nil.  So if a buffer is already shown
 >> in another window it's against some unwritten rule to show it in the
 >> window in question again.  If I follow that rule, then working with two
 >> windows showing the same buffer remains just as tedious as it is now.
 >
 > Yes, the window handling code currently considers that the most likely
 > thing the user wants is to see a buffer that's not currently shown.
 > [ I'm not sure if it's careful to distinguish "shown on the current
 > terminal" from "shown in some other terminal, miles away from here",
 > which it should. ]

It's not that careful.

 > This seems like a good default rule, so if we/you want to not follow
 > this rule in some cases,

The case at hand was a scenario earlier posted by Juri as ...

------------------------------------------------------------------------
2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.
------------------------------------------------------------------------

... which, together with another scenario, triggered the present
discussion.

 > we should think about how we can tell which is
 > the better choice in a given situation.

We could make this customizable.

 >> (2) The length of frame-local buffer-lists is unbound.  For a one-frame
 >> user this already doubles the consing and maintenance overhead of buffer
 >> lists without any gain.  If we add window-local buffer-lists, we'd
 >> double the current overhead once more for one window/one frame users.
 >
 > Is this overhead really significant?  Say the list is 100 buffers long,
 > that's 1 or 2 KB, right?  Isn't this lost in the noise?

Look at the following stretch from `other-buffer':

   tail = Vbuffer_alist;
   pred = frame_buffer_predicate (frame);

   /* Consider buffers that have been seen in the selected frame
      before other buffers.  */

   tem = frame_buffer_list (frame);
   add_ons = Qnil;
   while (CONSP (tem))
     {
       if (BUFFERP (XCAR (tem)))
	add_ons = Fcons (Fcons (Qnil, XCAR (tem)), add_ons);
       tem = XCDR (tem);
     }
   tail = nconc2 (Fnreverse (add_ons), tail);

This prepends a list of (nil . buffer) conses for every non-buried
buffer on the selected frame (or some specified frame) to the list of
all buffers.  Note that reusing a window in `display-buffer' doesn't
bury the previous buffer.

Now for one-frame Emacs users this means that its consing overhead is
usually always proportional to the number of live buffers.  Given the
fact that `bury-buffer' (and thus `next-buffer') and evaluating the `b'
and `B' interactive arguments all call `other-buffer' this makes me
think that some GC overhead result.

It shouldn't be too hard to fix this.  [`other-buffer' has not been coded
very cleanly, just try evaluating

(other-buffer nil nil 1)

in a _separate_ instance of Emacs.]

Similar problems exist for `buffer-list' and `last-buffer'.

 >> (3) For each buffer on the window-local buffer-list I'd have to maintain
 >> its old point and its old window start position as markers.  Otherwise
 >> restoring the buffer would either get me a silly position if the buffer
 >> was modified in the meantime (a rare case probably, but unacceptable
 >> nevertheless) or a useless position like `point' (which would usually
 >> coincide with `window-point' of some other window showing that buffer).
 >> This means that for each buffer we get as many additional markers as
 >> there are live windows in which the buffer was shown (times two).
 >
 > The use of `point' for that has not brought many complaints over the
 > many years it's been used.  Any reason to think it's a bad choice?

It's a bad choice if you show a buffer in two windows W1 and W2,
temporaily show another buffer in W2, select W1, and switch back to the
original buffer in W2.  The whole "point" of showing the same buffer in
two windows is lost.  Note that if the temporarily displayed buffer is
in view or help mode you don't have this problem since `view-mode-exit'
handles the case.

martin

Re: Window configurations

[Stefan Monnier]

> +---------+---------+
> |         |         |
> | dired 1 | dired 1 |
> |         |         |
> |         |         |
> +---------+---------+

> Now view a file in the first window, and quit: `v q'.
> The window configuration is correctly restored
> (without using `set-window-configuration') - good.

> Now do the same without `view-mode': `RET C-x k'.
> Instead of the original buffer, some random buffer is displayed
> in this window.

So you're saying that C-x k's heuristic should be to try and restore the
previous window state?  I guess that could make sense, yes.

>> we should think about how we can tell which is
>> the better choice in a given situation.
> We could make this customizable.

No, we want instead to try and think in each case which behavior would
make more sense.  And maybe you're right that in "all" cases, trying to
restore the previous window state is TRT, rather than choosing some
non-shown buffer.


        Stefan

Re: Window configurations

[Lennart Borgman]

On Tue, Jun 1, 2010 at 3:08 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> No, we want instead to try and think in each case which behavior would
> make more sense.  And maybe you're right that in "all" cases, trying to
> restore the previous window state is TRT, rather than choosing some
> non-shown buffer.


Maybe something like this:

1) Save window config when running a command that changes window
config (and not does it as a user request).

2) Keep this around until either:

  - It is used.
  - A user request changes the window configuration.
  - 1 is applied again. (No stack.)

Re: Window configurations

[martin rudalics]

 > So you're saying that C-x k's heuristic should be to try and restore the
 > previous window state?  I guess that could make sense, yes.

I was saying that _if_ we want to fix the behavior to handle Juri's
case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
something the like).

 >> We could make this customizable.
 >
 > No, we want instead to try and think in each case which behavior would
 > make more sense.

We probably all agree that a window should not show a buffer visible
elsewhere when its buffer is killed or buried and its window-local
buffer list contains no other buffer.  Maybe we also agree that we
should show such a buffer when the window was "stolen" by a construct
like `with-temp-buffer'.

However, I'm afraid that there's no good approximation for the remaining
cases.  There are people used to edit large buffers by showing related
sections in two or more windows.  And there are people who don't do
that.  [The latter group should not be affected much by the new behavior
since we expect them to never show the same buffer twice at the same
time.  But I'm not sure whether the use of `split-window' runs counter
to such an assumption.]

 > And maybe you're right that in "all" cases, trying to
 > restore the previous window state is TRT, rather than choosing some
 > non-shown buffer.

I cannot be right since I never proposed that ;-)

martin

Re: Window configurations

[Stefan Monnier]

>>> We could make this customizable.
>> No, we want instead to try and think in each case which behavior would
>> make more sense.
> We probably all agree that a window should not show a buffer visible
> elsewhere when its buffer is killed or buried and its window-local
> buffer list contains no other buffer.

Makes sense, yes/

> Maybe we also agree that we should show such a buffer when the window
> was "stolen" by a construct like `with-temp-buffer'.

with-temp-buffer is probably a poor example since it doesn't affect
windows, but if you mean something like with-output-to-temp-buffer, then
yes, we probably all agree.

> However, I'm afraid that there's no good approximation for the remaining
> cases.  There are people used to edit large buffers by showing related
> sections in two or more windows.  And there are people who don't do
> that.  [The latter group should not be affected much by the new behavior
> since we expect them to never show the same buffer twice at the same
> time.  But I'm not sure whether the use of `split-window' runs counter
> to such an assumption.]

We can solve each case as it shows up.  E.g. for the split-window case
(i.e. buffer shown in 2 windows only because that's what split-window
does, but the user then immediately switches to some other buffer), we
should try and find a way to capture the user's intention.
E.g. "immediately" after split-window, any set-window-buffer will not
push the current buffer on the buffer-list of that window.

>> And maybe you're right that in "all" cases, trying to restore the
>> previous window state is TRT, rather than choosing some
>> non-shown buffer.
> I cannot be right since I never proposed that ;-)

I thought you suggested to have a config var to decide whether to use
the current heuristic, or to use another heuristic which prefers buffers
from the window's buffer-list regardless of whether they are
shown elsewhere.  Isn't that what you meant in:

   >> we should think about how we can tell which is
   >> the better choice in a given situation.
   > We could make this customizable.


-- Stefan

Re: Window configurations

[martin rudalics]

 >> Maybe we also agree that we should show such a buffer when the window
 >> was "stolen" by a construct like `with-temp-buffer'.
 >
 > with-temp-buffer is probably a poor example since it doesn't affect
 > windows, but if you mean something like with-output-to-temp-buffer,

That's what I meant.

 > then
 > yes, we probably all agree.

Tracing `with-output-to-temp-buffer' is a pain.  I suppose
temp_output_buffer_show needs some reserved value for the second
argument of `display-buffer' so the latter can set up the window-local
buffer list appropriately.

 > We can solve each case as it shows up.  E.g. for the split-window case
 > (i.e. buffer shown in 2 windows only because that's what split-window
 > does, but the user then immediately switches to some other buffer), we
 > should try and find a way to capture the user's intention.

That's precisely the case I had in mind.  I have no idea how and why
people use `split-window'.  Hardly always to show the same buffer twice.
But I don't even know how I use it myself.

 > E.g. "immediately" after split-window, any set-window-buffer will not
 > push the current buffer on the buffer-list of that window.

Aren't there too many ways to make this `set-window-buffer' happen?  One
of the simplest is `next-buffer' which does `bury-buffer' for the old
buffer so it won't create any problems.  But what if the user decides to
consult some buffer switching application that pops up a window with
suggestions?

 > I thought you suggested to have a config var to decide whether to use
 > the current heuristic, or to use another heuristic which prefers buffers
 > from the window's buffer-list regardless of whether they are
 > shown elsewhere.  Isn't that what you meant in:
 >
 >    >> we should think about how we can tell which is
 >    >> the better choice in a given situation.
 >    > We could make this customizable.

Not really.  I want to avoid that changing the established behavior
causes people who do not care anyway ask for getting the old behavior
back.  If we make this customizable we can concentrate on the criticism
of people who really do care.

martin

Re: Window configurations

[Stefan Monnier]

>> then yes, we probably all agree.

> Tracing `with-output-to-temp-buffer' is a pain.  I suppose
> temp_output_buffer_show needs some reserved value for the second
> argument of `display-buffer' so the latter can set up the window-local
> buffer list appropriately.

I don't want to link with-output-to-temp-buffer and display-buffer.
I.e. if it requires something special from display-buffer, then that
extra flexibility will have to be added to display-buffer, but not in
a "reserved value" kind of way.

>> E.g. "immediately" after split-window, any set-window-buffer will not
>> push the current buffer on the buffer-list of that window.
> Aren't there too many ways to make this `set-window-buffer' happen?

Maybe.  I think we won't know before we try it.

>> > We could make this customizable.
> Not really.  I want to avoid that changing the established behavior
> causes people who do not care anyway ask for getting the old behavior
> back.  If we make this customizable we can concentrate on the criticism
> of people who really do care.

I'd rather deal with the disgruntled than add a customization variable.


        Stefan

Re: Window configurations

[martin rudalics]

 > I don't want to link with-output-to-temp-buffer and display-buffer.
 > I.e. if it requires something special from display-buffer, then that
 > extra flexibility will have to be added to display-buffer, but not in
 > a "reserved value" kind of way.

If you eventually want to replace `switch-to-buffer' by `pop-to-buffer'
it becomes important to distinguish calls to show a specific buffer from
calls for showing unspecified, temporary buffers.  Otherwise, you can't
tell apart the explicit placing of buffers in windows from merely
accidental ones that happened just because some window had the right
size at the right moment.

 > I'd rather deal with the disgruntled than add a customization variable.

I'll take your word for that.

martin

Re: Window configurations

[Juri Linkov]

>> So you're saying that C-x k's heuristic should be to try and restore
>> the previous window state?  I guess that could make sense, yes.
>
> I was saying that _if_ we want to fix the behavior to handle Juri's
> case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
> something the like).

I think changing the argument VISIBLE_OK won't help.  The existing
calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
current behavior of `other-buffer' that prefers not visible buffers
to visible buffers (when the window-local buffer-list is empty).

>>> We could make this customizable.
>>
>> No, we want instead to try and think in each case which behavior would
>> make more sense.
>
> We probably all agree that a window should not show a buffer visible
> elsewhere when its buffer is killed or buried and its window-local
> buffer list contains no other buffer.

Yes, without making this customizable, a simple rule could be to get
next buffers from the window-local buffer-list when it is non-empty.

> However, I'm afraid that there's no good approximation for the remaining
> cases.  There are people used to edit large buffers by showing related
> sections in two or more windows.  And there are people who don't do
> that.  [The latter group should not be affected much by the new behavior
> since we expect them to never show the same buffer twice at the same
> time.  But I'm not sure whether the use of `split-window' runs counter
> to such an assumption.]

I see no problem if we will push the current buffer to the window-local
buffer-list in the same places in code where currently the buffer is
pushed to the frame-local buffer-list (and buried-buffer-list).

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

Re: Window configurations

[martin rudalics]

 > I think changing the argument VISIBLE_OK won't help.  The existing
 > calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
 > current behavior of `other-buffer' that prefers not visible buffers
 > to visible buffers (when the window-local buffer-list is empty).

You mean that when the window-local buffer-list is not empty these calls
should be allowed to choose a visible buffer?  What if an application
wants to specify for a specific call that `other-buffer' does not return
a visible buffer?

 > I see no problem if we will push the current buffer to the window-local
 > buffer-list in the same places in code where currently the buffer is
 > pushed to the frame-local buffer-list (and buried-buffer-list).

We'd change the behavior for people used to see the same buffer in two
windows simultaneously only for the short period when they've split a
window and have not yet shown the wanted buffer in it.

martin

Re: Window configurations

[Juri Linkov]

>> I think changing the argument VISIBLE_OK won't help.  The existing
>> calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
>> current behavior of `other-buffer' that prefers not visible buffers
>> to visible buffers (when the window-local buffer-list is empty).
>
> You mean that when the window-local buffer-list is not empty these calls
> should be allowed to choose a visible buffer?  What if an application
> wants to specify for a specific call that `other-buffer' does not return
> a visible buffer?

Then `other-buffer' is too low-level to implement this.
Maybe `kill-buffer' and `bury-buffer' are more suitable places.

>> I see no problem if we will push the current buffer to the window-local
>> buffer-list in the same places in code where currently the buffer is
>> pushed to the frame-local buffer-list (and buried-buffer-list).
>
> We'd change the behavior for people used to see the same buffer in two
> windows simultaneously only for the short period when they've split a
> window and have not yet shown the wanted buffer in it.

I don't see a problem with `split-window': after splitting, the second
window's buffer-list is empty, thus it adheres to the current behavior.

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

Re: Window configurations

[martin rudalics]

 >>> I think changing the argument VISIBLE_OK won't help.  The existing
 >>> calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
 >>> current behavior of `other-buffer' that prefers not visible buffers
 >>> to visible buffers (when the window-local buffer-list is empty).
 >> You mean that when the window-local buffer-list is not empty these calls
 >> should be allowed to choose a visible buffer?  What if an application
 >> wants to specify for a specific call that `other-buffer' does not return
 >> a visible buffer?
 >
 > Then `other-buffer' is too low-level to implement this.
 > Maybe `kill-buffer' and `bury-buffer' are more suitable places.

We could use a 'this-window-only value for the VISIBLE_OK argument.

 > I don't see a problem with `split-window': after splitting, the second
 > window's buffer-list is empty, thus it adheres to the current behavior.

I meant after splitting _and_ selecting the new window in order to
decide which buffer to display in it.  I suppose we always want to
update the window-local buffer list after selecting a window with
NORECORD nil?

martin

Re: Window configurations

[Juri Linkov]

> I meant after splitting _and_ selecting the new window in order to
> decide which buffer to display in it.  I suppose we always want to
> update the window-local buffer list after selecting a window with
> NORECORD nil?

I think the window-local buffer list should be updated in all places
where the frame-local buffer list is currently updated.

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

Re: Window configurations

[martin rudalics]

 >>> So you're saying that C-x k's heuristic should be to try and restore
 >>> the previous window state?  I guess that could make sense, yes.
 >> I was saying that _if_ we want to fix the behavior to handle Juri's
 >> case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or
 >> something the like).
 >
 > I think changing the argument VISIBLE_OK won't help.  The existing
 > calls of `other-buffer' (where VISIBLE_OK is nil) should keep the
 > current behavior of `other-buffer' that prefers not visible buffers
 > to visible buffers (when the window-local buffer-list is empty).

Sorry, I don't get you here.  Reconsider your earlier example:

------------------------------------------------------------------------
2. Another example - visit the same buffer in two windows, and put point
at different positions of the same buffer.

+---------+---------+
|         |         |
| dired 1 | dired 1 |
|         |         |
|         |         |
+---------+---------+

Now view a file in the first window, and quit: `v q'.
The window configuration is correctly restored
(without using `set-window-configuration') - good.

Now do the same without `view-mode': `RET C-x k'.
Instead of the original buffer, some random buffer is displayed
in this window.
------------------------------------------------------------------------

Doing C-x k currently winds up calling

replace_buffer_in_all_windows (buffer);

which calls

Fother_buffer (w->buffer, Qnil, w->frame)

so a visible buffer will not be put into that window.

martin

Re: Window configurations

[Juri Linkov]

> Doing C-x k currently winds up calling
>
> replace_buffer_in_all_windows (buffer);
>
> which calls
>
> Fother_buffer (w->buffer, Qnil, w->frame)
>
> so a visible buffer will not be put into that window.

Right.  But it should put a visible buffer into that window,
if the window-local buffer-list is non-empty and that buffer
happens to be at the top of the window-local buffer-list.

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

Re: Window configurations

[martin rudalics]

 >> Doing C-x k currently winds up calling
 >>
 >> replace_buffer_in_all_windows (buffer);
 >>
 >> which calls
 >>
 >> Fother_buffer (w->buffer, Qnil, w->frame)
 >>
 >> so a visible buffer will not be put into that window.
 >
 > Right.  But it should put a visible buffer into that window,
 > if the window-local buffer-list is non-empty and that buffer
 > happens to be at the top of the window-local buffer-list.

So we have to decide

(1) wherever this "But it should put ..." shall be done (in
     `bury-buffer', `quit-window', ...), and

(2) whether a window-local buffer-list may contain something else but
     entries associated with buffers (as your text somehow insinuates).

martin

Re: Window configurations

[Juri Linkov]

> So we have to decide
>
> (1) wherever this "But it should put ..." shall be done (in
>     `bury-buffer', `quit-window', ...), and

I suppose this should be done in all places that currently modify
the buffer-list.

> (2) whether a window-local buffer-list may contain something else but
>     entries associated with buffers (as your text somehow insinuates).

Yes, elements of a window-local buffer-list should also contain
window-start and window-point.

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

Re: Window configurations

[martin rudalics]

 >> So we have to decide
 >>
 >> (1) wherever this "But it should put ..." shall be done (in
 >>     `bury-buffer', `quit-window', ...), and
 >
 > I suppose this should be done in all places that currently modify
 > the buffer-list.

`select-window' does modify the buffer list but there we probably don't
care.  Anyway, what I need to know is how to deal with all the
`other-buffer' calls in general.  For example, how do we determine the
prompt for `read-buffer-to-switch'?  This is called by
`switch-to-buffer' but also by `switch-to-buffer-other-window' and
`switch-to-buffer-other-frame' where we don't know the target window in
advance.  And we certainly don't want to prompt with a visible buffer
there.

 >> (2) whether a window-local buffer-list may contain something else but
 >>     entries associated with buffers (as your text somehow insinuates).
 >
 > Yes, elements of a window-local buffer-list should also contain
 > window-start and window-point.

In my `quit-restore-window' parameter I currently store whether to the
kill the window and which window to select instead.  These are not very
compatible with buffer lists but I do need them in order to keep up the
current behavior of quitting a help buffer or view mode.  Mixing these
into window local buffer list is not very nice.

martin

Re: Window configurations

[Juri Linkov]

> Anyway, what I need to know is how to deal with all the `other-buffer'
> calls in general.  For example, how do we determine the prompt for
> `read-buffer-to-switch'?  This is called by `switch-to-buffer' but
> also by `switch-to-buffer-other-window' and `switch-to-buffer-other-frame'
> where we don't know the target window in advance.  And we certainly
> don't want to prompt with a visible buffer there.

If we don't know the target window in advance, then we can't use
the window-local buffer-list for `read-buffer-to-switch'.

> In my `quit-restore-window' parameter I currently store whether to the
> kill the window and which window to select instead.  These are not very
> compatible with buffer lists but I do need them in order to keep up the
> current behavior of quitting a help buffer or view mode.  Mixing these
> into window local buffer list is not very nice.

This means that you need to store more information for the first
element of the window-local buffer-list, i.e. when popping the
stack of buffers reaches the first element, it should know what to do
after popping the last element: whether to kill the window and
which window to select instead.

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

Re: Window configurations

[martin rudalics]

 > If we don't know the target window in advance, then we can't use
 > the window-local buffer-list for `read-buffer-to-switch'.

In `switch-to-buffer' we usually know the target window.  In
`switch-to-buffer-other-window' we don't.  How distinguish the two?

But I'm afraid that the idea of handling window local buffer lists just
like the other buffer lists is flawed anyway.  For example, when I
display a buffer without selecting the window as in
`with-output-to-temp-buffer' I do want to update the window local buffer
list.  When I do `bury-buffer' and the buffer is not displayed in the
selected but maybe some other window the buffer will get buried in the
selected window and remains the first buffer in the other window.  Both
make hardly sense either (and are flawed for frame local buffer lists as
well).

I suppose that for the moment I'll abandon the idea of window local
buffer lists and return to them after I have solved some other issues.

 > This means that you need to store more information for the first
 > element of the window-local buffer-list, i.e. when popping the
 > stack of buffers reaches the first element, it should know what to do
 > after popping the last element: whether to kill the window and
 > which window to select instead.

The problem is that the information contained there might be already
stale (the user might have done a lot of things in between).  For help
windows it makes sense to check whether the window still displays the
help buffer and only if it does I proceed according to the information
stored in the window parameter.  For arbitrary buffers in non-dedicated
windows I might just violate the principle of least surprise.

martin

Re: Window configurations

[Juri Linkov]

> (and are flawed for frame local buffer lists as well).

If frame-local buffer-lists are flawed, they should be fixed.
But I think window-local buffer-lists should be modelled after
frame-local buffer-lists.  A frame-local buffer-list is a frame
parameter, so a window-local buffer-list could be a window parameter,
with more information associated with every element (window-start,
window-point, quit-restore function).

> I suppose that for the moment I'll abandon the idea of window local
> buffer lists and return to them after I have solved some other issues.

You will need window-local buffer-lists anyway to correctly restore
previous places when quitting the window.  IOW, instead of
`quit-restore-window' parameter (that saves only 1 previous place),
you can add a window parameter `buffer-list' (and use it to restore
previous places when quitting) that later could combine its values
with frame-local `buffer-list' and global `buffer-list' for the
function `(buffer-list)'.

> The problem is that the information contained there might be already
> stale (the user might have done a lot of things in between).  For help
> windows it makes sense to check whether the window still displays the
> help buffer and only if it does I proceed according to the information
> stored in the window parameter.  For arbitrary buffers in non-dedicated
> windows I might just violate the principle of least surprise.

I see no such problems for `view-return-to-alist', so maybe it won't
a problem for other buffers too.

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

Re: Window configurations

[martin rudalics]

 > If frame-local buffer-lists are flawed, they should be fixed.
 > But I think window-local buffer-lists should be modelled after
 > frame-local buffer-lists.  A frame-local buffer-list is a frame
 > parameter,

... implemented within the frame structure ...

 > so a window-local buffer-list could be a window parameter,
 > with more information associated with every element (window-start,
 > window-point, quit-restore function).
 >
 >> I suppose that for the moment I'll abandon the idea of window local
 >> buffer lists and return to them after I have solved some other issues.
 >
 > You will need window-local buffer-lists anyway to correctly restore
 > previous places when quitting the window.  IOW, instead of
 > `quit-restore-window' parameter (that saves only 1 previous place),
 > you can add a window parameter `buffer-list' (and use it to restore
 > previous places when quitting) that later could combine its values
 > with frame-local `buffer-list' and global `buffer-list' for the
 > function `(buffer-list)'.

Yes.  But my `quit-restore-window' parameter was a very simple start.
It doesn't use markers and doesn't do much when a window's buffer no
longer equals that specified in the parameter.  OTOH, `view-mode' has
other pitfalls like the need for copying the parameter when splitting
the window.

 >> The problem is that the information contained there might be already
 >> stale (the user might have done a lot of things in between).  For help
 >> windows it makes sense to check whether the window still displays the
 >> help buffer and only if it does I proceed according to the information
 >> stored in the window parameter.  For arbitrary buffers in non-dedicated
 >> windows I might just violate the principle of least surprise.
 >
 > I see no such problems for `view-return-to-alist', so maybe it won't
 > a problem for other buffers too.

It does not have problems because you do it via `View-quit', hence the
window is probably still the same window showing the same buffer.  If
you switch to another buffer in an earlier popped up help window, then
having a later `unbury-buffer' delete that window might be surprising.

martin

Re: Window configurations

[Juri Linkov]

>> I see no such problems for `view-return-to-alist', so maybe it won't
>> a problem for other buffers too.
>
> It does not have problems because you do it via `View-quit', hence the
> window is probably still the same window showing the same buffer.  If
> you switch to another buffer in an earlier popped up help window, then
> having a later `unbury-buffer' delete that window might be surprising.

I'm not sure this will be surprising because it will delete the window
when the Help buffer is displayed in it, not with some other buffer.
So when I see the Help buffer and type `q', I expect that it will delete
that window.

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

Re: Window configurations

[Lennart Borgman]

On Thu, Jun 17, 2010 at 10:38 PM, Juri Linkov <juri@jurta.org> wrote:
>>> I see no such problems for `view-return-to-alist', so maybe it won't
>>> a problem for other buffers too.
>>
>> It does not have problems because you do it via `View-quit', hence the
>> window is probably still the same window showing the same buffer.  If
>> you switch to another buffer in an earlier popped up help window, then
>> having a later `unbury-buffer' delete that window might be surprising.
>
> I'm not sure this will be surprising because it will delete the window
> when the Help buffer is displayed in it, not with some other buffer.
> So when I see the Help buffer and type `q', I expect that it will delete
> that window.

Yes, if helped opened it.

But not if help was just displayed in that window. Then I expect q to
remove help and show what was there before.

I simply expect q to restore the state if it is possible.


However on thing that has disturbed me is that for example window
configurations are restored after I have made changes to the temporary
window configuration. That does not seem useful (except in the case of
debugging which is very different).

Re: Window configurations

[martin rudalics]

 >> It does not have problems because you do it via `View-quit', hence the
 >> window is probably still the same window showing the same buffer.  If
 >> you switch to another buffer in an earlier popped up help window, then
 >> having a later `unbury-buffer' delete that window might be surprising.
 >
 > I'm not sure this will be surprising because it will delete the window
 > when the Help buffer is displayed in it, not with some other buffer.
 > So when I see the Help buffer and type `q', I expect that it will delete
 > that window.

My description was unclear.  I meant:

(1) Pop up the help window.

(2) In that window display some other buffer.

(3) Kill that other buffer.

What Emacs now shall do with the window is unclear.  If it does delete
the window and step (3) happens some time after (1) the effect will be
strange because the user already has forgotten about (1).  If it does
not delete the window the case where my step (3) is rewritten as

(3') Switch back to the help buffer.

will not delete the window.

I solve this problem currently by checking whether the buffer in (3) is
the buffer displayed by (1).  But this doesn't solve the problem when
(2) and (3) appear as

(2") Reuse the window to display info.

(3") Quit info.

which likely should delete the window.  [Note that making the help
window weakly dedicated in step (1) will currently have (2") fail.]

martin

Re: Window configurations

[Juri Linkov]

> My description was unclear.  I meant:
>
> (1) Pop up the help window.
>
> (2) In that window display some other buffer.
>
> (3) Kill that other buffer.
>
> What Emacs now shall do with the window is unclear.

Of course, it should switch back to the help buffer
without deleting the window.

> (2") Reuse the window to display info.
>
> (3") Quit info.
>
> which likely should delete the window.

3" should not delete the window.

Everything should work exactly as it already works in the simplest case:

(0) Run `emacs -Q'.

(1) Pop up the help window. `C-h f car RET C-x o'

(2) Reuse the window to display info.  `C-h i'

(3) In that window display some other buffer.  `C-h C-t'

(4) Kill that other buffer.  `C-x k RET'
    The previous buffer "*info*" is displayed in this window.

(5) Quit info.  `q'
    The previous buffer "*Help*" is displayed in this window.

(6) Type `q'
    The window is deleted.

IOW, we should not invent a new behavior, just fix some cases
(that I mentioned earlier where selecting another windows messes up
the global buffer list and thus detaches the buffer from its original
window).  I believe that using a window parameter `buffer-list'
will help to fix this.

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

Re: Window configurations

[martin rudalics]

 >> My description was unclear.  I meant:
 >>
 >> (1) Pop up the help window.
 >>
 >> (2) In that window display some other buffer.
 >>
 >> (3) Kill that other buffer.
 >>
 >> What Emacs now shall do with the window is unclear.
 >
 > Of course, it should switch back to the help buffer
 > without deleting the window.

I said that (3) would happen after some time.  Meanwhile the help buffer
could have been popped up a number of times, with completely different
contents, have been killed a number of times ...

martin

Re: Window configurations

[Juri Linkov]

>>> My description was unclear.  I meant:
>>>
>>> (1) Pop up the help window.
>>>
>>> (2) In that window display some other buffer.
>>>
>>> (3) Kill that other buffer.
>>>
>>> What Emacs now shall do with the window is unclear.
>>
>> Of course, it should switch back to the help buffer
>> without deleting the window.
>
> I said that (3) would happen after some time.  Meanwhile the help buffer
> could have been popped up a number of times, with completely different
> contents, have been killed a number of times ...

The best way to observe possible problems is to implement
a simple prototype with a window parameter `buffer-list',
and see how well it works ;-)

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

Re: Window configurations

[martin rudalics]

> The best way to observe possible problems is to implement
> a simple prototype with a window parameter `buffer-list',
> and see how well it works ;-)

I'm too silly dodging this :-(

martin

Re: Window configurations

[Juri Linkov]

>> The best way to observe possible problems is to implement
>> a simple prototype with a window parameter `buffer-list',
>> and see how well it works ;-)
>
> I'm too silly dodging this :-(

And I'm no less silly doing that  ;-)
I believe by trial-and-error we could
find an optimal implementation.

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

Re: Window configurations

[martin rudalics]

> I believe by trial-and-error we could
> find an optimal implementation.

If you take care of the trials I'll do the errors ;-)

martin

Re: Window configurations

[Juri Linkov]

> just try evaluating
>
> (other-buffer nil nil 1)

The docstring of `other-buffer' contains this line:

  If BUFFER is omitted or nil, some interesting buffer is returned.

We could add a similar line:

  If FRAME is 1, something interesting happens.

:-)

> Similar problems exist for `buffer-list' and `last-buffer'.

I don't see the same problem in `buffer-list' because it has
guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'.

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

Re: Window configurations

[martin rudalics]

 >> Similar problems exist for `buffer-list' and `last-buffer'.
 >
 > I don't see the same problem in `buffer-list' because it has
 > guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'.

Try evaluating

(let ((list (list "*scratch*")))
   (set-frame-parameter nil 'buffer-list (setcdr list list))
   (buffer-list (selected-frame)))

;-)

martin

Re: Window configurations

[Juri Linkov]

>>> Similar problems exist for `buffer-list' and `last-buffer'.
>>
>> I don't see the same problem in `buffer-list' because it has
>> guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'.
>
> Try evaluating
>
> (let ((list (list "*scratch*")))
>   (set-frame-parameter nil 'buffer-list (setcdr list list))
>   (buffer-list (selected-frame)))

This is unfair ;-) You can break almost everything with a cyclic list.

However, I'd like to fix the invalid frame case for
`(other-buffer nil nil 1)' with:

=== modified file 'src/buffer.c'
--- src/buffer.c	2010-05-27 23:30:11 +0000
+++ src/buffer.c	2010-06-02 19:49:04 +0000
@@ -1299,6 +1299,7 @@ (at your option) any later version.
 
   if (NILP (frame))
     frame = selected_frame;
+  CHECK_FRAME (frame);
 
   tail = Vbuffer_alist;
   pred = frame_buffer_predicate (frame);

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

Re: Window configurations

[martin rudalics]

 >> (let ((list (list "*scratch*")))
 >>   (set-frame-parameter nil 'buffer-list (setcdr list list))
 >>   (buffer-list (selected-frame)))
 >
 > This is unfair ;-) You can break almost everything with a cyclic list.

But usually you can quit via C-g.  This case has a special history: Once
upon a time Vbuffer_alist "used to be a variable, but is no longer, to
prevent lossage due to user rplac'ing this alist or its elements".  Then
eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
their loops allow quitting.  Write a special loop by hand." which was
still OK because Vbuffer_alist was no longer accessible from Elisp.
Next we got frame local buffer lists and finally someone decided to
allow setting a frame's buffer list from Elisp ...

I think two things have to be done here: Remove the special constructs
that don't allow quitting.  They are hardly useful today.  Moreover,
there are routines operating on buffer lists that _do allow quitting_
like unrecord_buffer so the original motivation is moot anyway (unless
we want unrecord_buffer use a construct like record_buffer).

In addition we should disallow changing a frame's buffer and buried
buffer lists by setting the corresponding frame's parameter.  I think
this was part of an attempt to make each and every frame related object
part of a frame's parameters.  But an application should not be allowed
to alter the history of buffers shown on a particular frame.  Let's
leave such activities to politicians - that's what they get paid for.

 > However, I'd like to fix the invalid frame case for
 > `(other-buffer nil nil 1)' with:
[...]

Elementary.

martin

Re: Window configurations

[Stefan Monnier]

> eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
> their loops allow quitting.  Write a special loop by hand." which was

What was the problem with quitting?

> part of a frame's parameters.  But an application should not be allowed
> to alter the history of buffers shown on a particular frame.

Why not?


        Stefan

Re: Window configurations

[martin rudalics]

 >> eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
 >> their loops allow quitting.  Write a special loop by hand." which was
 >
 > What was the problem with quitting?

Probably that Vbuffer_list gets corrupted when the user triggers a quit
before the Fdelq gets executed.  In that case a buffer might get dropped
from the buffer list and not be reinserted as first element.

I don't know whether this might happen at all and what kind of
consequences this could have.  The fact that Funrecord_buffer uses Fdelq
without complaints for years seems to indicate that there's no problem.

 >> part of a frame's parameters.  But an application should not be allowed
 >> to alter the history of buffers shown on a particular frame.
 >
 > Why not?

Why should it lie?  Histories should not be altered at will.

But this is a minor issue.  Hardly anyone knows that a frame's buried
buffer list can be altered, and which application would want to change
it anyway?  It's only some wasted lines in the manual (just like those
for a frame's buffer-predicate).

martin

Re: Window configurations

[Stefan Monnier]

>>> part of a frame's parameters.  But an application should not be allowed
>>> to alter the history of buffers shown on a particular frame.
>> Why not?
> Why should it lie?  Histories should not be altered at will.

This list is not a "sworn statement about history".  It's just
a data-structure where we record some state so as to help some heuristic
make decisions.  Modifying it won't get us trapped in a time warp.

> But this is a minor issue.  Hardly anyone knows that a frame's buried
> buffer list can be altered, and which application would want to change
> it anyway?  It's only some wasted lines in the manual (just like those
> for a frame's buffer-predicate).

I don't have much opinion about whether it's worth mentioning in the
manual, but I really can't think of any reason why we should
prevent modification.


        Stefan

Re: Window configurations

[martin rudalics]

 > This list is not a "sworn statement about history".  It's just
 > a data-structure where we record some state so as to help some heuristic
 > make decisions.  Modifying it won't get us trapped in a time warp.

Surely not.  The list isn't very useful anyway after a longer window
excursion.

 > I don't have much opinion about whether it's worth mentioning in the
 > manual, but I really can't think of any reason why we should
 > prevent modification.

Maybe Juri has an argument why modifying it _is_ useful.

martin

Re: Window configurations

[Juri Linkov]

> Maybe Juri has an argument why modifying it _is_ useful.

No, you have to prove why modifying it _is_ illegal ;-)

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

Re: Window configurations

[martin rudalics]

 >> Maybe Juri has an argument why modifying it _is_ useful.
 >
 > No, you have to prove why modifying it _is_ illegal ;-)

You know that I can't ;-)

martin

Re: Window configurations

[Richard Stallman]

    > eventually Richard decided to "not use Frassq, Fmemq or Fdelq since
    > their loops allow quitting.  Write a special loop by hand." which was

    What was the problem with quitting?

If it is a matter of deleting a window, it is a bug to quit anywhere
in the middle of that.  It has to be either done completely or not
done at all.  Therefore it must not use functions that can quit.
Or else it has to inhibit quitting some other way.

Re: Window configurations

[martin rudalics]

 >     What was the problem with quitting?
 >
 > If it is a matter of deleting a window, it is a bug to quit anywhere
 > in the middle of that.  It has to be either done completely or not
 > done at all.  Therefore it must not use functions that can quit.
 > Or else it has to inhibit quitting some other way.

It's not related to window deletion.  When Emacs buries a buffer it
first removes the buffer from the buffer list and then adds it to the
end of that list in the following way:

       aelt = Frassq (buffer, Vbuffer_alist);
       link = Fmemq (aelt, Vbuffer_alist);
       Vbuffer_alist = Fdelq (aelt, Vbuffer_alist);
       XSETCDR (link, Qnil);
       Vbuffer_alist = nconc2 (Vbuffer_alist, link);

If the Fdelq above quits, the buffer is lost (in some sense).  The code
for record_buffer avoids the problem but chokes on circular lists.

martin

Re: Window configurations

[Juri Linkov]

> In addition we should disallow changing a frame's buffer and buried
> buffer lists by setting the corresponding frame's parameter.  I think
> this was part of an attempt to make each and every frame related object
> part of a frame's parameters.  But an application should not be allowed
> to alter the history of buffers shown on a particular frame.  Let's
> leave such activities to politicians - that's what they get paid for.

Definitely not, changing a frame's buffer and buried buffer lists
is the only way to implement a sane behavior for the tab-bar!
Switching tabs should save the frame's buffer list of the current tab
into a variable and update the frame's parameters with the value
of frame's buffer list of the next tab.

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

Re: Window configurations

[martin rudalics]

 > Definitely not, changing a frame's buffer and buried buffer lists
 > is the only way to implement a sane behavior for the tab-bar!
 > Switching tabs should save the frame's buffer list of the current tab
 > into a variable and update the frame's parameters with the value
 > of frame's buffer list of the next tab.

But why should working from the tab-bar affect these?  Shouldn't such
side-effects stay within the framework of the tab-bar functions?

martin

Re: Window configurations

[Juri Linkov]

>> Definitely not, changing a frame's buffer and buried buffer lists
>> is the only way to implement a sane behavior for the tab-bar!
>> Switching tabs should save the frame's buffer list of the current tab
>> into a variable and update the frame's parameters with the value
>> of frame's buffer list of the next tab.
>
> But why should working from the tab-bar affect these?

They implement tab-local buffer-list by modifying the frame-local
buffer-list after switching the tab.

> Shouldn't such side-effects stay within the framework of the
> tab-bar functions?

The tab-bar functions implemented by Lisp packages use
`modify-frame-parameters' to change `buffer-list' frame parameter.

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

Re: Window configurations

[martin rudalics]

 > They implement tab-local buffer-list by modifying the frame-local
 > buffer-list after switching the tab.

Could you please explain in one or two sentences?  Where can I find the
source of these tab-bars?

 > The tab-bar functions implemented by Lisp packages use
 > `modify-frame-parameters' to change `buffer-list' frame parameter.

But wouldn't it make more sense to have tab-bar use its own list?  Can
tab-bar live with the fact that a user switches buffers without using
tab-bar and thus `select-window' changes the list?

martin

Re: Window configurations

[Juri Linkov]

>> They implement tab-local buffer-list by modifying the frame-local
>> buffer-list after switching the tab.
>
> Could you please explain in one or two sentences?  Where can I find the
> source of these tab-bars?

Please see for example in the branch x-tabs/lisp/tab.el.

>> The tab-bar functions implemented by Lisp packages use
>> `modify-frame-parameters' to change `buffer-list' frame parameter.
>
> But wouldn't it make more sense to have tab-bar use its own list?

Yes, it makes sense to have the following composite buffer-list:

 window-local buffer-list
 tab-local buffer-list
 frame-local buffer-list
 global buffer-list
 frame-local buried-buffer-list
 tab-local buried-buffer-list
 window-local buried-buffer-list

But how would you implement tab-local buffer-list without modifying
frame-local buffer-list?

> Can tab-bar live with the fact that a user switches buffers without
> using tab-bar and thus `select-window' changes the list?

A user can switch buffers inside the same tab - this modifies the
frame-local (tab-local) buffer-list.  A user can switch tabs without
using tab-bar - this updates the frame-local (tab-local) buffer-list
with the buffer-list of another tab.

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

Re: Window configurations

[Stefan Monnier]

> But how would you implement tab-local buffer-list without modifying
> frame-local buffer-list?

You could imagine getting rid of this special handling of frames and
buffers's buffer-list and instead provide a record-buffer-function and
a buffer-list-function, so Elisp packages can implement them as
they wish.  I'm not sure it's worth the trouble.


        Stefan

Re: Window configurations

[Juri Linkov]

>> But how would you implement tab-local buffer-list without modifying
>> frame-local buffer-list?
>
> You could imagine getting rid of this special handling of frames and
> buffers's buffer-list and instead provide a record-buffer-function and
> a buffer-list-function, so Elisp packages can implement them as
> they wish.  I'm not sure it's worth the trouble.

Maybe record-buffer-functions and buffer-list-functions (plural)
where Elisp packages could add own function to a list of functions.
Then core primitives will construct a composite list by appending
values returned by these functions.  An example of buffer-list-functions:
'(window-buffer-list-function tab-buffer-list-function frame-buffer-list-function).
created with code in

window.el:
  (add-to-list 'buffer-list-functions 'window-buffer-list-function)

tab.el
  (add-to-list 'buffer-list-functions 'tab-buffer-list-function)

frame.el
  (add-to-list 'buffer-list-functions 'frame-buffer-list-function)

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

Re: Window configurations

[Juri Linkov]

> The case at hand was a scenario earlier posted by Juri as ...

There is another case that is more annoying:

1. Run `emacs -q', the current buffer is "*scratch*".

2. Type `C-h i', the current buffer is "*info*".

3. Type `C-h C-t', the current buffer is "TODO".

4. Type `C-h C-n', the current buffer is "NEWS".

5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good.

6. Type `C-x k RET', the current buffer is "*scratch*".  Why?
   The previous buffer is "*info*", not "*scratch*"!

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

Re: Window configurations

[martin rudalics]

 > There is another case that is more annoying:
 >
 > 1. Run `emacs -q', the current buffer is "*scratch*".
 >
 > 2. Type `C-h i', the current buffer is "*info*".
 >
 > 3. Type `C-h C-t', the current buffer is "TODO".
 >
 > 4. Type `C-h C-n', the current buffer is "NEWS".
 >
 > 5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good.
 >
 > 6. Type `C-x k RET', the current buffer is "*scratch*".  Why?
 >    The previous buffer is "*info*", not "*scratch*"!

This happened in revision 90833 of `pop-to-buffer' from 2008-09-13.
Since then `pop-to-buffer' doesn't reselect the selected window.

The culprit is this conditional

     (unless (eq new-window old-window)
       ;; `display-buffer' has chosen another window, select it.

which does not select the *info* window because it was already selected
before but obviously doesn't record the *info* buffer either :-(

I'm running my code without the conditional for more than two months
now so it shouldn't harm if you remove it as well.

martin

Re: Window configurations

[Juri Linkov]

>> There is another case that is more annoying:
>>
>> 1. Run `emacs -q', the current buffer is "*scratch*".
>>
>> 2. Type `C-h i', the current buffer is "*info*".
>>
>> 3. Type `C-h C-t', the current buffer is "TODO".
>>
>> 4. Type `C-h C-n', the current buffer is "NEWS".
>>
>> 5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good.
>>
>> 6. Type `C-x k RET', the current buffer is "*scratch*".  Why?
>>    The previous buffer is "*info*", not "*scratch*"!
>
> This happened in revision 90833 of `pop-to-buffer' from 2008-09-13.
> Since then `pop-to-buffer' doesn't reselect the selected window.
>
> The culprit is this conditional
>
>     (unless (eq new-window old-window)
>       ;; `display-buffer' has chosen another window, select it.
>
> which does not select the *info* window because it was already selected
> before but obviously doesn't record the *info* buffer either :-(
>
> I'm running my code without the conditional for more than two months
> now so it shouldn't harm if you remove it as well.

I tried to remove the conditional, but it doesn't help.
Maybe some other your changes fixed that?

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

Re: Window configurations

[martin rudalics]

 > I tried to remove the conditional, but it doesn't help.
 > Maybe some other your changes fixed that?

[Indeed.  Just that I had the fix in my build but no more in the
source so it took me three hours to find out what really happened.]

It's a longstanding bug in Fselect_window.  At the time I changed
`pop-to-buffer' I wasn't aware of it and thus only added to the
confusion.

Please do two things: In Fselect_window move the

   if (NILP (norecord))
     record_buffer (w->buffer);

up into the

   if (NILP (norecord))
     {
       ++window_select_count;
       XSETFASTINT (w->use_time, window_select_count);
     }

clause such that the latter reads as

   if (NILP (norecord))
     {
       ++window_select_count;
       XSETFASTINT (w->use_time, window_select_count);
       record_buffer (w->buffer);
     }

so the buffer gets recorded even if the selected window does not change.

In addition, remove the conditional from `pop-to-buffer' as explained
before.  If you don't encounter problems, please check it in.

martin


PS: I'm not sure whether in Fselect_window this

   /* Go to the point recorded in the window.
      This is important when the buffer is in more
      than one window.  It also matters when
      redisplay_window has altered point after scrolling,
      because it makes the change only in the window.  */
   {
     register int new_point = marker_position (w->pointm);
     if (new_point < BEGV)
       SET_PT (BEGV);
     else if (new_point > ZV)
       SET_PT (ZV);
     else
       SET_PT (new_point);
   }

stuff should be moved in front of the

   if (EQ (window, selected_window))
     return window;

as well.  Any ideas?

Re: Window configurations

[Juri Linkov]

>   if (NILP (norecord))
>     {
>       ++window_select_count;
>       XSETFASTINT (w->use_time, window_select_count);
>       record_buffer (w->buffer);
>     }
>
> so the buffer gets recorded even if the selected window does not change.
>
> In addition, remove the conditional from `pop-to-buffer' as explained
> before.  If you don't encounter problems, please check it in.

Thanks for finding the source of this bug.  It works now.
Stefan, is it ok to install this change?

> PS: I'm not sure whether in Fselect_window this
>
>   /* Go to the point recorded in the window.
>      This is important when the buffer is in more
>      than one window.  It also matters when
>      redisplay_window has altered point after scrolling,
>      because it makes the change only in the window.  */
>   {
>     register int new_point = marker_position (w->pointm);
>     if (new_point < BEGV)
>       SET_PT (BEGV);
>     else if (new_point > ZV)
>       SET_PT (ZV);
>     else
>       SET_PT (new_point);
>   }
>
> stuff should be moved in front of the
>
>   if (EQ (window, selected_window))
>     return window;
>
> as well.  Any ideas?

But this will move it in front of Fset_buffer too.  Is this right?

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

Re: Window configurations

[Stefan Monnier]

>> so the buffer gets recorded even if the selected window does not change.
>> In addition, remove the conditional from `pop-to-buffer' as explained
>> before.  If you don't encounter problems, please check it in.

> Thanks for finding the source of this bug.  It works now.
> Stefan, is it ok to install this change?

I'm not sure what kind of impact this might have, but we can try
checking it in and then seeing what changes.


        Stefan

Re: Window configurations

[Juri Linkov]

>>> so the buffer gets recorded even if the selected window does not change.
>>> In addition, remove the conditional from `pop-to-buffer' as explained
>>> before.  If you don't encounter problems, please check it in.
>
>> Thanks for finding the source of this bug.  It works now.
>> Stefan, is it ok to install this change?
>
> I'm not sure what kind of impact this might have, but we can try
> checking it in and then seeing what changes.

Checked in.

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

Re: Window configurations

[martin rudalics]

 >> PS: I'm not sure whether in Fselect_window this
[...]
 >> stuff should be moved in front of the
 >>
 >>   if (EQ (window, selected_window))
 >>     return window;
 >>
 >> as well.  Any ideas?
 >
 > But this will move it in front of Fset_buffer too.  Is this right?

I'm afraid not.  It would probably also interact badly with the
set_marker_both stuff.  I suppose most of what is missing here is later
covered up by the command loop synchronizing selected window and current
buffer via set_buffer_internal_1.

One of my favorite mysteries is why, when WINDOW is already selected,
`select-window' should not set the current buffer.

martin

Re: Window configurations

[Stefan Monnier]

> One of my favorite mysteries is why, when WINDOW is already selected,
> `select-window' should not set the current buffer.

I think the answer is simply "because it's not needed".  In contrast,
when we do have to change the selected window, we have to pay attention
to the point/window-point correspondence which makes it necessary to set
the buffer.  Of course, this necessity could be made just internal.

IOW, it's mostly accidental.


        Stefan

Re: Window configurations

[martin rudalics]

 >> One of my favorite mysteries is why, when WINDOW is already selected,
 >> `select-window' should not set the current buffer.
 >
 > I think the answer is simply "because it's not needed".  In contrast,
 > when we do have to change the selected window, we have to pay attention
 > to the point/window-point correspondence which makes it necessary to set
 > the buffer.  Of course, this necessity could be made just internal.
 >
 > IOW, it's mostly accidental.

What I meant was that the current implementation gives very contrived
semantics.  The test in

(with-current-buffer buffer
   (with-selected-window window
     (eq (current-buffer) buffer)

succeeds unless `window' was not selected and did not display `buffer'
at the time `with-selected-window' was entered.

martin

Re: Window configurations

[Stefan Monnier]

> What I meant was that the current implementation gives very contrived
> semantics.

I know.  Maybe we should "fix it", as you implicitly suggested, by
simply always doing a set-buffer.  It's fairly risky, kind of like
replacing every (save-excursion (set-buffer foo) bar) with
(with-current-buffer foo bar) ;-)


        Stefan

Re: Window configurations

[Lennart Borgman]

On Mon, Jun 7, 2010 at 5:36 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> What I meant was that the current implementation gives very contrived
>> semantics.
>
> I know.  Maybe we should "fix it", as you implicitly suggested, by
> simply always doing a set-buffer.  It's fairly risky, kind of like
> replacing every (save-excursion (set-buffer foo) bar) with
> (with-current-buffer foo bar) ;-)


Why is it risky? This is on the display level so to say and always
associated with windows on the display. I think there will be no big
surprises.

Re: Window configurations

[martin rudalics]

 > I know.  Maybe we should "fix it", as you implicitly suggested, by
 > simply always doing a set-buffer.  It's fairly risky, kind of like
 > replacing every (save-excursion (set-buffer foo) bar) with
 > (with-current-buffer foo bar) ;-)

I haven't looked into the calls in xdisp.c but I hope you're right ;-)

Vivisecting Fselect_window reveals at least three suspicious components.
------------------------------------------------------------------------
   /* Store the current buffer's actual point into the
      old selected window.  It belongs to that window,
      and when the window is not selected, must be in the window.  */
   if (!NILP (selected_window))
     {
       ow = XWINDOW (selected_window);
       if (! NILP (ow->buffer))
	set_marker_both (ow->pointm, ow->buffer,
			 BUF_PT (XBUFFER (ow->buffer)),
			 BUF_PT_BYTE (XBUFFER (ow->buffer)));
     }

I suppose "current buffer" means the buffer displayed in the currently
selected window which is not the window we are going to select.  Why the
heck do we care about storing `point' into that window's `window-point'?
------------------------------------------------------------------------
   XBUFFER (w->buffer)->last_selected_window = window;

IMHO it's a bug to not set last_selected_window when the selected window
did not change but the buffer displayed in it did change.  It means that
when we remove the buffer from the window and display it in that window
again Emacs will not go to the previous `window-point' but to `point'.
------------------------------------------------------------------------
   /* Go to the point recorded in the window.
      This is important when the buffer is in more
      than one window.  It also matters when
      redisplay_window has altered point after scrolling,
      because it makes the change only in the window.  */
   {
     register int new_point = marker_position (w->pointm);
     if (new_point < BEGV)
       SET_PT (BEGV);
     else if (new_point > ZV)
       SET_PT (ZV);
     else
       SET_PT (new_point);
   }

It sets `point' to `window-point'.  If the selected window didn't change
but the buffer did, the buffer's `point' is not changed.  Obviously,
command_loop_1 will fix this eventually but any code running after the
call of `select-window' will have `point' positioned as whether the
selected window changed or not.
------------------------------------------------------------------------
Neither of these seems to have bothered anyone so far.  But the problem
Juri brought up wasn't noticed either - till now.

martin

Re: Window configurations

[Stefan Monnier]

> I suppose "current buffer" means the buffer displayed in the currently
> selected window which is not the window we are going to select.  Why the
> heck do we care about storing `point' into that window's `window-point'?

Because when a window is selected, the window-point is actually stored
in the buffer's point.  So when we deselect it we have to copy the
buffer's point back into the window-point.


        Stefan

Re: Window configurations

[martin rudalics]

 > Because when a window is selected, the window-point is actually stored
 > in the buffer's point.  So when we deselect it we have to copy the
 > buffer's point back into the window-point.

Thanks.  No way to get around this.  So I'd rather skip this part when
the selected window does not change.

Initially, I wanted to store a pointer to a window's buffer list in a
window configuration but that apparently breaks things when restoring
the configuration.  IIUC I'd have to copy window buffer lists when
saving a configuration since otherwise they can get messed up by an
intermittent `delq'.  Copying buffer lists is 100% not worth the
trouble.  Hence any change to a window's buffer list that happens inside
a window excursion will get recorded (including selections that happen
inside a window that is deleted when the configuration is restored).

martin

Re: Window configurations

[Stefan Monnier]

> Initially, I wanted to store a pointer to a window's buffer list in a
> window configuration but that apparently breaks things when restoring
> the configuration.  IIUC I'd have to copy window buffer lists when
> saving a configuration since otherwise they can get messed up by an
> intermittent `delq'.  Copying buffer lists is 100% not worth the
> trouble.  Hence any change to a window's buffer list that happens inside
> a window excursion will get recorded (including selections that happen
> inside a window that is deleted when the configuration is restored).

I'm not sure if keeping window's buffer-lists in window-configs would be
a good thing, and/or if it's worth the trouble, but we could use a new
Fremq rather Fdelq.


        Stefan

Re: Window configurations

[martin rudalics]

 > I'm not sure if keeping window's buffer-lists in window-configs would be
 > a good thing, and/or if it's worth the trouble, but we could use a new
 > Fremq rather Fdelq.

I don't understand how that would help here.  Besides, `remq' does copy
the list so what would we gain?

Anyway, I'm afraid that our previous "fix" of `select-window' was wrong:
With two frames f1 and f2 and f1 selected, selecting a window on f2 will
cause that window's buffer get recorded for f1 :-(

martin

Re: Window configurations

[Stefan Monnier]

> problem.  In particular, I display eldoc output on a per-window basis in
> a one-line window below the code window (I hate eldoc output in the echo
> area, I don't like it in the header line, and I very much hate tooltips.
> Ideally, there would be a bottom-line right above the mode-line where I
> could put it, but ...).

Interesting problem in itself, indeed.  Luckily, I'm satisfied with the
each area for that purpose.  Good luck!

> Now I'm killing such an eldoc-buffer as soon as it is no more shown in
> its eldoc-window.  But when (1) a `save-window-excursion' restores the
> saved configuration and (2) it has to restore a former eldoc-window that
> was deleted within the body of `save-window-excursion', I get the first
> buffer from `buffer-list' shown in that window which is downright silly.

I know you think dedicated windows suck and that I like them so much
that "when you have a hammer everything looks like a nail", but I think
this is really a good case to mark the window dedicated.  I'm not sure
whether set-window-configuration would do the right thing currently
(kill the window if the buffer died), but if it doesn't, it'd be
a clear bug that needs fixing.


        Stefan

Re: Window configurations

[martin rudalics]

 > Interesting problem in itself, indeed.  Luckily, I'm satisfied with the
 > each area for that purpose.  Good luck!

The echo area sucks for two reasons: When you have windows above each
other and work in the upper one, your eyes have to continuously pass
through the lower window down to the echo area.  What's worse, however,
is that the eldoc message obscures all sorts of other messages which is
particularly annoying when you want to read them during debugging.

 > I know you think dedicated windows suck and that I like them so much
 > that "when you have a hammer everything looks like a nail", but I think
 > this is really a good case to mark the window dedicated.  I'm not sure
 > whether set-window-configuration would do the right thing currently
 > (kill the window if the buffer died), but if it doesn't, it'd be
 > a clear bug that needs fixing.

I don't think that dedicated windows suck and even went so far as to
give them an entire section in the Elisp manual ;-)

On the average, 50% of my windows are dedicated and they suit my needs
well.  So I think that hardly anyone out there uses dedicated windows
more than me.  And my eldoc-windows are obviously dedicated - they would
not be usable otherwise.

Having `set-window-configuration' "kill the window if the buffer died"
is not entirely trivial though.  What shall we do when the last window
has a deleted buffer?  Kill the frame?

martin

Re: Window configurations

[Stefan Monnier]

>> Interesting problem in itself, indeed.  Luckily, I'm satisfied with the
>> echo area for that purpose.  Good luck!
> The echo area sucks for two reasons: When you have windows above each
> other and work in the upper one, your eyes have to continuously pass
> through the lower window down to the echo area.  What's worse, however,
> is that the eldoc message obscures all sorts of other messages which is
> particularly annoying when you want to read them during debugging.

Yes, I'm not trying to argue it's perfect.  Just that I'm satisfied for
my own use.  Of course we should try to minimize the number of cases
where it hides useful info.  One possibility is to try and provide
better control so the user can prevent eldoc from showing up while she's
reading a previous message, and so that she can remove the eldoc message
to recover the previous message.

> Having `set-window-configuration' "kill the window if the buffer died"
> is not entirely trivial though.

What kind of problems did you encounter (other than the one below)?

> What shall we do when the last window has a deleted buffer?
> Kill the frame?

That could make sense, yes, since that's what would happen if the
deletion had taken place while the frame was displayed.  But we could
also fallback to the current behavior in that corner case, since
I'd assume it to be rare anyway (i.e. not worth spending too much time,
at least for now).


        Stefan

Re: Window configurations

[martin rudalics]

 >> Having `set-window-configuration' "kill the window if the buffer died"
 >> is not entirely trivial though.
 >
 > What kind of problems did you encounter (other than the one below)?

A minor technical annoyance - I have to construct a list of windows to
delete because I cannot delete a window before restoration is complete.
And obviously I have to assign some buffer during restoration just to
handle the case where the deletion fails for whatever reason.

 >> What shall we do when the last window has a deleted buffer?
 >> Kill the frame?
 >
 > That could make sense, yes, since that's what would happen if the
 > deletion had taken place while the frame was displayed.  But we could
 > also fallback to the current behavior in that corner case, since
 > I'd assume it to be rare anyway (i.e. not worth spending too much time,
 > at least for now).

We'd still have to solve the problem where a frame is the last frame
anyway.  But we haven't yet decided what to do with non-dedicated
windows that lose their buffers.  Solving that more general problem
should solve this corner case too.

martin

Re: Window configurations

[Stefan Monnier]

>>> Having `set-window-configuration' "kill the window if the buffer died"
>>> is not entirely trivial though.
>> What kind of problems did you encounter (other than the one below)?
> A minor technical annoyance - I have to construct a list of windows to
> delete because I cannot delete a window before restoration is complete.
> And obviously I have to assign some buffer during restoration just to
> handle the case where the deletion fails for whatever reason.

I think it's OK.  If you can provide a patch for it, please submit (or
install) it.

> We'd still have to solve the problem where a frame is the last frame
> anyway.  But we haven't yet decided what to do with non-dedicated
> windows that lose their buffers.  Solving that more general problem
> should solve this corner case too.

The desired behavior for (non-sole) dedicated windows is pretty clear,
so we can install a fix for it right away.

For the remaining cases, it's much less clear what would be the "right"
behavior (it seems to depend on the intention behind the save&restore of
the window-config, so it should probably be handled at some other
level).


        Stefan

Re: Window configurations

[Kevin Rodgers]

martin rudalics wrote:
>  > The point of set-window-configuration-from-sexp is to restore the
>  > configuration of windows, not to duplicate the functionality of 
> desktop.el.
> 
> That's true from a theoretical point of view.  It separates concerns in
> a clear way and gives clean semantics.  Hence I fully agree with you.
> 
> Unfortunately, in personal practice, I'm suffering from a quite similar
> problem.  In particular, I display eldoc output on a per-window basis in
> a one-line window below the code window (I hate eldoc output in the echo
> area, I don't like it in the header line, and I very much hate tooltips.
> Ideally, there would be a bottom-line right above the mode-line where I
> could put it, but ...).

Have you tried displaying a tooltip in that position, by let-binding
tooltip-frame-parameters around the call to tooltip-show?

,----[ C-h f tooltip-show RET ]
| tooltip-show is a compiled Lisp function in `tooltip.el'.
| (tooltip-show text &optional use-echo-area)
|
| Show a tooltip window displaying text.
|
| Text larger than `x-max-tooltip-size' is clipped.
|
| If the alist in `tooltip-frame-parameters' includes `left' and `top'
| parameters, they determine the x and y position where the tooltip
| is displayed.  Otherwise, the tooltip pops at offsets specified by
| `tooltip-x-offset' and `tooltip-y-offset' from the current mouse
| position.
|
| Optional second arg use-echo-area non-nil means to show tooltip
| in echo area.
|
| [back]
`----

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Window configurations

[martin rudalics]

 > Have you tried displaying a tooltip in that position, by let-binding
 > tooltip-frame-parameters around the call to tooltip-show?

You convinced me ;-)

Only that `tooltip-show' displays the text in `tooltip' face, spoiling
everything.  However, `x-show-tip' works fine and is much much cheaper
than the tribulations of `eldoc-display-message-no-interference-p' and
`eldoc-pre-command-refresh-echo-area'.

martin

Re: Window configurations

[Lennart Borgman]

On Sat, May 8, 2010 at 3:54 PM, martin rudalics <rudalics@gmx.at> wrote:
>> Have you tried displaying a tooltip in that position, by let-binding
>> tooltip-frame-parameters around the call to tooltip-show?
>
> You convinced me ;-)
>
> Only that `tooltip-show' displays the text in `tooltip' face, spoiling
> everything.  However, `x-show-tip' works fine and is much much cheaper
> than the tribulations of `eldoc-display-message-no-interference-p' and
> `eldoc-pre-command-refresh-echo-area'.

How about adding that to the trunk?

Re: Window configurations

[martin rudalics]

 > How about adding that to the trunk?

We could add something like that eventually.  However, I suppose that
most people would like to see the tooltip frame at the right of `point'
in some otherwise blank space of the screen.  This means that I probably
should be able to format argument lists and doc-strings vertically.
And, interaction with the mouse cursor would have to be evaluated too.

Also, tooltips currently have quite a number of annoying features which
must be corrected first.

martin

Re: Window configurations

[Lennart Borgman]

On Sun, May 9, 2010 at 4:01 PM, martin rudalics <rudalics@gmx.at> wrote:
>> How about adding that to the trunk?
>
> We could add something like that eventually.  However, I suppose that
> most people would like to see the tooltip frame at the right of `point'
> in some otherwise blank space of the screen.

Does not this very much depend on the purpose of the tooltip?

>   This means that I probably
> should be able to format argument lists and doc-strings vertically.
> And, interaction with the mouse cursor would have to be evaluated too.
>
> Also, tooltips currently have quite a number of annoying features which
> must be corrected first.

Maybe a topmost frame is not the best frame style. I
suppose "transient-for" (on w32 "owned") is better. This was discussed
a bit in the thread below:

  http://comments.gmane.org/gmane.emacs.devel/124334

Re: Window configurations

[martin rudalics]

 >> We could add something like that eventually.  However, I suppose that
 >> most people would like to see the tooltip frame at the right of `point'
 >> in some otherwise blank space of the screen.
 >
 > Does not this very much depend on the purpose of the tooltip?

Maybe.  But displaying the tooltip frame right above the modeline is
just my personal preference.  I doubt many people will like it.

 >> Also, tooltips currently have quite a number of annoying features which
 >> must be corrected first.
 >
 > Maybe a topmost frame is not the best frame style. I
 > suppose "transient-for" (on w32 "owned") is better.

Maybe.  But first of all, the mode-line updating in `delete-frame' has
to be made conditional on non-tooltip frames since currently this
interacts very badly with timers.  (There's also a splendid sillyness in
delete_frame, apparently introduced by yours truly, which allows running
hooks when they shouldn't.)  But so far I don't understand why we have
to always delete tooltip frames in the first place.  Also, tooltip
frames should be either moved or made invisible whenever frames are
resized - the current behavior is intolerable in this regard.  Finally,
the `tooltip-show' interface should be improved to allow, for example,
merging with other faces.  BTW, is there any way to make tooltip frames
transparent?

martin

Re: Window configurations

[martin rudalics]

 > Do you plan to create a branch for your rewrite of window.c?
 > It would be very interesting to look at it.

I've now put up a branch called window-pub.  Please have a look.

The major aspects are

- Internal windows exposed in Elisp

- Window resizing moved to Elisp

- Basic support for window groups and compound windows

ChangeLog entries are rudimentary.

The branch does NOT incorporate any of

- the window local buffer list implementation,

- the new semantics for the second argument of `display-buffer',

because I'm afraid that providing these will break things.  It will take
some time to add them ;-)

martin

Re: Window configurations

[Juri Linkov]

>> Do you plan to create a branch for your rewrite of window.c?
>> It would be very interesting to look at it.
>
> I've now put up a branch called window-pub.  Please have a look.

Thank you!

> The major aspects are
>
> - Internal windows exposed in Elisp
>
> - Window resizing moved to Elisp
>
> - Basic support for window groups and compound windows

Could you put a short informal explanation of every aspect
to a file (e.g. README.window-pub) in the window-pub branch,

> ChangeLog entries are rudimentary.
>
> The branch does NOT incorporate any of
>
> - the window local buffer list implementation,
>
> - the new semantics for the second argument of `display-buffer',
>
> because I'm afraid that providing these will break things.  It will take
> some time to add them ;-)

It's not terrible to break things in the branch ;-)

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

Re: Window configurations

[martin rudalics]

 > Could you put a short informal explanation of every aspect
 > to a file (e.g. README.window-pub) in the window-pub branch,

Please try to read the Elisp manual section on windows first.

 > It's not terrible to break things in the branch ;-)

Sure.  But the remainder works here quite well for some times and I'd
hate to lose any feedback on that part due to bugs in features I have
not yet tested throughly myself.

martin

Re: Window configurations

[Juanma Barranquero]

I know you're not supposed to do that (I was just stress-testing) but after

   (setq window-safe-min-height 0 window-min-height 0)

you can make a one-line window with no mode-line. Shouldn't that be checked?

    Juanma

Re: Window configurations

[martin rudalics]

 > I know you're not supposed to do that (I was just stress-testing) but after
 >
 >    (setq window-safe-min-height 0 window-min-height 0)
 >
 > you can make a one-line window with no mode-line. Shouldn't that be checked?

I'm cheating here.  The doc-string of the former says

   "The absolut minimum number of lines of a window.
Anything less might crash Emacs."

but you can quietly set it to an arbitrary value.  Emacs will crash ;-)
regardless of whether this has been changed - the value 1 is hardcoded
in C.

Now as a matter of fact if you do

   (setq window-safe-min-height 0)
   (setq window-min-height 0)

you can make the modeline of a window disappear.  This is intentional
for the following reason: When I drastically shrink a frame with the
window manager I prefer making windows without a modeline rather than
delete them.  The modelines will reappear as soon as the frame grows
again.  Unfortunately, I don't see any way to prevent this in the case
you describe since the window resizing code is in Elisp.  IIUC, even
putting these constants in pure store wouldn't prevent it.  But, after
all, anyone who changes the value of a constant is on her own?

martin

Re: Window configurations

[Juanma Barranquero]

On Tue, Jun 29, 2010 at 14:16, martin rudalics <rudalics@gmx.at> wrote:

> you can make the modeline of a window disappear.  This is intentional
> for the following reason: When I drastically shrink a frame with the
> window manager I prefer making windows without a modeline rather than
> delete them.  The modelines will reappear as soon as the frame grows
> again.

OK, this makes sense.

> But, after
> all, anyone who changes the value of a constant is on her own?

Sure.

    Juanma

Re: Window configurations

[Juri Linkov]

> The major aspects are
>
> - Internal windows exposed in Elisp

Does this mean that now it's possible to create/restore
window configurations in Elisp?

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

Re: Window configurations

[martin rudalics]

 > Does this mean that now it's possible to create/restore
 > window configurations in Elisp?

As a matter of fact I expected you to write that.  Your proposals in
this context were pretty convincing so that I even threw out some
routines I wrote earlier (mostly for putting frames into windows and
vice versa).

So please have a look into what I wrote and tell me what you need to
make your code work.  We could provide functions like `make-window',
`set-window-parent', `set-window-vchild', ... in Elisp and write a C
function - say `replace-window' - which replaces an existing (internal)
window with an (internal) window constructed by the routines mentioned
before.

But I'd do that iff your "construct configuration from sexps" approach
really profited from it since we'd have to augment the window structure
by new_parent, new_vchild, new_sibling, ... fields which is cumbersome.

martin

Re: Window configurations

[Juri Linkov]

> So please have a look into what I wrote and tell me what you need to
> make your code work.  We could provide functions like `make-window',
> `set-window-parent', `set-window-vchild', ... in Elisp and write a C
> function - say `replace-window' - which replaces an existing (internal)
> window with an (internal) window constructed by the routines mentioned
> before.

Ok, I'll have a look into what is necessary to rewrite
`current-window-configuration' and `set-window-configuration'
in Elisp.

> But I'd do that iff your "construct configuration from sexps" approach
> really profited from it since we'd have to augment the window structure
> by new_parent, new_vchild, new_sibling, ... fields which is cumbersome.

I guess after rewriting existing two functions `current-window-configuration'
and `set-window-configuration' in Elisp, implementing "construct
configuration from sexps" would be trivial.

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

Re: Gtk tabs in emacs, new branch

[Stefan Monnier]

> Loading native-tabs.el (source)...
> Attempt to autoload define-minor-mode while preparing to dump

Looks like src/Makefile forgot to byte-compile native-tabs.el before
dumping Emacs.


        Stefan

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Clicking on the tab's 'X', should not close the file? It deletes only
> the tab, the buffer being still 'visited' by Emacs. (I do not remember
> a similar behavior with other applications using tabs.)

The behaviour of other applications is not necessarily a draft for
useful features. Emacs (luckily) has thousands of features where I do
not remember a similar behavior with other applications.

I would think of tabs as of a different kind of windows. In Emacs
closing a window and killing a buffer are distinct actions. Tabs should
behave the same.

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Daniel Colascione]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/2/10 12:19 PM, Uwe Siart wrote:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>> Clicking on the tab's 'X', should not close the file? It deletes only
>> the tab, the buffer being still 'visited' by Emacs. (I do not remember
>> a similar behavior with other applications using tabs.)
> 
> The behaviour of other applications is not necessarily a draft for
> useful features.

On the other hand, being gratuitously different will just alienate
users, especially new ones. When it comes to new users, programs aren't
judged by what they can be configured to do, but what they do by default.

> Emacs (luckily) has thousands of features where I do
> not remember a similar behavior with other applications.

Usually because Emacs predates these other applications.

> I would think of tabs as of a different kind of windows. In Emacs
> closing a window and killing a buffer are distinct actions. Tabs should
> behave the same.
> 

It seems the most natural thing to do is to kill the buffer iff the
window killed by closing a tab is the last window showing the given buffer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAku2N/gACgkQ17c2LVA10VutbgCfTsOS+49V3Q4os2iYnEFsBaxj
IK0AoMsnz7j+iHJDTon45dws6pUNzf10
=Y1dV
-----END PGP SIGNATURE-----

Re: Gtk tabs in emacs, new branch

[Stefan Monnier]

> It seems the most natural thing to do is to kill the buffer iff the
> window killed by closing a tab is the last window showing the given buffer.

[ I mostly use one frame per buffer and indeed have such a key binding
to kill the buffer and the frame. ]
Doing it for the *Messages* buffer is a bad idea, in my experience.
In any case, this issue has nothing to do with tabs since it also
appears in many other contexts.


        Stefan

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Daniel Colascione <daniel@censorshipresearch.org> writes:

>> Emacs (luckily) has thousands of features where I do
>> not remember a similar behavior with other applications.
>
> Usually because Emacs predates these other applications.

This is a big advantage of Emacs over "these other applications".

> It seems the most natural thing to do is to kill the buffer iff the
> window killed by closing a tab is the last window showing the given
> buffer.

I disagree. Why should it be? In Emacs there can be buffers with
information that I need over and over again. But I don't want do kill
this information just because I don't need it in a window at the moment.

Your rationale is to disable Emacs because "modern applications" are
disabled and because "modern users" expect those disabilities.

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Uwe Siart <usenet@siart.de> writes:

> I disagree. Why should it be? In Emacs there can be buffers with
> information that I need over and over again. But I don't want do kill
> this information just because I don't need it in a window at the moment.

What about making it customizable by a variable like
'close-last-tab-kills-buffer' that can be set to t or nil?

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Perhaps we need something like 'M-x tabs-mode' (by default possibly!
> :-))

Please don't enable such stuff by default. The user should be able to
decide by himself how many frames/windows/(tabs) he would like to open.

Also IMO tabs are not that useful as many (windows) users think because
there's only one tab visible at a time. Emacs' concept of frames and
windows (and iswitchb-mode) is much better here.

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Uwe Siart skrev:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>> Perhaps we need something like 'M-x tabs-mode' (by default possibly!
>> :-))
> 
> Please don't enable such stuff by default. The user should be able to
> decide by himself how many frames/windows/(tabs) he would like to open.
> 
> Also IMO tabs are not that useful as many (windows) users think because
> there's only one tab visible at a time. Emacs' concept of frames and
> windows (and iswitchb-mode) is much better here.
> 

It depends.  Making many frames is no good if you don't have much screen space 
and want to view a large portion of your file.  Many windows also reduces the 
amount of text you can view at once.  Tabs have a role.  Consider the use case 
of viewing 3 or 4 log files with very long lines at once.  I currently do that 
by making Emacs fullscreen and switch buffers.  Having tabs for this would be 
a small improvement, as the tabs give the file name and makes for faster 
switching.  But I suspect long time Emacs users have developed habits that 
makes tabs less desirable.

An iswitcht-mode for tabs would probably be a good idea though.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> An iswitcht-mode for tabs would probably be a good idea though.

https://addons.mozilla.org/en-US/firefox/addon/3919

brings Emacs' iswitchb-mode to Firefox and back to Emacs :-)

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

Re: Gtk tabs in emacs, new branch

[Stephen J. Turnbull]

Uwe Siart writes:
 > Angelo Graziosi <angelo.graziosi@alice.it> writes:
 > 
 > > Perhaps we need something like 'M-x tabs-mode' (by default possibly!
 > > :-))
 > 
 > Please don't enable such stuff by default. The user should be able to
 > decide by himself how many frames/windows/(tabs) he would like to
 > open.

Opening many frames or windows is annoying to me, because I invariably
have too many open when I shut down for whatever reason. and they can
take up a lot of screen/frame real estate.  If I'm going to have tabs
for 99.9% of a session though, I'm just as happy having the tabs at
startup as long as the top tab is sane (typically defined as "the
selected tab in the selected frame at close-and-save time").  The
extra 1.5 or 2 lines of text is almost never an issue.

I think this is an even better candidate for "try as default and wait
for screams of pain" than delete-selection-mode.  People who hate it
will only have to turn it off once.  Many people who might love it
won't find out about it for years if it's not default.

BTW, at one time I had the same intuition you do.  Then XEmacs put in
tabs and enabled them by default.  What I discovered is that at
startup, the window I was working in *last* is a very good candidate
for top tab, and it's at the top of buffer-list.  What surprised me is
that the second-to-last window was typically not a good guess for the
second most important; rather it was often buried down the list at
fifth or sixth.  Tabs made it quite easy to find those precisely
because they're in-your-face.

iswitch and friends might make that advantage quite small for most
users; I don't know.  On the other hand, the actual cost is *very*
small if you're going to enable tabs anyway.

RE: Gtk tabs in emacs, new branch.

[grischka]

 > It's not clear to me, for example, what you mean by tabs (necessarily)
 > doing the same thing to different objects.

See, tabs are defined by their shape, more by their placement and
mostly by their action.  Which is to "switch content in the associated
window".  If it does not perform this action then it is not a tabs
control but just a row of buttons.

To give another example:  A scrollbar is defined mostly by its action
to "scroll content in the associated window".  Of course you could use
the scrollbar widget just as well to adjust your speaker volume, but
then it wouldn't be a scrollbar, even if it looked like one.

Aside from that it is completely unnecessary and boring to overload
widgets with alien functionality.  If for example you like to have
a row of buttons to switch color themes in the buffer, then well,
just use a row of (possibly colored) buttons.

--- grischka

Re: Gtk tabs in emacs, new branch.

[A. Soare]

I did understand what he did; I did the same 2 years ago, and gave up, because it is a rude method of implementing tabs for emacs in this manner.

I suggest you to do something like that:

opening a new tab, a function will initialize the structure of that tab.

For example, if you want a tab to represent a window-configuration, it will need an initialization function like that:

(let (new-tab (get-current-window-configuration))
     ...)

or , if you want the tab  to switch to *scratch* buffer,


(switch-to-buffer *scratch), etc

Every tab should have also a function of hide-event, in which it saves its old configuration, like

(setq new-tab (get-current-conf))

etc.


You might need a tab to represent a buffer of a compilation, or to start a compilation and switch to its buffer. In this case of use of a tab, you need no need of initializing a tab as a win-conf, etc.

It will be needed a local environment to a tab, such that the function associated to close/switch/hide be able to find the same new-tab variable, as initialized by init-function, and be hidden in other tabs, etc

I suggest you not to hurry to install the tabs as implemented by Jan D. Once installed, it might be difficult in future to switch to a nice implementation of tabs.

I have written the tabs for console, and if they are implemented as I like, I will send it when I have time.

Please, do not hurry to install such an implementation. Please improve it to accept lisp function for every gtk event, etc, before installing, and to suppose nothing about what a tab is.








____________________________________________________

 Voila People a retrouvé les photos que les stars aimeraient oublier sur http://people.voila.fr/people/mediatheque/dossiers/ces-stars-pour-qui-le-temps-a-bien-fait-les-choses.html

Re: Gtk tabs in emacs, new branch.

[A. Soare]

> A. Soare wrote:
> 
> > 
> > I do not want to add widgets to an implementation based on another
> > idea , than that of a lisp function for all kinds of events: a lisp
> > function at the creation, a function when closing, switching, etc.
> 
> It isn't any "idea" as such, it is practicallity and user experience. 
> For example, I tried having switching in elisp, but it is too slow 
> (causes flicker) and there are race conditions between when the widget 
> does the switching and when Emacs thinks the switch is done.
> 
> There is nothing in the current implementation that excludes lisp 
> functions for switching, creation, e.t.c, but it doesn't give any 
> advantages, just complications.
> 
> Also, creation may be by drag and drop from other frames.  Due to the 
> way Gtk+ implements this, and how Emacs lisp may interact with GUI 
> callbacks, doing that in lisp isn't possible.
> 
> Having an idea may be good, but sometimes reality requires other ways.
> 


Ok, good luck.



____________________________________________________

 Voila People a retrouvé les photos que les stars aimeraient oublier sur http://people.voila.fr/people/mediatheque/dossiers/ces-stars-pour-qui-le-temps-a-bien-fait-les-choses.html

Re: Gtk tabs in emacs, new branch.

[A. Soare]

> It is too early to tell.  The implementation and design is still 
> evolving.  Implementations other than for Gtk+ makes sense in any case.
> 
> 	Jan D.


Before the implementation that I have in mind now, I have tried more versions, and I gave up.

I do not want to add widgets to an implementation based on another idea , than that of a lisp function for all kinds of events: a lisp function at the creation, a function when closing, switching, etc.

So I do not want to work on an already - implemented version of tabs, as time as that implementation does not share this idea.

It does not matter, I can do other tasks for emacs, if tabs will be implemented by someone else.


Alin
---
Wenn ich Kultur höre, nehme ich meine Pistole.



____________________________________________________

 Voila People a retrouvé les photos que les stars aimeraient oublier sur http://people.voila.fr/people/mediatheque/dossiers/ces-stars-pour-qui-le-temps-a-bien-fait-les-choses.html

Re: Gtk tabs in emacs, new branch.

[Jan D.]

A. Soare wrote:

> 
> I do not want to add widgets to an implementation based on another
> idea , than that of a lisp function for all kinds of events: a lisp
> function at the creation, a function when closing, switching, etc.

It isn't any "idea" as such, it is practicallity and user experience. 
For example, I tried having switching in elisp, but it is too slow 
(causes flicker) and there are race conditions between when the widget 
does the switching and when Emacs thinks the switch is done.

There is nothing in the current implementation that excludes lisp 
functions for switching, creation, e.t.c, but it doesn't give any 
advantages, just complications.

Also, creation may be by drag and drop from other frames.  Due to the 
way Gtk+ implements this, and how Emacs lisp may interact with GUI 
callbacks, doing that in lisp isn't possible.

Having an idea may be good, but sometimes reality requires other ways.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> It isn't any "idea" as such, it is practicallity and user experience. For
> example, I tried having switching in elisp, but it is too slow (causes
> flicker) and there are race conditions between when the widget does the
> switching and when Emacs thinks the switch is done.

> There is nothing in the current implementation that excludes lisp
> functions for switching, creation, e.t.c, but it doesn't give any
> advantages, just complications.

Tabs may seem like a good idea to switch between different
window-configurations, but there can actually be other uses for it.
And even for that use, there can be different choices in terms of which
tabs to show, ...
All that needs to be written in Lisp.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> Tabs may seem like a good idea to switch between different
> window-configurations, but there can actually be other uses for it.
> And even for that use, there can be different choices in terms of which
> tabs to show, ...
> All that needs to be written in Lisp.

In the `x-tabs' branch, creating and switching tabs in the tab-bar is
implemented in Lisp in tab-bar.el where tabs can be used for anything.

The most useful application of tabs for switching window-configurations
is implemented in the separate file tab.el.

I think the `gtk-tabs' branch should do something like that.

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

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Juri Linkov skrev 2010-04-10 03.36:
>> Tabs may seem like a good idea to switch between different
>> window-configurations, but there can actually be other uses for it.
>> And even for that use, there can be different choices in terms of which
>> tabs to show, ...
>> All that needs to be written in Lisp.
>
> In the `x-tabs' branch, creating and switching tabs in the tab-bar is
> implemented in Lisp in tab-bar.el where tabs can be used for anything.
>
> The most useful application of tabs for switching window-configurations
> is implemented in the separate file tab.el.
>
> I think the `gtk-tabs' branch should do something like that.
>

Something like what?  Switching window configurations or used for anything?

Having tabs in Gtk+ is mostly to have the look and feel of the current user 
selected UI-theme, but also to behave like tabs in other applications.

Your implementation is more like a tool bar and probably more general (arrows 
in a Gtk-tab would look funny for example).  But as with the native tool bar, 
the look and feel clashes with the selected theme.

Maybe you shouldn't call it tab-bar at all, but something like action-bar.  It 
is buttons you can use for different actions.  That is not what tabs does in 
current GUI-applications.


	Jan D.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> I think the `gtk-tabs' branch should do something like that.
>
> Something like what?  Switching window configurations or used for anything?

I see two separate tasks here:

1. Using Gtk-tabs at the top the the frame to switch window configurations.
This is like tabs in web browsers and "perspectives" in Eclipse.

2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs.
This is like tabs above a subwindow in Eclipse that would allow
Emacs packages to create tabs above the window along with the header line.

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

Re: Gtk tabs in emacs, new branch.

[Tobias C. Rittweiler]

Juri Linkov <juri@jurta.org> writes:

> I see two separate tasks here:
>
> 1. Using Gtk-tabs at the top the the frame to switch window configurations.
> This is like tabs in web browsers and "perspectives" in Eclipse.
>
> 2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs.
> This is like tabs above a subwindow in Eclipse that would allow
> Emacs packages to create tabs above the window along with the header line.

I've been following the discussion only cursorly, so please excuse any
ignorance on my part, but let me chime in with a real-life use case for
the 2nd variant:

In Common Lisp you can enter the debugger on a per thread basis. So at
the moment, every time an error is signaled in a thread, a new buffer
displaying a new debugger instance pops up. In case of many threads
interacting with each other, it can easily arise that an error in one
thread leads to other threads erroring out too after some small
delay. At the moment, input focus is always stolen after each delay
because a new buffer pops up, and you're essentially forced to wait
until the system reached an equilibrium.

Now there may be existing ways to improve that situation, but I think
mode-specific tabs would fit really well: for each new error in a
thread, a new tab will be pushed onto the existing tab list of the
debugger window.

  -T.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Tobias C. Rittweiler wrote:

> I've been following the discussion only cursorly, so please excuse any
> ignorance on my part, but let me chime in with a real-life use case for
> the 2nd variant:
>

> In Common Lisp you can enter the debugger on a per thread basis. So at
> the moment, every time an error is signaled in a thread, a new buffer
> displaying a new debugger instance pops up

> Now there may be existing ways to improve that situation, but I think
> mode-specific tabs would fit really well: for each new error in a
> thread, a new tab will be pushed onto the existing tab list of the
> debugger window.
>


I don't think that in paricular is a strong a use case for juri's 2. 
relative to tabs-for-3rd-axis-for-window-splits as such  (If you haven't 
been following the thread closely admittedly the distinction may be 
unclear):

Each new debugger instance buffer could be opened in a new window, a 
window that's just put in a tab split with the other debugger instance 
windows (which might need some window group management, yes).

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Juri Linkov wrote:
>>> I think the `gtk-tabs' branch should do something like that.
>> Something like what?  Switching window configurations or used for anything?
> 
> I see two separate tasks here:
> 
> 1. Using Gtk-tabs at the top the the frame to switch window configurations.
> This is like tabs in web browsers and "perspectives" in Eclipse.
> 
> 2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs.
> This is like tabs above a subwindow in Eclipse that would allow
> Emacs packages to create tabs above the window along with the header line.
> 


Mode specific actions to tabs?

I do get a certain impression that people who propose 
non-switch-pane-of-content uses for tabs are really looking for just 
more toolbars - rows of buttons. NOT tabs, which have specific ui 
affordances towards being "for" managing stacked panes of content, and 
often the same panes that may also be tiled (like emacs).

And emacs has panes of content - windows...

Cnsider the GIMP's tab docks - You can have a layers window, channels 
window and paths window (not the gimp terminology, they actually call 
each window a "tab") docked into a tab group or a  brushes window, 
layers window and palette window.  Or whatever.  And rearrange them as 
you see fit.

[What's more, in contrast to ancient and quirky motif notebooks which 
used tabs like the index cards in a rolodex, not necessarily attached to 
every pane of content in the stack, in a splendid example of overly 
literal real-world analogy, modern guis have pretty much settled on that 
being 1:1]


Having said that, it would be possible to have both - my interwindow 
tabs as an interface for managing the window split 3rd axis, and further 
intrawindow tabs associated with a single window like a modeline, that
could either be mode-specific and presumably handled with callbacks to 
the mode code, or for what I strongly suspect people given such a 
callback api would end up wheel-reinventing repeatedly: a kind of 
narrowing the mode could initiate, with sections of the whole buffer 
narrowed to the different tabs.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> Mode specific actions to tabs?
> I do get a certain impression that people who propose
> non-switch-pane-of-content uses for tabs are really looking for just more
> toolbars - rows of buttons.

Indeed.  The current tool-bar has some serious limitations for tabs:
- the appearance isn't right.
- no text.
- can't have two "tool bars".

If we could have more flexible tool-bars (more control over the
appearance and content, more control over the possible key-bindings,
...) and if we could have more of them and placed differently
(e.g. anywhere in the window tree), then that would subsume the need for
tabs and the neds for extra header-lines.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:
>> Mode specific actions to tabs?
>> I do get a certain impression that people who propose
>> non-switch-pane-of-content uses for tabs are really looking for just more
>> toolbars - rows of buttons.
> 
> Indeed.  The current tool-bar has some serious limitations for tabs:
> - the appearance isn't right.
> - no text.

This is just a case of "nobody needed that yet".  It isn't hard to add.

> - can't have two "tool bars".
> 

Ditto for this.  However, a tool bar per window might be hard if we are 
talking native tool bars.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> - no text.
>
> This is just a case of "nobody needed that yet".  It isn't hard to add.

Gedit has text under tool-bar icons.  Some icons are not self-evident,
so text helps to understand what they do.  An option for icon/text/icon+text
would be nice for the Emacs tool-bar.

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

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>>> - no text.
>> This is just a case of "nobody needed that yet".  It isn't hard to add.
> Gedit has text under tool-bar icons.  Some icons are not self-evident,
> so text helps to understand what they do.  An option for icon/text/icon+text
> would be nice for the Emacs tool-bar.

Indeed.  But for uses like tabs, the icons might not be an option.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

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

>> Gedit has text under tool-bar icons.  Some icons are not self-evident,
>> so text helps to understand what they do.  An option for icon/text/icon+text
>> would be nice for the Emacs tool-bar.
>
> Indeed.  But for uses like tabs, the icons might not be an option.

For the per-frame tab-bar, yes.

But for interior per-window tab-bars I am completely lost now
since there is too wide range of opinions how general they should be
and what they should do.

If a tab is just a little rectangle on the screen associated
with an action, then the tab-bar is indistinguishable from the
tool-bar, so we might need only tool-bars inserted into the window-tree.

This screenshot illustrates how interior per-window tool-bars and
tab-bars could look where the Info tab-bar displays Info-breadcrumbs
and the lower tab-bar switches into compilation like in Eclipse:


[-- Attachment #2: tab-bars.png --]
[-- Type: image/png, Size: 47180 bytes --]

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


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

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> If a tab is just a little rectangle on the screen associated
> with an action, then the tab-bar is indistinguishable from the
> tool-bar, so we might need only tool-bars inserted into the window-tree.

Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
*part* of a toolbar.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Richard Stallman]

    > If a tab is just a little rectangle on the screen associated
    > with an action, then the tab-bar is indistinguishable from the
    > tool-bar, so we might need only tool-bars inserted into the window-tree.

    Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
    *part* of a toolbar.

Logically that would be equivalent, but in GUI terms it would be
disappointing.  The visual appearance of tabs is very different from
the visual appearance of tool bar items.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>     Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
>     *part* of a toolbar.
> Logically that would be equivalent, but in GUI terms it would be
> disappointing.  The visual appearance of tabs is very different from
> the visual appearance of tool bar items.

You misunderstood: when I said "tabbar" I really meant a bar with tabs
using their usual appearance.  Just that it should be possible to place
it with buttons on either side within the same screen area where the
toolbar is displayed.



        Stefan

Re: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Indeed.  But for uses like tabs, the icons might not be an option.

Why not?  Or do you mean to say that in many cases the expected icon
would not be informative?

Eg, I have Firefox set up to "Open all [my moderated mailing lists] in
tabs".  Most of them are for XEmacs, so each tab has the list name
(informative string), the XEmacs favicon (uninformative icon), and a
close box (uninformative widget).  Obviously, just the favicon
wouldn't be very useful!

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> Obviously, just the favicon wouldn't be very useful!

My point exactly,


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Juri Linkov skrev 2010-04-13 01.47:
>>> - no text.
>>
>> This is just a case of "nobody needed that yet".  It isn't hard to add.
>
> Gedit has text under tool-bar icons.  Some icons are not self-evident,
> so text helps to understand what they do.  An option for icon/text/icon+text
> would be nice for the Emacs tool-bar.
>

For the GUI-part it is just a matter of not turning off text, like we do now. 
  But there are no short good strings available, the big part is adding those 
strings to all available tool bar items.  The help text or even the name is 
frequently too long.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> For the GUI-part it is just a matter of not turning off text, like we do
> now.

That's a very Gtk-centric point of view.  The Lucid version begs to
differ,


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-13 14.30:
>> For the GUI-part it is just a matter of not turning off text, like we do
>> now.
>
> That's a very Gtk-centric point of view.  The Lucid version begs to
> differ,
>

Yes, a bit more work there, but not terribly diffcult.

	Jan D.

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> I do get a certain impression that people who propose 
> non-switch-pane-of-content uses for tabs are really looking for just 
> more toolbars - rows of buttons. NOT tabs, which have specific ui 
> affordances towards being "for" managing stacked panes of 
> content, and often the same panes that may also be tiled (like emacs).

That tabs can be naturally used for managing stacked panes of content does not
mean that they should only be used for that. I see no contradiction between tabs
as "buttons" and tabs as selectors for stacked panes.

The former is more general, that's all. However, I would not like to see the
current Emacs tool-bar and its buttons as the model for Emacs tabs. We can do a
lot better. (See my other mail on this today.)

I agree with what Stefan said:

SM> Indeed.  The current tool-bar has some serious limitations
SM> for tabs:
SM> - the appearance isn't right.
SM> - no text.
SM> - can't have two "tool bars".
SM> 
SM> If we could have more flexible tool-bars (more control over the
SM> appearance and content, more control over the possible key-bindings,
SM> ...) and if we could have more of them and placed differently
SM> (e.g. anywhere in the window tree), then that would subsume 
SM> the need for tabs and the neds for extra header-lines.

> And emacs has panes of content - windows...

Well, "pane" kinda implies "window", so it's hard to argue with that. But Emacs
has lots of _sets_ of content (visible or not), and letting a tab select for
such a set of content is part of what I would like to see. I do not want to see
Emacs tabs being only about window selection (whether individual windows or
window configs).

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> And emacs has panes of content - windows...

Let's clear this up: content is in buffers, panes of content are windows.

There are two ways to switch content in the window according to the
tab-bar click:

1. Update content of the buffer in the selected window.
   In this case, the same buffer gets erased and new content
   inserted into it with the same mode.

2. Switch the buffer in the selected window where the tab-bar
   belongs to the buffer's window.  This has one constraint: all related
   buffers should be in the mode that provides the same tab-bar.

> Cnsider the GIMP's tab docks - You can have a layers window, channels
> window and paths window (not the gimp terminology, they actually call each
> window a "tab") docked into a tab group or a  brushes window, layers window
> and palette window.  Or whatever.  And rearrange them as you see fit.

I don't think it's right to call these things "windows".  A "window" in Emacs
is the physical area of the screen in which a buffer is displayed.  So they
are rather a layers buffer, channels buffer and paths buffer.

Another variant is to call them "window-subtrees", i.e. as part of the
window-tree in window configurations.  This makes sense too: a layers
window-subtree, channels window-subtree and paths window-subtree.

This variant supposes there is a way to create a special window that
holds the tab-bar, prepare its window-subtrees and assign them to the
tab-bar's actions.

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

Re: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Juri Linkov writes:

 > > Cnsider the GIMP's tab docks - You can have a layers window, channels
 > > window and paths window (not the gimp terminology, they actually call each
 > > window a "tab") docked into a tab group or a  brushes window, layers window
 > > and palette window.  Or whatever.  And rearrange them as you see fit.
 > 
 > I don't think it's right to call these things "windows".

That depends on the implementation.  Almost certainly, though, each of
these is actually a GUI widget, which is more or less equivalent in
Emacs terms to a window dedicated to a buffer.

 > A "window" in Emacs is the physical area of the screen in which a
 > buffer is displayed.

That's a restriction of Emacs, not of the concept of window, though.
Emacs is effectively a tiling window manager (within each frame).

 > So they are rather a layers buffer, channels buffer and paths
 > buffer.

This on the other hand is definitely not the case.  The GIMP's tabs
are indeed tightly bound to screen regions, whatever you want to call
them.  They are not conceptually independent of the screen, as Emacs
buffers are.

 > Another variant is to call them "window-subtrees",

The use of the word "call", suggesting that the underlying
implementation is the same, is misleading.  As you and others have
pointed out, in Emacs there are at least four different ways to
implement the usual tab behavior: (1) one Emacs window, clear and
rewrite the content of the associated buffer (eg, the echo area/
minibuffer); (2) one window, move point in the associated buffer
(bookmarks); (3) one window, switch associated buffers; and (4)
multiple windows, delete a window and restore another in its place.
(Here I use "Emacs window" in its general sense of a window tree,
which may be split horizontally or vertically.)

So far the only interesting argument I've seen against a general
callback implementation supporting any and all of the above, as well
as others my marginal imagination is insufficient to contain, is Jan's
claim that it results in flashing and a race condition.

In XEmacs, which implements its tab control widget with a generic
callback into Lisp, I admit that I do see flashing in builds with
Lucid toolkit and a homegrown tab control widget (based on Edward
Falk's free widget set available on the 'net, but heavily modified;
don't blame Ed!)  However I claim that this is a bug in our redisplay;
if you have a sufficiently slow X connection, you can see the tabs (in
fact the whole window) being redrawn multiple times as the result of a
single tab press.

In the ten years that we've had the tab control, I can't recall a bug
that was diagnosed as a race condition in the tab control.  So maybe
that's a problem for GTK builds, but GTK getting in the way of the
app's design is nothing new.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stephen J. Turnbull skrev:

> So far the only interesting argument I've seen against a general
> callback implementation supporting any and all of the above, as well
> as others my marginal imagination is insufficient to contain, is Jan's
> claim that it results in flashing and a race condition.
> 

There is flashing just by restoring window configurations as well, we really 
should have double buffering here.  I've introduced the purposed zero sized 
subwidgets to tabs so the tabs don't switch content at once.  This reduces 
flashing, but just to the same level as restoring window configurations.


> In the ten years that we've had the tab control, I can't recall a bug
> that was diagnosed as a race condition in the tab control.  So maybe
> that's a problem for GTK builds, but GTK getting in the way of the
> app's design is nothing new.

The race condition has more to do with Emacs event design (i.e. content change 
=> Gtk callback => elisp event => elisp function => switch windows => 
redisplay).  I removed that by saving and restoring window configurations in 
the Gtk callback and cut out the whole elisp part.  The zero sized subwidgets 
will fix that also, as content change no longer happens.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 13 Apr 2010 11:42:00 +0900
> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>, "Emacs Dev
> 	\[emacs-devel\]" <emacs-devel@gnu.org>,
> 	David De La Harpe Golden <david@harpegolden.net>
> 
>  > A "window" in Emacs is the physical area of the screen in which a
>  > buffer is displayed.
> 
> That's a restriction of Emacs, not of the concept of window, though.
> Emacs is effectively a tiling window manager (within each frame).

Actually, there is no such restriction.  For example, the tool bar, in
its Emacs implementation, is just a specialized window.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Eli Zaretskii skrev:
>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Date: Tue, 13 Apr 2010 11:42:00 +0900
>> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>, "Emacs Dev
>> 	\[emacs-devel\]" <emacs-devel@gnu.org>,
>> 	David De La Harpe Golden <david@harpegolden.net>
>>
>>  > A "window" in Emacs is the physical area of the screen in which a
>>  > buffer is displayed.
>>
>> That's a restriction of Emacs, not of the concept of window, though.
>> Emacs is effectively a tiling window manager (within each frame).
> 
> Actually, there is no such restriction.  For example, the tool bar, in
> its Emacs implementation, is just a specialized window.

Not for the Gtk tool bar.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Eli Zaretskii]

> Date: Tue, 13 Apr 2010 20:15:07 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, juri@jurta.org, 
>  emacs-devel@gnu.org, david@harpegolden.net
> 
> >>  > A "window" in Emacs is the physical area of the screen in which a
> >>  > buffer is displayed.
> >>
> >> That's a restriction of Emacs, not of the concept of window, though.
> >> Emacs is effectively a tiling window manager (within each frame).
> > 
> > Actually, there is no such restriction.  For example, the tool bar, in
> > its Emacs implementation, is just a specialized window.
> 
> Not for the Gtk tool bar.

That doesn't matter.  My point is that a "window" in Emacs is not just
for displaying a buffer.  The fact that the Gtk build does not use
this feature does not diminish the feature in any way.

Re: Gtk tabs in emacs, new branch.

[Lennart Borgman]

On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> Tabs may seem like a good idea to switch between different
> window-configurations,


Switching between named window configuration seems like a good idea -
but is tabs actually needed for that?

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> Tabs may seem like a good idea to switch between different
>> window-configurations,
>
> Switching between named window configuration seems like a good idea -
> but is tabs actually needed for that?

Of course, you can use tabs without the tab-bar.  With tab.el from the
`x-tabs' branch, you will be able to work with tabs like with buffers
using the command `list-tabs' that like `list-buffers' displays a list
of tabs that will allow to switch between them.

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

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Lennart Borgman skrev 2010-04-10 03.47:
> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
> <monnier@iro.umontreal.ca>  wrote:
>>
>> Tabs may seem like a good idea to switch between different
>> window-configurations,
>
>
> Switching between named window configuration seems like a good idea -
> but is tabs actually needed for that?

Needed, no.  The best GUI for it?  Probably.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Lennart Borgman]

On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> Lennart Borgman skrev 2010-04-10 03.47:
>>
>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>> <monnier@iro.umontreal.ca>  wrote:
>>>
>>> Tabs may seem like a good idea to switch between different
>>> window-configurations,
>>
>>
>> Switching between named window configuration seems like a good idea -
>> but is tabs actually needed for that?
>
> Needed, no.  The best GUI for it?  Probably.


So there are two parts of this:

- Implementing tabs.
- Better handling of window configurations, probably including naming,
save and restore etc.

Could we please move the second part to the main developing branch so
we can take advantage of that part as soon as possible?

Re: Gtk tabs in emacs, new branch.

[joakim]

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

> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>>
>> Lennart Borgman skrev 2010-04-10 03.47:
>>>
>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>> <monnier@iro.umontreal.ca>  wrote:
>>>>
>>>> Tabs may seem like a good idea to switch between different
>>>> window-configurations,
>>>
>>>
>>> Switching between named window configuration seems like a good idea -
>>> but is tabs actually needed for that?
>>
>> Needed, no.  The best GUI for it?  Probably.
>
>
> So there are two parts of this:
>
> - Implementing tabs.
> - Better handling of window configurations, probably including naming,
> save and restore etc.

Dont we have this already in "winner" or "winring" or some of the
existing window configuration packages?

IMHO tabs should just be buttons that generate events that by default
are bound to activating a particular window configuration.

Then again, window configurations could be further enhanced by
finishing one of the "window group" proposals discussed some time
ago on this list, but that nots necesary for tabs.


> Could we please move the second part to the main developing branch so
> we can take advantage of that part as soon as possible?



>
-- 
Joakim Verona

Re: Gtk tabs in emacs, new branch.

[Lennart Borgman]

2010/4/10  <joakim@verona.se>:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>>
>>> Lennart Borgman skrev 2010-04-10 03.47:
>>>>
>>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>>> <monnier@iro.umontreal.ca>  wrote:
>>>>>
>>>>> Tabs may seem like a good idea to switch between different
>>>>> window-configurations,
>>>>
>>>>
>>>> Switching between named window configuration seems like a good idea -
>>>> but is tabs actually needed for that?
>>>
>>> Needed, no.  The best GUI for it?  Probably.
>>
>>
>> So there are two parts of this:
>>
>> - Implementing tabs.
>> - Better handling of window configurations, probably including naming,
>> save and restore etc.
>
> Dont we have this already in "winner" or "winring" or some of the
> existing window configuration packages?


I don't thijnk so. I have not used winring.el, but it looks like it
can name window configurations. However it is not a part of Emacs.

None of them can save and restore window configurations from file
which I think is essential. I am thinking about adding that to
winsav.el. Most of it is already there, but I do not remember how far
we got with a printed representation of window configurations. Anyone
remember?


> Then again, window configurations could be further enhanced by
> finishing one of the "window group" proposals discussed some time
> ago on this list, but that nots necesary for tabs.


I think it is more essential than tabs. It can be used without tabs
and it enhances tabs.


>> Could we please move the second part to the main developing branch so
>> we can take advantage of that part as soon as possible?

Re: Gtk tabs in emacs, new branch.

[joakim]

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

> 2010/4/10  <joakim@verona.se>:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>>
>>>>
>>>> Lennart Borgman skrev 2010-04-10 03.47:
>>>>>
>>>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>>>> <monnier@iro.umontreal.ca>  wrote:
>>>>>>
>>>>>> Tabs may seem like a good idea to switch between different
>>>>>> window-configurations,
>>>>>
>>>>>
>>>>> Switching between named window configuration seems like a good idea -
>>>>> but is tabs actually needed for that?
>>>>
>>>> Needed, no.  The best GUI for it?  Probably.
>>>
>>>
>>> So there are two parts of this:
>>>
>>> - Implementing tabs.
>>> - Better handling of window configurations, probably including naming,
>>> save and restore etc.
>>
>> Dont we have this already in "winner" or "winring" or some of the
>> existing window configuration packages?
>
>
> I don't thijnk so. I have not used winring.el, but it looks like it
> can name window configurations. However it is not a part of Emacs.
>
> None of them can save and restore window configurations from file
> which I think is essential. I am thinking about adding that to
> winsav.el. Most of it is already there, but I do not remember how far
> we got with a printed representation of window configurations. Anyone
> remember?
>

That sounds cool! There was a read representation added for hash tables
recenlty, will that help?

>> Then again, window configurations could be further enhanced by
>> finishing one of the "window group" proposals discussed some time
>> ago on this list, but that nots necesary for tabs.
>
>
> I think it is more essential than tabs. It can be used without tabs
> and it enhances tabs.

Yes, but development is stalled. Maybe I should try to revive my
proposal to the point of a bzr branch, maybe then others can bring their
proposals forward.

>
>>> Could we please move the second part to the main developing branch so
>>> we can take advantage of that part as soon as possible?
-- 
Joakim Verona

Re: Gtk tabs in emacs, new branch.

[Štěpán Němec]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> None of them can save and restore window configurations from file
> which I think is essential. I am thinking about adding that to
> winsav.el. Most of it is already there, but I do not remember how far
> we got with a printed representation of window configurations. Anyone
> remember?

The recent thread discussing that starts here:
http://article.gmane.org/gmane.emacs.devel/121656


  Štěpán

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> None of them can save and restore window configurations from file
> which I think is essential. I am thinking about adding that to
> winsav.el. Most of it is already there, but I do not remember how far
> we got with a printed representation of window configurations. Anyone
> remember?

I agree that adding commands to manage window-configurations would be
good, and that we'll need additional low-level functionality to make it
work well (e.g. so you can restore a window-configuration in
a different frame, and/or a different session).

I'll be happy to integrate such a thing in Emacs,


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

joakim@verona.se skrev 2010-04-10 11.46:

> Dont we have this already in "winner" or "winring" or some of the
> existing window configuration packages?

They can't save or restore configurations from file.  Winring seems more 
advanced, it uses C-x 7 as a prefix as do gtk-tabs.

>
> IMHO tabs should just be buttons that generate events that by default
> are bound to activating a particular window configuration.
>

As I said before, that causes flicker, race conditions and prohibits Gtk tab 
drag and drop.  Talk is easy, show us the implementation.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[joakim]

Jan Djärv <jan.h.d@swipnet.se> writes:

> joakim@verona.se skrev 2010-04-10 11.46:
>
>> Dont we have this already in "winner" or "winring" or some of the
>> existing window configuration packages?
>
> They can't save or restore configurations from file.  Winring seems
> more advanced, it uses C-x 7 as a prefix as do gtk-tabs.
>
>>
>> IMHO tabs should just be buttons that generate events that by default
>> are bound to activating a particular window configuration.
>>
>
> As I said before, that causes flicker, race conditions and prohibits
> Gtk tab drag and drop.  Talk is easy, show us the implementation.

Of course, sorry if it seemed like I implied any demands on your
implementation. My personal interest is really only in convenient
handling of window configurations, not in a tab gui as such. 


>
> 	Jan D.
-- 
Joakim Verona

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> So there are two parts of this:
>> - Implementing tabs.
>> - Better handling of window configurations, probably including naming,
>> save and restore etc.
>
> Dont we have this already in "winner" or "winring" or some of the
> existing window configuration packages?

The problem with existing packages is that they can't be used
without some modifications.

> IMHO tabs should just be buttons that generate events that by default
> are bound to activating a particular window configuration.

Don't forget that the other way round events (from window configurations
to tabs) should be possible too, e.g. changes in window configurations
should update the current tab's name, etc.

> Then again, window configurations could be further enhanced by
> finishing one of the "window group" proposals discussed some time
> ago on this list, but that nots necesary for tabs.

This is a separate feature. There are different names for it:
"window groups", "framelettes", "internal frames".  It basically means
an ability to insert special windows into the window tree.
There additional special windows could be:

  1. a grouping parent window for its subwindows
     (this can be done by adding a `parent' attribute to normal windows)
  2. an inner mode-specific tool-bar subwindow
  3. an inner mode-specific tab-bar subwindow

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

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Lennart Borgman skrev 2010-04-10 11.14:
> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>
>> Lennart Borgman skrev 2010-04-10 03.47:
>>>
>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>> <monnier@iro.umontreal.ca>    wrote:
>>>>
>>>> Tabs may seem like a good idea to switch between different
>>>> window-configurations,
>>>
>>>
>>> Switching between named window configuration seems like a good idea -
>>> but is tabs actually needed for that?
>>
>> Needed, no.  The best GUI for it?  Probably.
>
>
> So there are two parts of this:
>
> - Implementing tabs.
> - Better handling of window configurations, probably including naming,
> save and restore etc.
>
> Could we please move the second part to the main developing branch so
> we can take advantage of that part as soon as possible?

There is nothing that prevents you from starting implementing that in the 
trunk AFAIK.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-10 03.22:
>> It isn't any "idea" as such, it is practicallity and user experience. For
>> example, I tried having switching in elisp, but it is too slow (causes
>> flicker) and there are race conditions between when the widget does the
>> switching and when Emacs thinks the switch is done.
>
>> There is nothing in the current implementation that excludes lisp
>> functions for switching, creation, e.t.c, but it doesn't give any
>> advantages, just complications.
>
> Tabs may seem like a good idea to switch between different
> window-configurations, but there can actually be other uses for it.
> And even for that use, there can be different choices in terms of which
> tabs to show, ...
> All that needs to be written in Lisp.

I'm not a big fan for making things general just for the sake of making things 
general so we maybe in the future can add something we don't know what it is now.

Are there any concrete examples of other uses?  I still think window 
configurations are the "natural" thing, as this is how tabs are used in web 
browsers, other editors, IDE:s and so on.  That doesn't mean that tabs must be 
exclusively about window configurations.  The implementation can easily be 
made to do tabs also for "other" lisp-based uses.  But implementation for the 
primary use case (window configurations) should not have to suffer because of 
other uses.

But I still haven't seen any example of other uses, so I haven't made gtk-tabs 
for that.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> I'm not a big fan for making things general just for the sake of making
> things general so we maybe in the future can add something we don't know
> what it is now.

It's not just making them more general.  It's making them work in the
"right/natural" way.  In Emacs this usually means among other things
that clicks on it should generate Elisp events caught via a keymap and
that the list of tabs should be specified by Elisp code.

> Are there any concrete examples of other uses?

I can imagine switching the buffer of one of the windows (in an ECB-style
frame, for example).  In mpc.el I could imagine using it to switch
between various selections.

> I still think window configurations are the "natural" thing, as this
> is how tabs are used in web browsers, other editors, IDE:s and so on.

No one is arguing against that.

> But implementation for the primary use case (window configurations)
> should not have to suffer because of other uses.

I still don't understand what kind of suffering you're referring to.
If you could describe more concretely (e.g. what kind of undesirable
user-behavior could happen in which case and why).


        Stefan

Re: Gtk tabs in emacs, new branch.

[Chong Yidong]

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

> It's not just making them more general.  It's making them work in the
> "right/natural" way.  In Emacs this usually means among other things
> that clicks on it should generate Elisp events caught via a keymap and
> that the list of tabs should be specified by Elisp code.

If clicking on a tab is to act via keybindings, maybe the neatest way to
handle this is to allow keys to be bound to window configurations, with
the meaning of "impose this window configuration".  Then the Lisp side
of the tab feature would act by storing window configurations in a
keymap.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>> It's not just making them more general.  It's making them work in the
>> "right/natural" way.  In Emacs this usually means among other things
>> that clicks on it should generate Elisp events caught via a keymap and
>> that the list of tabs should be specified by Elisp code.
> If clicking on a tab is to act via keybindings, maybe the neatest way to
> handle this is to allow keys to be bound to window configurations, with
> the meaning of "impose this window configuration".

I don't think we need any such new feature.  It's easy to use a binding
like

   (define-key map <foo>
     `(lambda () (interactive) (restore-window-configuration ,bar)))


-- Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:

> 
>> Are there any concrete examples of other uses?
> 
> I can imagine switching the buffer of one of the windows (in an ECB-style
> frame, for example).

Isn't that a window configuration?  I don't get it.

> In mpc.el I could imagine using it to switch
> between various selections.

I don't know what mpc.el is, so the statements has no meaning.


> 
>> But implementation for the primary use case (window configurations)
>> should not have to suffer because of other uses.
> 
> I still don't understand what kind of suffering you're referring to.
> If you could describe more concretely (e.g. what kind of undesirable
> user-behavior could happen in which case and why).

The most obvious thing is flickering.  When the user clicks on the tab Gtk+ 
switches tab, there is nothing you can do about that.  Depending on what was 
drawn in that widget previously, something else is shown than what was shown 
in the old wiindows before.  Then a callback is made.  From here we can 
generate a Lisp event.  Then the event goes to some elisp defun  Then the 
window confiuration is extracted and applied.  Then redisplay happens.  This 
takes time and looks bad, unless you have a fast machine.

You guys seem to think that tabs are just extra buttons to be pressed.  In 
Gtk+ they are not.  When you press on a tab an whole new Gtk widget (with 
associated X window) covering the whole frame is switched in.  So the old 
contents is not shown.  Doing window configuration switch as fast as we can 
helps, but it still isn't good.  Workable, but not good.

Add saving of the old configuration to this and more time passes before a 
redsplay.

Then there is the race condition.  Say we restore window configurations in 
elisp.  But from the time Gtk+ does the switch until the new window 
configuration is in place, the old one is in Emacs idea of what is on the 
screen, but as I said earlier, it isn't what is really on screen.  So 
redisplay may happen, based on the old configuration, making the flicker even 
more annoying.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:


> You guys seem to think that tabs are just extra buttons to be pressed.  
> In Gtk+ they are not.  When you press on a tab an whole new Gtk widget 
> (with associated X window) covering the whole frame is switched in.  So 
> the old contents is not shown. 

This I think is why I liked the idea of whole-emacs-frames being "in" 
gtk tab notebooks rather than vice-versa.  So what are the tab notebooks 
"in" from the emacs perspective? It doesn't matter, some sort of 
transient thingy created and destructed on demand - doesn't really need 
to be visible to the emacs lisp side, since the x11-level window manager 
plus the outer gtk notebook layer is acting as the "window manager" 
level layer to emacs frames.



OTOH - can one fudge a gtk notebook with funny dimensions and catch
the tab change event? i.e. rather than putting the old contents "truly" 
in the tab notebook

  _______________
|   \___\_______|
|+-------------+|
||             ||
||             ||
|+-------------+|
|_______________|

fake it with a zero-sized content of each tab, and just put the contents 
next to it?

  _______________
|___\___\_______|
+---------------+
|               |
|               |
+---------------+

There might be fugliness problems, of course.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

David De La Harpe Golden skrev 2010-04-10 18.40:

> OTOH - can one fudge a gtk notebook with funny dimensions and catch
> the tab change event? i.e. rather than putting the old contents "truly"
> in the tab notebook
>
> _______________
> | \___\_______|
> |+-------------+|
> || ||
> || ||
> |+-------------+|
> |_______________|
>
> fake it with a zero-sized content of each tab, and just put the contents
> next to it?
>
> _______________
> |___\___\_______|
> +---------------+
> | |
> | |
> +---------------+
>
> There might be fugliness problems, of course.
>

I don't know if you could do it, but I suspect it can't be zero sized, and 
then you have widget placements to handle.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Davis Herring]

> You guys seem to think that tabs are just extra buttons to be pressed.  In
> Gtk+ they are not.  When you press on a tab an whole new Gtk widget (with
> associated X window) covering the whole frame is switched in.  So the old
> contents is not shown.  Doing window configuration switch as fast as we
> can helps, but it still isn't good.  Workable, but not good.

This isn't necessary, is it?  I'm sure that GTK+ tabs can govern (switch)
an area that isn't a top-most window.  Then, if we want to, we can just
make the "content" part of that area have 0 size (so that the user-visible
line of tabs is in fact the whole area they control) and merely react to
the tab switch events however we want.

This might cause the tab-switch-redraw to be slower than it would be if
GTK+ merely blits in some double-buffered image it remembered from the
last time that tab was foremost, but I've never noticed that things like
C-x 1 were slow enough to be a bother (except over very slow remote X11
connections), so this shouldn't be either.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Davis Herring skrev 2010-04-10 18.42:
>> You guys seem to think that tabs are just extra buttons to be pressed.  In
>> Gtk+ they are not.  When you press on a tab an whole new Gtk widget (with
>> associated X window) covering the whole frame is switched in.  So the old
>> contents is not shown.  Doing window configuration switch as fast as we
>> can helps, but it still isn't good.  Workable, but not good.
>
> This isn't necessary, is it?

What is "this"?

> I'm sure that GTK+ tabs can govern (switch)
> an area that isn't a top-most window.

Well, yes, that is what it is doing.  It isn't a top-most window.

> Then, if we want to, we can just
> make the "content" part of that area have 0 size (so that the user-visible
> line of tabs is in fact the whole area they control) and merely react to
> the tab switch events however we want.

I haven't tried it.  However, stuff like putting tabs at the bottom would then 
not work well.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Davis Herring]

>> This isn't necessary, is it?
>
> What is "this"?

Sorry -- I meant the window covering the whole frame and associated problems.

My whole message was practically identical to David's anyway (except for
the comprehensibility), so we need not worry about it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Davis Herring skrev:
>>> This isn't necessary, is it?
>> What is "this"?
> 
> Sorry -- I meant the window covering the whole frame and associated problems.
> 

I just tested it, you can have zero sized widgets in the tab.  But there are 
borders the Gtk+ widget expects to draw around its children.  This now comes 
at the top, A minor issue.  I'll see if I can simplify my implementation with 
this approach.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:
> 
> I just tested it, you can have zero sized widgets in the tab.  But there 
> are borders the Gtk+ widget expects to draw around its children.  This 
> now comes at the top, A minor issue.  I'll see if I can simplify my 
> implementation with this approach.
> 
>     Jan D.

Should make interior tabs easier to implement too. hmm.

So, I was wondering just how firefox tabs did their thing given the 
quirks of a naive gtk notebook instance.  People here are quite likely 
already aware of this:

Mozilla XUL's "native gtk" theme engine doesn't really use the
notebook widget directly at all for its "tabbox" (or other gtk widgets 
directly for most anything else...)!

It apparently makes an examplar singleton instance of each widget then 
borrows their (GtkStyle) style  members to pass to 
gtk_(paint|draw|style)_* functions to handle drawing lookalikes more 
flexibly itself.

You can see the idea in the mozilla sources:
http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/gtk2drawing.c

http://www.gtk.org/api/2.6/gtk/GtkStyle.html

This apparently includes scrollbars - maybe a way around gtk's scrollbar
quirks...

Though recasting "gtk" emacs to use the approach throughout might be 
...a lot of work...

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

David De La Harpe Golden skrev:
> Jan Djärv wrote:
>>
>> I just tested it, you can have zero sized widgets in the tab.  But 
>> there are borders the Gtk+ widget expects to draw around its 
>> children.  This now comes at the top, A minor issue.  I'll see if I 
>> can simplify my implementation with this approach.
>>
>>     Jan D.
> 
> Should make interior tabs easier to implement too. hmm.
> 
> So, I was wondering just how firefox tabs did their thing given the 
> quirks of a naive gtk notebook instance.  People here are quite likely 
> already aware of this:
> 
> Mozilla XUL's "native gtk" theme engine doesn't really use the
> notebook widget directly at all for its "tabbox" (or other gtk widgets 
> directly for most anything else...)!
> 
> It apparently makes an examplar singleton instance of each widget then 
> borrows their (GtkStyle) style  members to pass to 
> gtk_(paint|draw|style)_* functions to handle drawing lookalikes more 
> flexibly itself.
> 
> You can see the idea in the mozilla sources:
> http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/gtk2drawing.c

It is a clever hack, but I don't fancy drawing tabs "manually", handling 
drag&drop, memory allocations and so on.  It is a big job.

> 
> http://www.gtk.org/api/2.6/gtk/GtkStyle.html

Actually 2.6 is quite old, we even require 2.10 for Emacs.  2.20 is current.

> 
> This apparently includes scrollbars - maybe a way around gtk's scrollbar
> quirks...
> 
> Though recasting "gtk" emacs to use the approach throughout might be 
> ...a lot of work...

And kind of meaningless to use a toolkit in the first place.  The widgets are 
supposed to simplify things after all.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:

> Actually 2.6 is quite old, we even require 2.10 for Emacs.  2.20 is 
> current.
>

Hah. Yeah, apparently current gtk documentation is on gnome.org not 
gtk.org and I restricted a web search to gtk.org. Premature optimization...

(for completeness 
http://library.gnome.org/devel/gtk/unstable/GtkStyle.html )

>>
>> This apparently includes scrollbars - maybe a way around gtk's scrollbar
>> quirks...
>>
>> Though recasting "gtk" emacs to use the approach throughout might be 
>> ...a lot of work...
> 
> And kind of meaningless to use a toolkit in the first place.

Well, you do still get the pretty/coherent style...

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> And kind of meaningless to use a toolkit in the first place.  The widgets
> are supposed to simplify things after all.

Apparently the Gnome/Gtk guys aren't out to make life of application
writers easier.  They're instead dedicated to making things easy/uniform
for the end user, which imposes severe constraints on the applications,
especially ones like Emacs which haven't been designed around Gtk's ideas.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:

> Apparently the Gnome/Gtk guys aren't out to make life of application
> writers easier.  They're instead dedicated to making things easy/uniform
> for the end user, which imposes severe constraints on the applications,
> especially ones like Emacs which haven't been designed around Gtk's ideas.
> 

They do wan't Gtk+/Gnome applications to behave and look uniform, I think that 
is a good thing for a desktop environment.

On the other hand, the GUI design in Emacs is awkward at best and doesn't fit 
well with *any* toolkit out there.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>> Apparently the Gnome/Gtk guys aren't out to make life of application
>> writers easier.  They're instead dedicated to making things easy/uniform
>> for the end user, which imposes severe constraints on the applications,
>> especially ones like Emacs which haven't been designed around Gtk's ideas.
> They do wan't Gtk+/Gnome applications to behave and look uniform, I think
> that is a good thing for a desktop environment.
> On the other hand, the GUI design in Emacs is awkward at best and doesn't
> fit well with *any* toolkit out there.

But the Gtk guys go to extra trouble to make sure that apps like Emacs
can't conveniently use Gtk to get what they want, without this effort
making it any easier for other apps to get a consistent look&feel.
[ I'm obviously thinking of scrollbars here. ]


        Stefan

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>>> Are there any concrete examples of other uses?
>> I can imagine switching the buffer of one of the windows (in an ECB-style
>> frame, for example).
> Isn't that a window configuration?  I don't get it.

Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
then resize some windows, then select the "toto.c" tab and it will
switch the buffer to toto.c without reverting the window sizes.

>> In mpc.el I could imagine using it to switch
>> between various selections.
> I don't know what mpc.el is, so the statements has no meaning.

It's emacs/lisp/mpc.el (new in Emacs-23.2), a front end (client) for the
Music Player Daemon.  So think of it as switch between different
selections in Rhythmbox's browser.

>>> But implementation for the primary use case (window configurations)
>>> should not have to suffer because of other uses.
>> I still don't understand what kind of suffering you're referring to.
>> If you could describe more concretely (e.g. what kind of undesirable
>> user-behavior could happen in which case and why).

> The most obvious thing is flickering.  When the user clicks on the tab Gtk+
> switches tab, there is nothing you can do about that.

I think we need to define "tab" here.  For me a "tab" is a little
rectangle on the screen with a label.  The actions on this tab are
usually linked to switching the content of an X window that's
drawn underneath.
From what you write I get the impression that your notion of a "tab"
includes not just the tab itself but also the window underneath.

> Depending on what was drawn in that widget previously, something else
> is shown than what was shown in the old wiindows before.

If I understand correctly, that means that Gtk tabs have a built-in
semantics of "switch the window underneath the tabbar".
That's obviously too restrictive for the kinds of use cases I suggest,
so we'd have to hack around it, e.g. by creating a dummy 0-pixel high
X-window where Gtk can "switch tabs" at its heart content without
bothering us.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:
>>>> Are there any concrete examples of other uses?
>>> I can imagine switching the buffer of one of the windows (in an ECB-style
>>> frame, for example).
>> Isn't that a window configuration?  I don't get it.
> 
> Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
> then resize some windows, then select the "toto.c" tab and it will
> switch the buffer to toto.c without reverting the window sizes.
> 

Ok, that might be useful.

>>> In mpc.el I could imagine using it to switch
>>> between various selections.
>> I don't know what mpc.el is, so the statements has no meaning.
> 
> It's emacs/lisp/mpc.el (new in Emacs-23.2), a front end (client) for the
> Music Player Daemon.  So think of it as switch between different
> selections in Rhythmbox's browser.

Well, I don't use Rhythmbox either, so ... :-)

> 
>>>> But implementation for the primary use case (window configurations)
>>>> should not have to suffer because of other uses.
>>> I still don't understand what kind of suffering you're referring to.
>>> If you could describe more concretely (e.g. what kind of undesirable
>>> user-behavior could happen in which case and why).
> 
>> The most obvious thing is flickering.  When the user clicks on the tab Gtk+
>> switches tab, there is nothing you can do about that.
> 
> I think we need to define "tab" here.  For me a "tab" is a little
> rectangle on the screen with a label.  The actions on this tab are
> usually linked to switching the content of an X window that's
> drawn underneath.
>>From what you write I get the impression that your notion of a "tab"
> includes not just the tab itself but also the window underneath.

It is not my notion, it is Gtk+.

> 
>> Depending on what was drawn in that widget previously, something else
>> is shown than what was shown in the old wiindows before.
> 
> If I understand correctly, that means that Gtk tabs have a built-in
> semantics of "switch the window underneath the tabbar".
> That's obviously too restrictive for the kinds of use cases I suggest,
> so we'd have to hack around it, e.g. by creating a dummy 0-pixel high
> X-window where Gtk can "switch tabs" at its heart content without
> bothering us.

I'm looking into that now.  There is that damned border though...

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:
> Stefan Monnier skrev:
>>>>> Are there any concrete examples of other uses?
>>>> I can imagine switching the buffer of one of the windows (in an 
>>>> ECB-style
>>>> frame, for example).
>>> Isn't that a window configuration?  I don't get it.
>>
>> Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
>> then resize some windows, then select the "toto.c" tab and it will
>> switch the buffer to toto.c without reverting the window sizes.
>>
> 
> Ok, that might be useful.
> 

Hmm. Well, switching a "single window"* between buffers toto.c and 
toto.h might be something I'd rather use (yes, presently hypothetical) 
interior split-tab tabs, attached directly to the window in question.

This is not unusual - Note how eclipse has tab bars on multiple panes, 
and switching the main editor pane between files is done with the tab 
bar most directly attached to it:

http://www.eclipse.org/screenshots/images/FortranIde-RedFlag_Linux.png

(* actually in the implementation I envisage it'd be switching /between 
two emacs windows/ formed from a "split" on the "tab" axis, but at this 
level of the discussion that's a detail).

My reservations about window-configurations-as-thing-tab-switches also
turn out to apply:

See, thinking about it, switching window configurations as a whole could 
IMO be more like switching "perspectives" in eclipse (window 
configurations do currently encapsulate the buffer being shown in each 
window, and assuming split-tabbed existed would also record tab 
arrangement).

So a "debug" window configuration may have (possibly tabbed) windows 
open on buffers with your source, compilation outputs, a gdb window 
etc., while a "edit java" window configuration has windows with your 
source, a directory tree browser, doc and completion windows etc.

Now, a tab bar is probably still a vaguely reasonable UI for switching 
between a small number of perspectives, though not actually the UI 
eclipse uses (see the "Debug" button in the upper right of Fig.1 
screenshot here:

http://www.ibm.com/developerworks/library/os-ecbug/#N10089
)

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-10 17.19:
>In Emacs this usually means among other things
> that clicks on it should generate Elisp events caught via a keymap and
> that the list of tabs should be specified by Elisp code.

Are you suggesting we add and remove tabs dynamically to a keymap as they get 
created?  I'm not sure I follow.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>> In Emacs this usually means among other things
>> that clicks on it should generate Elisp events caught via a keymap and
>> that the list of tabs should be specified by Elisp code.
> Are you suggesting we add and remove tabs dynamically to a keymap as they
> get created?  I'm not sure I follow.

Not necessarily, no (tho that's what we do for tool-bars), just that
when the user clicks on a tab, the action performed should be looked up
in a keymap.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-12 21.18:
>>> In Emacs this usually means among other things
>>> that clicks on it should generate Elisp events caught via a keymap and
>>> that the list of tabs should be specified by Elisp code.
>> Are you suggesting we add and remove tabs dynamically to a keymap as they
>> get created?  I'm not sure I follow.
>
> Not necessarily, no (tho that's what we do for tool-bars), just that
> when the user clicks on a tab, the action performed should be looked up
> in a keymap.
>

I still don't get it.  If the user creates three tabs, where are the keymap 
entries for those if we don't create them?  Or do you mean a default entry 
that catches those tabs that haven't got an action set explicitly?


	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>>>> In Emacs this usually means among other things
>>>> that clicks on it should generate Elisp events caught via a keymap and
>>>> that the list of tabs should be specified by Elisp code.
>>> Are you suggesting we add and remove tabs dynamically to a keymap as they
>>> get created?  I'm not sure I follow.
>> Not necessarily, no (tho that's what we do for tool-bars), just that
>> when the user clicks on a tab, the action performed should be looked up
>> in a keymap.
> I still don't get it.  If the user creates three tabs, where are the keymap
> entries for those if we don't create them?  Or do you mean a default entry
> that catches those tabs that haven't got an action set explicitly?

If we don't create one entry per tab, then we presumably would have
a single entry for all tabs, and the bound command would figure out
which tab was clicked by looking at the triggering event.

But again, I do not specifically care either way at this point.


        Stefan

Re: Gtk tabs in emacs, new branch.

[René Kyllingstad]

On Sat, Apr 10, 2010 at 5:19 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Are there any concrete examples of other uses?
>
> I can imagine switching the buffer of one of the windows (in an ECB-style
> frame, for example).

Let's call that window the editor window.  This means having the tabs as
part of the frame instead of as part of the editor window.  The appeal is
clear: it affords more space for the tabs for an ECB-style frame.

However, it breaks the expectation that the tab changes the display of the
attached pane.

Eclipse provides a ECB style frame, but uses tabs-per-pane rather than tabs
at the frame level. This allows one to later add tabs to the individual
windows in ECB, and it makes the interface consistent wrt tabs.

In Eclipse this is put to good use, most of the ECB-style windows have tabs
on them.  It would be great if an Eclipse-like setup could be achieved in
Emacs.  This would mean:

  - a window-set-tabs function taking a list of (icon, text, tooltip, buffer).
    clicking on the tab displays the buffer.

That would take care of the non-editor windows. There are other features
needed (other-window shouldn't switch to the non-editor windows,
switch-buffer shouldn't suggest the buffers in the non-editor windows,
persistence of window configurations), but it would be useful by itself.

For the editor windows another mechanism is needed to create the tabs, as
the list of tabs should be some subset of the open buffers.

A related item: many Eclipse panes have tool-bars as well as tabs.  If
there is space for both the list of open tabs and the tool-bar on one line,
they are displayed with the tabs to the left, tool-bar buttons to the
right, otherwise they are broken up into two lines with the tabs above the
tool-bar.  The tool-bar is related to the current tab (displayed
buffer), so switching
tabs may remove the tool-bar or change its content.


-- René

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:


> Are there any concrete examples of other uses?  I still think window 
> configurations are the "natural" thing, as this is how tabs are used in 
> web browsers, other editors, IDE:s and so on.  That doesn't mean that 
> tabs must be exclusively about window configurations.

I'm still not sure about this.   At least the Gtk+ notebook model still 
suggests to me that the most natural thing to put in some toplevel 
outermost tabs for gtk purposes might be the emacs frames themselves.

I also still like my idea of tabs being a sort of third "depth" axis 
emacs windows are split on. Then such (interior*) tabs would be /an 
aspect of/ window configuration, not something that switches /between/ 
window configurations.

e.g. changing frame from window configuration
A to window configuration B involve rearranging the horizontal, 
vertical, and tab type window splits:

A:                              B:

  ________________________        ________________________
|              |         |      |                        |
|              |         |      |______   _______________|
|______________|         |      |__/__/__/__/____________|
|              |         |      |      |        |        |
|___   ________|         |      |   ___|________|________|
|__/__/__/_____|_________|      |__/__/__________________|


A: horizontally-split into 2 then LHS vertically-split into 2. Lower 
left then "tab-split" into 3 tabs.

B: vertically-split into 2.  Upper then "tab-split" into 4 tabs.  Lower 
tab-split into 2 tabs.  First tab then vertically-split into 3.

I suppose it doesn't preclude the outermost set of tabs switching 
between window configurations. Or frames. Or even outer tabs containing 
frames, second level switching window configurations of frames, and 
further interior tabs being split-window type. Sigh.

Anyway, talk is cheap - you have working code and I still don't, despite 
previously mentioning this months ago now, I haven't really been working 
on it.

>  The 
> implementation can easily be made to do tabs also for "other" lisp-based 
> uses.  

I'd also point out again there's a completely different sort of tab to 
consider - an emacs widget that is a tab notebook, that embeds _in_ a 
buffer like other emacs widgets for customisation.

That's little to do with your sort of tabs apart from my concern there's 
some possibility some non-window-configuration-switching use cases some 
people might be envisaging for tabs might be better served by a 
tabbed/notebook presentation composite emacs widget.

Re: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Jan Djärv writes:

 > I'm not a big fan for making things general just for the sake of
 > making things general so we maybe in the future can add something
 > we don't know what it is now.
 > 
 > Are there any concrete examples of other uses?

Because the tab metaphor involves switching a well-defined area of
screen from one use to another (I don't subscribe to the "just a
contiguous row of buttons" interpretation), one can trivially subsume
all uses into "window configuration management".  But the
implementation of changing what's seen onscreen might involve far more
than swapping one GUI widget in in place of another, and it might not
involve swapping GUI widgets at all (where for this purpose I consider
Emacs windows as widgets).

In use now?  Probably not, because of the very limited imaginations of
tab developers (or if you prefer, because of the very limited
imaginations that tab developers attribute to their users).

But easy to implement given a flexible tab framework?  Lots of them.
How about varying font-lock to highlight different aspects of a buffer
using "layers" of font-lock specs controlled by tabs?  Many others
that you might classify as "window configuration management", but
other users might not.  I have in mind switching "projects", which
might involve piles of behind the scenes machinery such as restoring
undisplayed buffers in the background, querying status of VCS, etc.

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> Because the tab metaphor involves switching a well-defined area of
> screen from one use to another..., one can trivially subsume
> all uses into "window configuration management".  But the
> implementation of changing what's seen onscreen might involve far more
> than swapping one GUI widget in in place of another, and it might not
> involve swapping GUI widgets at all (where for this purpose I consider
> Emacs windows as widgets).
> 
> In use now?  Probably not, because of the very limited imaginations of
> tab developers (or if you prefer, because of the very limited
> imaginations that tab developers attribute to their users).
> 
> But easy to implement given a flexible tab framework?  Lots of them.
> How about varying font-lock to highlight different aspects of a buffer
> using "layers" of font-lock specs controlled by tabs?  Many others
> that you might classify as "window configuration management", but
> other users might not.  I have in mind switching "projects", which
> might involve piles of behind the scenes machinery such as restoring
> undisplayed buffers in the background, querying status of VCS, etc.

`Amen' to "flexible tab framework". And Stephen gives good examples of
exploiting such generality. My message is in the same vein.

I don't really want to get into this thread much - don't have much to offer,
especially regarding implementation. I'd just suggest the following about what
tabs should be able to _do_, that is, what you should be able to do with them.

I have nothing particular to say now about the questions of where tabs are
(frame, window, subwindows, whatever), how the user interacts with them
(clicking, sorting, whatever), how they should be implemented, etc.

A different and at least equally important question is what happens when a tab
is selected/clicked: what actions are carried out? what does the tab actually do
or control? Emacs gives us the opportunity to do something much more general wrt
tabs than might exist elsewhere.

Other things being equal, we should not forego generality wrt what a tab
selection can do. We should not, for example, decide that tabs should only
switch among window configs or only among buffers or desktops or projects or...
At the least, we should allow a tab to invoke an arbitrary function. That means
at least providing a hook, a handler, or equivalent.

One model that can help guide the design is to allow (but of course not require)
a tab to be associated with an Emacs bookmark. Not just with the buffer
resulting from invoking a bookmark, but with the bookmark itself - that is, with
a particular entry in `bookmark-alist'. Again, I'm not at all suggesting that we
_limit_ tabs to bookmarks but that we allow tabs to access or map to existing
bookmarks. Thinking about bookmarks can help guide the discussion about what
tabs can/should do.

A bookmark is essentially a (persistent) named collection of info. That info
typically includes a destination, which is typically a file location and a
position within the file. But although that is typical, a bookmark need not be
associated with any destination.

A bookmark can record state of any kind (persistently), and invoking a bookmark
can restore that state, without necessarily "going to" any destination. The
state restored might be entirely invisible, for example.

Stephen's example of switching among projects, thus restoring project state, is
something that you can do using bookmarks. In my library bookmark+.el[*] for
example, there are Desktop bookmarks, Dired bookmarks that restore markings and
hidden-subdirs state, del.icio.us-style tags, and other ways to represent and
switch among things such as "projects". And more and better such could easily be
imagined. (I'm looking forward to restoring window configs once we have their
serialization.)

But jumping to a bookmark need not even restore anything. "Jumping" can do
anything you want it to. A bookmark can include a handler, which is pretty much
an arbitrary function that is invoked during "jumping". Users can easily define
their own types of bookmarks (e.g. with their own handlers). Bookmark+ offers
several examples of additional kinds of bookmarks and out-of-the-ordinary
bookmark handling, to give you an idea.

The bookmarking and bookmark-jumping mechanisms are very general and are
available for any possible kind of bookmark - which means pretty much any
(persistent) named collection of info.

Being able to have a tab represent (map to) a bookmark would be very useful,
IMO. By "represent" I mean just that a tab could have as its name a bookmark
name, and clicking (selecting) the tab would invoke ("jump" to) the bookmark.
IOW, the tab would just be a shortcut for a jump call, the same way that an
entry in the *Bookmark List* buffer (`C-x r l') is such a shortcut.

Look at it also from another point of view. In bookmark+ (for example), you can
hide or show (in the *Bookmark List*) the bookmarks that satisfy certain
properties. You can mark bookmarks and then perform operations on them (as in
Dired or Buffer Menu). You can sort the bookmarks that are visible. And so on.

I'd like to be able to do the same kinds of things with tabs: hide tabs based on
certain criteria, mark tabs, act on the marked tabs (or on all tabs), sort the
tabs in a given tab bar, etc. And that includes opening/showing a set of tabs
that satisfy some property (whether or not they were shown previously and then
hidden). For example, be able to hit a key to open/add (or close/hide) all tabs
belonging to a given project.

Whatever choices are made for implementing tabs in Emacs, I'd hope that they
could trivially be made to accommodate this suggestion (using bookmarks) - among
other uses. I mention the example of bookmarks to underline what Stephen T. and
others have said wrt letting tabs be general and not forcing them to map only to
certain things such as window configurations. Bookmarks serve as a good example,
as food for thought.

And the fact that bookmarks already offer so many possibilities of switching and
restoring state points out an important point: We need not build such
functionality into the tabs (design) themselves. We should just _allow_ tabs to
leverage other features of Emacs that provide such functionality.

It would be a mistake to try to decide the behavior of tabs - what they _do_ in
some narrow way. We should define the GUI behavior (user interaction) and design
ways to invoke Emacs functions or objects such as bookmarks, but we should not
otherwise define what tabs actually do when you click them, beyond invoking some
arbitrary (Emacs-Lisp) thingy.

In general, I suggest that we look to things like bookmarks for examples of the
kinds of things we might want to be able to do with tabs. That will help us
avoid limiting the design of Emacs tabs unnecessarily. When looking for models
on which to base our design, we should think of other thingies in Emacs (such as
bookmarks), and not just think of other uses of tabs in existing applications.

Yes, we do want to be able to do with Emacs tabs _at least_ the kinds of things
you can do with Eclipse tabs or Firefox tabs. But let's not limit our design
thinking to what you can do with tabs in other apps.

Dunno whether I was clear, and apologies for rambling a bit. The point is to
keep what tabs _do_ very general, regardless of how they're implemented or what
the user/GUI interaction will be like. And thinking of what bookmarks can do is
not a bad model for such generality. Being able to use existing bookmarks via
tabs would be one example of exploiting the generality that I hope tabs will
have.

[* http://www.emacswiki.org/emacs/BookmarkPlus]

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> A bookmark is essentially a (persistent) named collection of info.
> That info typically includes a destination, which is typically a file
> location and a position within the file. But although that is
> typical, a bookmark need not be associated with any destination.

Let's compare how this is implemented in web browsers.  Typing C-b in
Firefox opens a left-side pane that indeed looks like a vertical tab bar.
But it has completely different semantics than the real tab bar.
Clicking on a bookmark opens a web page in a new tab.  Clicking on a tab
selects a web page in the existing tab.  So bookmarks are not a good example
what the tab bar could be used for.  I think in Emacs the most suitable
widget for that is the speed bar.

Of course, we could allow any action for tabs by design, but using them
for bookmarks is a bad idea.

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

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> > A bookmark is essentially a (persistent) named collection of info.
> > That info typically includes a destination, which is 
> > typically a file location and a position within the file. But
> > although that is typical, a bookmark need not be associated with
> > any destination.
> 
> Let's compare how this is implemented in web browsers.  Typing C-b in
> Firefox opens a left-side pane that indeed looks like a 
> vertical tab bar. But it has completely different semantics than the
> real tab bar.

I don't care about "real" tab bars or "real" Firefox bookmarks. I care about
what tabs will be in Emcs.

> Clicking on a bookmark opens a web page in a new tab.  
> Clicking on a tab selects a web page in the existing tab.

So what?

> So bookmarks are not a good example what the tab bar could
> be used for.

That doesn't follow at all. Anyway, please read what I wrote.

I said that I would like to be able to use tabs for the _kinds of things_ I use
Emacs bookmarks for - whether or not bookmarks are used as an intermediary. And
I gave examples of such diverse uses, which go far beyond the usual use of Emacs
bookmarks, not to mention even further beyond what one can use Firefox bookmarks
for.

I suggested thinking about such things in the interest of keeping the
model/design for Emacs tags open, general, flexible. The idea was to foster
thinking about what tabs can do and argue for keeping their use completely
flexible and general - that is, undefined.

In particular, I suggested separating a concern for implementation and
user-interaction design (GUI) from what tabs actually _do_, that is, what you
can do with them. 

I do not want Emacs design to hard-couple user-tab interaction (the GUI) with
any particular action to be effected by a tab. I want the possibilities for the
thingies that are selected or invoked by choosing a tab to remain open and
bindable at runtime (in Lisp). I want those thingies to be anything at all: a
window configuration, a desktop, a "project", a buffer, a mail, a process
invocation, or whatever.

I want a tab to be able to invoke any function whatever.

Define the GUI, fine (and I said that I probably have next to nothing to say
about that), but please let the mapping of tab<->thingie
selected/activated/invoked be open, not predefined.

As one instance of exploiting such hoped-for openness, I would like to be able
to attach/map-to/invoke a arbitrary Lisp function. Stefan spoke of commands -
via a keymap. As another instance, I suggested being able to attach an Emacs
bookmark. (No, not a Firefox bookmark, but a chunk of Emacs-Lisp that can
represent saved state and a handler function.)

So there were two different uses/mentions of bookmarks in what I wrote: (1)
bookmarks (in bookmark+) as a model or illustration of generality, to point out
some of the many different kinds of things one might like to do by clicking a
tab, and (2) invocation of existing Emacs bookmarks as one concrete example of
attaching a thingie to a tab - that is, bookmarks as one type of attachable
thingie.

The more important point is #1, by far: tabs should be able to do pretty much
anything.

If you don't in fact design them in such a way that I can directly map bookmarks
to tabs (#2), that's not a big deal. As long as I can hook/map a tab to an
arbitrary function, I can invoke a bookmark anyway (or anything else).

So perhaps reread my mail, concentrating on #1: bookmark uses as examples of
things one might want a tab to do. And forget about #2 if it adds confusion to
the discussion.

I'm OK with a hook, a handler, a keymap,...whatever (we can get to preferences
among those later). The point is simply *not* to hard-design tabs as *only*
selectors of window configs (or of any other specific thing). Do not predefine
what tabs do.

I wrote my mail in response to Jan's proposed implementation that I understand
(perhaps incorrectly) to hard-couple tabs to window configs. I do not want Emacs
tabs to be like that. I want them to be open.

> I think in Emacs the most suitable widget for that is the speed bar.
> 
> Of course, we could allow any action for tabs by design, but 
> using them for bookmarks is a bad idea.

Allow any action by design, yes. That was precisely the point.

I used different kinds of bookmarks (in bookmark+) as examples of different
kinds of things one might want to use tabs for. They were illustrations of why
tabs can be and should be more than simply window-selectors. Apparently, the
bookmark model as illustration was not clear.

Just please make sure we can attach an arbitrary function to a tab and I'll be a
happy camper, no doubt. A keymap, such as Stefan proposed, would be OK. A
function might be better. Allowing either would be good. Allowing a function,
keymap, or bookmark would be grand, but it's not necessary.

What I do not want to see is tabs being dedicated to *only* switching among X's,
where X is any single thing such as window configs, prohibiting the use of tabs
for Y's, where a Y is not an X.

Please do not predefine what tabs can do. Capice?

RE: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Drew Adams writes:

 > I want a tab to be able to invoke any function whatever.

While perhaps sufficient generality may require that ability, remember
that tabs as a metaphor are *not* just a contiguous row of buttons.
They are ordered, and they "do the same thing" (but to different
objects).  (There is an analogy to the difference between "a set of
check boxes" and "an array of radio buttons", where the radio buttons
aren't constrained to do the same thing, but rather to be mutually
exclusive.)

So I would refine "any function whatever" so that each tab control
should have a *single* callback function, which takes maybe three
arguments: the individual tab object itself (perhaps represented as an
integer but better a symbol, I think, because then you could put
properties on it), a per-tab user-defined datum (any Lisp object the
application wants to hang on the individual tab), and perhaps another
user-defined datum for the whole tab control.  (If you do need the
generality of function-per-tab, you could always have the tab-control-
wide function dispatch to per-tab functions stored in the per-tab user
datum.  This would *remind* you that all tabs in a group "should" do
the same thing, but it wouldn't *enforce* it.)

Either the per-tab datum or the whole-tab datum or both could be
subsumed by properties on the tab object, I guess.

WDYT?

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

>  > I want a tab to be able to invoke any function whatever.
> 
> While perhaps sufficient generality may require that ability, remember
> that tabs as a metaphor are *not* just a contiguous row of buttons.
> They are ordered,

Yes.

> and they "do the same thing" (but to different objects).

How so?

> So I would refine "any function whatever" so that each tab control
> should have a *single* callback function, which takes maybe three
> arguments: the individual tab object itself (perhaps represented as an
> integer but better a symbol, I think, because then you could put
> properties on it), a per-tab user-defined datum (any Lisp object the
> application wants to hang on the individual tab), and perhaps another
> user-defined datum for the whole tab control.  (If you do need the
> generality of function-per-tab, you could always have the tab-control-
> wide function dispatch to per-tab functions stored in the per-tab user
> datum.  This would *remind* you that all tabs in a group "should" do
> the same thing, but it wouldn't *enforce* it.)
> 
> Either the per-tab datum or the whole-tab datum or both could be
> subsumed by properties on the tab object, I guess.
> 
> WDYT?

I'm not sure I understand all you wrote. I'm quite ignorant about much of this,
especially the how-to. My only ideas about this so far pertain to what tabs
might do and what kind of info might therefore be associated with them.

It's not clear to me, for example, what you mean by tabs (necessarily) doing the
same thing to different objects. It's also not clear why there should be a
single callback function, or what you mean by "the individual tab object" (what
is it for?) or "the whole tab control". What's the difference between the tab
and the whole tab?

Perhaps an example to illustrate, or define the terms a bit?

You click a given tab, and something happens. The tab has a name. The GUI/tab
control looks up the name to find the corresponding something-to-happen and then
effects it. Perhaps this is what you mean by "dispatch to per-tab functions
stored in the per-tab user datum" - dunno.

Yes, there is then some question about where to display things, if something
gets displayed as part of the something-to-happen. For example, if the action
involves visiting a buffer then you'd probably want that buffer to appear in a
window associated with the tab. 

I've said nothing about this display part of things. It is questions about
display that distinguish tabs from tool-bar buttons, no doubt. Yes, there is a
natural association between a tab and a window. That doesn't mean that every tab
need display exactly one window. But yes, clicking a tab typically results in
the window below it showing something that is associated with the tab.

Apart from the GUI aspects (including the display question), I see a tab bar as
an ordered sequence of named (Lisp) thingies that you can select (e.g. by
clicking). I therefore think of an alist, where the keys are the tab names and
the values are arbitrary Lisp objects.

That brings to mind an Emacs menu, where menu items are essentially alist
entries (item-name/key and command/value). Perhaps that's what Stefan had in
mind when he spoke of keymaps - dunno.

To me, it also brings to mind Emacs bookmarks, which is one reason I mentioned
them. A bookmark is just a cons (NAME . VALUE), where NAME is a string. It's
true that VALUE has an expected form to some extent for bookmarks, but really it
can be quite general. Predefined bookmark entries (in VALUE) such as `filename'
and `position' need not be mandatory. One important thing that VALUE can include
is a handler, which determines what happens when the bookmark is invoked.

Unlike the case for menus, the structure of the VALUE part of a bookmark is
quite flexible and open (e.g. to user definition), and the associated action
(handler) need not be an Emacs command (`interactive'). A default handler
applies, if none is present explicitly. To me, the bookmark model is quite
general and corresponds conceptually to a tab: a named Lisp value that can
represent some action to be performed when the tab is selected.

How a tab gets selected and what gets displayed (and how) are questions that I
haven't tried to address.

I mentioned that I would also like to be able to perform certain operations on
the tabs of a given tab bar that are similar to operations that I perform on a
list of bookmarks: (1) sort the tabs in various ways, based on both NAME and
VALUE, (2) mark the tabs and then perform operations on the marked tabs, (3)
hide certain tabs (e.g. those marked), (4) show a set of tabs that might not
already have been shown and then hidden (e.g. to "open" a project that involves
multiple tabs). And so on.

And I mentioned that (bookmark+) bookmarks can be tagged (del.icio.us-style),
which would mean that tabs would be tagged, so you could easily manipulate sets
of tabs - e.g. all the tabs that correspond to a particular project or query.

IOW, individual tabs can be selected, yes, but code (hence users) should also be
able to act on sets of tabs in various ways.

I'm thinking about tabs from a user point of view. Not just a user who clicks a
tab but also a user who might write some Lisp code to associate with a given
tab, to affect what happens when it is clicked.

Suppose, for illustration, that it would be sufficient to associate a given
existing bookmark with a given tab. The displayed tab name would be the bookmark
name. When you click the tab, the bookmark handler would be invoked, and
whatever destination is involved (if any) would be displayed (e.g. in the tab's
window).

When you invoke a bookmark normally (e.g. with `bookmark-jump') the handler is
invoked, and the handler typically includes a display function (e.g.
`pop-to-buffer'). What I envision for tabs is using the handler without its
display part. That is, suppress the display part of the bookmark handler and
substitute for it whatever display behavior we will define for tabs.

The bookmark handler would need to still visit the proper buffer (if it visits a
buffer), but not display that buffer. It is the tab code that would be in charge
of display, perhaps basing its behavior on the particular display function
defined for the handler. I haven't addressed the tab-display question, and I
probably don't have much to say about it.

What I'm concerned about is having the generality of associating an arbitrary
handler with each tab. And it would be very nice if we could leverage the
existing format of bookmarks in this regard - that is, be able to handle
existing bookmarks out of the box.

RE: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Drew Adams writes:

 > >  > I want a tab to be able to invoke any function whatever.
 > > 
 > > While perhaps sufficient generality may require that ability, remember
 > > that tabs as a metaphor are *not* just a contiguous row of buttons.
 > > They are ordered,
 > 
 > Yes.
 > 
 > > and they "do the same thing" (but to different objects).
 > 
 > How so?
 >
 > It's not clear to me, for example, what you mean by tabs
 > (necessarily) doing the same thing to different objects.

Those are scare quotes.  I wouldn't have quoted if I was able to
*define* "do the same thing"!

Let me start with some definitions: A *tab bar* (what in my previous
post I called a "tab control") is a widget which contains several
*tabs*, and (usually) a *pane* in which some kind of content is
displayed.  (In the implementation discussed below I assume the pane
is an Emacs window, but that need not be true.)  *Tabs* are clickable
buttons, but they only appear as part of a tab bar.  Within a tab bar,
there is a distinguished *top tab*.  In cases where the tabs control a
specific pane in the display, the top tab is the one associated with
the currently visible content.  Tabs may also be ordered from left to
right (assuming a horizontal orientation to avoid overloading the word
"top").  The top tab need not be leftmost, but is always visible and
visually distinguishable (unless the user has selected a weird face).

Clicking on an individual tab will cause some action to occur, usually
reflected by a change in the appearance of the content.  It always
causes the clicked tab to become the top tab.

 > Apart from the GUI aspects (including the display question), I see
 > a tab bar as an ordered sequence of named (Lisp) thingies that you
 > can select (e.g. by clicking). I therefore think of an alist, where
 > the keys are the tab names and the values are arbitrary Lisp
 > objects.

That's very adequately represented visually by a toolbar.  Why do you
want to duplicate the functionality of toolbars in tab bars?

 > Unlike the case for menus, the structure of the VALUE part of a
 > bookmark is quite flexible and open (e.g. to user definition), and
 > the associated action (handler) need not be an Emacs command
 > (`interactive'). A default handler applies, if none is present
 > explicitly. To me, the bookmark model is quite general and
 > corresponds conceptually to a tab: a named Lisp value that can
 > represent some action to be performed when the tab is selected.

"All hope abandon ye who enter here."  That's a toolbar.  (But I
repeat myself.  "What I say three times is true."  Wait for it!)  If
toolbars have the restrictions that menus do (which are hardly
restrictive, actually; anything that can take a function symbol as a
value can implement arbitrary behavior), you can bet that tabs will
suffer the same restrictions.

 > I mentioned that I would also like to be able to perform certain
 > operations on the tabs of a given tab bar that are similar to
 > operations that I perform on a list of bookmarks: (1) sort the tabs
 > in various ways, based on both NAME and VALUE, (2) mark the tabs
 > and then perform operations on the marked tabs, (3) hide certain
 > tabs (e.g. those marked), (4) show a set of tabs that might not
 > already have been shown and then hidden (e.g. to "open" a project
 > that involves multiple tabs). And so on.
 >
 > And I mentioned that (bookmark+) bookmarks can be tagged
 > (del.icio.us-style), which would mean that tabs would be tagged, so
 > you could easily manipulate sets of tabs - e.g. all the tabs that
 > correspond to a particular project or query.
 > 
 > IOW, individual tabs can be selected, yes, but code (hence users)
 > should also be able to act on sets of tabs in various ways.

Sure.  A tab bar will surely be visible to Lisp as a sequence of some
kind, and accessed by a variable.  I don't see why any of the things
you describe above will be prevented by any particular implementation
of the action invoked by a tab.

 > What I'm concerned about is having the generality of associating an
 > arbitrary handler with each tab.

That's a toolbar.  Q.E.D.

If you really really need both the visual cues provided by a tab bar,
and an arbitrary handler for each tab, then (using your alist
representation, which is probably as good as any other) you could have

(defun my-tab-handler (tab ignored-datum)    ; all tab handlers take 2 args
  (let ((name (nth 0 tab))
        (handler (nth 1 tab))
        (tab-data (nthcdr 2 tab)))
    (message "handling tab '%s'" name)
    (apply handler tab-data)))

as the handler, and the tab bar would be represented in Lisp as
something like

("This establishment serves only 17-year-old Scottish tabs." ; name/doc
 my-tab-handler
 (random)          ; random tab-bar-wide datum, not used by my-tab-handler
 ("One name"       handler-1   various data)
 ("Another name"   handler-2   some    information)
 ;; etc etc
 )

But in most cases, having tab-specific handlers is probably a bad fit
for the tab metaphor.  Use a toolbar.  If your problem with that is
that Emacs toolbars are too restrictive, then fix the restrictions.

OTOH, a typical over-simplified buffer tab bar would be handled by

(defun buffer-tab-handler (tab tab-controlled-window)
  (with-selected-window tab-controlled-window
    (switch-to-buffer (second tab))))

(defun make-buffer-tabs (how-many controlled-window)
  (let ((buffers (buffer-list))
        (tabs '(controlled-window buffer-tab-handler "buffer tab")))
    (while (and buffers (> how-many 0))
      (setq tabs (cons (list (buffer-name (car buffers)) (car buffers))
                       tabs))
      (setq how-many (1- how-many))
      (setq buffers (cdr buffers)))
    (reverse tabs)))

Gtk tabs in emacs, new branch.

[Jan Djärv]

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

Hello.

I've published a new branch (I hope, it is the first time I do this) that adds 
Gtk+ tabs to Emacs, it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.

Tabs isn't visible internally, it looks like just one frame at the lisp level. 
    Window configurations are used when switching between tabs.  I think this 
may cause flicker on slower machines.  Making Emacs use Gtk+ double buffering 
here would help.  I may violate running Lisp from C restrictions here, but I 
am not sure.  Tabs most likely introduces new frame sizing errors.

The TODO file talks about tabs on each window.  To make this happen, at least 
for Gtk+, each window needs to be its own widget, instead of one widget per 
frame as we have now.  This is a bigger task.

You can drag tabs to reorder them, drop them on another frame to move it there
and drop on the root window to create a new frame.

The tabs themselves should be smaller IMHO, but the x to delete a tab makes 
them larger than the text.

Lisp code is in native-tabs.el.  Keybindings are:

       (global-set-key "\C-x7\C-f" 'find-file-new-tab)
       (global-set-key "\C-x70" 'tab-delete)
       (global-set-key "\C-x71" 'tab-delete-other)
       (global-set-key "\C-x72" 'tab-new)
       (global-set-key "\C-x7f" 'find-file-new-tab)
       (global-set-key "\C-x7o" 'tab-next)
       (global-set-key "\C-x7n" 'tab-next)
       (global-set-key "\C-x7p" 'tab-previous)))


The lisp interface is:

(find-file-new-tab (filename &optional wildcards)

Edit file FILENAME, in a new tab.

(tab-new &optional LABEL FRAME)

Create a new tab with label LABEL in frame FRAME.
If LABEL is nil, use current buffer name.
FRAME nil means use the selected frame.

Returns the key for the tab, which can be passed to `tab-delete'.

(tab-delete &optional KEY FRAME)

Remove tab KEY from frame FRAME.
KEY is what `tab-new' returned or nil, which means the current tab.
FRAME nil means use the selected frame.

(tab-delete-other &optional FRAME)

Remove all tabs from frame FRAME except the current one.
FRAME nil means use the selected frame.

(tab-set-label LABEL &optional FRAME)

Set label for the current tab in frame FRAME to LABEL.
LABEL nil means use current buffer name.
FRAME nil means use the selected frame.

(tab-next &optional FRAME)

Go to the next tab on frame FRAME.
Wrap around to the beginning if current tab is last.
FRAME nil means use the selected frame.

(tab-previous &optional FRAME)

Go to the previous tab on frame FRAME.
Wrap around to the end if current tab is first.
FRAME nil means use the selected frame.

I'm sure there are tons of bugs.  I have not compiled this tree for anything 
other than Gtk+.

	Jan D.


[-- Attachment #2: tabs.png --]
[-- Type: image/png, Size: 37832 bytes --]

Re: Gtk tabs in emacs, new branch.

[Leo]

On 2010-04-01 14:07 +0100, Jan Djärv wrote:
> I'm sure there are tons of bugs.  I have not compiled this tree for
> anything other than Gtk+.
>
> 	Jan D.

The screenshot looks very nice ;)

Leo

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> I've published a new branch (I hope, it is the first time I do this) that
> adds Gtk+ tabs to Emacs,

Great!

> it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.

Why the branch name is gtk-specific?

I've been thinking about merging the non-toolkit tabs,
but this branch name is too restrictive.

> The TODO file talks about tabs on each window.  To make this happen, at
> least for Gtk+, each window needs to be its own widget, instead of one
> widget per frame as we have now.  This is a bigger task.

Tabs on each window is what tabbar.el already does.  I'm not sure
if Gtk+ tabs are necessary for every window.  Maybe what's need is
to improve tabbar.el to use its own dedicated header window, because
currently it conflicts with modes that use the same single header line
(e.g. Info, proced, ruler-mode).

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

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Juri Linkov skrev 2010-04-01 20.02:
>> I've published a new branch (I hope, it is the first time I do this) that
>> adds Gtk+ tabs to Emacs,
>
> Great!
>
>> it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.
>
> Why the branch name is gtk-specific?
>

Because it is an example of toolkit tabs, in this case very Gtk+ specific. 
Just to see how native toolkit tabs looks and behaves as opposed to for 
example tabbar.

> I've been thinking about merging the non-toolkit tabs,
> but this branch name is too restrictive.

Well, branches are easy with bzr, so just create your own :-).

>
>> The TODO file talks about tabs on each window.  To make this happen, at
>> least for Gtk+, each window needs to be its own widget, instead of one
>> widget per frame as we have now.  This is a bigger task.
>
> Tabs on each window is what tabbar.el already does.  I'm not sure
> if Gtk+ tabs are necessary for every window.  Maybe what's need is
> to improve tabbar.el to use its own dedicated header window, because
> currently it conflicts with modes that use the same single header line
> (e.g. Info, proced, ruler-mode).

I guess stuff like drag and drop for tabs don't work for tabbar?  That would 
be one difference if we where to mix the two.  I'll vote for either toolkit 
tabs or non-toolkit tabs, but not a mix.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

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

>> I've been thinking about merging the non-toolkit tabs,
>> but this branch name is too restrictive.
>
> Well, branches are easy with bzr, so just create your own :-).

I've published a new branch that implements tabs for non-toolkit X builds.
It is at bzr.savannah.gnu.org/srv/bzr/emacs/x-tabs.
The tab bar is modelled after the tool bar.  Tab functions share
some similarities with frame-, window- and buffer-related functions
(same name conventions, etc.)


[-- Attachment #2: tab-bar.png --]
[-- Type: image/png, Size: 21005 bytes --]

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


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

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> >> I've been thinking about merging the non-toolkit tabs,
> >> but this branch name is too restrictive.
> >
> > Well, branches are easy with bzr, so just create your own :-).
> 
> I've published a new branch that implements tabs for 
> non-toolkit X builds.
> It is at bzr.savannah.gnu.org/srv/bzr/emacs/x-tabs.
> The tab bar is modelled after the tool bar.  Tab functions share
> some similarities with frame-, window- and buffer-related functions
> (same name conventions, etc.)

When describing such a feature, it would help to compare and contrast it with
tabbar.el, with which many people are familiar. Similarly, it would help to
compare it with tabs in other apps. 

At least at a summary level of description, to give an idea.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> When describing such a feature, it would help to compare and contrast
> it with tabbar.el, with which many people are familiar. Similarly, it
> would help to compare it with tabs in other apps.

I'm a big fan of the tabbed UI in different apps, mostly in web browsers
since mid-1990s.  This feature is a real efficiency booster that helps
to organize the workspace.

The most natural entity in Emacs to display in a tab would be a window
configuration.  Actually, something like this is already implemented in
Konqueror where you can split the window vertically/horizontally in a tab.
If you try it, you will understand how convenient it is.

In the screenshot I sent, you can see Back/Forward buttons that expose
in UI a useful feature existed for a long time in winner.el (currently
winner.el is not used directly since it should be modified to support tabs).
This will work like History Back/Forward buttons in web browsers.

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

Re: Gtk tabs in emacs, new branch.

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 10 Apr 2010 02:27:45 +0300, Juri Linkov <juri@jurta.org> said:

> I've published a new branch that implements tabs for non-toolkit X
> builds.  It is at bzr.savannah.gnu.org/srv/bzr/emacs/x-tabs.  The
> tab bar is modelled after the tool bar.  Tab functions share some
> similarities with frame-, window- and buffer-related functions (same
> name conventions, etc.)

The following patch will make a few things more consistent with my
2010-01-09 changes.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

=== modified file 'src/window.h'
*** src/window.h	2010-04-09 23:19:38 +0000
--- src/window.h	2010-04-10 01:34:30 +0000
***************
*** 415,425 ****
    (WINDOWP (WINDOW_XFRAME (W)->tool_bar_window) \
     && (W) == XWINDOW (WINDOW_XFRAME (W)->tool_bar_window))
  
  /* Return the frame y-position at which window W starts.
     This includes a header line, if any.  */
  
  #define WINDOW_TOP_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  
--- 415,431 ----
    (WINDOWP (WINDOW_XFRAME (W)->tool_bar_window) \
     && (W) == XWINDOW (WINDOW_XFRAME (W)->tool_bar_window))
  
+ /* 1 if W is a tab bar window.  */
+ 
+ #define WINDOW_TAB_BAR_P(W) \
+   (WINDOWP (WINDOW_XFRAME (W)->tab_bar_window) \
+    && (W) == XWINDOW (WINDOW_XFRAME (W)->tab_bar_window))
+ 
  /* Return the frame y-position at which window W starts.
     This includes a header line, if any.  */
  
  #define WINDOW_TOP_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W) || WINDOW_TAB_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  
***************
*** 427,433 ****
     This includes a mode line, if any.  */
  
  #define WINDOW_BOTTOM_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  
--- 433,439 ----
     This includes a mode line, if any.  */
  
  #define WINDOW_BOTTOM_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W) || WINDOW_TAB_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  

=== modified file 'src/xfns.c'
*** src/xfns.c	2010-04-09 23:19:38 +0000
--- src/xfns.c	2010-04-10 02:35:00 +0000
***************
*** 1540,1546 ****
      {
        int height = FRAME_INTERNAL_BORDER_WIDTH (f);
        int width = FRAME_PIXEL_WIDTH (f);
!       int y = nlines * FRAME_LINE_HEIGHT (f);
  
        /* height can be zero here. */
        if (height > 0 && width > 0)
--- 1540,1547 ----
      {
        int height = FRAME_INTERNAL_BORDER_WIDTH (f);
        int width = FRAME_PIXEL_WIDTH (f);
!       int y = (FRAME_MENU_BAR_LINES (f) + FRAME_TOOL_BAR_LINES (f)
! 	       + nlines) * FRAME_LINE_HEIGHT (f);
  
        /* height can be zero here. */
        if (height > 0 && width > 0)

=== modified file 'src/xterm.c'
*** src/xterm.c	2010-04-09 23:19:38 +0000
--- src/xterm.c	2010-04-10 02:31:59 +0000
***************
*** 751,761 ****
      {
        int y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, desired_row->y));
  
-       /* Internal border is drawn below the tab bar.  */
-       if (WINDOWP (f->tab_bar_window)
- 	  && w == XWINDOW (f->tab_bar_window))
- 	y -= width;
- 
        BLOCK_INPUT;
        x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
  		    0, y, width, height, False);
--- 751,756 ----

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> The following patch will make a few things more consistent with my
> 2010-01-09 changes.

Thank you!  This branch was created before 2010-01-09, so I missed
your changes.  Now you patch is installed in the x-tabs branch.

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

Re: Gtk tabs in emacs, new branch.

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Tabs isn't visible internally, it looks like just one frame at the
> lisp level.  Window configurations are used when switching between
> tabs.  I think this may cause flicker on slower machines.  Making
> Emacs use Gtk+ double buffering here would help.  I may violate
> running Lisp from C restrictions here, but I am not sure.  Tabs most
> likely introduces new frame sizing errors.

I haven't had time to take a look at the implementation, but why do you
need to use window configurations?  It seems cleaner to treat each tab
as a separate frame, at both the C and Lisp levels.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Chong Yidong skrev 2010-04-01 20.50:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Tabs isn't visible internally, it looks like just one frame at the
>> lisp level.  Window configurations are used when switching between
>> tabs.  I think this may cause flicker on slower machines.  Making
>> Emacs use Gtk+ double buffering here would help.  I may violate
>> running Lisp from C restrictions here, but I am not sure.  Tabs most
>> likely introduces new frame sizing errors.
>
> I haven't had time to take a look at the implementation, but why do you
> need to use window configurations?  It seems cleaner to treat each tab
> as a separate frame, at both the C and Lisp levels.
>

Yes, but that kind of requires modifications to almost all .c-files.  I just 
wanted something that does tabs like for example Firefox does.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Chong Yidong skrev 2010-04-01 20.50:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Tabs isn't visible internally, it looks like just one frame at the
>> lisp level.  Window configurations are used when switching between
>> tabs.  I think this may cause flicker on slower machines.  Making
>> Emacs use Gtk+ double buffering here would help.  I may violate
>> running Lisp from C restrictions here, but I am not sure.  Tabs most
>> likely introduces new frame sizing errors.
>
> I haven't had time to take a look at the implementation, but why do you
> need to use window configurations?  It seems cleaner to treat each tab
> as a separate frame, at both the C and Lisp levels.
>

Yes, but that kind of requires modifications to almost all .c-files.  I just 
wanted something that does tabs like for example Firefox does.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> I haven't had time to take a look at the implementation, but why do you
> need to use window configurations?

FWIW, I think the link between TABs and their "meaning" (i.e. the
action to perform when one TAB is selected) should be in Elisp, and
using window-configs seem like a very natural choice.  Much more
lightweight that frames.


        Stefan "who thinks there's a continuum between tabs-on-frames
                and tabs-on-window, by allowing tabs at any level of the
                window tree".

Re: Gtk tabs in emacs, new branch.

[alin.s]

Jan Djärv wrote:
> 
> Hello.
> 
> I've published a new branch (I hope, it is the first time I do this) that
> adds 
> Gtk+ tabs to Emacs, it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.
> 
> Tabs isn't visible internally, it looks like just one frame at the lisp
> level. 
>     Window configurations are used when switching between tabs.  I think
> this 
> may cause flicker on slower machines.  Making Emacs use Gtk+ double
> buffering 
> here would help.  I may violate running Lisp from C restrictions here, but
> I 
> am not sure.  Tabs most likely introduces new frame sizing errors.
> 
> The TODO file talks about tabs on each window.  To make this happen, at
> least 
> for Gtk+, each window needs to be its own widget, instead of one widget
> per 
> frame as we have now.  This is a bigger task.
> 
> You can drag tabs to reorder them, drop them on another frame to move it
> there
> and drop on the root window to create a new frame.
> 
> The tabs themselves should be smaller IMHO, but the x to delete a tab
> makes 
> them larger than the text.
> 
> Lisp code is in native-tabs.el.  Keybindings are:
> 
>        (global-set-key "\C-x7\C-f" 'find-file-new-tab)
>        (global-set-key "\C-x70" 'tab-delete)
>        (global-set-key "\C-x71" 'tab-delete-other)
>        (global-set-key "\C-x72" 'tab-new)
>        (global-set-key "\C-x7f" 'find-file-new-tab)
>        (global-set-key "\C-x7o" 'tab-next)
>        (global-set-key "\C-x7n" 'tab-next)
>        (global-set-key "\C-x7p" 'tab-previous)))
> 
> 
> The lisp interface is:
> 
> (find-file-new-tab (filename &optional wildcards)
> 
> Edit file FILENAME, in a new tab.
> 
> (tab-new &optional LABEL FRAME)
> 
> Create a new tab with label LABEL in frame FRAME.
> If LABEL is nil, use current buffer name.
> FRAME nil means use the selected frame.
> 
> Returns the key for the tab, which can be passed to `tab-delete'.
> 
> (tab-delete &optional KEY FRAME)
> 
> Remove tab KEY from frame FRAME.
> KEY is what `tab-new' returned or nil, which means the current tab.
> FRAME nil means use the selected frame.
> 
> (tab-delete-other &optional FRAME)
> 
> Remove all tabs from frame FRAME except the current one.
> FRAME nil means use the selected frame.
> 
> (tab-set-label LABEL &optional FRAME)
> 
> Set label for the current tab in frame FRAME to LABEL.
> LABEL nil means use current buffer name.
> FRAME nil means use the selected frame.
> 
> (tab-next &optional FRAME)
> 
> Go to the next tab on frame FRAME.
> Wrap around to the beginning if current tab is last.
> FRAME nil means use the selected frame.
> 
> (tab-previous &optional FRAME)
> 
> Go to the previous tab on frame FRAME.
> Wrap around to the end if current tab is first.
> FRAME nil means use the selected frame.
> 
> I'm sure there are tons of bugs.  I have not compiled this tree for
> anything 
> other than Gtk+.
> 
> 	Jan D.
> 
> 
>  
> 


Hi,


I worked on tabs, and after I did something general at C level, I realised
that I could have done better. Unfortunately, for now I cannot continue to
work on that, but I can do in in about 6 months. I can do the interface at C
level.

For me a tab will  be neither a window configuration, nor a frame, but it
will act according to an initialization function written in lisp. Every
event will have associated a script, like switch, etc. It is useful also for
me to insert an environment of tab-local variables.

In this manner, I could do it in 6 months for all.

If you work on tabs and install a definitive version, please tell me whether
it makes sense for me to implement my version in future, when I have time.




Alin




-- 
View this message in context: http://old.nabble.com/Gtk-tabs-in-emacs%2C-new-branch.-tp28108550p28188551.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Gtk tabs in emacs, new branch.

[Jan D.]

alin.s wrote:

> For me a tab will  be neither a window configuration, nor a frame, but it
> will act according to an initialization function written in lisp. Every
> event will have associated a script, like switch, etc. It is useful also for
> me to insert an environment of tab-local variables.

I don't know if we want tab-local variables. We had frame-local, but 
they are obsolete now.  You have to give a convincing reason for that 
and what an initialization function and script gives for advantages.

> 
> In this manner, I could do it in 6 months for all.
> 
> If you work on tabs and install a definitive version, please tell me whether
> it makes sense for me to implement my version in future, when I have time.
> 

It is too early to tell.  The implementation and design is still 
evolving.  Implementations other than for Gtk+ makes sense in any case.

	Jan D.