Emacs development

Leo | 1 Apr 2010 15:24

Re: Gtk tabs in emacs, new branch.

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

headers

Angelo Graziosi | 1 Apr 2010 18:52

Re: Gtk tabs in emacs, new branch

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.

headers

Jan Djärv | 1 Apr 2010 19:45

Re: Gtk tabs in emacs, new branch

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.

(Continue reading)

headers

Juri Linkov | 1 Apr 2010 20:03

Re: Gtk tabs in emacs, 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.

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/

headers

Jan Djärv | 1 Apr 2010 22:18

Re: Gtk tabs in emacs, new branch


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.

(Continue reading)

headers

Jan Djärv | 2 Apr 2010 09:10

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 1 Apr 2010 22:51

Re: Gtk tabs in emacs, new branch

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.

headers

Jan Djärv | 2 Apr 2010 08:49

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 2 Apr 2010 11:21

Re: Gtk tabs in emacs, new branch

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.

headers

Stephen J. Turnbull | 2 Apr 2010 04:06

Re: Gtk tabs in emacs, new branch

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.

(Continue reading)

headers

Jan Djärv | 2 Apr 2010 09:00

Re: Gtk tabs in emacs, new branch

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.

headers

Jan Djärv | 2 Apr 2010 08:53

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 2 Apr 2010 11:59

Re: Gtk tabs in emacs, new branch

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.

headers

Jan Djärv | 2 Apr 2010 17:10

Re: Gtk tabs in emacs, new branch

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.

(Continue reading)

headers

Angelo Graziosi | 2 Apr 2010 18:55

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 5 Apr 2010 10:50

Re: Gtk tabs in emacs, new branch

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.

headers

Jan Djärv | 10 Apr 2010 14:44

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 10 Apr 2010 19:34

Re: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Jan Djärv | 10 Apr 2010 20:03

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 11 Apr 2010 00:09

Re: Gtk tabs in emacs, new branch

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

headers

Jan Djärv | 11 Apr 2010 07:45

Re: Gtk tabs in emacs, new branch

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

headers

Angelo Graziosi | 11 Apr 2010 10:16

Re: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Jan Djärv | 11 Apr 2010 12:52

Re: Gtk tabs in emacs, new branch

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.

headers

Angelo Graziosi | 11 Apr 2010 19:28

Re: Gtk tabs in emacs, new branch

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.

(Continue reading)

headers

Jan Djärv | 11 Apr 2010 20:33

Re: Gtk tabs in emacs, new branch

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.

headers

Juri Linkov | 21 Apr 2010 10:55

Re: Gtk tabs in emacs, new branch

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

headers

David Kastrup | 21 Apr 2010 11:46

Re: Gtk tabs in emacs, new branch

Juri Linkov <juri <at> 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

(Continue reading)

headers

Juri Linkov | 21 Apr 2010 17:43

Re: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Angelo Graziosi | 21 Apr 2010 15:54

Re: Gtk tabs in emacs, new branch

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

headers

Juri Linkov | 21 Apr 2010 17:45

Re: Gtk tabs in emacs, new branch

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)

(Continue reading)

headers

Jan Djärv | 21 Apr 2010 18:04

Re: Gtk tabs in emacs, new branch

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)

(Continue reading)

headers

Juri Linkov | 22 Apr 2010 10:14

Re: Gtk tabs in emacs, new branch

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

headers

Juanma Barranquero | 22 Apr 2010 18:20

Re: Gtk tabs in emacs, new branch

On Thu, Apr 22, 2010 at 10:14, Juri Linkov <juri <at> 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

headers

Juri Linkov | 24 Apr 2010 20:45

Re: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Drew Adams | 23 Apr 2010 18:53

RE: Gtk tabs in emacs, new branch

> 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

(Continue reading)

headers

Juri Linkov | 23 Apr 2010 20:02

Re: Gtk tabs in emacs, new branch

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

headers

Drew Adams | 23 Apr 2010 20:28

RE: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Juri Linkov | 24 Apr 2010 11:17

Re: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Drew Adams | 24 Apr 2010 16:41

RE: Gtk tabs in emacs, new 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.

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

(Continue reading)

headers

Juri Linkov | 24 Apr 2010 20:49

Re: Gtk tabs in emacs, new branch

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

headers

Drew Adams | 24 Apr 2010 21:24

RE: Gtk tabs in emacs, new branch

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

headers

Juri Linkov | 25 Apr 2010 07:36

Re: Gtk tabs in emacs, new branch

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

headers

martin rudalics | 25 Apr 2010 11:15

Re: Gtk tabs in emacs, new branch

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

(Continue reading)

headers

Juri Linkov | 25 Apr 2010 20:33

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

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

(Continue reading)

headers

martin rudalics | 26 Apr 2010 18:16

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 27 Apr 2010 10:54

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 27 Apr 2010 14:54

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 27 Apr 2010 20:03

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 27 Apr 2010 21:47

Info buffers in Desktop

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
 <at>  <at>  -3202,25 +3217,15  <at>  <at> 
 	       (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*"
 <at>  <at>  -4863,7 +4869,8  <at>  <at> 

 (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

--

--

(Continue reading)

headers

martin rudalics | 28 Apr 2010 09:12

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 28 Apr 2010 10:27

Re: Window configurations

> 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

(Continue reading)

headers

Davis Herring | 27 Apr 2010 21:55

Re: Window configurations

> 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

(Continue reading)

headers

Juri Linkov | 28 Apr 2010 10:35

Re: Window configurations

> 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

(Continue reading)

headers

Davis Herring | 28 Apr 2010 16:15

Re: Window configurations

> 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

(Continue reading)

headers

Juri Linkov | 7 May 2010 20:14

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 28 Apr 2010 09:12

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 28 Apr 2010 16:50

Re: Window configurations

> 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

headers

Ken Hori | 30 Apr 2010 05:19

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

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

(Continue reading)

headers

Stefan Monnier | 30 Apr 2010 22:33

Re: Window configurations

> 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

headers

Juri Linkov | 2 May 2010 22:31

Re: Window configurations

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

headers

Drew Adams | 3 May 2010 01:34

RE: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 3 May 2010 02:50

Re: Window configurations

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

headers

Juri Linkov | 3 May 2010 02:57

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 3 May 2010 04:50

Re: Window configurations

> 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

headers

Juri Linkov | 4 May 2010 18:09

Re: Window configurations

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

headers

Stephen J. Turnbull | 5 May 2010 08:41

Re: Window configurations

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

headers

Stefan Monnier | 5 May 2010 15:22

Re: Window configurations

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

headers

Stephen J. Turnbull | 5 May 2010 16:35

Re: Window configurations

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.

headers

Juri Linkov | 5 May 2010 23:59

Re: Window configurations

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

headers

Juri Linkov | 2 May 2010 22:28

Re: Window configurations

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

(Continue reading)

headers

Ken Hori | 3 May 2010 05:31

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 4 May 2010 18:12

Re: Window configurations

> 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

(Continue reading)

headers

martin rudalics | 5 May 2010 11:19

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 5 May 2010 20:19

Re: Window configurations

> 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

headers

martin rudalics | 6 May 2010 10:22

Re: Window configurations

 > 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

(Continue reading)

headers

Stefan Monnier | 6 May 2010 15:04

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 6 May 2010 16:59

Re: Window configurations

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

headers

Stefan Monnier | 6 May 2010 18:17

Re: Window configurations

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

headers

grischka | 6 May 2010 13:18

Re: Window configurations

 > I don't think that dedicated windows suck and even went so far as to
 > give them an entire section in the Elisp manual 

I guess if the feature would dedicate buffers to windows (rather than
windows to buffers) it would be much more useful (and less suck).

--- grischka

headers

Juri Linkov | 5 May 2010 20:05

Re: Window configurations

> 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

(Continue reading)

headers

martin rudalics | 6 May 2010 10:21

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 6 May 2010 22:47

Re: Window configurations

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

headers

Juri Linkov | 10 May 2010 21:16

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 11 May 2010 09:01

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 11 May 2010 18:45

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 12 May 2010 11:29

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 14 May 2010 00:46

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 14 May 2010 08:59

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 17 May 2010 00:51

Re: Window configurations

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

headers

martin rudalics | 17 May 2010 11:06

Re: Window configurations

 > 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

headers

Juri Linkov | 18 May 2010 00:54

Re: Window configurations

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

headers

martin rudalics | 18 May 2010 14:07

Re: Window configurations

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

headers

martin rudalics | 31 May 2010 19:28

Re: Window configurations

 > 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

(Continue reading)

headers

Stefan Monnier | 31 May 2010 20:39

Re: Window configurations

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

(Continue reading)

headers

Lennart Borgman | 31 May 2010 21:12

Re: Window configurations

On Mon, May 31, 2010 at 8:39 PM, Stefan Monnier
<monnier <at> 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).

headers

Juri Linkov | 31 May 2010 22:23

Re: Window configurations

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

headers

martin rudalics | 1 Jun 2010 11:24

Re: Window configurations

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

headers

Juri Linkov | 31 May 2010 22:19

Re: Window configurations

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

headers

Stefan Monnier | 1 Jun 2010 05:13

Re: Window configurations

> 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

headers

martin rudalics | 1 Jun 2010 11:25

Re: Window configurations

 > 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

headers

Stefan Monnier | 1 Jun 2010 14:58

Re: Window configurations

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

headers

martin rudalics | 1 Jun 2010 11:24

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 1 Jun 2010 15:08

Re: Window configurations

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

(Continue reading)

headers

Lennart Borgman | 1 Jun 2010 16:02

Re: Window configurations

On Tue, Jun 1, 2010 at 3:08 PM, Stefan Monnier <monnier <at> 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.)

headers

martin rudalics | 1 Jun 2010 18:04

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 1 Jun 2010 21:20

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 2 Jun 2010 14:59

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 2 Jun 2010 16:08

Re: Window configurations

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

headers

martin rudalics | 3 Jun 2010 10:55

Re: Window configurations

 > 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

headers

Juri Linkov | 1 Jun 2010 21:54

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 2 Jun 2010 15:00

Re: Window configurations

 > 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

headers

Juri Linkov | 2 Jun 2010 21:46

Re: Window configurations

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

headers

martin rudalics | 3 Jun 2010 10:55

Re: Window configurations

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

headers

Juri Linkov | 3 Jun 2010 20:55

Re: Window configurations

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

headers

martin rudalics | 14 Jun 2010 19:05

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 14 Jun 2010 23:54

Re: Window configurations

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

headers

martin rudalics | 15 Jun 2010 09:08

Re: Window configurations

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

headers

Juri Linkov | 15 Jun 2010 23:31

Re: Window configurations

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

headers

martin rudalics | 16 Jun 2010 19:25

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 16 Jun 2010 22:51

Re: Window configurations

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

headers

martin rudalics | 17 Jun 2010 09:58

Re: Window configurations

 > 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

(Continue reading)

headers

Juri Linkov | 17 Jun 2010 10:42

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 17 Jun 2010 12:20

Re: Window configurations

 > 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

(Continue reading)

headers

Juri Linkov | 17 Jun 2010 22:38

Re: Window configurations

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

headers

Lennart Borgman | 18 Jun 2010 00:55

Re: Window configurations

On Thu, Jun 17, 2010 at 10:38 PM, Juri Linkov <juri <at> 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).

headers

martin rudalics | 18 Jun 2010 08:34

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 18 Jun 2010 10:28

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 18 Jun 2010 11:04

Re: Window configurations

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

headers

Juri Linkov | 19 Jun 2010 10:50

Re: Window configurations

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

headers

martin rudalics | 19 Jun 2010 15:47

Re: Window configurations

> 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

headers

Juri Linkov | 19 Jun 2010 16:12

Re: Window configurations

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

headers

martin rudalics | 19 Jun 2010 20:56

Re: Window configurations

> 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

headers

Juri Linkov | 1 Jun 2010 21:51

Re: Window configurations

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

headers

martin rudalics | 2 Jun 2010 15:00

Re: Window configurations

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

headers

Juri Linkov | 2 Jun 2010 21:49

Re: Window configurations

>>> 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
 <at>  <at>  -1299,6 +1299,7  <at>  <at>  (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

(Continue reading)

headers

martin rudalics | 3 Jun 2010 10:57

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 3 Jun 2010 16:22

Re: Window configurations

> 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

headers

martin rudalics | 3 Jun 2010 17:42

Re: Window configurations

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

headers

Stefan Monnier | 4 Jun 2010 15:11

Re: Window configurations

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

headers

martin rudalics | 4 Jun 2010 16:07

Re: Window configurations

 > 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

headers

Juri Linkov | 4 Jun 2010 18:59

Re: Window configurations

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

headers

martin rudalics | 5 Jun 2010 14:49

Re: Window configurations

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

headers

Richard Stallman | 4 Jun 2010 12:36

Re: Window configurations

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

headers

martin rudalics | 4 Jun 2010 16:06

Re: Window configurations

 >     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

headers

Juri Linkov | 3 Jun 2010 20:54

Re: Window configurations

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

headers

martin rudalics | 4 Jun 2010 10:11

Re: Window configurations

 > 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

headers

Juri Linkov | 4 Jun 2010 18:57

Re: Window configurations

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

headers

martin rudalics | 5 Jun 2010 14:49

Re: Window configurations

 > 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

headers

Juri Linkov | 5 Jun 2010 21:47

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 6 Jun 2010 15:21

Re: Window configurations

> 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

headers

Juri Linkov | 7 Jun 2010 20:31

Re: Window configurations

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

headers

Juri Linkov | 3 Jun 2010 20:52

Re: Window configurations

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

headers

martin rudalics | 4 Jun 2010 10:11

Re: Window configurations

 > 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

(Continue reading)

headers

Juri Linkov | 4 Jun 2010 19:09

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 5 Jun 2010 14:49

Re: Window configurations

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

(Continue reading)

headers

Juri Linkov | 5 Jun 2010 21:49

Re: Window configurations

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

(Continue reading)

headers

Stefan Monnier | 5 Jun 2010 23:58

Re: Window configurations

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

headers

Juri Linkov | 7 Jun 2010 20:30

Re: Window configurations

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

headers

martin rudalics | 6 Jun 2010 12:38

Re: Window configurations

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

headers

Stefan Monnier | 7 Jun 2010 03:12

Re: Window configurations

> 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

headers

martin rudalics | 7 Jun 2010 15:40

Re: Window configurations

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

headers

Stefan Monnier | 7 Jun 2010 17:36

Re: Window configurations

> 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

headers

Lennart Borgman | 7 Jun 2010 19:38

Re: Window configurations

On Mon, Jun 7, 2010 at 5:36 PM, Stefan Monnier <monnier <at> 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.

headers

martin rudalics | 8 Jun 2010 15:06

Re: Window configurations

 > 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

(Continue reading)

headers

Stefan Monnier | 8 Jun 2010 22:19

Re: Window configurations

> 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

headers

martin rudalics | 11 Jun 2010 15:20

Re: Window configurations

 > 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

headers

Stefan Monnier | 11 Jun 2010 15:52

Re: Window configurations

> 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

headers

martin rudalics | 11 Jun 2010 19:12

Re: Window configurations

 > 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

headers

Kevin Rodgers | 8 May 2010 05:09

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 8 May 2010 15:54

Re: Window configurations

 > 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

headers

Lennart Borgman | 8 May 2010 17:42

Re: Window configurations

On Sat, May 8, 2010 at 3:54 PM, martin rudalics <rudalics <at> 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?

headers

martin rudalics | 9 May 2010 16:01

Re: Window configurations

 > 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

headers

Lennart Borgman | 9 May 2010 16:21

Re: Window configurations

On Sun, May 9, 2010 at 4:01 PM, martin rudalics <rudalics <at> 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

headers

martin rudalics | 9 May 2010 17:01

Re: Window configurations

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

(Continue reading)

headers

grischka | 5 May 2010 15:31

Re: Window configurations

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

FWIW I think the introduction of window-configurations (as API) was
a mistake and let them save to file is an even bigger mistake.

Really not every kludge is a feature and in this case the best you can
do is to get rid of it.

--- grischka

headers

Juri Linkov | 5 May 2010 20:10

Re: Window configurations

> FWIW I think the introduction of window-configurations (as API) was
> a mistake and let them save to file is an even bigger mistake.
>
> Really not every kludge is a feature and in this case the best you can
> do is to get rid of it.

Thanks for the constructive comment.

--

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

headers

grischka | 5 May 2010 21:47

Re: Window configurations

Juri Linkov wrote:
>> FWIW I think the introduction of window-configurations (as API) was
>> a mistake and let them save to file is an even bigger mistake.
>>
>> Really not every kludge is a feature and in this case the best you can
>> do is to get rid of it.
> 
> Thanks for the constructive comment.
> 

That was deconstructive ;)

headers

Drew Adams | 5 May 2010 22:07

RE: Window configurations

> > The point of set-window-configuration-from-sexp is to restore the
> > configuration of windows, not to duplicate the functionality of
> > desktop.el.
> 
> FWIW I think the introduction of window-configurations (as API) was
> a mistake and let them save to file is an even bigger mistake.
> 
> Really not every kludge is a feature and in this case the best you can
> do is to get rid of it.

Just a suggestion -

It can help others if you give _reasons_ why you feel the way you do. That might
even persuade others who would feel the same way if they knew your reasons.

headers

grischka | 11 May 2010 15:54

Re: Window configurations

Maybe a matter of taste but I would not count on more conclusive behavior
from even more new options that allow packages to do what you want in case
anyone bothers to understand the complex specifications.  Instead it might
be much more effective to implement conclusive behavior in a simple algorithm
and remove any options for packages to circumvent it.

For instance, one could have a buffer stack for each window, such that each
buffer displayed is added on top of the window's buffer stack.  If a buffer is
killed or hidden, then the window's next buffer is displayed.  If there is
no "next", then the window is deleted (including the frame if it's the last
window).

--- grischka

From: martin rudalics
>    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.

(Continue reading)

headers

martin rudalics | 12 May 2010 11:28

Re: Window configurations

 > Maybe a matter of taste but I would not count on more conclusive behavior
 > from even more new options that allow packages to do what you want in case
 > anyone bothers to understand the complex specifications.  Instead it might
 > be much more effective to implement conclusive behavior in a simple
 > algorithm
 > and remove any options for packages to circumvent it.

I didn't describe a new option.  The parameter I described is implicitly
present in the current behavior of help windows.  What I did was moving
it from such windows to `display-buffer' and also to a function intended
to get rid of window contents in some way.

 > For instance, one could have a buffer stack for each window, such that each
 > buffer displayed is added on top of the window's buffer stack.

Probably a buffer should be added at the time it's unshown and still
alive - yet another complication for `kill-buffer'.

 > If a
 > buffer is
 > killed or hidden, then the window's next buffer is displayed.

That's more or less what I do now - modulo the stack behavior, but this
could be changed.  One complication is that window configurations would
have to store the buffer stack and all buffer references.

What's more problematic, however, is that it's not clear whether each
and every occurrence of `set-window-buffer' should add its buffer to the
stack.  Currently, I put a buffer there only when `display-buffer'
displays it.  And, obviously, stacks have the usual annoying attitude to

(Continue reading)

headers

grischka | 12 May 2010 13:12

Re: Window configurations

martin rudalics wrote:
> ... And, obviously, stacks have the usual annoying attitude to
> forget about their tops, so sooner or later someone will come up and ask
> for a ring or eventually a buffer history tree for each window and some
> way to navigate it.

You're already lost if you plan to expose details of your design to users
or packages.  If people want rings or history, they can still implement
it on top of your design as a whole.  It is then their responsibility to
make their feature conclusive to yours.

> But all this doesn't easily solve the problem of displaying a buffer in
> the intuitively right window, for example, the window where it has been
> already shown a couple of times before.  For this we could scan all
> windows' stacks and pick the one that has this buffer at the most
> prominent position - maybe supplied with some sort of a time-stamp.

One mistake is to cater for windows on the same level of generality as you
obviously do for low level lisp.  Of course you want functions "cons" etc.
to allow generation of arbitrarily complex lisp structures, but it cannot
be the point of "split-window" to generate arbitrarily complex window-trees,
(and anyway the result of some such is not a "window-configuration" but at
most a "window-state").

The other mistake is _not_ to cater for windows on the same level of
_reliability_ as you obviously do for low level lisp.  "Cons" doesn't work
"intuitively" in the sense of "heuristically", and one has to accept that
there is no other "intuitively right window" to display some buffer except
the exactly one defined location where the user wants to see it.

(Continue reading)

headers

martin rudalics | 12 May 2010 15:03

Re: Window configurations

 >> ... And, obviously, stacks have the usual annoying attitude to
 >> forget about their tops, so sooner or later someone will come up and ask
 >> for a ring or eventually a buffer history tree for each window and some
 >> way to navigate it.
 >
 > You're already lost if you plan to expose details of your design to users
 > or packages.  If people want rings or history, they can still implement
 > it on top of your design as a whole.  It is then their responsibility to
 > make their feature conclusive to yours.

There's hardly anything to implement "on top" of this.  The primitives
are `set-window-buffer' and `kill-buffer' so any implementation on top
of this would have to hook into `window-configuration-change-hook' and
`kill-buffer-hook'.

 > One mistake is to cater for windows on the same level of generality as you
 > obviously do for low level lisp.  Of course you want functions "cons" etc.
 > to allow generation of arbitrarily complex lisp structures, but it cannot
 > be the point of "split-window" to generate arbitrarily complex
 > window-trees,

I'm not sure whether I get your point.  But windows are first class
citizens in the Elisp world and `split-window' must be allowed to create
arbitrarily complex window trees on an arbitrarily complex machine.

 > (and anyway the result of some such is not a "window-configuration" but at
 > most a "window-state").

In my book a "window configuration" is "the state of all windows".

(Continue reading)

headers

grischka | 12 May 2010 20:33

Re: Window configurations

martin rudalics wrote:
>  > One mistake is to cater for windows on the same level of generality  as you
>  > obviously do for low level lisp.  Of course you want functions "cons" etc.
>  > to allow generation of arbitrarily complex lisp structures, but it cannot
>  > be the point of "split-window" to generate arbitrarily complex
>  > window-trees,
> 
> I'm not sure whether I get your point.  But windows are first class
> citizens in the Elisp world and `split-window' must be allowed to create
> arbitrarily complex window trees on an arbitrarily complex machine.

Which does not mean that any feature can be allowed to use split-window
as it happens to think.

>  > (and anyway the result of some such is not a "window-configuration" but at
>  > most a "window-state").
> 
> In my book a "window configuration" is "the state of all windows".

In my book configuration is rules and state is result from their application
(together with other conditions).  Conflating the both will just produce a
classical chicken & egg problem.

>  > The other mistake is _not_ to cater for windows on the same level of
>  > _reliability_ as you obviously do for low level lisp.  "Cons" doesn't work
>  > "intuitively" in the sense of "heuristically", and one has to accept that
>  > there is no other "intuitively right window" to display some buffer except
>  > the exactly one defined location where the user wants to see it.
> 
> The question which buffer I want to display must be solved heuristically

(Continue reading)

headers

martin rudalics | 13 May 2010 12:22

Re: Window configurations

 >> I'm not sure whether I get your point.  But windows are first class
 >> citizens in the Elisp world and `split-window' must be allowed to create
 >> arbitrarily complex window trees on an arbitrarily complex machine.
 >
 > Which does not mean that any feature can be allowed to use split-window
 > as it happens to think.

Features shouldn't do so, indeed.  `display-buffer' is the preferred
interface.

 >> In my book a "window configuration" is "the state of all windows".
 >
 > In my book configuration is rules and state is result from their
 > application
 > (together with other conditions).  Conflating the both will just produce a
 > classical chicken & egg problem.

If you specify a configuration procedurally you have to supply (1) an
initial state and (2) a set of actions and the order in which these
actions are applied.  In the context of window configurations, the state
resulting after applying (2) to (1) is the "state of all windows" as I
call it.  Hence the difference is basically only a matter of taste,
theroretically.

 From a practical point of view things are different: If you want to
derive (1) and (2) from the state of Emacs at some arbitrary point of
time you do have to guess a _minimum_ set of actions/rules that
reproduce the state of windows.  Otherwise, you end up like the
designers of ECB who record _all_ actions applied by the user and
"replay" them to produce the desired state.

(Continue reading)

headers

grischka | 13 May 2010 13:40

Re: Window configurations

martin rudalics wrote:
>  > In my book configuration is rules and state is result from their application
>  > (together with other conditions).  Conflating the both will just produce a
>  > classical chicken & egg problem.
> 
> If you specify a configuration procedurally you have to supply (1) an
> initial state and (2) a set of actions and the order in which these
> actions are applied.  In the context of window configurations, the state
> resulting after applying (2) to (1) is the "state of all windows" as I
> call it.  Hence the difference is basically only a matter of taste,
> theroretically.

It might be a matter of taste whether you prefer eggs or chicken but
the difference is certainly more than theoretical ;)

>  From a practical point of view things are different: If you want to
> derive (1) and (2) from the state of Emacs at some arbitrary point of
> time you do have to guess a _minimum_ set of actions/rules that
> reproduce the state of windows.  Otherwise, you end up like the
> designers of ECB who record _all_ actions applied by the user and
> "replay" them to produce the desired state.

I remember that differently.  With ECB you can really choose from layouts
visually and even create new ones with a sort of interactive layout editor.
It is true that it stored the layouts as procedural sequences internally,
but that is just an implementation detail.

Aside from that it is really trivial to specify any reasonably complex
layouts as simple lisp structure, with sizes in percent, similar to say
framesets in html:

(Continue reading)

headers

martin rudalics | 13 May 2010 15:53

Re: Window configurations

 > I remember that differently.  With ECB you can really choose from layouts
 > visually and even create new ones with a sort of interactive layout editor.
 > It is true that it stored the layouts as procedural sequences internally,
 > but that is just an implementation detail.

I was talking about practical issues, i.e., implementation.

 > Aside from that it is really trivial to specify any reasonably complex
 > layouts as simple lisp structure, with sizes in percent, similar to say
 > framesets in html:
 >
 > (setq my-layout '(

And we'd get this structure from `window-tree', I suppose?  Things like
that have been proposed and written a number of times already.

 > That simple thing would be a pretty detailed layout already suited for
 > almost all purposes (except GUD perhaps).  More precisely, a layout
 > _configuration_, which means that the elements (windows) are shown only
 > when needed.
 >
 > Now you'd have a function that processes the tree to remove the unshown
 > components, resizes the remaining components proportionally and then put
 > it on screen in one go using good old split-window and then shows the
 > buffers

That's what XEmacs does IIUC ...

 > on top of each window's buffer stack.

(Continue reading)

headers

grischka | 13 May 2010 19:13

Re: Window configurations

martin rudalics wrote:
>  > (setq my-layout '(
> 
> And we'd get this structure from `window-tree', I suppose?  

But no!  You let the user define it.  And/or write one as default.
(And learn to love your users and to hate heuristics!)

> That's what ECB's layouts are supposed to accomplish.  But I still don't
> know how we want to use a window's buffer stack.  It's probably trivial
> when the only operation popping the stack also kills that buffer.
> However, if the buffer remains alive where put it on the stack?  The
> only reasonable answer is burying it.  But usually that buffer is the
> one a user most likely wants to see first when unshowing another buffer
> in that window.

A buffer-stack per window stands for some such as "virtually overlapped
windows", with a notion of "behind" if you want to.  Of course it is
possible to swap the two topmost position, if such semantics exist or
are desirable.

Probably it will help you with decisions if you can get the per window
tab-bar feature working, first.

--- grischka

> 
> martin
>

(Continue reading)

headers

Juri Linkov | 14 May 2010 00:57

Re: Window configurations

> Probably it will help you with decisions if you can get the per window
> tab-bar feature working, first.

There are different problems with per-window tab-bars.
They can be implemented using the header-line (like
tabbar.el already does).  But the main problem is that
currently only one header-line is allowed per window.

--

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

headers

martin rudalics | 14 May 2010 08:58

Re: Window configurations

 >> And we'd get this structure from `window-tree', I suppose?
 >
 > But no!  You let the user define it.  And/or write one as default.
 > (And learn to love your users and to hate heuristics!)

Then you are missing one point: We need a structure that can be defined
(a) via some layout specification package as the one provided by ECB,
and (b) from user interactions in order to fit it into the desktop.el
framework.  In the latter case the user won't care about any such
structures, she simply wants her windows back.

 > A buffer-stack per window stands for some such as "virtually overlapped
 > windows", with a notion of "behind" if you want to.  Of course it is
 > possible to swap the two topmost position, if such semantics exist or
 > are desirable.

The question is what the _standard_ semantics are when a window ceases to
be topmost and we have to move it somewhere else on the stack.

martin

headers

grischka | 14 May 2010 12:42

Re: Window configurations

martin rudalics wrote:
 >  >> And we'd get this structure from `window-tree', I suppose?
 >  >
 >  > But no!  You let the user define it.  And/or write one as default.
 >  > (And learn to love your users and to hate heuristics!)
 >
 > Then you are missing one point: We need a structure that can be defined
 > (a) via some layout specification package as the one provided by ECB,
 > and (b) from user interactions in order to fit it into the desktop.el
 > framework.  In the latter case the user won't care about any such
 > structures, she simply wants her windows back.

If is no necessary to save windows. You'd just use the same configuration
to show the same buffers, i.e. throw them at "display-buffer" which calls
into your window manager which will create windows in the same place as before
by definition, because to do this is the whole point of it:   To make sure
that same (class of) content is presented to the user in the same trusty
topological position always.

Anyway, it is true that you'll probably want some nifty code to let the
user interactively resize the layout configuration (e.g. by dragging borders
with the mouse).  It should be doable though.

 >  > A buffer-stack per window stands for some such as "virtually overlapped
 >  > windows", with a notion of "behind" if you want to.  Of course it is
 >  > possible to swap the two topmost position, if such semantics exist or
 >  > are desirable.
 >
 > The question is what the _standard_ semantics are when a window ceases to
 > be topmost and we have to move it somewhere else on the stack.

(Continue reading)

headers

martin rudalics | 14 May 2010 13:45

Re: Window configurations

 > If is no necessary to save windows. You'd just use the same configuration
 > to show the same buffers, i.e. throw them at "display-buffer" which calls
 > into your window manager which will create windows in the same place as
 > before
 > by definition, because to do this is the whole point of it:   To make sure
 > that same (class of) content is presented to the user in the same trusty
 > topological position always.

`display-buffer' is completely untrustworthy in this regard.  The
trustworthy primitives to do what you mean are `split-window' and
`set-window-buffer'.

 >  > The question is what the _standard_ semantics are when a window
 > ceases to
 >  > be topmost and we have to move it somewhere else on the stack.
 >
 > The standard semantics for "ceasing to be topmost" on a stack are
 > "pushed down"
 > and "popped off".

Precisely that's why a stack is probably not sufficient for our purpose.

martin

headers

grischka | 14 May 2010 15:32

Re: Window configurations

martin rudalics wrote:
>  > If is no necessary to save windows. You'd just use the same configuration
>  > to show the same buffers, i.e. throw them at "display-buffer" which calls
>  > into your window manager which will create windows in the same place as before
>  > by definition, because to do this is the whole point of it:   To make sure
>  > that same (class of) content is presented to the user in the same trusty
>  > topological position always.
> 
> `display-buffer' is completely untrustworthy in this regard.  The
> trustworthy primitives to do what you mean are `split-window' and
> `set-window-buffer'.

No.  Sometimes I write what I mean and obviously the "display-buffer"
function that calls into an emacs window manager has to be different
from the one that we already know.

--- grischka

headers

Juri Linkov | 14 May 2010 00:54

Re: Window configurations

> Aside from that it is really trivial to specify any reasonably complex
> layouts as simple lisp structure, with sizes in percent, similar to say
> framesets in html:
>
> (setq my-layout '(
>      (div-v
>       (30 div-h
>           (75 top-window-1)
>           (25 top-window-2)
>           )
>       (55 div-h
>           (25 div-v
>               (50 sidebar-1)
>               (25 sidebar-2)
>               (25 sidebar-3)
>               )
>           (75 edit-area)
>           )
>       (15 tool-window)
>       )))

HTML framesets use the `rows' and `cols' attributes to split the screen
vertically and horizontally into frames (Emacs windows).

The above window configuration could be defined by HTML framesets as:

<FRAMESET rows="30%, 55%, 15%">
  <FRAMESET cols="75%, 25%">
    <FRAME src="top-window-1">
    <FRAME src="top-window-2">

(Continue reading)

headers

grischka | 14 May 2010 13:12

Re: Window configurations

Juri Linkov wrote:
>> Aside from that it is really trivial to specify any reasonably complex
>> layouts as simple lisp structure, with sizes in percent, similar to say
>> framesets in html:
>>
>> (setq my-layout '(
>>      (div-v
>>       (30 div-h
>>           (75 top-window-1)
>>           (25 top-window-2)
>>           )
>>       (55 div-h
>>           (25 div-v
>>               (50 sidebar-1)
>>               (25 sidebar-2)
>>               (25 sidebar-3)
>>               )
>>           (75 edit-area)
>>           )
>>       (15 tool-window)
>>       )))
> 
> HTML framesets use the `rows' and `cols' attributes to split the screen
> vertically and horizontally into frames (Emacs windows).
> 
> The above window configuration could be defined by HTML framesets as:
> 
> <FRAMESET rows="30%, 55%, 15%">
>   <FRAMESET cols="75%, 25%">
>     <FRAME src="top-window-1">

(Continue reading)

headers

martin rudalics | 14 May 2010 13:45

Re: Window configurations

 > One aspect of the layout configuration is that windows have names, that
 > could evolve to a sort of convention.  Say, any configuration has to
 > provide some standard names, then packages/features could choose to
 > show their stuff in e.g. "edit-area", "sidebar", "tools-window", "top-pane"
 > (instead of just in "this" or "other" as currently).

That's what `display-buffer-function' is for.  If a buffer is in some
way special wrt a specific package, that package has to take care of
displaying it in an appropriate way.

martin

headers

Juri Linkov | 17 May 2010 00:49

Re: Window configurations

> <FRAMESET rows="30%, 55%, 15%">
>   <FRAMESET cols="75%, 25%">
>     <FRAME src="top-window-1">
>     <FRAME src="top-window-2">
>   </FRAMESET>
>   <FRAMESET cols="25%, 75%">
>     <FRAMESET rows="50%, 25%, 25%">
>       <FRAME src="sidebar-1">
>       <FRAME src="sidebar-2">
>       <FRAME src="sidebar-3">
>     </FRAMESET>
>     <FRAME src="edit-area">
>   </FRAMESET>
>   <FRAME src="tool-window">
> </FRAMESET>

We could use something like this to define window configurations because
FRAME is like Emacs window, and FRAMESET is like internal window, e.g.

(window-set (rows 30 55 15)
  (window-set (cols 75 25)
    (window (buffer . "top-window-1"))
    (window (buffer . "top-window-2")))
  (window-set (cols 25 75)
    (window-set (rows 50 25 25)
      (window (buffer . "sidebar-1"))
      (window (buffer . "sidebar-2"))
      (window (buffer . "sidebar-3")))
    (window (buffer . "edit-area")))
  (window (buffer . "tool-window")))

(Continue reading)

headers

martin rudalics | 17 May 2010 11:06

Re: Window configurations

 > We could use something like this to define window configurations because
 > FRAME is like Emacs window, and FRAMESET is like internal window, e.g.
 >
 > (window-set (rows 30 55 15)
 >   (window-set (cols 75 25)
 >     (window (buffer . "top-window-1"))
[...]
 > where window-set with rows splits vertically,
 > and window-set with cols splits horizontally.

I suppose we need something more accurate than integer precentages.

And we have to decide how to handle fixed-size windows - they want some
absolute size.

martin

headers

Juri Linkov | 18 May 2010 00:48

Re: Window configurations

>> We could use something like this to define window configurations because
>> FRAME is like Emacs window, and FRAMESET is like internal window, e.g.
>>
>> (window-set (rows 30 55 15)
>>   (window-set (cols 75 25)
>>     (window (buffer . "top-window-1"))
> [...]
>> where window-set with rows splits vertically,
>> and window-set with cols splits horizontally.
>
> I suppose we need something more accurate than integer precentages.
>
> And we have to decide how to handle fixed-size windows - they want some
> absolute size.

HTML frame configurations allow percentages, relative and absolute values,
e.g. rows="30%,400,*,2*".  We could support the same specification
http://www.w3.org/TR/REC-html40/present/frames.html with a list like
(rows 0.3 400 '* '(* 2))

--

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

headers

Juri Linkov | 14 May 2010 00:48

Re: Window configurations

> One complication is that window configurations would
> have to store the buffer stack and all buffer references.

Yes, window configurations have to store the buffer stack.
Like frame configurations store the buffer list,
there is no problem with that.

> What's more problematic, however, is that it's not clear whether each
> and every occurrence of `set-window-buffer' should add its buffer to
> the stack.  Currently, I put a buffer there only when `display-buffer'
> displays it.

`set-window-buffer' could add its buffer to the stack only when
it is different than a buffer on the top of the stack.  A problem
may occur when `set-window-buffer' is used to set a buffer
temporarily.  Perhaps `set-window-buffer' should have a new argument
(e.g. NO-RECORD) to not change the stack in this case.

--

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

headers

martin rudalics | 14 May 2010 09:00

Re: Window configurations

 >> One complication is that window configurations would
 >> have to store the buffer stack and all buffer references.
 >
 > Yes, window configurations have to store the buffer stack.
 > Like frame configurations store the buffer list,
 > there is no problem with that.

In a list structure we'd store buffer names and have to resolve the
known ambiguities.

 > `set-window-buffer' could add its buffer to the stack only when
 > it is different than a buffer on the top of the stack.

That's obvious.

 > A problem
 > may occur when `set-window-buffer' is used to set a buffer
 > temporarily.  Perhaps `set-window-buffer' should have a new argument
 > (e.g. NO-RECORD) to not change the stack in this case.

I suppose we need the extra argument also to specify whether the buffer
should go to the top or the bottom of the stack.  For example,
`quit-window' and `replace-buffer-in-windows' must be able to make sure
that the buffer goes to the bottom where it's the most unlikely
candidate to be shown again.  Otherwise, I might end up cycling through
a subset of the stacked buffers only when I continuously try to pop
items from it (via some `other-window-buffer' function, say).

On the other hand, when `display-buffer' reuses a window to show another
buffer in it, the old buffer should go to the top of the stack instead,

(Continue reading)

headers

martin rudalics | 29 Jun 2010 11:01

Re: Window configurations

 > 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

headers

Juri Linkov | 29 Jun 2010 11:23

Re: Window configurations

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

(Continue reading)

headers

martin rudalics | 29 Jun 2010 12:01

Re: Window configurations

 > 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

headers

Juanma Barranquero | 29 Jun 2010 12:37

Re: Window configurations

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

headers

martin rudalics | 29 Jun 2010 14:16

Re: Window configurations

 > 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

(Continue reading)

headers

Juanma Barranquero | 29 Jun 2010 22:14

Re: Window configurations

On Tue, Jun 29, 2010 at 14:16, martin rudalics <rudalics <at> 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

headers

Juri Linkov | 29 Jun 2010 22:01

Re: Window configurations

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

headers

martin rudalics | 30 Jun 2010 08:35

Re: Window configurations

 > 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

headers

Juri Linkov | 30 Jun 2010 10:12

Re: Window configurations

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

headers

Stefan Monnier | 10 Apr 2010 21:19

Re: Gtk tabs in emacs, new branch

> 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

headers

Uwe Siart | 2 Apr 2010 18:19

Re: Gtk tabs in emacs, new branch

Angelo Graziosi <angelo.graziosi <at> 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

headers

Daniel Colascione | 2 Apr 2010 20:31

Re: Gtk tabs in emacs, new branch

On 4/2/10 12:19 PM, Uwe Siart wrote:
> Angelo Graziosi <angelo.graziosi <at> 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.

headers

Stefan Monnier | 2 Apr 2010 22:38

Re: Gtk tabs in emacs, new branch

> 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

headers

Uwe Siart | 3 Apr 2010 08:29

Re: Gtk tabs in emacs, new branch

Daniel Colascione <daniel <at> 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

headers

Uwe Siart | 3 Apr 2010 11:07

Re: Gtk tabs in emacs, new branch

Uwe Siart <usenet <at> 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

headers

Uwe Siart | 2 Apr 2010 08:53

Re: Gtk tabs in emacs, new branch

Angelo Graziosi <angelo.graziosi <at> 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

headers

Jan Djärv | 2 Apr 2010 09:25

Re: Gtk tabs in emacs, new branch

Uwe Siart skrev:
> Angelo Graziosi <angelo.graziosi <at> 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.

headers

Juri Linkov | 4 Apr 2010 13:01

Re: Gtk tabs in emacs, new branch

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

headers

Stephen J. Turnbull | 2 Apr 2010 14:19

Re: Gtk tabs in emacs, new branch

Uwe Siart writes:
 > Angelo Graziosi <angelo.graziosi <at> 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

(Continue reading)

headers

Juri Linkov | 1 Apr 2010 20:02

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 1 Apr 2010 22:13

Re: Gtk tabs in emacs, new branch.


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

(Continue reading)

headers

Juri Linkov | 10 Apr 2010 01:27

Re: Gtk tabs in emacs, new branch.

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


--

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

headers

Drew Adams | 10 Apr 2010 01:54

RE: Gtk tabs in emacs, new branch.

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

headers

Juri Linkov | 10 Apr 2010 02:17

Re: Gtk tabs in emacs, new branch.

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

headers

YAMAMOTO Mitsuharu | 10 Apr 2010 04:56

Re: Gtk tabs in emacs, new branch.

>>>>> On Sat, 10 Apr 2010 02:27:45 +0300, Juri Linkov <juri <at> 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 <at> 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))

(Continue reading)

headers

Juri Linkov | 11 Apr 2010 03:06

Re: Gtk tabs in emacs, new branch.

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

headers

Chong Yidong | 1 Apr 2010 20:50

Re: Gtk tabs in emacs, new branch.

Jan Djärv <jan.h.d <at> 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.

headers

Jan Djärv | 1 Apr 2010 22:09

Re: Gtk tabs in emacs, new branch.


Chong Yidong skrev 2010-04-01 20.50:
> Jan Djärv<jan.h.d <at> 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.

headers

Jan Djärv | 1 Apr 2010 22:08

Re: Gtk tabs in emacs, new branch.


Chong Yidong skrev 2010-04-01 20.50:
> Jan Djärv<jan.h.d <at> 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.

headers

Stefan Monnier | 1 Apr 2010 23:53

Re: Gtk tabs in emacs, new branch.

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

headers

alin.s | 9 Apr 2010 09:23

Re: Gtk tabs in emacs, new branch.


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

(Continue reading)

headers

Jan D. | 9 Apr 2010 11:34

Re: Gtk tabs in emacs, new branch.

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.

headers

A. Soare | 9 Apr 2010 11:47

Re: Gtk tabs in emacs, new branch.


> 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

headers

Jan D. | 9 Apr 2010 13:15

Re: Gtk tabs in emacs, new branch.

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.

headers

Stefan Monnier | 10 Apr 2010 03:22

Re: Gtk tabs in emacs, new branch.

> 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

headers

Lennart Borgman | 10 Apr 2010 03:47

Re: Gtk tabs in emacs, new branch.

On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
<monnier <at> 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?

headers

Juri Linkov | 10 Apr 2010 04:19

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 10 Apr 2010 08:15

Re: Gtk tabs in emacs, new branch.


Lennart Borgman skrev 2010-04-10 03.47:
> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
> <monnier <at> 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.

headers

Lennart Borgman | 10 Apr 2010 11:14

Re: Gtk tabs in emacs, new branch.

On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>
> Lennart Borgman skrev 2010-04-10 03.47:
>>
>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>> <monnier <at> 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?

headers

joakim | 10 Apr 2010 11:46

Re: Gtk tabs in emacs, new branch.

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>>
>>
>> Lennart Borgman skrev 2010-04-10 03.47:
>>>
>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>> <monnier <at> 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

(Continue reading)

headers

Lennart Borgman | 10 Apr 2010 12:18

Re: Gtk tabs in emacs, new branch.

2010/4/10  <joakim <at> verona.se>:
> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>
>> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>>>
>>>
>>> Lennart Borgman skrev 2010-04-10 03.47:
>>>>
>>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>>> <monnier <at> 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?

(Continue reading)

headers

joakim | 10 Apr 2010 13:01

Re: Gtk tabs in emacs, new branch.

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> 2010/4/10  <joakim <at> verona.se>:
>> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>>
>>> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>>>>
>>>>
>>>> Lennart Borgman skrev 2010-04-10 03.47:
>>>>>
>>>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>>>> <monnier <at> 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

(Continue reading)

headers

Štěpán Němec | 10 Apr 2010 14:38

Re: Gtk tabs in emacs, new branch.

Lennart Borgman <lennart.borgman <at> 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

headers

Stefan Monnier | 10 Apr 2010 16:58

Re: Gtk tabs in emacs, new branch.

> 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

headers

Jan Djärv | 10 Apr 2010 12:58

Re: Gtk tabs in emacs, new branch.


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

headers

joakim | 10 Apr 2010 14:09

Re: Gtk tabs in emacs, new branch.

Jan Djärv <jan.h.d <at> swipnet.se> writes:

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

headers

Juri Linkov | 11 Apr 2010 03:18

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Jan Djärv | 10 Apr 2010 12:52

Re: Gtk tabs in emacs, new branch.


Lennart Borgman skrev 2010-04-10 11.14:
> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv<jan.h.d <at> swipnet.se>  wrote:
>>
>>
>> Lennart Borgman skrev 2010-04-10 03.47:
>>>
>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>> <monnier <at> 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

(Continue reading)

headers

Juri Linkov | 10 Apr 2010 03:36

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 10 Apr 2010 08:12

Re: Gtk tabs in emacs, new branch.


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.

(Continue reading)

headers

Juri Linkov | 11 Apr 2010 03:16

Re: Gtk tabs in emacs, new branch.

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

headers

Tobias C. Rittweiler | 11 Apr 2010 14:50

Re: Gtk tabs in emacs, new branch.

Juri Linkov <juri <at> 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.

(Continue reading)

headers

David De La Harpe Golden | 11 Apr 2010 17:40

Re: Gtk tabs in emacs, new branch.

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

headers

David De La Harpe Golden | 11 Apr 2010 17:28

Re: Gtk tabs in emacs, new branch.

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.

(Continue reading)

headers

Stefan Monnier | 11 Apr 2010 18:05

Re: Gtk tabs in emacs, new branch.

> 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

headers

Jan Djärv | 11 Apr 2010 20:32

Re: Gtk tabs in emacs, new branch.

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.

headers

Juri Linkov | 13 Apr 2010 01:47

Re: Gtk tabs in emacs, new branch.

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

headers

Stefan Monnier | 13 Apr 2010 05:50

Re: Gtk tabs in emacs, new branch.

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

headers

Juri Linkov | 13 Apr 2010 07:29

Re: Gtk tabs in emacs, new branch.

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


--

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

headers

Stefan Monnier | 13 Apr 2010 15:05

Re: Gtk tabs in emacs, new branch.

> 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

headers

Juri Linkov | 14 Apr 2010 01:34

Header windows (was: Gtk tabs in emacs, new branch.)

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

We already have a mechanism suitable for creating per-window tool bars
and tab bars.  And the package tabbar.el that switches buffers proves
that the header line serves the purpose of the tab bar pretty well.

The header line can display a per-window tool-bar or tab-bar when
`header-line-format' is set to a propertized string that contains icons
with the `display' and `keymap' properties.

The only problem with the header line is the limitation of only one
instance per window.  Since the task of allowing multiple header-lines
is necessary to do anyway, it would be better to start with it.
But it seems this limitation is hard-coded and not easy to get rid of.

Maybe, a better option is to create header windows (i.e. a 1-line window
without the mode-line)?

--

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

headers

Richard Stallman | 14 Apr 2010 07:03

Re: Gtk tabs in emacs, new branch.

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

headers

Stefan Monnier | 14 Apr 2010 16:30

Re: Gtk tabs in emacs, new branch.

>     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

headers

Stephen J. Turnbull | 13 Apr 2010 08:53

Re: Gtk tabs in emacs, new branch.

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!

headers

Stefan Monnier | 13 Apr 2010 14:28

Re: Gtk tabs in emacs, new branch.

> Obviously, just the favicon wouldn't be very useful!

My point exactly,

        Stefan

headers

Jan Djärv | 13 Apr 2010 07:53

Re: Gtk tabs in emacs, new branch.


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.

headers

Stefan Monnier | 13 Apr 2010 14:30

Re: Gtk tabs in emacs, new branch.

> 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

headers

Jan Djärv | 13 Apr 2010 22:54

Re: Gtk tabs in emacs, new branch.


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.

headers

Jan Djärv | 21 Apr 2010 18:58

Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

Stefan Monnier skrev:
>> 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,
> 

Actually there is no lucid toolbar, it is just native code and redisplay.  You 
get it even without using lucid.  Actually, a lucid tool bar replacement would 
be a good thing, but then lucid would be a requirement.

Anyway, I checked in the possibilty to have text in the tool bar.  Just for 
Gtk+ for now, I'm working on the native one.

See variable tool-bar-style for styles.  The default is taken from Xsettings 
(i.e. Gnome setting).

The code tries to generate a text for tool bar items based on key and caption. 
  This sometimes fails, so the property :label can be set on tool bar items. 
I've done this for a few items I saw at once, I'm sure plenty remain.

	Jan D.

headers

Juri Linkov | 23 Apr 2010 10:35

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

> Anyway, I checked in the possibilty to have text in the tool bar.  Just for
> Gtk+ for now, I'm working on the native one.
>
> See variable tool-bar-style for styles.  The default is taken from
> Xsettings (i.e. Gnome setting).
>
> The code tries to generate a text for tool bar items based on key and
> caption. This sometimes fails, so the property :label can be set on tool
> bar items. I've done this for a few items I saw at once, I'm sure
> plenty remain.

Do you have an idea how to implement the style `both'
(with text under image) on a non-toolkit build?

The remaining options `text' and `both-horiz' would be easy to do.
Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
to the right of the tab label.

--

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

headers

Jan D. | 23 Apr 2010 11:33

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

Juri Linkov wrote:
>> Anyway, I checked in the possibilty to have text in the tool bar.  Just for
>> Gtk+ for now, I'm working on the native one.
>>
>> See variable tool-bar-style for styles.  The default is taken from
>> Xsettings (i.e. Gnome setting).
>>
>> The code tries to generate a text for tool bar items based on key and
>> caption. This sometimes fails, so the property :label can be set on tool
>> bar items. I've done this for a few items I saw at once, I'm sure
>> plenty remain.
> 
> Do you have an idea how to implement the style `both'
> (with text under image) on a non-toolkit build?

Do you mean on the glyph (a.ka. redisplay) level or by the actual 
drawing done by for example X?  I don't think this can be done simply at 
the lisp level.  The overflow for the tool bar, and highlightning needs 
to handle text and image as one.  How do you deal with that in your 
tabs?  The tool bar display code is kind of hardwired in C anyway.

> 
> The remaining options `text' and `both-horiz' would be easy to do.
> Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
> to the right of the tab label.

That is the RtoL version, both-horiz for Gtk+ has the icon to the left 
of the text, i.e. opposite of what a tab bar has.

	Jan D.

(Continue reading)

headers

Juri Linkov | 23 Apr 2010 18:46

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

>> Do you have an idea how to implement the style `both'
>> (with text under image) on a non-toolkit build?
>
> Do you mean on the glyph (a.ka. redisplay) level or by the actual drawing
> done by for example X?  I don't think this can be done simply at the lisp
> level.  The overflow for the tool bar, and highlightning needs to handle
> text and image as one.  How do you deal with that in your tabs?

Currently text and image are separate.  I'll try to use your new property
:label for the tab name.

>> The remaining options `text' and `both-horiz' would be easy to do.
>> Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
>> to the right of the tab label.
>
> That is the RtoL version, both-horiz for Gtk+ has the icon to the left of
> the text, i.e. opposite of what a tab bar has.

Maybe then add a new style `text-image-horiz' (for icon to the right of
the label) to keep the tool-bar implementation closer to the tab-bar
implementation.  This style is not necessary to add to defcustom.

--

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

headers

Jan Djärv | 23 Apr 2010 19:47

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

Juri Linkov skrev:

>>> The remaining options `text' and `both-horiz' would be easy to do.
>>> Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
>>> to the right of the tab label.
>> That is the RtoL version, both-horiz for Gtk+ has the icon to the left of
>> the text, i.e. opposite of what a tab bar has.
> 
> Maybe then add a new style `text-image-horiz' (for icon to the right of
> the label) to keep the tool-bar implementation closer to the tab-bar
> implementation.  This style is not necessary to add to defcustom.
> 

The problem is that the Gtk+ tool bar can't do text-image-horiz, not even for 
a RtoL locale.

	Jan D.

headers

Drew Adams | 11 Apr 2010 20:09

RE: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Juri Linkov | 13 Apr 2010 01:45

Re: Gtk tabs in emacs, new branch.

> 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

(Continue reading)

headers

Stephen J. Turnbull | 13 Apr 2010 04:42

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Jan Djärv | 13 Apr 2010 08:29

Re: Gtk tabs in emacs, new branch.

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.

headers

Eli Zaretskii | 13 Apr 2010 19:59

Re: Gtk tabs in emacs, new branch.

> From: "Stephen J. Turnbull" <stephen <at> xemacs.org>
> Date: Tue, 13 Apr 2010 11:42:00 +0900
> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d <at> swipnet.se>, "Emacs Dev
> 	\[emacs-devel\]" <emacs-devel <at> gnu.org>,
> 	David De La Harpe Golden <david <at> 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.

headers

Jan Djärv | 13 Apr 2010 20:15

Re: Gtk tabs in emacs, new branch.

Eli Zaretskii skrev:
>> From: "Stephen J. Turnbull" <stephen <at> xemacs.org>
>> Date: Tue, 13 Apr 2010 11:42:00 +0900
>> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d <at> swipnet.se>, "Emacs Dev
>> 	\[emacs-devel\]" <emacs-devel <at> gnu.org>,
>> 	David De La Harpe Golden <david <at> 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.

headers

Eli Zaretskii | 13 Apr 2010 20:44

Re: Gtk tabs in emacs, new branch.

> Date: Tue, 13 Apr 2010 20:15:07 +0200
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: "Stephen J. Turnbull" <stephen <at> xemacs.org>, juri <at> jurta.org, 
>  emacs-devel <at> gnu.org, david <at> 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.

headers

Jan Djärv | 10 Apr 2010 07:51

Re: Gtk tabs in emacs, new branch.


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.

(Continue reading)

headers

Stefan Monnier | 10 Apr 2010 17:19

Re: Gtk tabs in emacs, new branch.

> 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

(Continue reading)

headers

Chong Yidong | 10 Apr 2010 17:33

Re: Gtk tabs in emacs, new branch.

Stefan Monnier <monnier <at> 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.

headers

Stefan Monnier | 10 Apr 2010 20:51

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 10 Apr 2010 18:10

Re: Gtk tabs in emacs, new branch.

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.

(Continue reading)

headers

David De La Harpe Golden | 10 Apr 2010 18:40

Re: Gtk tabs in emacs, new branch.

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?

(Continue reading)

headers

Jan Djärv | 10 Apr 2010 19:06

Re: Gtk tabs in emacs, new branch.


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.

(Continue reading)

headers

Davis Herring | 10 Apr 2010 18:42

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 10 Apr 2010 19:11

Re: Gtk tabs in emacs, new branch.


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.

headers

Davis Herring | 10 Apr 2010 19:16

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 10 Apr 2010 19:54

Re: Gtk tabs in emacs, new branch.

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.

headers

David De La Harpe Golden | 10 Apr 2010 20:44

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Jan Djärv | 10 Apr 2010 21:14

Re: Gtk tabs in emacs, new branch.

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.

(Continue reading)

headers

David De La Harpe Golden | 10 Apr 2010 21:51

Re: Gtk tabs in emacs, new branch.

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

headers

Stefan Monnier | 10 Apr 2010 23:12

Re: Gtk tabs in emacs, new branch.

> 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

headers

Jan Djärv | 11 Apr 2010 12:56

Re: Gtk tabs in emacs, new branch.

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.

headers

Stefan Monnier | 11 Apr 2010 17:09

Re: Gtk tabs in emacs, new branch.

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

headers

Stefan Monnier | 10 Apr 2010 21:00

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Jan Djärv | 10 Apr 2010 21:07

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

David De La Harpe Golden | 10 Apr 2010 21:56

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Jan Djärv | 12 Apr 2010 18:14

Re: Gtk tabs in emacs, new branch.


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.

headers

Stefan Monnier | 12 Apr 2010 21:18

Re: Gtk tabs in emacs, new branch.

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

headers

Jan Djärv | 12 Apr 2010 22:22

Re: Gtk tabs in emacs, new branch.


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.

headers

Stefan Monnier | 12 Apr 2010 23:02

Re: Gtk tabs in emacs, new branch.

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

headers

René Kyllingstad | 13 Apr 2010 17:08

Re: Gtk tabs in emacs, new branch.

On Sat, Apr 10, 2010 at 5:19 PM, Stefan Monnier
<monnier <at> 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.

(Continue reading)

headers

David De La Harpe Golden | 10 Apr 2010 18:06

Re: Gtk tabs in emacs, new branch.

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:

  ________________________        ________________________
|              |         |      |                        |
|              |         |      |______   _______________|
|______________|         |      |__/__/__/__/____________|
|              |         |      |      |        |        |
|___   ________|         |      |   ___|________|________|
|__/__/__/_____|_________|      |__/__/__________________|

(Continue reading)

headers

Stephen J. Turnbull | 11 Apr 2010 14:11

Re: Gtk tabs in emacs, new branch.

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.

(Continue reading)

headers

Drew Adams | 11 Apr 2010 20:09

RE: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Juri Linkov | 13 Apr 2010 01:49

Re: Gtk tabs in emacs, new branch.

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

headers

Drew Adams | 13 Apr 2010 04:58

RE: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Stephen J. Turnbull | 13 Apr 2010 06:11

RE: Gtk tabs in emacs, new branch.

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?

(Continue reading)

headers

Drew Adams | 13 Apr 2010 18:15

RE: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

Stephen J. Turnbull | 14 Apr 2010 12:30

RE: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

A. Soare | 9 Apr 2010 15:33

Re: Gtk tabs in emacs, new branch.


> 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

(Continue reading)

headers

A. Soare | 10 Apr 2010 19:33

Re: Gtk tabs in emacs, new branch.

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

(Continue reading)

headers

grischka | 13 Apr 2010 21:53

RE: Gtk tabs in emacs, new branch.

 > 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

headers

Juri Linkov | 14 Apr 2010 01:31

Side windows (was: Gtk tabs in emacs, new branch.)

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

There is a task in etc/TODO:

  ** Compilation error navigation bar, parallel to the scroll bar,
  indicating where in the buffer there are compilation errors.
  Perhaps we could arrange to display these error indications on top
  of the scroll bar itself.  That depends on to what extent toolkit
  scroll bars are extensible.

If it's possible to display such tab-like indications
on the scroll bar, is it still called a scroll bar?

If it's not possible, then what is an alternative?
Maybe, 1-column side bar windows?

--

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

headers

Eli Zaretskii | 14 Apr 2010 05:18

Re: Side windows (was: Gtk tabs in emacs, new branch.)

> From: Juri Linkov <juri <at> jurta.org>
> Date: Wed, 14 Apr 2010 02:31:30 +0300
> Cc: drew.adams <at> oracle.com, emacs-devel <at> gnu.org
> 
> There is a task in etc/TODO:
> 
>   ** Compilation error navigation bar, parallel to the scroll bar,
>   indicating where in the buffer there are compilation errors.
>   Perhaps we could arrange to display these error indications on top
>   of the scroll bar itself.  That depends on to what extent toolkit
>   scroll bars are extensible.
> 
> If it's possible to display such tab-like indications
> on the scroll bar, is it still called a scroll bar?
> 
> If it's not possible, then what is an alternative?
> Maybe, 1-column side bar windows?

The fringe, I think.

headers

Jason Rumney | 14 Apr 2010 17:24

Re: Side windows

Eli Zaretskii <eliz <at> gnu.org> writes:

>>   ** Compilation error navigation bar, parallel to the scroll bar,
>>   indicating where in the buffer there are compilation errors.
>>   Perhaps we could arrange to display these error indications on top
>>   of the scroll bar itself.  That depends on to what extent toolkit
>>   scroll bars are extensible.
>> 
>> If it's possible to display such tab-like indications
>> on the scroll bar, is it still called a scroll bar?
>> 
>> If it's not possible, then what is an alternative?
>> Maybe, 1-column side bar windows?
>
> The fringe, I think.

The fringe nearest the scroll-bar is the right place to display the
indicators I think, but we need a new mechanism to display them, as they
should not scroll with the buffer text.

headers

Juri Linkov | 14 Apr 2010 18:52

Re: Side windows

>>>   ** Compilation error navigation bar, parallel to the scroll bar,
>>>   indicating where in the buffer there are compilation errors.
>>>   Perhaps we could arrange to display these error indications on top
>>>   of the scroll bar itself.  That depends on to what extent toolkit
>>>   scroll bars are extensible.
>>>
>>> If it's possible to display such tab-like indications
>>> on the scroll bar, is it still called a scroll bar?
>>>
>>> If it's not possible, then what is an alternative?
>>> Maybe, 1-column side bar windows?
>>
>> The fringe, I think.
>
> The fringe nearest the scroll-bar is the right place to display the
> indicators I think, but we need a new mechanism to display them, as they
> should not scroll with the buffer text.

Does this mean an additional fringe is necessary that doesn't scroll?

Then we have the same question as with multiple header lines:
whether to allow multiple fringes and header lines or implement them
as true windows placed on the left or on the top of the base window.

Using windows will allow implementing emulations of the scroll bar
like minimap.el, etc.  I'm not sure whether this is possible to do
with additional fringes?

--

-- 
Juri Linkov

(Continue reading)

headers

Eli Zaretskii | 14 Apr 2010 20:19

Re: Side windows

> From: Juri Linkov <juri <at> jurta.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  grishka <at> gmx.de,  drew.adams <at> oracle.com,  emacs-devel <at> gnu.org
> Date: Wed, 14 Apr 2010 19:52:01 +0300
> 
> >>>   ** Compilation error navigation bar, parallel to the scroll bar,
> >>>   indicating where in the buffer there are compilation errors.
> >>>   Perhaps we could arrange to display these error indications on top
> >>>   of the scroll bar itself.  That depends on to what extent toolkit
> >>>   scroll bars are extensible.
> >>>
> >>> If it's possible to display such tab-like indications
> >>> on the scroll bar, is it still called a scroll bar?
> >>>
> >>> If it's not possible, then what is an alternative?
> >>> Maybe, 1-column side bar windows?
> >>
> >> The fringe, I think.
> >
> > The fringe nearest the scroll-bar is the right place to display the
> > indicators I think, but we need a new mechanism to display them, as they
> > should not scroll with the buffer text.
> 
> Does this mean an additional fringe is necessary that doesn't scroll?

Not necessarily.  We could provide a feature whereby bitmaps displayed
in the fringe would be moved by redisplay so that their position
relative to the window top does not change as the window is scrolled.

headers

Juri Linkov | 15 Apr 2010 01:54

Re: Side windows

>> >>> Maybe, 1-column side bar windows?
>> >>
>> >> The fringe, I think.
>> >
>> > The fringe nearest the scroll-bar is the right place to display the
>> > indicators I think, but we need a new mechanism to display them, as
>> > they should not scroll with the buffer text.
>>
>> Does this mean an additional fringe is necessary that doesn't scroll?
>
> Not necessarily.  We could provide a feature whereby bitmaps displayed
> in the fringe would be moved by redisplay so that their position
> relative to the window top does not change as the window is scrolled.

Currently fringe positions are relative to lines (to indicate truncated
lines, continued lines, overlay arrows, etc.)

Using it to indicate window relative positions like scroll bars do
will make a mess in the same fringe.

--

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

headers

Eli Zaretskii | 15 Apr 2010 05:18

Re: Side windows

> From: Juri Linkov <juri <at> jurta.org>
> Cc: jasonr <at> gnu.org,  grishka <at> gmx.de,  drew.adams <at> oracle.com,  emacs-devel <at> gnu.org
> Date: Thu, 15 Apr 2010 02:54:21 +0300
> 
> Currently fringe positions are relative to lines (to indicate truncated
> lines, continued lines, overlay arrows, etc.)
> 
> Using it to indicate window relative positions like scroll bars do
> will make a mess in the same fringe.

The proposed bitmap is very small (thin), AFAIU, so I'm not sure the
mess would be quite as big as you seem to fear.  Overlay arrows are on
the left fringe, so they do not contribute to the mess at all.  We
could enlarge the right fringe (in compilation-mode) to make the mess
even smaller.

An alternative could be to use the margin for this.  Its advantage is
that it will also work on a TTY.  But I think this would be a larger
job because currently margins are not clickable, while the fringe is.

headers

Juri Linkov | 16 Apr 2010 01:46

Re: Side windows

> The proposed bitmap is very small (thin), AFAIU, so I'm not sure the
> mess would be quite as big as you seem to fear.  Overlay arrows are on
> the left fringe, so they do not contribute to the mess at all.  We
> could enlarge the right fringe (in compilation-mode) to make the mess
> even smaller.

This practically means multi-column fringes.  Maybe the same suggests
implementing the multi-line header line instead of multiple header lines
or multiple header windows.

--

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

headers

Eli Zaretskii | 16 Apr 2010 08:33

Re: Side windows

> From: Juri Linkov <juri <at> jurta.org>
> Cc: jasonr <at> gnu.org,  grishka <at> gmx.de,  drew.adams <at> oracle.com,  emacs-devel <at> gnu.org
> Date: Fri, 16 Apr 2010 02:46:17 +0300
> 
> > The proposed bitmap is very small (thin), AFAIU, so I'm not sure the
> > mess would be quite as big as you seem to fear.  Overlay arrows are on
> > the left fringe, so they do not contribute to the mess at all.  We
> > could enlarge the right fringe (in compilation-mode) to make the mess
> > even smaller.
> 
> This practically means multi-column fringes.

No, it doesn't.  I wasn't suggesting to have more than one bitmap on
the fringe at the same place (I think this is impossible with today's
code).  I was just saying that the visual appearance would not be as
bad as it may sound.

> Maybe the same suggests implementing the multi-line header line
> instead of multiple header lines or multiple header windows.

I don't think so.  The current display engine does not support a
notion of glyph rows that are more than one glyph tall.  And since
each glyph comes from some font, you cannot have two of them together,
unless you either (a) craft a font with combination of 2 characters in
it, or (b) make some composition rules to compose them into a single
glyph.

headers

Jan Djärv | 14 Apr 2010 07:15

Re: Side windows


Juri Linkov skrev 2010-04-14 01.31:
>> 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.
>
> There is a task in etc/TODO:
>
>    ** Compilation error navigation bar, parallel to the scroll bar,
>    indicating where in the buffer there are compilation errors.
>    Perhaps we could arrange to display these error indications on top
>    of the scroll bar itself.  That depends on to what extent toolkit
>    scroll bars are extensible.
>
> If it's possible to display such tab-like indications
> on the scroll bar, is it still called a scroll bar?
>
> If it's not possible, then what is an alternative?
> Maybe, 1-column side bar windows?
>

As Eli already said, the fringe.  Scrollbars aren't the place for this.
How do you know when to remove these indications?

	Jan D.

headers

grischka | 16 Apr 2010 16:03

Re: Side windows

Juri Linkov wrote:
> There is a task in etc/TODO:
> 
>   ** Compilation error navigation bar, parallel to the scroll bar,
>   indicating where in the buffer there are compilation errors.
>   Perhaps we could arrange to display these error indications on top
>   of the scroll bar itself.  That depends on to what extent toolkit
>   scroll bars are extensible.
> 
> If it's possible to display such tab-like indications
> on the scroll bar, is it still called a scroll bar?
> 
> If it's not possible, then what is an alternative?
> Maybe, 1-column side bar windows?

WinMerge and KDiff3 have a "sort of" scrollbar with transparent thumb
used to indicate (and jump to) the regions with differences.

See picture.

headers

Juri Linkov | 16 Apr 2010 22:48

Re: Side windows

>>   ** Compilation error navigation bar, parallel to the scroll bar,
>>   indicating where in the buffer there are compilation errors.
>>   Perhaps we could arrange to display these error indications on top
>>   of the scroll bar itself.  That depends on to what extent toolkit
>>   scroll bars are extensible.
>>
>> If it's possible to display such tab-like indications
>> on the scroll bar, is it still called a scroll bar?
>>
>> If it's not possible, then what is an alternative?
>> Maybe, 1-column side bar windows?
>
> WinMerge and KDiff3 have a "sort of" scrollbar with transparent thumb
> used to indicate (and jump to) the regions with differences.
>
> See picture.

This is definitely impossible to do in fringes with today's code.
But using the same technique as is used by palette.el
http://www.emacswiki.org/emacs/ColorPalette to create pseudo-graphics
in a side window it should be doable.

--

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