* Re: Gtk tabs in emacs, new branch
@ 2010-04-01 16:52 Angelo Graziosi
2010-04-01 17:45 ` Jan Djärv
` (2 more replies)
0 siblings, 3 replies; 194+ messages in thread
From: Angelo Graziosi @ 2010-04-01 16:52 UTC (permalink / raw
To: Emacs
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.
^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 16:52 Gtk tabs in emacs, new branch Angelo Graziosi @ 2010-04-01 17:45 ` Jan Djärv 2010-04-01 18:03 ` Juri Linkov ` (2 more replies) 2010-04-02 6:53 ` Jan Djärv 2010-04-02 6:53 ` Uwe Siart 2 siblings, 3 replies; 194+ messages in thread From: Jan Djärv @ 2010-04-01 17:45 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 17:45 ` Jan Djärv @ 2010-04-01 18:03 ` Juri Linkov 2010-04-01 20:18 ` Jan Djärv 2010-04-01 20:51 ` Angelo Graziosi 2010-04-02 2:06 ` Stephen J. Turnbull 2 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-01 18:03 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs, Angelo Graziosi >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 18:03 ` Juri Linkov @ 2010-04-01 20:18 ` Jan Djärv 2010-04-02 7:10 ` Jan Djärv 0 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-01 20:18 UTC (permalink / raw To: Juri Linkov; +Cc: Angelo Graziosi, Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 20:18 ` Jan Djärv @ 2010-04-02 7:10 ` Jan Djärv 0 siblings, 0 replies; 194+ messages in thread From: Jan Djärv @ 2010-04-02 7:10 UTC (permalink / raw To: Juri Linkov; +Cc: Angelo Graziosi, Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 17:45 ` Jan Djärv 2010-04-01 18:03 ` Juri Linkov @ 2010-04-01 20:51 ` Angelo Graziosi 2010-04-02 6:49 ` Jan Djärv 2010-04-02 2:06 ` Stephen J. Turnbull 2 siblings, 1 reply; 194+ messages in thread From: Angelo Graziosi @ 2010-04-01 20:51 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 20:51 ` Angelo Graziosi @ 2010-04-02 6:49 ` Jan Djärv 2010-04-02 9:21 ` Angelo Graziosi 0 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-02 6:49 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs [-- Attachment #1: Type: text/plain, Size: 871 bytes --] Angelo Graziosi skrev: > Il 01/04/2010 19.45, Jan Djärv ha scritto: >> >> >> Angelo Graziosi skrev 2010-04-01 18.52: >>> Jan D. wrote: >>>> Hello. >>>> >>>> >>>> I've published a new branch... >>> >>> I have build that, but when I start Emacs, I don't 'see' any tabs. How >>> can we enable those? I have a desktop file which opens several file when >>> I start Emacs, so I would expect to see them in tabs! :-) >> >> I don't think that is a good idea in general. I have desktopfiles with >> over 50 files. 50 tabs isn't manageable. > > Obviously (20 files in my case). Beside a minimum number, the tabs > should be 'collapsed' with an 'arrow' pointing to the 'collapsing'. > I don't know exactly what you mean by collapsed, but Gtk+ adds arrows on the sides when the tabs are too many to fit. Not exactly pretty, but it works. Jan D. [-- Attachment #2: tabs2.png --] [-- Type: image/png, Size: 26309 bytes --] ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 6:49 ` Jan Djärv @ 2010-04-02 9:21 ` Angelo Graziosi 0 siblings, 0 replies; 194+ messages in thread From: Angelo Graziosi @ 2010-04-02 9:21 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 17:45 ` Jan Djärv 2010-04-01 18:03 ` Juri Linkov 2010-04-01 20:51 ` Angelo Graziosi @ 2010-04-02 2:06 ` Stephen J. Turnbull 2010-04-02 7:00 ` Jan Djärv 2 siblings, 1 reply; 194+ messages in thread From: Stephen J. Turnbull @ 2010-04-02 2:06 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs, Angelo Graziosi 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 2:06 ` Stephen J. Turnbull @ 2010-04-02 7:00 ` Jan Djärv 0 siblings, 0 replies; 194+ messages in thread From: Jan Djärv @ 2010-04-02 7:00 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: Emacs, Angelo Graziosi 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 16:52 Gtk tabs in emacs, new branch Angelo Graziosi 2010-04-01 17:45 ` Jan Djärv @ 2010-04-02 6:53 ` Jan Djärv 2010-04-02 9:59 ` Angelo Graziosi 2010-04-02 6:53 ` Uwe Siart 2 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-02 6:53 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 6:53 ` Jan Djärv @ 2010-04-02 9:59 ` Angelo Graziosi 2010-04-02 15:10 ` Jan Djärv 2010-04-02 16:19 ` Uwe Siart 0 siblings, 2 replies; 194+ messages in thread From: Angelo Graziosi @ 2010-04-02 9:59 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs [-- Attachment #1: Type: text/plain, Size: 982 bytes --] Il 02/04/2010 8.53, Jan Djärv ha scritto: > Angelo Graziosi skrev: > >> >> When I use 'M-x tab-new', I see a single buffer in two tabs. After >> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode >> line, Emas becomes very slow, perhaps it hangs... >> > > It may be timing related, I can't reproduce it. Does it always happen? > Do you have a recepie for it? At the moment, I can't reproduce too! So I haven't a clean recipe. By the way, I want to flag that on Cygwin, the active tab shows a sort of 'focus' rectangle which should not be expected (see 'sp_test.f90' in the attached figure). Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by default if you prefer, but that we can customize in the .emacs file. Another thing. Clicking on the tab's 'X', should not close the file? It deletes only the tab, the buffer being still 'visited' by Emacs. (I do not remember a similar behavior with other applications using tabs.) Ciao, Angelo. [-- Attachment #2: cygtest.png --] [-- Type: image/png, Size: 29793 bytes --] ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 9:59 ` Angelo Graziosi @ 2010-04-02 15:10 ` Jan Djärv 2010-04-02 16:55 ` Angelo Graziosi 2010-04-05 8:50 ` Angelo Graziosi 2010-04-02 16:19 ` Uwe Siart 1 sibling, 2 replies; 194+ messages in thread From: Jan Djärv @ 2010-04-02 15:10 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs Angelo Graziosi skrev: > Il 02/04/2010 8.53, Jan Djärv ha scritto: >> Angelo Graziosi skrev: >> >>> >>> When I use 'M-x tab-new', I see a single buffer in two tabs. After >>> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode >>> line, Emas becomes very slow, perhaps it hangs... >>> >> >> It may be timing related, I can't reproduce it. Does it always happen? >> Do you have a recepie for it? > > At the moment, I can't reproduce too! So I haven't a clean recipe. > > By the way, I want to flag that on Cygwin, the active tab shows a sort > of 'focus' rectangle which should not be expected (see 'sp_test.f90' in > the attached figure). It is a Gtk+ thing (i.e. focus border). I have pushed a new version that doesn't have it. For other additions, see README.TABS th the root of the tree. > > Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by default > if you prefer, but that we can customize in the .emacs file. I'm not sure if it is a mode. It is kind of outside that. You can now disable tab creation entirely by specifying disable-tabs in frame parameters at frame creation. > > Another thing. Clicking on the tab's 'X', should not close the file? It > deletes only the tab, the buffer being still 'visited' by Emacs. (I do > not remember a similar behavior with other applications using tabs.) I don't think so. After all, closing a frame doesn't close files. The file may still be visible in other frames or tabs. Jan D. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 15:10 ` Jan Djärv @ 2010-04-02 16:55 ` Angelo Graziosi 2010-04-05 8:50 ` Angelo Graziosi 1 sibling, 0 replies; 194+ messages in thread From: Angelo Graziosi @ 2010-04-02 16:55 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 15:10 ` Jan Djärv 2010-04-02 16:55 ` Angelo Graziosi @ 2010-04-05 8:50 ` Angelo Graziosi 2010-04-10 12:44 ` Jan Djärv 1 sibling, 1 reply; 194+ messages in thread From: Angelo Graziosi @ 2010-04-05 8:50 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-05 8:50 ` Angelo Graziosi @ 2010-04-10 12:44 ` Jan Djärv 2010-04-10 17:34 ` Angelo Graziosi 0 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-10 12:44 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-10 12:44 ` Jan Djärv @ 2010-04-10 17:34 ` Angelo Graziosi 2010-04-10 18:03 ` Jan Djärv 2010-04-10 19:19 ` Gtk tabs in emacs, new branch Stefan Monnier 0 siblings, 2 replies; 194+ messages in thread From: Angelo Graziosi @ 2010-04-10 17:34 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs Il 10/04/2010 14.44, Jan Djärv ha scritto: > Angelo Graziosi skrev: >> Still some observation... >> >> Suppose one starts Emacs, a single frame with 38 lines >> (Emacs.geometry: 80x40-0+0 in .Xdefaults, for example). Now suppose >> one creates some tabs: M-x tab-new. The lines now are 37 because one >> line is that of tabs and the frame has the same size (height). If, >> now, one deletes the tabs, the lines remain at 37 but the frame has >> the height shorter by one line. Repeating this procedure the lines >> become 36, 35,... and the frame shorter, shorter... >> >> Is this to be the right thing? My opinion is that the frame should >> have always the same height and the line should be 38 (N) or 37 (N-1) >> if the tabs are visible. > > Emacs tries to keep the frame size so an integral number of lines just > fits. But tabs aren't (in general) exactly one or two lines high, so > some resize will occur. I made some fix. > > I also made tab-mode a minor mode so it can be turned off by customize. Good to hear! but I can't yet test it because bootstrapping rev. 99648 (gtk-tabs branch) fails as follows: [...] make[3]: Entering directory `/tmp/emacs-gtk-tabs/build/lisp' Compiling /tmp/emacs/src/../lisp/term/w32-win.el Compiling /tmp/emacs/src/../lisp/emacs-lisp/easymenu.el Wrote /tmp/emacs/lisp/term/w32-win.elc Wrote /tmp/emacs/lisp/emacs-lisp/easymenu.elc make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp' make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp' rm -f ../etc/DOC ../lib-src/make-docfile -d /tmp/emacs/src dosfns.o msdos.o xterm.o xfns.o[...] /lisp/jka-cmpr-hook.elc ../lisp/ediff-hook.elc ../lisp/epa-hook.elc ../lisp/widget.elc ../lisp/window.elc ../lisp/version.el LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump Loading loadup.el (source)... Using load-path (/tmp/emacs/lisp) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... Loading version.el (source)... [...] Loading tool-bar... Loading font-setting... Loading native-tabs.el (source)... Attempt to autoload define-minor-mode while preparing to dump make[2]: *** [emacs.exe] Error 255 make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build' make: *** [bootstrap] Error 2 This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same manner. Ciao, Angelo. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-10 17:34 ` Angelo Graziosi @ 2010-04-10 18:03 ` Jan Djärv 2010-04-10 22:09 ` Angelo Graziosi 2010-04-10 19:19 ` Gtk tabs in emacs, new branch Stefan Monnier 1 sibling, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-10 18:03 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-10 18:03 ` Jan Djärv @ 2010-04-10 22:09 ` Angelo Graziosi 2010-04-11 5:45 ` Jan Djärv 0 siblings, 1 reply; 194+ messages in thread From: Angelo Graziosi @ 2010-04-10 22:09 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-10 22:09 ` Angelo Graziosi @ 2010-04-11 5:45 ` Jan Djärv 2010-04-11 8:16 ` Angelo Graziosi 0 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-11 5:45 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs Did you make sure native-tabs.el is byte-compiled? Also do make clean and then make again. Jan D. 11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>: > Il 10/04/2010 20.03, Jan Djärv ha scritto: >> Angelo Graziosi skrev: >>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the >>> same >>> manner. >> >> Hmm, I have pushed a new version where the autoload is removed. The >> problem is, then C-h f tab-mode doesn't show anything. > > I have tried also with rev. 99649, but same problem. :( > > Angelo > > ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-11 5:45 ` Jan Djärv @ 2010-04-11 8:16 ` Angelo Graziosi 2010-04-11 10:52 ` Jan Djärv 0 siblings, 1 reply; 194+ messages in thread From: Angelo Graziosi @ 2010-04-11 8:16 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs As I have flagged sometime on this list, I do ALWAYS clean build of Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-) So, perhaps, that branch has other problems. For example, $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in is empty in rev. 99648 and 99649. The last useful build is with rev. 99645. Ciao, Angelo. Il 11/04/2010 7.45, Jan Djärv ha scritto: > Did you make sure native-tabs.el is byte-compiled? Also do make clean > and then make again. > > Jan D. > > 11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>: > >> Il 10/04/2010 20.03, Jan Djärv ha scritto: >>> Angelo Graziosi skrev: >>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same >>>> manner. >>> >>> Hmm, I have pushed a new version where the autoload is removed. The >>> problem is, then C-h f tab-mode doesn't show anything. >> >> I have tried also with rev. 99649, but same problem. :( >> >> Angelo >> >> ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-11 8:16 ` Angelo Graziosi @ 2010-04-11 10:52 ` Jan Djärv 2010-04-11 17:28 ` Angelo Graziosi 0 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-11 10:52 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-11 10:52 ` Jan Djärv @ 2010-04-11 17:28 ` Angelo Graziosi 2010-04-11 18:33 ` Jan Djärv 2010-04-21 8:55 ` Juri Linkov 0 siblings, 2 replies; 194+ messages in thread From: Angelo Graziosi @ 2010-04-11 17:28 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-11 17:28 ` Angelo Graziosi @ 2010-04-11 18:33 ` Jan Djärv 2010-04-21 8:55 ` Juri Linkov 1 sibling, 0 replies; 194+ messages in thread From: Jan Djärv @ 2010-04-11 18:33 UTC (permalink / raw To: Angelo Graziosi; +Cc: Emacs 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-11 17:28 ` Angelo Graziosi 2010-04-11 18:33 ` Jan Djärv @ 2010-04-21 8:55 ` Juri Linkov 2010-04-21 9:46 ` David Kastrup ` (2 more replies) 1 sibling, 3 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-21 8:55 UTC (permalink / raw To: Angelo Graziosi; +Cc: Jan Djärv, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-21 8:55 ` Juri Linkov @ 2010-04-21 9:46 ` David Kastrup 2010-04-21 15:43 ` Juri Linkov 2010-04-21 13:54 ` Angelo Graziosi 2010-04-21 15:45 ` Juri Linkov 2 siblings, 1 reply; 194+ messages in thread From: David Kastrup @ 2010-04-21 9:46 UTC (permalink / raw To: emacs-devel Juri Linkov <juri@jurta.org> writes: >> Observations: I see that in Options | Show/Hide Tabs are on by default >> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x >> tab-new' to see some tab. I would expect that, if Tabs are on by default, >> starting Emacs shows desktop buffers in tabs, at least compatibly with the >> starting 'geometry' of Emacs. > > I implemented a new command line argument, so a command: > > emacs --tabs file1 file2 file3 > > will open each file in a new tab. That should be the default in a tab-capable Emacs when more than one file is specified. > And > > emacsclient --create-tab > > creates a new tab on the current Emacs frame. Again, I don't see a necessity for a new option. If Emacs is configured to open a new frame, all given files should appear in tabs of this frame. If not, all given files should appear in tabs in the existing selected frame, in front of existing tabs. -- David Kastrup ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-21 9:46 ` David Kastrup @ 2010-04-21 15:43 ` Juri Linkov [not found] ` <jwv633k4rn2.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-21 15:43 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel >> emacs --tabs file1 file2 file3 >> >> will open each file in a new tab. > > That should be the default in a tab-capable Emacs when more than one > file is specified. This seems better than splitting the window and displaying the buffer list, as it currently does. Tabs also have another advantage: the startup screen is displayed in a separate tab, so it does not interfere with editing input files. But what if some users might prefer the old behavior? Maybe to add a command line argument `--no-tabs'? >> emacsclient --create-tab >> >> creates a new tab on the current Emacs frame. > > Again, I don't see a necessity for a new option. If Emacs is configured > to open a new frame, all given files should appear in tabs of this > frame. If not, all given files should appear in tabs in the existing > selected frame, in front of existing tabs. Like Forefox having command line arguments `new-tab' and `new-window', I think Emacs should allow the user to choose whether to display the file in the selected window, a new frame or a new tab. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
[parent not found: <jwv633k4rn2.fsf-monnier+emacs@gnu.org>]
* Re: Gtk tabs in emacs, new branch [not found] ` <jwv633k4rn2.fsf-monnier+emacs@gnu.org> @ 2010-04-22 8:16 ` Juri Linkov 2010-04-22 15:08 ` Jan Djärv 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-22 8:16 UTC (permalink / raw To: Stefan Monnier; +Cc: David Kastrup, emacs-devel >> But what if some users might prefer the old behavior? >> Maybe to add a command line argument `--no-tabs'? > > We could assume the user will always want the same, so we could give him > some way to write down his preference in a file. We could that > "~/.emacs", for example. WDYT? Exactly like `pop-up-frames' defines whether `display-buffer' should make a separate frame, a new implemented option `pop-up-tabs' makes a separate tab when it is non-nil. It can be defined in ~/.emacs. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-22 8:16 ` Juri Linkov @ 2010-04-22 15:08 ` Jan Djärv 2010-04-23 8:33 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-22 15:08 UTC (permalink / raw To: Juri Linkov; +Cc: David Kastrup, Stefan Monnier, emacs-devel Juri Linkov skrev 2010-04-22 10.16: >>> But what if some users might prefer the old behavior? >>> Maybe to add a command line argument `--no-tabs'? >> >> We could assume the user will always want the same, so we could give him >> some way to write down his preference in a file. We could that >> "~/.emacs", for example. WDYT? > > Exactly like `pop-up-frames' defines whether `display-buffer' > should make a separate frame, a new implemented option `pop-up-tabs' > makes a separate tab when it is non-nil. It can be defined in ~/.emacs. > What if both pop-up-tabs and pop-up-frames are set? Jan D. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-22 15:08 ` Jan Djärv @ 2010-04-23 8:33 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-23 8:33 UTC (permalink / raw To: Jan Djärv; +Cc: David Kastrup, Stefan Monnier, emacs-devel >> Exactly like `pop-up-frames' defines whether `display-buffer' >> should make a separate frame, a new implemented option `pop-up-tabs' >> makes a separate tab when it is non-nil. It can be defined in ~/.emacs. > > What if both pop-up-tabs and pop-up-frames are set? Then pop-up-frames takes priority over pop-up-tabs and creates a new frame (with a single tab in it). -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-21 8:55 ` Juri Linkov 2010-04-21 9:46 ` David Kastrup @ 2010-04-21 13:54 ` Angelo Graziosi 2010-04-21 15:45 ` Juri Linkov 2 siblings, 0 replies; 194+ messages in thread From: Angelo Graziosi @ 2010-04-21 13:54 UTC (permalink / raw To: Juri Linkov; +Cc: Jan Djärv, Emacs 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. > ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-21 8:55 ` Juri Linkov 2010-04-21 9:46 ` David Kastrup 2010-04-21 13:54 ` Angelo Graziosi @ 2010-04-21 15:45 ` Juri Linkov 2010-04-21 16:04 ` Jan Djärv 2010-04-23 16:53 ` Drew Adams 2 siblings, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-21 15:45 UTC (permalink / raw To: Emacs I also implemented C functions to save window configurations in Lisp expressions that could be used later to save tabs in the desktop file. For example, (current-window-configuration-to-sexp) => (window-configuration (frame-cols . 80) (frame-lines . 41) (frame-menu-bar-lines . 1) (frame-tool-bar-lines . 4) (frame-tab-bar-lines . 4) (current-buffer . "*scratch*") (minibuf-scroll-window) (minibuf-selected-window) (saved-windows . (saved-window (current-window . t) (buffer . "*scratch*") (left-col . 0) (top-line . 5) (total-cols . 86) (total-lines . 35) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally) (pointm . 236) (start . 1) (start-at-line-beg . t) (mark . 192) (next . (saved-window (buffer . " *Minibuf-0*") (left-col . 0) (top-line . 40) (total-cols . 86) (total-lines . 1) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally) (pointm . 1) (start . 1) (start-at-line-beg)))))) -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-21 15:45 ` Juri Linkov @ 2010-04-21 16:04 ` Jan Djärv 2010-04-22 8:14 ` Juri Linkov 2010-04-23 16:53 ` Drew Adams 1 sibling, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-21 16:04 UTC (permalink / raw To: Juri Linkov; +Cc: Emacs This is good. But I suspect the restore part is the more difficult work. Jan D. Juri Linkov skrev 2010-04-21 17.45: > I also implemented C functions to save window configurations > in Lisp expressions that could be used later to save tabs > in the desktop file. For example, > > (current-window-configuration-to-sexp) > => > (window-configuration > (frame-cols . 80) > (frame-lines . 41) > (frame-menu-bar-lines . 1) > (frame-tool-bar-lines . 4) > (frame-tab-bar-lines . 4) > (current-buffer . "*scratch*") > (minibuf-scroll-window) > (minibuf-selected-window) > (saved-windows > . (saved-window > (current-window . t) > (buffer . "*scratch*") > (left-col . 0) > (top-line . 5) > (total-cols . 86) > (total-lines . 35) > (hscroll . 0) > (min-hscroll . 0) > (display-table) > (orig-top-line) > (orig-total-lines) > (left-margin-cols) > (right-margin-cols) > (left-fringe-width) > (right-fringe-width) > (fringes-outside-margins) > (scroll-bar-width) > (vertical-scroll-bar-type . t) > (dedicated) > (resize-proportionally) > (pointm . 236) > (start . 1) > (start-at-line-beg . t) > (mark . 192) > (next > . (saved-window > (buffer . " *Minibuf-0*") > (left-col . 0) > (top-line . 40) > (total-cols . 86) > (total-lines . 1) > (hscroll . 0) > (min-hscroll . 0) > (display-table) > (orig-top-line) > (orig-total-lines) > (left-margin-cols) > (right-margin-cols) > (left-fringe-width) > (right-fringe-width) > (fringes-outside-margins) > (scroll-bar-width) > (vertical-scroll-bar-type . t) > (dedicated) > (resize-proportionally) > (pointm . 1) > (start . 1) > (start-at-line-beg)))))) > ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-21 16:04 ` Jan Djärv @ 2010-04-22 8:14 ` Juri Linkov 2010-04-22 16:20 ` Juanma Barranquero 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-22 8:14 UTC (permalink / raw To: Jan Djärv; +Cc: Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-22 8:14 ` Juri Linkov @ 2010-04-22 16:20 ` Juanma Barranquero 2010-04-24 18:45 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Juanma Barranquero @ 2010-04-22 16:20 UTC (permalink / raw To: Juri Linkov; +Cc: Jan Djärv, Emacs On Thu, Apr 22, 2010 at 10:14, Juri Linkov <juri@jurta.org> wrote: > I've committed the initial workable > version of `set-window-configuration-from-sexp' to the x-tabs branch. > At least, it restores window configurations saved in another session. This is generally useful, i.e., if it works it should perhaps go to the trunk. Juanma ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-22 16:20 ` Juanma Barranquero @ 2010-04-24 18:45 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-24 18:45 UTC (permalink / raw To: Juanma Barranquero; +Cc: Jan Djärv, Emacs >> I've committed the initial workable >> version of `set-window-configuration-from-sexp' to the x-tabs branch. >> At least, it restores window configurations saved in another session. > > This is generally useful, i.e., if it works it should perhaps go to the trunk. Before moving it to the trunk, I'd like first to make sure that saving tabs to the desktop works reliably. For example, I realized that functions `current-window-configuration-to-sexp' and `set-window-configuration-from-sexp' are not suitable to save tabs because their window configurations are kept in #<window-configuration>. There should be another set of functions like `(window-configuration-to-sexp #<window-configuration>)' and `(window-configuration-from-sexp sexp)' that returns #<window-configuration>. This means that the returned Lisp expression will contain a list of windows (where `parent' and `prev' refer to the index of the window in this list) instead of the window hierarchy. Maybe this is a good thing. E.g. (window-configuration-to-sexp (current-window-configuration)) => (window-configuration (frame-cols . 196) (frame-lines . 77) (frame-menu-bar-lines . 1) (frame-tool-bar-lines . 4) (frame-tab-bar-lines . 0) (minibuf-scroll-window) (minibuf-selected-window) (saved-windows (window (left-col . 0) (top-line . 5) (total-cols . 202) (total-lines . 71) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally)) (window (parent . 0) (left-col . 0) (top-line . 5) (total-cols . 101) (total-lines . 71) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally)) (window (parent . 1) (buffer . "*scratch*") (left-col . 0) (top-line . 5) (total-cols . 101) (total-lines . 35) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally)) (window (parent . 1) (prev . 2) (buffer . "*Messages*") (left-col . 0) (top-line . 40) (total-cols . 101) (total-lines . 36) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally)) (window (parent . 0) (prev . 1) (buffer . "*info*") (left-col . 101) (top-line . 5) (total-cols . 101) (total-lines . 71) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally)) (window (prev . 0) (window . " *Minibuf-0*") (left-col . 0) (top-line . 76) (total-cols . 202) (total-lines . 1) (hscroll . 0) (min-hscroll . 0) (display-table) (orig-top-line) (orig-total-lines) (left-margin-cols) (right-margin-cols) (left-fringe-width) (right-fringe-width) (fringes-outside-margins) (scroll-bar-width) (vertical-scroll-bar-type . t) (dedicated) (resize-proportionally)))) -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* RE: Gtk tabs in emacs, new branch 2010-04-21 15:45 ` Juri Linkov 2010-04-21 16:04 ` Jan Djärv @ 2010-04-23 16:53 ` Drew Adams 2010-04-23 18:02 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: Drew Adams @ 2010-04-23 16:53 UTC (permalink / raw To: 'Juri Linkov', 'Emacs'; +Cc: 'Lennart Borgman' > From: Juri Linkov > I also implemented C functions to save window configurations > in Lisp expressions that could be used later to save tabs > in the desktop file. For example, > > (current-window-configuration-to-sexp) > => > (window-configuration > (frame-cols . 80) > (frame-lines . 41) > (frame-menu-bar-lines . 1) > (frame-tool-bar-lines . 4) > (frame-tab-bar-lines . 4) ... Is the intention to be able to save and restore all current window & frame configurations? That is what I would like to see, to be able to save and restore an Emacs state as completely as possible wrt frames and windows. [That would of course mean saving all frame parameters that can be restored. I would even like to see the ability for users to hook into such a feature, so that user-defined frame parameters could be handled also. E.g. for a user-defined frame parameter `foo', a user could specify how it can be saved and restored, so that frame-config saving & restoring would then DTRT wrt it.] Lennart made a stab at saving/restoring frame and window configs, but his code didn't work when I tested it (there were apparently some dependencies on his EmacsW32 etc.). Perhaps you and he could put together something general. It seems like you're both close. I would like to see the ability to save & restore each of the following independently, in such a way that you could use them separately or together (to save and restore various combinations): desktops, window configs, frame configs. IOW, we should not couple any of them in such a way that you could no longer save only a desktop (without also saving frame configs) or only the current frame & window configs, etc. E.g., a saved desktop should not necessarily include frame and window configs, but you should also be able to save all at once. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-23 16:53 ` Drew Adams @ 2010-04-23 18:02 ` Juri Linkov 2010-04-23 18:28 ` Drew Adams 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-23 18:02 UTC (permalink / raw To: Drew Adams; +Cc: 'Lennart Borgman', 'Emacs' > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* RE: Gtk tabs in emacs, new branch 2010-04-23 18:02 ` Juri Linkov @ 2010-04-23 18:28 ` Drew Adams 2010-04-24 9:17 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Drew Adams @ 2010-04-23 18:28 UTC (permalink / raw To: 'Juri Linkov'; +Cc: 'Lennart Borgman', 'Emacs' > > 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-23 18:28 ` Drew Adams @ 2010-04-24 9:17 ` Juri Linkov 2010-04-24 14:41 ` Drew Adams 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-24 9:17 UTC (permalink / raw To: Drew Adams; +Cc: 'Emacs' >> Yes, I've implemented the task to save and restore frame and >> window configurations in the desktop file. > > Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If > so, is it documented? If it's in the pretest I would like to try it. This feature is part of the x-tabs branch. > Can users save such frame & window configs independently of desktops - and vice > versa? Can they save individual frame/window configs as well as all configs > together? If you want to save frame and window configurations independently of desktops, you can easily do this using the same functions that desktop.el now uses. > A desktop saves some variables, buffers, etc. Users should be able to save just > frame/window state or just the vars+bufs state, as well as being able to save > everything together at once. There is a new variable `desktop-save-frame-configuration' that defines whether to save frame and window configurations to the desktop. It is nil by default. > Also, desktop.el has a big limitation (which I would like to see removed): it > assumes only one desktop file per directory. It's a separate task to implement named desktops. I imagine that named desktops should be an object above frames in the hierarchy of screen objects: - desktop - frame - tab - window configuration - window So switching desktops could be like switching frames: M-x select-desktop-by-name RET will read a desktop name, delete old frames by calling `desktop-clear', and create a new desktop by calling `desktop-read' with the selected name. > Can users hook into this to handle user-defined frame parameters also? > The feature should be open and not limited to a predefined set > of parameters. Yes, there is a new variable `desktop-frame-parameters-to-save'. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* RE: Gtk tabs in emacs, new branch 2010-04-24 9:17 ` Juri Linkov @ 2010-04-24 14:41 ` Drew Adams 2010-04-24 18:49 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Drew Adams @ 2010-04-24 14:41 UTC (permalink / raw To: 'Juri Linkov'; +Cc: 'Emacs' > > Can users save such frame & window configs independently of > > desktops - and vice versa? Can they save individual > > frame/window configs as well as all configs > > together? > > If you want to save frame and window configurations > independently of desktops, you can easily do this using the > same functions that desktop.el now uses. So is that confirmation or not that one can save desktops without frame+win configs and one can also save frame configs or window configs or both independently of desktops (the traditional desktop info)? And can users do that interactively out of the box, or are you saying only that someone is free to create some user commands to do that using existing desktop functions? > > A desktop saves some variables, buffers, etc. Users should > > be able to save just frame/window state or just the > > vars+bufs state, as well as being able to save > > everything together at once. > > There is a new variable `desktop-save-frame-configuration' > that defines whether to save frame and window configurations > to the desktop. It is nil by default. You don't also say that there is a way to save frame and window configs without saving them to a desktop file. Or whether there is a way to save them without also saving the other desktop info (buffers, vars etc.). It sounds like frame+win are optionally part of a desktop, but not the contrary as well. That is different from them being separate things that can optionally be combined. I don't care much about the names - whether, for instance, "desktop" applies to what it means now (buffers, vars, etc.) or it is changed to apply to everything, including frames and windows. What I am concerned about is being able to easily save & restore the different kinds of things separately. > > Also, desktop.el has a big limitation (which I would like > > to see removed): it assumes only one desktop file per directory. > > It's a separate task to implement named desktops. > > I imagine that named desktops should be an object above frames > in the hierarchy of screen objects: > - desktop - frame - tab - window configuration - window > So switching desktops could be like switching frames: > M-x select-desktop-by-name RET > will read a desktop name, delete old frames by calling > `desktop-clear', and create a new desktop by calling > `desktop-read' with the selected name. I do not really want to see desktops and frames coupled that way. Again, the names don't matter to me much - what I want is to be able to save & restore such different things together or separately. I did not mention "named desktops". I asked to be able to have more than one desktop file per directory. Currently, the desktop functions assume you can have only one desktop file per dir. I would like the basic desktop functions to accept an optional FILE arg that tells them where the desktop file is. (If no such arg is passed, then they could do as they do now: look to `desktop-dirname' to find the file.) That would permit other code to pass a FILE arg to directly specify a desktop file to use. I have desktop bookmarks, for instance. Because the desktop.el code does not allow a caller to specify the file to use, my code jumps through a few extra hoops. Look at `desktop-change-dir' and `desktop-read'. They just change to the desktop represented by a particular desktop file. But they assume one file per dir, so they accept only a dir as arg. You would expect that you could explicitly pass a desktop file to read, but you cannot. The desktop.el code seems to be oriented toward a particular interaction between users and its basic features. That's the problem, as I see it. It has general features of saving and restoring a desktop to/from a file, but the functions that perform those basic operations are cobbled by making them assume a particular UI. That makes them less general (less useful) than they could be. IOW, there is not enough separation between the basic desktop functions and the UI that uses them - the UI design bleeds down into the basic functions themselves. We need not change the desktop UI. (But we could do that, to let users use multiple files per dir interactively as well.) The basic desktop functions could still assume that the desktop file they need is in the `desktop-dirname' dir by default. All I'm suggesting is that these functions should allow an optional parameter that provides the desktop file location. Other changes to the code (e.g. locking) might also be necessary to allow use of multiple files per dir - dunno. I'm guessing that the reason behind the original one-desktop-file-per-dir design had to do with locking (multiple users etc.). I don't know what all might be involved in trying to remove this limitation (maybe allow multiple lock files per dir?). For my use of desktop files for bookmarks, I want to let users save desktop files anywhere, and I don't use the locking. I brought up this point because you seem to be coupling persistence of frame and window configs with desktop files - and hence extending the limitation of one such file per dir to the new feature as well. That means users cannot have multiple frame-config files per dir etc. Don't get me wrong. I'm very glad you're working on this, and I don't pretend to be an expert on desktops or the desktop.el code. I just would like things to be modular - separable and combinable, and I would like the basic save-&-restore functions to handle multiple state-saving files per dir. > > Can users hook into this to handle user-defined frame > > parameters also? The feature should be open and not limited to > > a predefined set of parameters. > > Yes, there is a new variable `desktop-frame-parameters-to-save'. Very good. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-24 14:41 ` Drew Adams @ 2010-04-24 18:49 ` Juri Linkov 2010-04-24 19:24 ` Drew Adams 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-24 18:49 UTC (permalink / raw To: Drew Adams; +Cc: 'Emacs' > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* RE: Gtk tabs in emacs, new branch 2010-04-24 18:49 ` Juri Linkov @ 2010-04-24 19:24 ` Drew Adams 2010-04-25 5:36 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Drew Adams @ 2010-04-24 19:24 UTC (permalink / raw To: 'Juri Linkov'; +Cc: 'Emacs' > 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-24 19:24 ` Drew Adams @ 2010-04-25 5:36 ` Juri Linkov 2010-04-25 9:15 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-25 5:36 UTC (permalink / raw To: Drew Adams; +Cc: 'Emacs' > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-25 5:36 ` Juri Linkov @ 2010-04-25 9:15 ` martin rudalics 2010-04-25 18:33 ` Window configurations (was: Gtk tabs in emacs, new branch) Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-04-25 9:15 UTC (permalink / raw To: Juri Linkov; +Cc: 'Emacs' > ... Currently the design > is at the stage of deciding what format is better to represent the > window configuration. There are two options: a window tree and > a plain list of windows. I am inclined to the second option > since when saved it would be more compact. There's absolutely no need to make window configurations saved by `current-window-configuration' (I call them CWCs here) and window configurations saved for later reconstruction in a possibly different session (called EWCs) save the same states of things. CWCs are needed to restore the appearance of a frame after a short excursion or because some error occurred. They are heavily overused in that respect (for example, every time you drag a window's modeline with the mouse up or down by one line, Emacs saves and discards the current window configuration twice) but certain aspects might be needed to keep the appearance coherent like, for example, `hscroll' related entries. EWCs should IMHO strip window configurations to the absolutely needed bare minimum. In particular `orig-top-line' and `orig-total-lines' do more harm than good in EWCs (BTW, I've completely done away with these in my rewrite of window.c) as all other minibuffer related information. Also hscroll and min-hscroll should not be stored. Whether margin, fringe and scrollbar information should be stored in EWCs depends on whether the appropriate settings for frames and the buffer local values are stored and orderly processed as well - otherwise they make few sense. I'm afraid we'd have to store/restore all of them, although I'm also quite sure that hardly anyone could tell how their final appearance on screen is determined. Coordinates should probably be rather stored as fractions instead of absolute lines and columns. This would make it easier to (1) eventually switch to pixel based coordinates and (2) put an EWC into an Emacs window (that is, put an Emacs frame into an Emacs window) as some IDE advocats mentioned earlier. Since I suppose you're running `split-window' to restore configurations you'd probably also want to remember whether a "split" was a vertical or a horizontal one in EWCs. Note that CWCs don't do this since they need to restore the configuration from the stored "coordinates" anyway, but the design is a bit awkward as code like if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) in `set-window-configuration' shows. That said, the *entire* coordinate information of a particular window in an EWC would consist of (1) whether it is a horizontal or a vertical combination and (2) the proportional space - either a float or the fraction of "some largest integer" - occupied by the window wrt to its parent window. Anything else would be pure overkill. BTW in the earlier example structure you posted here I'm missing entries for window-point, window-start, ... Was that intentional? martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Window configurations (was: Gtk tabs in emacs, new branch) 2010-04-25 9:15 ` martin rudalics @ 2010-04-25 18:33 ` Juri Linkov 2010-04-26 16:16 ` Window configurations martin rudalics ` (2 more replies) 0 siblings, 3 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-25 18:33 UTC (permalink / raw To: martin rudalics; +Cc: 'Emacs' >> ... Currently the design >> is at the stage of deciding what format is better to represent the >> window configuration. There are two options: a window tree and >> a plain list of windows. I am inclined to the second option >> since when saved it would be more compact. > > There's absolutely no need to make window configurations saved by > `current-window-configuration' (I call them CWCs here) and window > configurations saved for later reconstruction in a possibly different > session (called EWCs) save the same states of things. Yes. That's why I added a new argument `live-p' to `current-window-configuration-to-sexp'. When non-nil, it adds live data (window objects, buffer objects, markers, etc.) that are necessary when its Lisp expression will be used in the same session. When nil, it returns bare minimum necessary to save and restore in another session. > EWCs should IMHO strip window configurations to the absolutely needed > bare minimum. In particular `orig-top-line' and `orig-total-lines' do > more harm than good in EWCs (BTW, I've completely done away with these > in my rewrite of window.c) Do you plan to create a branch for your rewrite of window.c? It would be very interesting to look at it. > Coordinates should probably be rather stored as fractions instead of > absolute lines and columns. This would make it easier to (1) eventually > switch to pixel based coordinates and (2) put an EWC into an Emacs > window (that is, put an Emacs frame into an Emacs window) as some IDE > advocats mentioned earlier. There are no problems with storing coordinates as absolute lines and columns. After restoring absolute coordinates `set-window-configuration' resizes the frame thus keeping original relative sizes unchanged. > Since I suppose you're running `split-window' to restore configurations > you'd probably also want to remember whether a "split" was a vertical or > a horizontal one in EWCs. Note that CWCs don't do this since they need > to restore the configuration from the stored "coordinates" anyway, but > the design is a bit awkward as code like > > if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) > > in `set-window-configuration' shows. No, I don't use `split-window'. I use exactly the same algorithm as in `set-window-configuration', and additionally make new windows. In my tests, this works correctly. > That said, the *entire* coordinate information of a particular window in > an EWC would consist of (1) whether it is a horizontal or a vertical > combination and (2) the proportional space - either a float or the > fraction of "some largest integer" - occupied by the window wrt to its > parent window. Currently `set-window-configuration-from-sexp' works without these parameters. But maybe they would be useful for user-defined window configurations. > BTW in the earlier example structure you posted here I'm missing entries > for window-point, window-start, ... Was that intentional? There are entries `pointm' and `start' in the output of of the really working function `current-window-configuration-to-sexp'. But the example of the output of `window-configuration-to-sexp' is for demonstration purposes only. It doesn't work yet, because I'm not sure yet whether it's better than `current-window-configuration-to-sexp'. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-25 18:33 ` Window configurations (was: Gtk tabs in emacs, new branch) Juri Linkov @ 2010-04-26 16:16 ` martin rudalics 2010-04-27 8:54 ` Juri Linkov 2010-04-27 19:55 ` Davis Herring 2010-04-30 3:19 ` Window configurations (was: Gtk tabs in emacs, new branch) Ken Hori 2010-06-29 9:01 ` martin rudalics 2 siblings, 2 replies; 194+ messages in thread From: martin rudalics @ 2010-04-26 16:16 UTC (permalink / raw To: Juri Linkov; +Cc: 'Emacs' > Do you plan to create a branch for your rewrite of window.c? > It would be very interesting to look at it. I have to catch up with recent developments on the trunk - currently I'm at revision 99248. And I yet have to write Change Logs. > No, I don't use `split-window'. I use exactly the same algorithm as in > `set-window-configuration', and additionally make new windows. > In my tests, this works correctly. That's what I intended to do when I first looked into this. Making new windows essentially has the problem that when, for whatever reason, coordinates are garbled, you end up with a distorted frame and, in the worst case, crash Emacs. Checking window edges is simple with an existing window tree. But if you build the entire tree from scatch, you also have to provide a safe way to GC windows you made just in case they don't fit. With `split-window' you always add one window at a time and you never make a new one unless you're sure it fits. By no means I want to talk you out of this ;-) but `split-window' is a socially well-established function. Saved window configurations will hardly ever get used that much. And we'll already have a hard time to maintain compatibility, for example, when you want to restore a configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa). >> That said, the *entire* coordinate information of a particular window in >> an EWC would consist of (1) whether it is a horizontal or a vertical >> combination and (2) the proportional space - either a float or the >> fraction of "some largest integer" - occupied by the window wrt to its >> parent window. > > Currently `set-window-configuration-from-sexp' works without these > parameters. But maybe they would be useful for user-defined window > configurations. Users "define" window configurations by splitting and deleting windows. They have no idea of the underlying window tree. But if you don't use `split-window' storing the type of window combinations doesn't make sense anyway. It's just that current window configurations have lots of redundancy: For a vertical combination, the widths of all subwindows are the same as that of the parent window, top-lines can be calculated on the fly by adding the top-line of the left sibling to its height, ... Anyway, the greatest problem IMO is to get windows correlate with their buffers. I don't think that restoring ediff configurations will become ever feasible (unless you build this into the ediff code) and I'm also pessimistic about Info buffers - in particular cloned ones. And obviously we'll fail to handle code based on window objects or overlays with a window property. But for merely "normal" buffers the integrity of buffer-local variables affecting size and appearance of windows displaying them must be preserved. For example, when a buffer has `window-size-fixed' non-nil, any frame resizing step in your `set-window-configuration' should keep the size of the window fixed. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-26 16:16 ` Window configurations martin rudalics @ 2010-04-27 8:54 ` Juri Linkov 2010-04-27 12:54 ` martin rudalics 2010-04-27 19:55 ` Davis Herring 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-27 8:54 UTC (permalink / raw To: martin rudalics; +Cc: emacs-devel > By no means I want to talk you out of this ;-) but `split-window' is a > socially well-established function. Saved window configurations will > hardly ever get used that much. And we'll already have a hard time to > maintain compatibility, for example, when you want to restore a > configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa). I agree that when designing this feature, we should think about the future. Let's imagine that Emacs 27 will switch from the tiling window manager to an overlapping window manager. Then `split-window' in window configurations will make no sense. This suggests that for the generality window configurations should be defined as a list of windows with their parameters, i.e. very much like frames are defined now. Frame parameters to define the frame geometry are `left', `top', `height', and `width'. Window parameters to define the window geometry are `left-col', `top-line', `total-lines', and `total-cols'. Perhaps, in an overlapping window manager they should be in pixels. > Users "define" window configurations by splitting and deleting windows. > They have no idea of the underlying window tree. But if you don't use > `split-window' storing the type of window combinations doesn't make > sense anyway. It's just that current window configurations have lots of > redundancy: For a vertical combination, the widths of all subwindows are > the same as that of the parent window, top-lines can be calculated on > the fly by adding the top-line of the left sibling to its height, ... Yes, currently window coordinates are redundant because of the limitations of the tiling window manager. So we have to find a minimal set of window parameters to define the window location. I agree that a window tree is an implementation detail and users have no idea of the underlying window tree. Another variant is to define window geometry relative to the neighbor windows, e.g. `left-window', `right-window' in terms of the package windmove.el. Such window configurations would be easy to define for users. > Anyway, the greatest problem IMO is to get windows correlate with their > buffers. I don't think that restoring ediff configurations will become > ever feasible (unless you build this into the ediff code) I see no problems with window-to-buffer relations. They can be defined using buffer names. This works successfully with desktop.el from the x-tabs branch by saving and restoring window configurations in the desktop file. > and I'm also pessimistic about Info buffers Window configurations with Info buffers are saved and restored successfully in the desktop file as well. > - in particular cloned ones. What problems do you see with cloned Info buffers? > And obviously we'll fail to handle code based on window objects > or overlays with a window property. Maybe a package that uses window overlays should use a new hook to restore window overlays after a new window is created from a window configuration. > But for merely "normal" buffers the integrity of buffer-local variables > affecting size and appearance of windows displaying them must be > preserved. For example, when a buffer has `window-size-fixed' non-nil, > any frame resizing step in your `set-window-configuration' should keep > the size of the window fixed. It seems the frame resizing step in `set-window-configuration' already keeps the size of the window fixed. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-27 8:54 ` Juri Linkov @ 2010-04-27 12:54 ` martin rudalics 2010-04-27 18:03 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-04-27 12:54 UTC (permalink / raw To: Juri Linkov; +Cc: emacs-devel > This suggests that for the generality > window configurations should be defined as a list of windows with their > parameters, i.e. very much like frames are defined now. Frame parameters > to define the frame geometry are `left', `top', `height', and `width'. > Window parameters to define the window geometry are `left-col', `top-line', > `total-lines', and `total-cols'. Perhaps, in an overlapping window manager > they should be in pixels. Sounds reasonable. If we apply this idea today, the restore-from-sexp step would decide how to rebuild the window tree from these geometry parameters - that means how to nest windows into each others. > Yes, currently window coordinates are redundant because of the > limitations of the tiling window manager. So we have to find a minimal > set of window parameters to define the window location. I agree that > a window tree is an implementation detail and users have no idea of the > underlying window tree. Some window managers are tiling window managers, even Windows XP has one built in. So even if Emacs permits overlapping windows it will probably still offer tiled frames too. > Another variant is to define window geometry relative to the neighbor > windows, e.g. `left-window', `right-window' in terms of the package > windmove.el. Such window configurations would be easy to define for users. Hmm ... windmove never helped me that much. I rewrote the core function for my own purposes because there are windows I never want to select interactively but the window behind such an unselectable one (or on the left or right of it) is the window I really want. > I see no problems with window-to-buffer relations. They can be defined > using buffer names. This works successfully with desktop.el from the > x-tabs branch by saving and restoring window configurations in the > desktop file. I have one buffer type which gets killed as soon as it's not shown in any window. Another one gets its name from the name of the window it's shown in. But I admit that in most cases the problematic issue is not the buffer itself but the major or minor mode a window's buffer is in. I suppose the solution is to (1) make the mode take care of saving the relevant information and (2) untie buffer and window management in some way. How this would work for edebug, GDB, or diff sessions is currently beyond my imagination. Note that all I'm concerned here is that we now should probably fix the order in which the restoring steps are perfomed and what impact that has on restoring window configurations. Whether and how modes can be fully restored would be left to their designers. > Window configurations with Info buffers are saved and restored > successfully in the desktop file as well. >> - in particular cloned ones. > > What problems do you see with cloned Info buffers? I never looked into this but I'm surprised that Info buffer would work out of the box. Do help buffers work well too? > Maybe a package that uses window overlays should use a new hook > to restore window overlays after a new window is created from > a window configuration. I recall that Lennart tried to do that. Currently, overlays can be a mess after reverting a buffer so I think there are more important things to do first. Maybe we could try to handle this by giving windows fairly unique print names. > It seems the frame resizing step in `set-window-configuration' already > keeps the size of the window fixed. Probably at the expense of deleting windows when the frame gets too small. But my point was only that we have to process buffer-local variables _before_ resizing frames. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-27 12:54 ` martin rudalics @ 2010-04-27 18:03 ` Juri Linkov 2010-04-27 19:47 ` Info buffers in Desktop Juri Linkov 2010-04-28 7:12 ` Window configurations martin rudalics 0 siblings, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-27 18:03 UTC (permalink / raw To: martin rudalics; +Cc: emacs-devel >> This suggests that for the generality >> window configurations should be defined as a list of windows with their >> parameters, i.e. very much like frames are defined now. Frame parameters >> to define the frame geometry are `left', `top', `height', and `width'. >> Window parameters to define the window geometry are `left-col', `top-line', >> `total-lines', and `total-cols'. Perhaps, in an overlapping window manager >> they should be in pixels. > > Sounds reasonable. If we apply this idea today, the restore-from-sexp > step would decide how to rebuild the window tree from these geometry > parameters - that means how to nest windows into each others. For an overlapping window manager there is no need to rebuild the window tree from geometry parameters. And for the current tiling window manager you said that window coordinates are redundant. That's why I proposed non-redundant and easy-to-define relative parameters. I think it would be sufficient to have two relative position parameters `left-window' and `top-window' (that point to the left/top neighbor window) and two relative size parameters `width' and `height' (fractions relative to the frame size). I guess it would be possible to rebuild the window tree from this minimal set of window parameters. > Some window managers are tiling window managers, even Windows XP has one > built in. So even if Emacs permits overlapping windows it will probably > still offer tiled frames too. But none of these window managers define tiled windows as a split window tree. So probably an Emacs' overlapping window manager will not be based on window trees. > Hmm ... windmove never helped me that much. I rewrote the core function > for my own purposes because there are windows I never want to select > interactively but the window behind such an unselectable one (or on the > left or right of it) is the window I really want. This looks like a new "intangible" window property discussed in the window-group threads. Have you implemented this in your rewrite of window.c? >> What problems do you see with cloned Info buffers? > > I never looked into this but I'm surprised that Info buffer would work > out of the box. Do help buffers work well too? No, help buffers don't have an addressing scheme like in Info with (info "(file)node"). Recently I proposed to display Help information in the Info reader. This will save and restore buffers with Help information in the desktop file. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Info buffers in Desktop 2010-04-27 18:03 ` Juri Linkov @ 2010-04-27 19:47 ` Juri Linkov 2010-04-28 7:12 ` Window configurations martin rudalics 1 sibling, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-27 19:47 UTC (permalink / raw To: emacs-devel Currently desktop.el doesn't save virtual Info buffers, but most of them are very fast to restore. This patch allows desktop.el to save virtual Info buffers except when their definition has a new property `desktop-not-to-save'. `info-apropos' is very slow to create its output node, so it has this property: === modified file 'lisp/info.el' --- lisp/info.el 2010-04-22 18:08:17 +0000 +++ lisp/info.el 2010-04-27 19:45:27 +0000 @@ -3202,25 +3217,15 @@ (toc-nodes . Info-apropos-toc-nodes) (find-file . Info-apropos-find-file) (find-node . Info-apropos-find-node) + (desktop-not-to-save . t) )) (defvar Info-apropos-file "*Apropos*" @@ -4863,7 +4869,8 @@ (defun Info-desktop-buffer-misc-data (desktop-dirname) "Auxiliary information to be saved in desktop file." - (unless (Info-virtual-file-p Info-current-file) + (unless (Info-virtual-fun 'desktop-not-to-save + Info-current-file Info-current-node) (list Info-current-file Info-current-node))) (defun Info-restore-desktop-buffer (desktop-buffer-file-name -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-27 18:03 ` Juri Linkov 2010-04-27 19:47 ` Info buffers in Desktop Juri Linkov @ 2010-04-28 7:12 ` martin rudalics 2010-04-28 8:27 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-04-28 7:12 UTC (permalink / raw To: Juri Linkov; +Cc: emacs-devel >> Sounds reasonable. If we apply this idea today, the restore-from-sexp >> step would decide how to rebuild the window tree from these geometry >> parameters - that means how to nest windows into each others. > > For an overlapping window manager there is no need to rebuild the window > tree from geometry parameters. And for the current tiling window manager > you said that window coordinates are redundant. That's what I said earlier. But if we eventually do need them for an overlapping window manager, we could build them into the current tiling manager. Just that (IMO) the tiling manager needs internal windows to work correctly. So the common format would be your four standard parameters left column, top line, height and width for _all_ windows including internal ones. The restore step for the current tiling manager would have to process the internal windows and reconstruct the nesting by comparing their coordinates with those of the leaf windows - just like the current `set-window-configuration' does in if (!NILP (w->parent)) { if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) { XWINDOW (w->parent)->vchild = p->window; XWINDOW (w->parent)->hchild = Qnil; } else { XWINDOW (w->parent)->hchild = p->window; XWINDOW (w->parent)->vchild = Qnil; } where it sets the vertical / horizontal child of a parent window according to whether the number of its columns equals that of its child windows (this work by virtue of Emacs's ability to collapse matryoshka windows although it might not harm much if for such windows the split direction would be inverted). The restore step for the overlapping manager would simply ignore internal windows. So we could restore configurations stored by a tiling manager in an overlapping manager. > That's why I proposed > non-redundant and easy-to-define relative parameters. I think it would > be sufficient to have two relative position parameters `left-window' and > `top-window' (that point to the left/top neighbor window) and two relative > size parameters `width' and `height' (fractions relative to the frame size). > I guess it would be possible to rebuild the window tree from this minimal > set of window parameters. Do you mean left would point to the left neighbor and top to the neighbor above? How would you assign them for a four window configuration like this: ----- |1 |2 | |-----| |3 |4 | ----- Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows. How would you convey that information with relative parameters? > This looks like a new "intangible" window property discussed in the > window-group threads. Have you implemented this in your rewrite of > window.c? It's virtually impossible to do that in a strict sense (unless you go for a `post-command-hook'). Note that you can always do a thing like (select-window (minibuffer-window)). What I've done is to make `other-window' by default not select certain window types. That default can be overridden by window parameters. And I wrote a `window-in-direction' function which does this for the window in a given direction (I need this because I never use C-x o). martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-28 7:12 ` Window configurations martin rudalics @ 2010-04-28 8:27 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-28 8:27 UTC (permalink / raw To: martin rudalics; +Cc: emacs-devel > The restore step for the overlapping manager would simply ignore > internal windows. So we could restore configurations stored by a tiling > manager in an overlapping manager. I agree that in a tiling manager internal windows should have coordinates, and an overlapping manager should ignore windows that don't display buffers (if a window manager will support displaying windows without buffers then window definitions should include a new window parameter for them). > Do you mean left would point to the left neighbor and top to the > neighbor above? Yes. > How would you assign them for a four window configuration like this: > > ----- > |1 |2 | > |-----| > |3 |4 | > ----- > > Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows. How > would you convey that information with relative parameters? This is easy to do. Since split window trees are order-dependent, a list of windows that defines the window configuration in the tiling manager should be order-dependent too. Thus (window 1 (buffer . 1)) (window 2 (buffer . 2) (left-window . 1)) (window 3 (buffer . 3) (top-window . 1)) (window 4 (buffer . 4) (top-window . 2) (left-window . 3)) will create 1+2 and 3+4, and (window 1 (buffer . 1)) (window 3 (buffer . 3) (top-window . 1)) (window 2 (buffer . 2) (left-window . 1)) (window 4 (buffer . 4) (top-window . 2) (left-window . 3)) will create 1+3 and 2+4. >> This looks like a new "intangible" window property discussed in the >> window-group threads. Have you implemented this in your rewrite of >> window.c? > > It's virtually impossible to do that in a strict sense (unless you go > for a `post-command-hook'). Note that you can always do a thing like > (select-window (minibuffer-window)). This is right that primitives should be able to do this, and user commands should take restrictions from additional parameters. > What I've done is to make `other-window' by default not select certain > window types. That default can be overridden by window parameters. And > I wrote a `window-in-direction' function which does this for the window > in a given direction (I need this because I never use C-x o). Ok, I'll wait until you publish a Bzr branch to look at this. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-26 16:16 ` Window configurations martin rudalics 2010-04-27 8:54 ` Juri Linkov @ 2010-04-27 19:55 ` Davis Herring 2010-04-28 7:12 ` martin rudalics 2010-04-28 8:35 ` Juri Linkov 1 sibling, 2 replies; 194+ messages in thread From: Davis Herring @ 2010-04-27 19:55 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, 'Emacs' > Users "define" window configurations by splitting and deleting windows. > They have no idea of the underlying window tree. I'm not sure that's right. While users certainly don't know about `frame-root-window' windows, the tree is otherwise readily apparent (since, for instance, resizing or deleting a window distinguishes +-+-+ +-+-+ |A|B| |A|B| +-|-+ and +---+ |C|D| |C|D| +-+-+ +-+-+ in an immediately obvious fashion). Why not store a configuration as a (resolution-independent) tree: subtree = window | tree ; tree = "(", horiz, subtree, split, { split }, ")" ; split = fraction, subtree ; horiz = nil | t ; (* t for C-x 3 *) fraction = ? float ? ; window = ? ... ? ; (* the hard part *) very much like (window-tree)? Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-27 19:55 ` Davis Herring @ 2010-04-28 7:12 ` martin rudalics 2010-04-28 14:50 ` Stefan Monnier 2010-04-28 8:35 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-04-28 7:12 UTC (permalink / raw To: herring; +Cc: Juri Linkov, 'Emacs' >> Users "define" window configurations by splitting and deleting windows. >> They have no idea of the underlying window tree. > > I'm not sure that's right. While users certainly don't know about > `frame-root-window' windows, the tree is otherwise readily apparent > (since, for instance, resizing or deleting a window distinguishes > > +-+-+ +-+-+ > |A|B| |A|B| > +-|-+ and +---+ > |C|D| |C|D| > +-+-+ +-+-+ > > in an immediately obvious fashion). Yes. But by merey looking at these configuration you can't tell the difference. > Why not store a configuration as a > (resolution-independent) tree: > > subtree = window | tree ; > tree = "(", horiz, subtree, split, { split }, ")" ; > split = fraction, subtree ; > horiz = nil | t ; (* t for C-x 3 *) > fraction = ? float ? ; > window = ? ... ? ; (* the hard part *) That's more or less what I proposed earlier: All I need for the current, tiling window-manager based on window-trees is the type of the split (horizontal or vertical) and the fraction occupied by a window wrt to its parent window. This implies, however, that an overlapping manager processing such a structure must be able to understand window trees. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-28 7:12 ` martin rudalics @ 2010-04-28 14:50 ` Stefan Monnier 0 siblings, 0 replies; 194+ messages in thread From: Stefan Monnier @ 2010-04-28 14:50 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, 'Emacs' > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-27 19:55 ` Davis Herring 2010-04-28 7:12 ` martin rudalics @ 2010-04-28 8:35 ` Juri Linkov 2010-04-28 14:15 ` Davis Herring 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-04-28 8:35 UTC (permalink / raw To: herring; +Cc: martin rudalics, 'Emacs' > Why not store a configuration as a (resolution-independent) tree: > > subtree = window | tree ; > tree = "(", horiz, subtree, split, { split }, ")" ; > split = fraction, subtree ; > horiz = nil | t ; (* t for C-x 3 *) > fraction = ? float ? ; > window = ? ... ? ; (* the hard part *) > > very much like (window-tree)? A window-tree format is good for androids. But for human beings it is too complicated. Please see how ECB defines window configurations as a plain list of function calls because it is more simple and convenient for human users: (ecb-set-directories-buffer) (ecb-split-ver 0.3) (ecb-set-sources-buffer) (ecb-split-ver 0.5) (ecb-set-methods-buffer) (select-window (previous-window)) (ecb-split-hor 0.5) (ecb-set-history-buffer) But this format has one drawback - it is procedural. Using a declarative, more general and future-proof format: (window A (buffer . A)) (window B (buffer . B) (left-window . A)) (window C (buffer . C) (top-window . A)) (window D (buffer . D) (top-window . B) (left-window . C)) will create +-+-+ |A|B| +---+ |C|D| +-+-+ and with a different order of window definitions: (window A (buffer . A)) (window C (buffer . C) (top-window . A)) (window B (buffer . B) (left-window . A)) (window D (buffer . D) (top-window . B) (left-window . C)) will create +-+-+ |A|B| +-|-+ |C|D| +-+-+ -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-28 8:35 ` Juri Linkov @ 2010-04-28 14:15 ` Davis Herring 2010-05-07 18:14 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Davis Herring @ 2010-04-28 14:15 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, 'Emacs' > A window-tree format is good for androids. But for human beings it is > too complicated. Please see how ECB defines window configurations as > a plain list of function calls because it is more simple and convenient > for human users: > > (ecb-set-directories-buffer) > (ecb-split-ver 0.3) > (ecb-set-sources-buffer) > (ecb-split-ver 0.5) > (ecb-set-methods-buffer) > (select-window (previous-window)) > (ecb-split-hor 0.5) > (ecb-set-history-buffer) Perhaps then I am an android. I look at that code and it takes me quite a while to decide that the window-tree it produces (as I defined it) is (I think) (nil #<methods> 0.15 #<sources> 0.3 (t #<history> 0.5 #<directories>)) ...assuming that ecb-split-{ver,hor} is just C-x {2,3} with the divide placed the argument fraction of the way {down,right} the original window. On the other hand I find interpreting the window-tree easy because I can just read it rather than tracing through it. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-28 14:15 ` Davis Herring @ 2010-05-07 18:14 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-05-07 18:14 UTC (permalink / raw To: herring; +Cc: martin rudalics, Emacs > Perhaps then I am an android. I look at that code and it takes me quite a > while to decide that the window-tree it produces (as I defined it) is (I > think) > > (nil #<methods> 0.15 #<sources> 0.3 (t #<history> 0.5 #<directories>)) The problem is that the internal structure with the window configuration is a list. So when exposed to Lisp, it should be a Lisp list. It you want a tree, it's possible to write a Lisp function that converts a window list to a window tree, e.g. (window-configuration-to-tree (window-configuration-to-list (current-window-configuration))) where `window-configuration-to-list' is a C function that exposes #<window-configuration> to Lisp as a list like (window-configuration (frame-cols . 194) (frame-lines . 77) (root-window . #<window 16>) (windows (window (window . #<window 16>) (left-col . 0) (top-line . 5) (total-cols . 200) (total-lines . 71)) (window (window . #<window 3 on *scratch*>) (parent . 0) (left-col . 0) (top-line . 5) (total-cols . 100) (total-lines . 71)) (window (window . #<window 18>) (parent . 0) (prev . 1) (left-col . 100) (top-line . 5) (total-cols . 100) (total-lines . 71)) (window (window . #<window 17 on *info*>) (parent . 2) (left-col . 100) (top-line . 5) (total-cols . 100) (total-lines . 35)) (window (window . #<window 19 on *Messages*>) (parent . 2) (prev . 3) (left-col . 100) (top-line . 40) (total-cols . 100) (total-lines . 36)) (window (window . #<window 4 on *Minibuf-0*>) (prev . 0) (left-col . 0) (top-line . 76) (total-cols . 200) (total-lines . 1)))) and `window-configuration-to-tree' is a Lisp function that converts it to a window-tree. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations (was: Gtk tabs in emacs, new branch) 2010-04-25 18:33 ` Window configurations (was: Gtk tabs in emacs, new branch) Juri Linkov 2010-04-26 16:16 ` Window configurations martin rudalics @ 2010-04-30 3:19 ` Ken Hori 2010-04-30 20:33 ` Window configurations Stefan Monnier 2010-05-02 20:28 ` Juri Linkov 2010-06-29 9:01 ` martin rudalics 2 siblings, 2 replies; 194+ messages in thread From: Ken Hori @ 2010-04-30 3:19 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, Emacs Juri, Could we add as an extra `buffer-file-name' alist element in the sexp of a window-configuration or is that a bad idea? (I was just tring to reconstruct a window-configuration after an emacs reboot but quickly found out filenames weren't just there.) On Sun, Apr 25, 2010 at 11:33 AM, Juri Linkov <juri@jurta.org> wrote: >>> ... Currently the design >>> is at the stage of deciding what format is better to represent the >>> window configuration. There are two options: a window tree and >>> a plain list of windows. I am inclined to the second option >>> since when saved it would be more compact. >> >> There's absolutely no need to make window configurations saved by >> `current-window-configuration' (I call them CWCs here) and window >> configurations saved for later reconstruction in a possibly different >> session (called EWCs) save the same states of things. > > Yes. That's why I added a new argument `live-p' to > `current-window-configuration-to-sexp'. When non-nil, it adds live data > (window objects, buffer objects, markers, etc.) that are necessary > when its Lisp expression will be used in the same session. When nil, > it returns bare minimum necessary to save and restore in another session. > >> EWCs should IMHO strip window configurations to the absolutely needed >> bare minimum. In particular `orig-top-line' and `orig-total-lines' do >> more harm than good in EWCs (BTW, I've completely done away with these >> in my rewrite of window.c) > > Do you plan to create a branch for your rewrite of window.c? > It would be very interesting to look at it. > >> Coordinates should probably be rather stored as fractions instead of >> absolute lines and columns. This would make it easier to (1) eventually >> switch to pixel based coordinates and (2) put an EWC into an Emacs >> window (that is, put an Emacs frame into an Emacs window) as some IDE >> advocats mentioned earlier. > > There are no problems with storing coordinates as absolute lines and > columns. After restoring absolute coordinates `set-window-configuration' > resizes the frame thus keeping original relative sizes unchanged. > >> Since I suppose you're running `split-window' to restore configurations >> you'd probably also want to remember whether a "split" was a vertical or >> a horizontal one in EWCs. Note that CWCs don't do this since they need >> to restore the configuration from the stored "coordinates" anyway, but >> the design is a bit awkward as code like >> >> if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) >> >> in `set-window-configuration' shows. > > No, I don't use `split-window'. I use exactly the same algorithm as in > `set-window-configuration', and additionally make new windows. > In my tests, this works correctly. > >> That said, the *entire* coordinate information of a particular window in >> an EWC would consist of (1) whether it is a horizontal or a vertical >> combination and (2) the proportional space - either a float or the >> fraction of "some largest integer" - occupied by the window wrt to its >> parent window. > > Currently `set-window-configuration-from-sexp' works without these > parameters. But maybe they would be useful for user-defined window > configurations. > >> BTW in the earlier example structure you posted here I'm missing entries >> for window-point, window-start, ... Was that intentional? > > There are entries `pointm' and `start' in the output of of the really > working function `current-window-configuration-to-sexp'. > > But the example of the output of `window-configuration-to-sexp' is for > demonstration purposes only. It doesn't work yet, because I'm not sure yet > whether it's better than `current-window-configuration-to-sexp'. > > -- > Juri Linkov > http://www.jurta.org/emacs/ > > > ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-30 3:19 ` Window configurations (was: Gtk tabs in emacs, new branch) Ken Hori @ 2010-04-30 20:33 ` Stefan Monnier 2010-05-02 20:31 ` Juri Linkov 2010-05-02 20:28 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-04-30 20:33 UTC (permalink / raw To: Ken Hori; +Cc: Juri Linkov, martin rudalics, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-30 20:33 ` Window configurations Stefan Monnier @ 2010-05-02 20:31 ` Juri Linkov 2010-05-02 23:34 ` Drew Adams 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-02 20:31 UTC (permalink / raw To: Stefan Monnier; +Cc: Ken Hori, martin rudalics, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* RE: Window configurations 2010-05-02 20:31 ` Juri Linkov @ 2010-05-02 23:34 ` Drew Adams 2010-05-03 0:50 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: Drew Adams @ 2010-05-02 23:34 UTC (permalink / raw To: 'Juri Linkov', 'Stefan Monnier' Cc: 'Ken Hori', 'martin rudalics', 'Emacs' > >> Could we add as an extra `buffer-file-name' alist element > >> in the sexp of a window-configuration or is that a bad idea? > >> (I was just tring to reconstruct a window-configuration > >> after an emacs reboot but quickly found out filenames > >> weren't just there.) > > > > For saving/restoring, we'll probably need to save the same info used > > by bookmark.el or desktop.el (unifying the two might also be a good > > idea, BTW). > > Since bookmark.el is conceptually more low-level than desktop.el, > the latter could use a subset of services provided by bookmarks. > > There is one problem of using bookmark records for desktop.el. > Some bookmarks take too much time to restore when reading > from the desktop file. So packages will need to distinguish > between making a bookmark for bookmark.el or desktop.el to not > save some bookmarks in the desktop file. Maybe > `bookmark-make-record-function' will require a new argument for that. Sigh. I really wish you guys wouldn't mess with this. Put what you want in a window config, but please do not try "unifying" bookmarks and desktops (and window configs). If anything, bookmarks are more general and higher-level (not lower-level) than desktops. Why? Because you can save/restore many different types of things as bookmarks, each in its own way. Each can have its own handler. Anything can be bookmarked. A desktop records one type of thing: a desktop, no matter what you might want to stuff into a desktop, no matter how complex it is. If you want to add handlers or other bells and whistles to desktops, go for it, but please do not try to merge bookmarks and desktops as if they were the same thing or one were an instance or a subset of the other. They both record state persistently and restore it; that's all. There is no reason to confuse the concepts or merge the code. On the other hand, a desktop can be targeted as one kind of bookmark - a bookmark can restore a desktop just as it can restore an Info node. That is the case in bookmark+.el, for example. But it does not make sense to record all of the info for a desktop directly in the bookmark (and thus in a bookmark file, which can contain _lots_ of bookmarks). What makes sense is for a desktop bookmark to simply refer to a particular desktop file, which records the desktop info. Likewise, for a window-config bookmark. (I'm still hoping you will not hard-couple window-configs and desktops - each can be used independently of the other, as well as together.) Nor does it make much sense to add bookmark records to a desktop file. I don't know what kind of bookmark "info" or bookmark "services" you think would be required by desktops. Do you plan on adding handlers to desktops? Whatever. Add whatever you must to window-config records or desktop records, but please keep bookmarks separate from them both. Keep things simple and separate, so users and programmers can easily combine them at will in various ways. Just give us a way to save and restore window configs, and we can always combine that (or not) with saving and restoring desktops. And we can always create a bookmark to either. Please do not start "unifying" everything into one big ball of knots. Wrt generalizing and improving _bookmarking_, which is a different topic from making window configs persistent and restorable, see bookmark+.el. All of that improvement could be added to Emacs, as a patch to bookmark.el. (No, I don't want to argue about it. If you don't want it, that's fine.) http://www.emacswiki.org/emacs/BookmarkPlus Bookmarking is about saving and restoring something - anything. It is therefore about handling different kinds of stateful things differently. To improve bookmarking, work on making it easy for users to distinguish and access the various types, provide type-specific UI features and help, and so on. Forget about constructing the uber unifying bookmark-cum-desktop-cum-window-config cathedral. Please. The goal should be separate Lego blocks of different shapes that fit together, not a big wad of fused plastic. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-02 23:34 ` Drew Adams @ 2010-05-03 0:50 ` Stefan Monnier 2010-05-03 0:57 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-05-03 0:50 UTC (permalink / raw To: Drew Adams Cc: 'Juri Linkov', 'Ken Hori', 'Emacs', 'martin rudalics' >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-03 0:50 ` Stefan Monnier @ 2010-05-03 0:57 ` Juri Linkov 2010-05-03 2:50 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-03 0:57 UTC (permalink / raw To: Stefan Monnier; +Cc: Ken Hori, martin rudalics, Drew Adams, Emacs >>> There is one problem of using bookmark records for desktop.el. >>> Some bookmarks take too much time to restore when reading >>> from the desktop file. > > Juri, do you have more details on this? I don't know of this problem. Currently, Info mode doesn't save/restore virtual Info nodes to the desktop file at all. Even `dir' is not saved (which is a virtual file now). The patch I sent on 2010-04-27 allows Info-desktop-buffer-misc-data to save all virtual nodes to the desktop, except Info-apropos. Info-apropos takes too much time to create a node with the search results. So restoring an Info-apropos node from the desktop file would be unacceptably slow. One variant is to save the apropos search results as text in the desktop file, but then it will grow too big. There is no such problem for bookmarks because when the user decides to restore a bookmark for an Info-apropos node, then the user is ready to wait until this Info node is created and displayed. > Noone's trying to unify the two: desktop.el uses internally > a representation of "the content and position of a given buffer" to be > able to reproduce it later, and as it turns out, this is the exact same > problem that bookmark tries to solve. So it might make sense for > desktop.el to use bookmarks for that internal thingy. > > I'm not 100% positive it does since the purpose is slightly different > (e.g. a bookmark is expected to be useful for a potentially long period > of time during which the file referenced might be modified many times, > so bookmark doesn't just record the buffer position but also some > context so as to find the same spot even if it's not at the same line > number any more. It's probably less important for desktop.el). There is another package that could benefit from the functionality of bookmark.el - saveplace.el that saves places in files. For instance, when I put point on the `* Elisp: (elisp)' line in `dir', kill the *info* buffer, and type `C-h i' again, then I'd like if point was on the same `* Elisp: (elisp)' line. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-03 0:57 ` Juri Linkov @ 2010-05-03 2:50 ` Stefan Monnier 2010-05-04 16:09 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-05-03 2:50 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, martin rudalics, Drew Adams, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-03 2:50 ` Stefan Monnier @ 2010-05-04 16:09 ` Juri Linkov 2010-05-05 6:41 ` Stephen J. Turnbull 2010-05-05 21:59 ` Juri Linkov 0 siblings, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-05-04 16:09 UTC (permalink / raw To: Stefan Monnier; +Cc: Ken Hori, martin rudalics, Drew Adams, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-04 16:09 ` Juri Linkov @ 2010-05-05 6:41 ` Stephen J. Turnbull 2010-05-05 13:22 ` Stefan Monnier 2010-05-05 21:59 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: Stephen J. Turnbull @ 2010-05-05 6:41 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, martin rudalics, Stefan Monnier, Drew Adams, Emacs 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"? ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 6:41 ` Stephen J. Turnbull @ 2010-05-05 13:22 ` Stefan Monnier 2010-05-05 14:35 ` Stephen J. Turnbull 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-05-05 13:22 UTC (permalink / raw To: Stephen J. Turnbull Cc: Juri Linkov, Ken Hori, Emacs, Drew Adams, martin rudalics >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 13:22 ` Stefan Monnier @ 2010-05-05 14:35 ` Stephen J. Turnbull 0 siblings, 0 replies; 194+ messages in thread From: Stephen J. Turnbull @ 2010-05-05 14:35 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Ken Hori, Emacs, Drew Adams, martin rudalics 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-04 16:09 ` Juri Linkov 2010-05-05 6:41 ` Stephen J. Turnbull @ 2010-05-05 21:59 ` Juri Linkov 1 sibling, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-05-05 21:59 UTC (permalink / raw To: Stefan Monnier; +Cc: Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-30 3:19 ` Window configurations (was: Gtk tabs in emacs, new branch) Ken Hori 2010-04-30 20:33 ` Window configurations Stefan Monnier @ 2010-05-02 20:28 ` Juri Linkov 2010-05-03 3:31 ` Ken Hori 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-02 20:28 UTC (permalink / raw To: Ken Hori; +Cc: martin rudalics, Emacs > Could we add as an extra `buffer-file-name' alist element in the sexp > of a window-configuration or is that a bad idea? (I was just tring to > reconstruct a window-configuration after an emacs reboot but quickly > found out filenames weren't just there.) I think that information about file names is redundant. To restore file buffers in windows of the saved window configuration, you can prepare buffers (open files, call packages that create special buffers, etc.), keep their buffer objects and use them later during restoring the saved window configuration. For instance, (setq buffer1 (find-file-noselect "file1.txt")) (setq buffer2 (find-file-noselect "file2.txt")) (set-window-configuration-from-list '(window-configuration (frame-cols . 80) (frame-lines . 41) (window (buffer . buffer1) (left-col . 0) (top-line . 5) (total-cols . 86) (total-lines . 35) ...) (window (buffer . buffer2) (left-col . 0) (top-line . 5) (total-cols . 86) (total-lines . 35) ...))) This is basically what desktop.el does: it restores buffers, and later it can restore window configurations using restored buffer names. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-02 20:28 ` Juri Linkov @ 2010-05-03 3:31 ` Ken Hori 2010-05-04 16:12 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Ken Hori @ 2010-05-03 3:31 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, Emacs Juri, My point was that you wound't be able to open a file without knowing buffer-file-name once emacs gets closed. In particular, if a window-configuration-sexp doesn't contain such a thing as buffer-file-name, you wound't be able to reconstruct > (setq buffer1 (find-file-noselect "<file-path>")) since <file-path> gets lost upon exit. Of course you can store <file-path> for each file buffer "somewhere", but I thought the point of having window-configuration-sexp's is to save that kind of extra work and provide a canonical way of restoring frame states. I was hoping that ideally emacs would hold buffer-file-name's in the sexp and let the user specify a "buffer-recovery-function" to recover a frame state as well as buffers, so that, hypothetically, (restore-window-configuration-from-sexp a-window-configuration-sexp 'live-p #'find-file-noselect) would restore buffers as well as a window configuration. On Sun, May 2, 2010 at 1:28 PM, Juri Linkov <juri@jurta.org> wrote: >> Could we add as an extra `buffer-file-name' alist element in the sexp >> of a window-configuration or is that a bad idea? (I was just tring to >> reconstruct a window-configuration after an emacs reboot but quickly >> found out filenames weren't just there.) > > I think that information about file names is redundant. > > To restore file buffers in windows of the saved window configuration, > you can prepare buffers (open files, call packages that create special > buffers, etc.), keep their buffer objects and use them later during > restoring the saved window configuration. For instance, > > (setq buffer1 (find-file-noselect "file1.txt")) > (setq buffer2 (find-file-noselect "file2.txt")) > > (set-window-configuration-from-list > '(window-configuration > (frame-cols . 80) > (frame-lines . 41) > (window > (buffer . buffer1) > (left-col . 0) > (top-line . 5) > (total-cols . 86) > (total-lines . 35) > ...) > (window > (buffer . buffer2) > (left-col . 0) > (top-line . 5) > (total-cols . 86) > (total-lines . 35) > ...))) > > This is basically what desktop.el does: it restores buffers, and later > it can restore window configurations using restored buffer names. > > -- > Juri Linkov > http://www.jurta.org/emacs/ > ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-03 3:31 ` Ken Hori @ 2010-05-04 16:12 ` Juri Linkov 2010-05-05 9:19 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-04 16:12 UTC (permalink / raw To: Ken Hori; +Cc: martin rudalics, Emacs > My point was that you wound't be able to open a file without > knowing buffer-file-name once emacs gets closed. In particular, > if a window-configuration-sexp doesn't contain such a thing as > buffer-file-name, you wound't be able to reconstruct > >> (setq buffer1 (find-file-noselect "<file-path>")) > > since <file-path> gets lost upon exit. Of course you can > store <file-path> for each file buffer "somewhere", but I > thought the point of having window-configuration-sexp's is to > save that kind of extra work and provide a canonical way of > restoring frame states. The point of set-window-configuration-from-sexp is to restore the configuration of windows, not to duplicate the functionality of desktop.el. > I was hoping that ideally emacs would hold buffer-file-name's in > the sexp and let the user specify a "buffer-recovery-function" to > recover a frame state as well as buffers, so that, hypothetically, > > (restore-window-configuration-from-sexp > a-window-configuration-sexp 'live-p #'find-file-noselect) > > would restore buffers as well as a window configuration. It is the purpose of desktop.el to save and restore buffers. It provides a special "hook" `desktop-save-buffer' where packages can save their buffer info to be able to restore them later. If you don't want to use desktop.el, perhaps you could take a look at bookmark.el. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-04 16:12 ` Juri Linkov @ 2010-05-05 9:19 ` martin rudalics 2010-05-05 18:05 ` Juri Linkov ` (2 more replies) 0 siblings, 3 replies; 194+ messages in thread From: martin rudalics @ 2010-05-05 9:19 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, Emacs > The point of set-window-configuration-from-sexp is to restore the > configuration of windows, not to duplicate the functionality of desktop.el. That's true from a theoretical point of view. It separates concerns in a clear way and gives clean semantics. Hence I fully agree with you. Unfortunately, in personal practice, I'm suffering from a quite similar problem. In particular, I display eldoc output on a per-window basis in a one-line window below the code window (I hate eldoc output in the echo area, I don't like it in the header line, and I very much hate tooltips. Ideally, there would be a bottom-line right above the mode-line where I could put it, but ...). Now I'm killing such an eldoc-buffer as soon as it is no more shown in its eldoc-window. But when (1) a `save-window-excursion' restores the saved configuration and (2) it has to restore a former eldoc-window that was deleted within the body of `save-window-excursion', I get the first buffer from `buffer-list' shown in that window which is downright silly. I solved my problem by killing such stale eldoc-windows after the configuration gets restored in a `window-configuration-change-hook'. This is, however, a slight redisplay pain, in particular with such niceties as (save-window-excursion (info)) in `info-lookup'. I maybe could come up with a satisfactory solution, but deleting and creating windows in `window-configuration-change-hook' is error-prone :-( So if we could hook into this in some way, for example by providing a window parameter that tells `set-window-configuration(-from-sexp)' what to do if the buffer no longer exists, that might not be a bad idea. If the buffer had a `buffer-file-name', we could try to regenerate it automatically from that name. If the file was deleted in the meantime (or is remote or hard to find), some warning message could be displayed in a temporary buffer in the restored window. Looking up a file via bookmarks could happen here as well. If the buffer was not associated with a file, we could try to regenerate it based on the old name stored in the parameter. For killed *info* and *help* buffers probably more information would be required. All this would happen independently from desktop.el in the session version and in the sexp version. And, as noted above, this idea is not based on clean semantics but on running into practical issues. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 9:19 ` martin rudalics @ 2010-05-05 18:05 ` Juri Linkov 2010-05-06 8:21 ` martin rudalics 2010-05-05 18:19 ` Stefan Monnier 2010-05-08 3:09 ` Kevin Rodgers 2 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-05 18:05 UTC (permalink / raw To: martin rudalics; +Cc: Ken Hori, Emacs > But when (1) a `save-window-excursion' restores the saved > configuration and (2) it has to restore a former eldoc-window that was > deleted within the body of `save-window-excursion', I get the first > buffer from `buffer-list' shown in that window which is > downright silly. I agree that displaying a random buffer (that happens to be the first in `buffer-list') is silly. This problem becomes more evident when switching window configuration using tabs. Let's summarize options we have to display when the buffer saved in a window configuration is gone: 0. Display the first buffer from `buffer-list'. Yes, this is silly. 1. Add a bookmark record (that may include `buffer-file-name' and other additional data from packages via `bookmark-make-record-function') to the window parameters in the window-configuration structure. After restoring the window configuration, try to regenerate it. I think this is a bad idea, because when the user deletes the buffer, and after switching to another window configuration this buffer automagically comes back, it would be annoying. 2. Delete the buffer's window after restoring the saved window configuration. Do you see any problem with doing this in `set-window-configuration' instead of `window-configuration-change-hook'? 3. Delete the buffer's window in the saved window configuration before restoring it. This looks good if it won't break other windows in the same window configuration. 4. Display some warning message in a temporary buffer in the restored window. This is good too. It keeps the original window configuration unchanged, and provides information about the deleted buffers. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 18:05 ` Juri Linkov @ 2010-05-06 8:21 ` martin rudalics 2010-05-06 20:47 ` Juri Linkov 2010-05-10 19:16 ` Juri Linkov 0 siblings, 2 replies; 194+ messages in thread From: martin rudalics @ 2010-05-06 8:21 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, Emacs > 2. Delete the buffer's window after restoring the saved window configuration. > > Do you see any problem with doing this in `set-window-configuration' > instead of `window-configuration-change-hook'? Since window configurations store coordinates it would have to be done just before the place where `window-configuration-change-hook' is called in `set-window-configuration'. So the effect would be roughly the same. It's not perfect since the windows showing deleted buffers might take up the entire frame. > 3. Delete the buffer's window in the saved window configuration > before restoring it. > > This looks good if it won't break other windows in the same > window configuration. Hardly doable. Note that we might also have to delete internal windows, adjust coordinates or fractions ... > 4. Display some warning message in a temporary buffer in the > restored window. > > This is good too. It keeps the original window configuration unchanged, > and provides information about the deleted buffers. Suitable for user created windows. Not suitable for windows created automatically. What I really want is some sort of function `set-window-configuration' could call whenever it encounters a window with a dead buffer. As a fallback it then would try your (2) first and (4) if the window can't be deleted. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-06 8:21 ` martin rudalics @ 2010-05-06 20:47 ` Juri Linkov 2010-05-10 19:16 ` Juri Linkov 1 sibling, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-05-06 20:47 UTC (permalink / raw To: martin rudalics; +Cc: Ken Hori, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-06 8:21 ` martin rudalics 2010-05-06 20:47 ` Juri Linkov @ 2010-05-10 19:16 ` Juri Linkov 2010-05-11 7:01 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-10 19:16 UTC (permalink / raw To: martin rudalics; +Cc: Ken Hori, Emacs > What I really want is some sort of function `set-window-configuration' > could call whenever it encounters a window with a dead buffer. As a > fallback it then would try your (2) first and (4) if the window can't be > deleted. Thinking more about this, I believe now this function should be like `view-mode-exit': (view-mode-exit &optional RETURN-TO-ALIST EXIT-ACTION ALL-WIN) Exit View mode in various ways, depending on optional arguments. RETURN-TO-ALIST, EXIT-ACTION and ALL-WIN determine what to do after exit. EXIT-ACTION is nil or a function that is called with current buffer as argument. RETURN-TO-ALIST is an alist that, for some of the windows displaying the current buffer, maintains information on what to do when exiting those windows. If ALL-WIN is non-nil or the variable `view-exits-all-viewing-windows' is non-nil, view-mode-exit attempts to restore all windows showing the current buffer to their old state. Otherwise, only the selected window is affected (provided it is on RETURN-TO-ALIST). Elements of RETURN-TO-ALIST must have the format (WINDOW OLD-WINDOW . OLD-BUF-INFO) where WINDOW is a window displaying the current buffer and OLD-WINDOW is either nil or a window to select after viewing. OLD-BUF-INFO provides information on what to do with WINDOW and may be one of: 1) nil Do nothing. 2) t Delete WINDOW and, if it is the only window and `view-remove-frame-by-deleting' is non-nil, its frame. 3) (OLD-BUF START POINT) Display buffer OLD-BUF with displayed text starting at START and point at POINT in WINDOW. 4) quit-window Do `quit-window' in WINDOW. 5) keep-frame Like case 2) but do not delete the frame. If one of the WINDOW in RETURN-TO-ALIST is the selected window and the corresponding OLD-WINDOW is a live window, then select OLD-WINDOW. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-10 19:16 ` Juri Linkov @ 2010-05-11 7:01 ` martin rudalics 2010-05-11 16:45 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-11 7:01 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, Emacs > Thinking more about this, I believe now this function should be > like `view-mode-exit': I had something like this in mind. BTW, I have rewritten this code in the meantime using a window parameter called `quit-restore'. From a preliminary description ... The `quit-restore' parameter tells how to proceed with a window when the user "quits" it by invoking `quit-restore-window', see *Note Displaying Buffers::. The following non-`nil' values of this parameter have a special meaning. `t' This means to delete the associated window. By default, `t' is used for a "temporary" window that was obtained by splitting an existing window. `frame' This means to delete the associated window's frame. This value indicates that the associated windows was obtained by popping up a new frame showing just this window. If the window is no more needed, it should be deleted together with the containing frame. A list This option is useful when the associated window was borrowed to temporarily display some buffer and quitting shall "restore" the previous contents of the window. The first three elements of the list must specify a buffer, a window start position, and a window point. Quitting the window will then try to display the indicated buffer with the given start position and point in that window. The fourth element, if non-`nil', must denote a live buffer. If specified, quitting will restore the previous window contents if and only if the buffer shown in the window is the buffer named by this element. The fifth element, if non-`nil', should specify the desired height of the window when its buffer is restored. This value is applied if the buffer temporarily shown in the window was in `temp-buffer-resize-mode' to restore the original height of the window. ... and the description of `quit-restore-window' goes like ... The command described next allows to quit the window chosen by `display-buffer' and restore the previous state without undoing changes to the window configuration that happend _after_ `display-buffer' was called. A more drastic solution is to save the window configuration before calling `display-buffer' and eventually restoring the saved configuration, *Note Window Configurations::. That solution sometimes has the undesirable side-effect that all changes that happened after the configuration was saved are undone too. -- Command: quit-restore-window &optional window kill This command "quits" WINDOW restoring its previous contents if possible. The argument WINDOW must be a live window and defaults to the selected one. This function always returns `nil'. According to information stored in WINDOW's `quit-restore' window parameter (*note Window Parameters::) this function performs one of the following actions. * Delete WINDOW and its frame. This action is useful when WINDOW was created on a standalone frame and there are other frames left. * Delete WINDOW. This action is usually taken when WINDOW was obtained by splitting some existing window. * Restore the buffer previously displayed in WINDOW. This action is taken when WINDOW was temporarily reused for displaying some other buffer. * Make WINDOW display some other buffer. This action is usually taken when the three preceding ones are not applicable. If its value was non-`nil', this function resets WINDOW's `quit-restore' parameter to `nil'. If the optional argument KILL is non-`nil', this means in addition kill WINDOW's buffer. If KILL is `nil', this simply puts WINDOW's buffer at the end of the buffer list. Interactively, KILL is the prefix argument. ... where `quit-restore-window' here replaces `quit-window' which has too obscure semantics for my taste. And obviously, exiting `view-mode' calls `quit-restore-window' here too. However, restoring a window configuration is a more primitive operation than exiting `view-mode'. One of the most hairy situation occurs when you kill a buffer: There's a window of vulnerability when the `kill-buffer' routine calls `replace_buffer_in_all_windows' and the latter, for some reason, doesn't do what it has been told, for example, because a `window-configuration-change-hook' shows the buffer to be killed in some other window. Obviously, doing things like that in a configuration change hook is foolish as in (get-buffer-create "*foo*") (defun foo-lish () (let (window-configuration-change-hook) (set-window-buffer (frame-first-window) "*foo*"))) (add-hook 'window-configuration-change-hook 'foo-lish) and now doing (kill-buffer "*foo*"). But I'm not sure whether there are useful things a `window-configuration-change-hook' could do along these lines. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-11 7:01 ` martin rudalics @ 2010-05-11 16:45 ` Juri Linkov 2010-05-12 9:29 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-11 16:45 UTC (permalink / raw To: martin rudalics; +Cc: Ken Hori, Emacs > ... where `quit-restore-window' here replaces `quit-window' which has > too obscure semantics for my taste. And obviously, exiting `view-mode' > calls `quit-restore-window' here too. Yes, `quit-window' is useless because it doesn't help to avoid the mess that occurs after killing buffers. Please look at two examples: 1. +---------+---------+ | | | | dired 1 | dired 2 | | | | | | | +---------+---------+ Now view a file in dired 1, select the second window, view another file in dired 2, select the first window, quit view-mode with `q', select the second window, quit view-mode with `q': `v C-x o v C-x o q C-x o q' The window configuration is exactly as was before - very good. Now do the same without using `view-mode' - visit a file in dired 1 with RET, select the second window, visit another file in dired 2, select the first window, kill the buffer, select the second window, kill the buffer: `RET C-x o RET C-x o C-x k C-x o C-x k' The window configuration is broken with original buffers exchanged their windows: +---------+---------+ | | | | dired 2 | dired 1 | | | | | | | +---------+---------+ 2. Another example - visit the same buffer in two windows, and put point at different positions of the same buffer. +---------+---------+ | | | | dired 1 | dired 1 | | | | | | | +---------+---------+ Now view a file in the first window, and quit: `v q'. The window configuration is correctly restored (without using `set-window-configuration') - good. Now do the same without `view-mode': `RET C-x k'. Instead of the original buffer, some random buffer is displayed in this window. It seems your implementation of `quit-restore-window' will fix this problem, but I don't see how it will work without a window history as a list? This list could be saved as a window parameter `window-history' where each element is like you implemented for the `quit-restore' parameter. Then every switch-to-buffer could add a `quit-restore' element to the window history parameter, and every kill-buffer could remove it from the history stack (and call its function at the same time). -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-11 16:45 ` Juri Linkov @ 2010-05-12 9:29 ` martin rudalics 2010-05-13 22:46 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-12 9:29 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, Emacs >> ... where `quit-restore-window' here replaces `quit-window' which has >> too obscure semantics for my taste. And obviously, exiting `view-mode' >> calls `quit-restore-window' here too. > > Yes, `quit-window' is useless because it doesn't help to avoid the mess > that occurs after killing buffers. You don't mean buffers killed by `quit-window' but by some standalone `kill-buffer' I suppose? > Now do the same without using `view-mode' - visit a file in dired 1 with > RET, select the second window, visit another file in dired 2, select the > first window, kill the buffer, select the second window, kill the buffer: > > `RET C-x o RET C-x o C-x k C-x o C-x k' > > The window configuration is broken with original buffers exchanged > their windows: > > +---------+---------+ > | | | > | dired 2 | dired 1 | > | | | > | | | > +---------+---------+ The culprit here is the `other-buffer' call when unshowing the buffer. Practically all occurrences of `other-buffer' in window handling code are harmful. Their original purpose was to make sure that the same buffer isn't displayed twice on a frame I suppose. > 2. Another example - visit the same buffer in two windows, and put point > at different positions of the same buffer. > > +---------+---------+ > | | | > | dired 1 | dired 1 | > | | | > | | | > +---------+---------+ > > Now view a file in the first window, and quit: `v q'. > The window configuration is correctly restored > (without using `set-window-configuration') - good. > > Now do the same without `view-mode': `RET C-x k'. > Instead of the original buffer, some random buffer is displayed > in this window. That's probably the most annoying instance of this. For some magic reason Emacs assumes that people never want to simultaneously look at two distinct portions of the same buffer ;-) > It seems your implementation of `quit-restore-window' will fix this problem, > but I don't see how it will work without a window history as a list? It doesn't solve any of these problems yet because `dired-find-file' uses `switch-to-buffer' and in `switch-to-buffer' I don't record any information about the dired buffer. I obviously could do so easily but we'd have to find a general agreement first. And, for lack of a history, it works only for the last `display-buffer' action which is sufficient for view mode purposes (by reverting to the last buffer displayed before view mode was entered). > This list could be saved as a window parameter `window-history' where each > element is like you implemented for the `quit-restore' parameter. Yes. We have to agree that we pay for the costs of this though. > Then every switch-to-buffer could add a `quit-restore' element to the > window history parameter, We'd have to enumerate all actions that would add such an element. > and every kill-buffer could remove it from the > history stack (and call its function at the same time). `kill-buffer' would probably scan all live windows' history stacks. But are we sure that a stack (a deque, rather) is sufficient? martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-12 9:29 ` martin rudalics @ 2010-05-13 22:46 ` Juri Linkov 2010-05-14 6:59 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-13 22:46 UTC (permalink / raw To: martin rudalics; +Cc: Ken Hori, Emacs >>> ... where `quit-restore-window' here replaces `quit-window' which has >>> too obscure semantics for my taste. And obviously, exiting `view-mode' >>> calls `quit-restore-window' here too. >> >> Yes, `quit-window' is useless because it doesn't help to avoid the mess >> that occurs after killing buffers. > > You don't mean buffers killed by `quit-window' but by some standalone > `kill-buffer' I suppose? I mean `quit-window' with non-nil argument KILL. When its argument KILL is nil (when the buffer is buried), the problem is the same. > The culprit here is the `other-buffer' call when unshowing the buffer. > Practically all occurrences of `other-buffer' in window handling code > are harmful. Their original purpose was to make sure that the same > buffer isn't displayed twice on a frame I suppose. Yes, and occurrences of `(car (buffer-list))' are harmful too. > It doesn't solve any of these problems yet because `dired-find-file' > uses `switch-to-buffer' and in `switch-to-buffer' I don't record any > information about the dired buffer. I obviously could do so easily but > we'd have to find a general agreement first. > > And, for lack of a history, it works only for the last `display-buffer' > action which is sufficient for view mode purposes (by reverting to the > last buffer displayed before view mode was entered). It is sufficient because it stores this information in the buffer-local variable `view-return-to-alist'. I don't think a similar variable would help for other non-view buffers because it is specific to windows, not to buffers. So it seems a window parameter is more suitable. >> Then every switch-to-buffer could add a `quit-restore' element to the >> window history parameter, > > We'd have to enumerate all actions that would add such an element. I think it should be every action that changes the window's buffer. >> and every kill-buffer could remove it from the >> history stack (and call its function at the same time). > > `kill-buffer' would probably scan all live windows' history stacks. No need to scan all windows' history stacks. During restoring the saved state from the stack, we could drop elements with killed buffers and continue popping the stack until we find an element with a live buffer. > But are we sure that a stack (a deque, rather) is sufficient? I think this window parameter should be treated like the frame parameter `buffer-list'. E.g. `other-buffer' prefers selected frame's buffer list instead of the global buffer list, etc. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-13 22:46 ` Juri Linkov @ 2010-05-14 6:59 ` martin rudalics 2010-05-16 22:51 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-14 6:59 UTC (permalink / raw To: Juri Linkov; +Cc: Ken Hori, Emacs >> The culprit here is the `other-buffer' call when unshowing the buffer. >> Practically all occurrences of `other-buffer' in window handling code >> are harmful. Their original purpose was to make sure that the same >> buffer isn't displayed twice on a frame I suppose. > > Yes, and occurrences of `(car (buffer-list))' are harmful too. Obviously. It just makes it more difficult grepping them. > It is sufficient because it stores this information in the buffer-local > variable `view-return-to-alist'. I don't think a similar variable > would help for other non-view buffers because it is specific to windows, > not to buffers. So it seems a window parameter is more suitable. What I meant is this: With view-mode the variable is useful in the sense that when I exit view-mode I get the last non-view-mode buffer shown in that window. For commands like "show me the last meaningful view-mode buffer when I'm already in view mode" or "show me the last meaningful non-view-mode buffer when I'm not in view-mode" I need a stack where to pop that buffer from. >>> Then every switch-to-buffer could add a `quit-restore' element to the >>> window history parameter, >> We'd have to enumerate all actions that would add such an element. > > I think it should be every action that changes the window's buffer. And these should all boil down to `set-window-buffer' calls. > No need to scan all windows' history stacks. During restoring the saved > state from the stack, we could drop elements with killed buffers and > continue popping the stack until we find an element with a live buffer. OK. If we put an upper limit on the size of such stacks, stale entries will get removed automatically after some time. > I think this window parameter should be treated like the frame parameter > `buffer-list'. E.g. `other-buffer' prefers selected frame's buffer list > instead of the global buffer list, etc. We'd have to specify the meaning of "prefers" here. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-14 6:59 ` martin rudalics @ 2010-05-16 22:51 ` Juri Linkov 2010-05-17 9:06 ` martin rudalics 2010-05-31 17:28 ` martin rudalics 0 siblings, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-05-16 22:51 UTC (permalink / raw To: martin rudalics; +Cc: Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-16 22:51 ` Juri Linkov @ 2010-05-17 9:06 ` martin rudalics 2010-05-17 22:54 ` Juri Linkov 2010-05-31 17:28 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-17 9:06 UTC (permalink / raw To: Juri Linkov; +Cc: Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-17 9:06 ` martin rudalics @ 2010-05-17 22:54 ` Juri Linkov 2010-05-18 12:07 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-17 22:54 UTC (permalink / raw To: martin rudalics; +Cc: Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-17 22:54 ` Juri Linkov @ 2010-05-18 12:07 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-05-18 12:07 UTC (permalink / raw To: Juri Linkov; +Cc: Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-16 22:51 ` Juri Linkov 2010-05-17 9:06 ` martin rudalics @ 2010-05-31 17:28 ` martin rudalics 2010-05-31 18:39 ` Stefan Monnier 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-31 17:28 UTC (permalink / raw To: Juri Linkov; +Cc: Emacs > In the functions `buffer-list' and `other-buffer' the buffers in the > selected frame's `buffer-list' come first, followed by the rest of the > buffers from the global value of `buffer-list', and buffers from the > selected frame's parameters `buried-buffer-list' come last. > > Doing the same for the window-local parameter `buffer-list', > i.e. when `buffer-list' will return a list composed of > > window-local buffer-list > frame-local buffer-list > global buffer-list > frame-local buried-buffer-list > window-local buried-buffer-list > > then `quit-window' and all occurrences of `other-buffer' > in window handling code should do the right thing like > `view-return-to-alist' does (i.e. to get the right buffer). I've been looking into this now. `buffer-list' and `other-buffer' are currently in pretty bad shape so it's occasionally difficult to tell what they are supposed to do. Anyway, the three major obstacles to your approach seem: (1) All calls to `other-buffer' for determining which buffer to show in a window have the second argument nil. So if a buffer is already shown in another window it's against some unwritten rule to show it in the window in question again. If I follow that rule, then working with two windows showing the same buffer remains just as tedious as it is now. (2) The length of frame-local buffer-lists is unbound. For a one-frame user this already doubles the consing and maintenance overhead of buffer lists without any gain. If we add window-local buffer-lists, we'd double the current overhead once more for one window/one frame users. (3) For each buffer on the window-local buffer-list I'd have to maintain its old point and its old window start position as markers. Otherwise restoring the buffer would either get me a silly position if the buffer was modified in the meantime (a rare case probably, but unacceptable nevertheless) or a useless position like `point' (which would usually coincide with `window-point' of some other window showing that buffer). This means that for each buffer we get as many additional markers as there are live windows in which the buffer was shown (times two). martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 17:28 ` martin rudalics @ 2010-05-31 18:39 ` Stefan Monnier 2010-05-31 19:12 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 194+ messages in thread From: Stefan Monnier @ 2010-05-31 18:39 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > (1) All calls to `other-buffer' for determining which buffer to show in > a window have the second argument nil. So if a buffer is already shown > in another window it's against some unwritten rule to show it in the > window in question again. If I follow that rule, then working with two > windows showing the same buffer remains just as tedious as it is now. Yes, the window handling code currently considers that the most likely thing the user wants is to see a buffer that's not currently shown. [ I'm not sure if it's careful to distinguish "shown on the current terminal" from "shown in some other terminal, miles away from here", which it should. ] This seems like a good default rule, so if we/you want to not follow this rule in some cases, we should think about how we can tell which is the better choice in a given situation. > (2) The length of frame-local buffer-lists is unbound. For a one-frame > user this already doubles the consing and maintenance overhead of buffer > lists without any gain. If we add window-local buffer-lists, we'd > double the current overhead once more for one window/one frame users. Is this overhead really significant? Say the list is 100 buffers long, that's 1 or 2 KB, right? Isn't this lost in the noise? > (3) For each buffer on the window-local buffer-list I'd have to maintain > its old point and its old window start position as markers. Otherwise > restoring the buffer would either get me a silly position if the buffer > was modified in the meantime (a rare case probably, but unacceptable > nevertheless) or a useless position like `point' (which would usually > coincide with `window-point' of some other window showing that buffer). > This means that for each buffer we get as many additional markers as > there are live windows in which the buffer was shown (times two). The use of `point' for that has not brought many complaints over the many years it's been used. Any reason to think it's a bad choice? Stefan "who coded up a hack for doc-view which preserves window-specific buffer-positions" ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 18:39 ` Stefan Monnier @ 2010-05-31 19:12 ` Lennart Borgman 2010-05-31 20:23 ` Juri Linkov 2010-06-01 9:24 ` martin rudalics 2010-05-31 20:19 ` Juri Linkov 2010-06-01 9:24 ` martin rudalics 2 siblings, 2 replies; 194+ messages in thread From: Lennart Borgman @ 2010-05-31 19:12 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, martin rudalics, Emacs On Mon, May 31, 2010 at 8:39 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > The use of `point' for that has not brought many complaints over the > many years it's been used. Any reason to think it's a bad choice? Could that be because people are using winpoint.el instead of complaining. At least that is what I do. But I really think Emacs should solve this internally by using window-point instead of point. winpoint is nice but does not solve the whole problem (and it may interfere badly with other code for window configuration, perhaps). ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 19:12 ` Lennart Borgman @ 2010-05-31 20:23 ` Juri Linkov 2010-06-01 9:24 ` martin rudalics 1 sibling, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-05-31 20:23 UTC (permalink / raw To: Lennart Borgman; +Cc: martin rudalics, Stefan Monnier, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 19:12 ` Lennart Borgman 2010-05-31 20:23 ` Juri Linkov @ 2010-06-01 9:24 ` martin rudalics 1 sibling, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-06-01 9:24 UTC (permalink / raw To: Lennart Borgman; +Cc: Juri Linkov, Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 18:39 ` Stefan Monnier 2010-05-31 19:12 ` Lennart Borgman @ 2010-05-31 20:19 ` Juri Linkov 2010-06-01 3:13 ` Stefan Monnier 2010-06-01 9:24 ` martin rudalics 2 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-05-31 20:19 UTC (permalink / raw To: Stefan Monnier; +Cc: martin rudalics, Emacs >> (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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 20:19 ` Juri Linkov @ 2010-06-01 3:13 ` Stefan Monnier 2010-06-01 9:25 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-01 3:13 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 3:13 ` Stefan Monnier @ 2010-06-01 9:25 ` martin rudalics 2010-06-01 12:58 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-01 9:25 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 9:25 ` martin rudalics @ 2010-06-01 12:58 ` Stefan Monnier 0 siblings, 0 replies; 194+ messages in thread From: Stefan Monnier @ 2010-06-01 12:58 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-31 18:39 ` Stefan Monnier 2010-05-31 19:12 ` Lennart Borgman 2010-05-31 20:19 ` Juri Linkov @ 2010-06-01 9:24 ` martin rudalics 2010-06-01 13:08 ` Stefan Monnier ` (2 more replies) 2 siblings, 3 replies; 194+ messages in thread From: martin rudalics @ 2010-06-01 9:24 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs >> (1) All calls to `other-buffer' for determining which buffer to show in >> a window have the second argument nil. So if a buffer is already shown >> in another window it's against some unwritten rule to show it in the >> window in question again. If I follow that rule, then working with two >> windows showing the same buffer remains just as tedious as it is now. > > Yes, the window handling code currently considers that the most likely > thing the user wants is to see a buffer that's not currently shown. > [ I'm not sure if it's careful to distinguish "shown on the current > terminal" from "shown in some other terminal, miles away from here", > which it should. ] It's not that careful. > This seems like a good default rule, so if we/you want to not follow > this rule in some cases, The case at hand was a scenario earlier posted by Juri as ... ------------------------------------------------------------------------ 2. Another example - visit the same buffer in two windows, and put point at different positions of the same buffer. +---------+---------+ | | | | dired 1 | dired 1 | | | | | | | +---------+---------+ Now view a file in the first window, and quit: `v q'. The window configuration is correctly restored (without using `set-window-configuration') - good. Now do the same without `view-mode': `RET C-x k'. Instead of the original buffer, some random buffer is displayed in this window. ------------------------------------------------------------------------ ... which, together with another scenario, triggered the present discussion. > we should think about how we can tell which is > the better choice in a given situation. We could make this customizable. >> (2) The length of frame-local buffer-lists is unbound. For a one-frame >> user this already doubles the consing and maintenance overhead of buffer >> lists without any gain. If we add window-local buffer-lists, we'd >> double the current overhead once more for one window/one frame users. > > Is this overhead really significant? Say the list is 100 buffers long, > that's 1 or 2 KB, right? Isn't this lost in the noise? Look at the following stretch from `other-buffer': tail = Vbuffer_alist; pred = frame_buffer_predicate (frame); /* Consider buffers that have been seen in the selected frame before other buffers. */ tem = frame_buffer_list (frame); add_ons = Qnil; while (CONSP (tem)) { if (BUFFERP (XCAR (tem))) add_ons = Fcons (Fcons (Qnil, XCAR (tem)), add_ons); tem = XCDR (tem); } tail = nconc2 (Fnreverse (add_ons), tail); This prepends a list of (nil . buffer) conses for every non-buried buffer on the selected frame (or some specified frame) to the list of all buffers. Note that reusing a window in `display-buffer' doesn't bury the previous buffer. Now for one-frame Emacs users this means that its consing overhead is usually always proportional to the number of live buffers. Given the fact that `bury-buffer' (and thus `next-buffer') and evaluating the `b' and `B' interactive arguments all call `other-buffer' this makes me think that some GC overhead result. It shouldn't be too hard to fix this. [`other-buffer' has not been coded very cleanly, just try evaluating (other-buffer nil nil 1) in a _separate_ instance of Emacs.] Similar problems exist for `buffer-list' and `last-buffer'. >> (3) For each buffer on the window-local buffer-list I'd have to maintain >> its old point and its old window start position as markers. Otherwise >> restoring the buffer would either get me a silly position if the buffer >> was modified in the meantime (a rare case probably, but unacceptable >> nevertheless) or a useless position like `point' (which would usually >> coincide with `window-point' of some other window showing that buffer). >> This means that for each buffer we get as many additional markers as >> there are live windows in which the buffer was shown (times two). > > The use of `point' for that has not brought many complaints over the > many years it's been used. Any reason to think it's a bad choice? It's a bad choice if you show a buffer in two windows W1 and W2, temporaily show another buffer in W2, select W1, and switch back to the original buffer in W2. The whole "point" of showing the same buffer in two windows is lost. Note that if the temporarily displayed buffer is in view or help mode you don't have this problem since `view-mode-exit' handles the case. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 9:24 ` martin rudalics @ 2010-06-01 13:08 ` Stefan Monnier 2010-06-01 14:02 ` Lennart Borgman 2010-06-01 16:04 ` martin rudalics 2010-06-01 19:51 ` Juri Linkov 2010-06-03 18:52 ` Juri Linkov 2 siblings, 2 replies; 194+ messages in thread From: Stefan Monnier @ 2010-06-01 13:08 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > +---------+---------+ > | | | > | 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 13:08 ` Stefan Monnier @ 2010-06-01 14:02 ` Lennart Borgman 2010-06-01 16:04 ` martin rudalics 1 sibling, 0 replies; 194+ messages in thread From: Lennart Borgman @ 2010-06-01 14:02 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, martin rudalics, Emacs On Tue, Jun 1, 2010 at 3:08 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > No, we want instead to try and think in each case which behavior would > make more sense. And maybe you're right that in "all" cases, trying to > restore the previous window state is TRT, rather than choosing some > non-shown buffer. Maybe something like this: 1) Save window config when running a command that changes window config (and not does it as a user request). 2) Keep this around until either: - It is used. - A user request changes the window configuration. - 1 is applied again. (No stack.) ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 13:08 ` Stefan Monnier 2010-06-01 14:02 ` Lennart Borgman @ 2010-06-01 16:04 ` martin rudalics 2010-06-01 19:20 ` Stefan Monnier 2010-06-01 19:54 ` Juri Linkov 1 sibling, 2 replies; 194+ messages in thread From: martin rudalics @ 2010-06-01 16:04 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > So you're saying that C-x k's heuristic should be to try and restore the > previous window state? I guess that could make sense, yes. I was saying that _if_ we want to fix the behavior to handle Juri's case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or something the like). >> We could make this customizable. > > No, we want instead to try and think in each case which behavior would > make more sense. We probably all agree that a window should not show a buffer visible elsewhere when its buffer is killed or buried and its window-local buffer list contains no other buffer. Maybe we also agree that we should show such a buffer when the window was "stolen" by a construct like `with-temp-buffer'. However, I'm afraid that there's no good approximation for the remaining cases. There are people used to edit large buffers by showing related sections in two or more windows. And there are people who don't do that. [The latter group should not be affected much by the new behavior since we expect them to never show the same buffer twice at the same time. But I'm not sure whether the use of `split-window' runs counter to such an assumption.] > And maybe you're right that in "all" cases, trying to > restore the previous window state is TRT, rather than choosing some > non-shown buffer. I cannot be right since I never proposed that ;-) martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 16:04 ` martin rudalics @ 2010-06-01 19:20 ` Stefan Monnier 2010-06-02 12:59 ` martin rudalics 2010-06-01 19:54 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-01 19:20 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs >>> We could make this customizable. >> No, we want instead to try and think in each case which behavior would >> make more sense. > We probably all agree that a window should not show a buffer visible > elsewhere when its buffer is killed or buried and its window-local > buffer list contains no other buffer. Makes sense, yes/ > Maybe we also agree that we should show such a buffer when the window > was "stolen" by a construct like `with-temp-buffer'. with-temp-buffer is probably a poor example since it doesn't affect windows, but if you mean something like with-output-to-temp-buffer, then yes, we probably all agree. > However, I'm afraid that there's no good approximation for the remaining > cases. There are people used to edit large buffers by showing related > sections in two or more windows. And there are people who don't do > that. [The latter group should not be affected much by the new behavior > since we expect them to never show the same buffer twice at the same > time. But I'm not sure whether the use of `split-window' runs counter > to such an assumption.] We can solve each case as it shows up. E.g. for the split-window case (i.e. buffer shown in 2 windows only because that's what split-window does, but the user then immediately switches to some other buffer), we should try and find a way to capture the user's intention. E.g. "immediately" after split-window, any set-window-buffer will not push the current buffer on the buffer-list of that window. >> And maybe you're right that in "all" cases, trying to restore the >> previous window state is TRT, rather than choosing some >> non-shown buffer. > I cannot be right since I never proposed that ;-) I thought you suggested to have a config var to decide whether to use the current heuristic, or to use another heuristic which prefers buffers from the window's buffer-list regardless of whether they are shown elsewhere. Isn't that what you meant in: >> we should think about how we can tell which is >> the better choice in a given situation. > We could make this customizable. -- Stefan ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 19:20 ` Stefan Monnier @ 2010-06-02 12:59 ` martin rudalics 2010-06-02 14:08 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-02 12:59 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs >> Maybe we also agree that we should show such a buffer when the window >> was "stolen" by a construct like `with-temp-buffer'. > > with-temp-buffer is probably a poor example since it doesn't affect > windows, but if you mean something like with-output-to-temp-buffer, That's what I meant. > then > yes, we probably all agree. Tracing `with-output-to-temp-buffer' is a pain. I suppose temp_output_buffer_show needs some reserved value for the second argument of `display-buffer' so the latter can set up the window-local buffer list appropriately. > We can solve each case as it shows up. E.g. for the split-window case > (i.e. buffer shown in 2 windows only because that's what split-window > does, but the user then immediately switches to some other buffer), we > should try and find a way to capture the user's intention. That's precisely the case I had in mind. I have no idea how and why people use `split-window'. Hardly always to show the same buffer twice. But I don't even know how I use it myself. > E.g. "immediately" after split-window, any set-window-buffer will not > push the current buffer on the buffer-list of that window. Aren't there too many ways to make this `set-window-buffer' happen? One of the simplest is `next-buffer' which does `bury-buffer' for the old buffer so it won't create any problems. But what if the user decides to consult some buffer switching application that pops up a window with suggestions? > I thought you suggested to have a config var to decide whether to use > the current heuristic, or to use another heuristic which prefers buffers > from the window's buffer-list regardless of whether they are > shown elsewhere. Isn't that what you meant in: > > >> we should think about how we can tell which is > >> the better choice in a given situation. > > We could make this customizable. Not really. I want to avoid that changing the established behavior causes people who do not care anyway ask for getting the old behavior back. If we make this customizable we can concentrate on the criticism of people who really do care. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-02 12:59 ` martin rudalics @ 2010-06-02 14:08 ` Stefan Monnier 2010-06-03 8:55 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-02 14:08 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-02 14:08 ` Stefan Monnier @ 2010-06-03 8:55 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-06-03 8:55 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 16:04 ` martin rudalics 2010-06-01 19:20 ` Stefan Monnier @ 2010-06-01 19:54 ` Juri Linkov 2010-06-02 13:00 ` martin rudalics 2010-06-14 17:05 ` martin rudalics 1 sibling, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-01 19:54 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> So you're saying that C-x k's heuristic should be to try and restore >> the previous window state? I guess that could make sense, yes. > > I was saying that _if_ we want to fix the behavior to handle Juri's > case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or > something the like). I think changing the argument VISIBLE_OK won't help. The existing calls of `other-buffer' (where VISIBLE_OK is nil) should keep the current behavior of `other-buffer' that prefers not visible buffers to visible buffers (when the window-local buffer-list is empty). >>> We could make this customizable. >> >> No, we want instead to try and think in each case which behavior would >> make more sense. > > We probably all agree that a window should not show a buffer visible > elsewhere when its buffer is killed or buried and its window-local > buffer list contains no other buffer. Yes, without making this customizable, a simple rule could be to get next buffers from the window-local buffer-list when it is non-empty. > However, I'm afraid that there's no good approximation for the remaining > cases. There are people used to edit large buffers by showing related > sections in two or more windows. And there are people who don't do > that. [The latter group should not be affected much by the new behavior > since we expect them to never show the same buffer twice at the same > time. But I'm not sure whether the use of `split-window' runs counter > to such an assumption.] I see no problem if we will push the current buffer to the window-local buffer-list in the same places in code where currently the buffer is pushed to the frame-local buffer-list (and buried-buffer-list). -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 19:54 ` Juri Linkov @ 2010-06-02 13:00 ` martin rudalics 2010-06-02 19:46 ` Juri Linkov 2010-06-14 17:05 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-02 13:00 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-02 13:00 ` martin rudalics @ 2010-06-02 19:46 ` Juri Linkov 2010-06-03 8:55 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-02 19:46 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-02 19:46 ` Juri Linkov @ 2010-06-03 8:55 ` martin rudalics 2010-06-03 18:55 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-03 8:55 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >>> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 8:55 ` martin rudalics @ 2010-06-03 18:55 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-03 18:55 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 19:54 ` Juri Linkov 2010-06-02 13:00 ` martin rudalics @ 2010-06-14 17:05 ` martin rudalics 2010-06-14 21:54 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-14 17:05 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >>> So you're saying that C-x k's heuristic should be to try and restore >>> the previous window state? I guess that could make sense, yes. >> I was saying that _if_ we want to fix the behavior to handle Juri's >> case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or >> something the like). > > I think changing the argument VISIBLE_OK won't help. The existing > calls of `other-buffer' (where VISIBLE_OK is nil) should keep the > current behavior of `other-buffer' that prefers not visible buffers > to visible buffers (when the window-local buffer-list is empty). Sorry, I don't get you here. Reconsider your earlier example: ------------------------------------------------------------------------ 2. Another example - visit the same buffer in two windows, and put point at different positions of the same buffer. +---------+---------+ | | | | dired 1 | dired 1 | | | | | | | +---------+---------+ Now view a file in the first window, and quit: `v q'. The window configuration is correctly restored (without using `set-window-configuration') - good. Now do the same without `view-mode': `RET C-x k'. Instead of the original buffer, some random buffer is displayed in this window. ------------------------------------------------------------------------ Doing C-x k currently winds up calling replace_buffer_in_all_windows (buffer); which calls Fother_buffer (w->buffer, Qnil, w->frame) so a visible buffer will not be put into that window. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-14 17:05 ` martin rudalics @ 2010-06-14 21:54 ` Juri Linkov 2010-06-15 7:08 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-14 21:54 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-14 21:54 ` Juri Linkov @ 2010-06-15 7:08 ` martin rudalics 2010-06-15 21:31 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-15 7:08 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-15 7:08 ` martin rudalics @ 2010-06-15 21:31 ` Juri Linkov 2010-06-16 17:25 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-15 21:31 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-15 21:31 ` Juri Linkov @ 2010-06-16 17:25 ` martin rudalics 2010-06-16 20:51 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-16 17:25 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-16 17:25 ` martin rudalics @ 2010-06-16 20:51 ` Juri Linkov 2010-06-17 7:58 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-16 20:51 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-16 20:51 ` Juri Linkov @ 2010-06-17 7:58 ` martin rudalics 2010-06-17 8:42 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-17 7:58 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > If we don't know the target window in advance, then we can't use > the window-local buffer-list for `read-buffer-to-switch'. In `switch-to-buffer' we usually know the target window. In `switch-to-buffer-other-window' we don't. How distinguish the two? But I'm afraid that the idea of handling window local buffer lists just like the other buffer lists is flawed anyway. For example, when I display a buffer without selecting the window as in `with-output-to-temp-buffer' I do want to update the window local buffer list. When I do `bury-buffer' and the buffer is not displayed in the selected but maybe some other window the buffer will get buried in the selected window and remains the first buffer in the other window. Both make hardly sense either (and are flawed for frame local buffer lists as well). I suppose that for the moment I'll abandon the idea of window local buffer lists and return to them after I have solved some other issues. > This means that you need to store more information for the first > element of the window-local buffer-list, i.e. when popping the > stack of buffers reaches the first element, it should know what to do > after popping the last element: whether to kill the window and > which window to select instead. The problem is that the information contained there might be already stale (the user might have done a lot of things in between). For help windows it makes sense to check whether the window still displays the help buffer and only if it does I proceed according to the information stored in the window parameter. For arbitrary buffers in non-dedicated windows I might just violate the principle of least surprise. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-17 7:58 ` martin rudalics @ 2010-06-17 8:42 ` Juri Linkov 2010-06-17 10:20 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-17 8:42 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > (and are flawed for frame local buffer lists as well). If frame-local buffer-lists are flawed, they should be fixed. But I think window-local buffer-lists should be modelled after frame-local buffer-lists. A frame-local buffer-list is a frame parameter, so a window-local buffer-list could be a window parameter, with more information associated with every element (window-start, window-point, quit-restore function). > I suppose that for the moment I'll abandon the idea of window local > buffer lists and return to them after I have solved some other issues. You will need window-local buffer-lists anyway to correctly restore previous places when quitting the window. IOW, instead of `quit-restore-window' parameter (that saves only 1 previous place), you can add a window parameter `buffer-list' (and use it to restore previous places when quitting) that later could combine its values with frame-local `buffer-list' and global `buffer-list' for the function `(buffer-list)'. > The problem is that the information contained there might be already > stale (the user might have done a lot of things in between). For help > windows it makes sense to check whether the window still displays the > help buffer and only if it does I proceed according to the information > stored in the window parameter. For arbitrary buffers in non-dedicated > windows I might just violate the principle of least surprise. I see no such problems for `view-return-to-alist', so maybe it won't a problem for other buffers too. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-17 8:42 ` Juri Linkov @ 2010-06-17 10:20 ` martin rudalics 2010-06-17 20:38 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-17 10:20 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > If frame-local buffer-lists are flawed, they should be fixed. > But I think window-local buffer-lists should be modelled after > frame-local buffer-lists. A frame-local buffer-list is a frame > parameter, ... implemented within the frame structure ... > so a window-local buffer-list could be a window parameter, > with more information associated with every element (window-start, > window-point, quit-restore function). > >> I suppose that for the moment I'll abandon the idea of window local >> buffer lists and return to them after I have solved some other issues. > > You will need window-local buffer-lists anyway to correctly restore > previous places when quitting the window. IOW, instead of > `quit-restore-window' parameter (that saves only 1 previous place), > you can add a window parameter `buffer-list' (and use it to restore > previous places when quitting) that later could combine its values > with frame-local `buffer-list' and global `buffer-list' for the > function `(buffer-list)'. Yes. But my `quit-restore-window' parameter was a very simple start. It doesn't use markers and doesn't do much when a window's buffer no longer equals that specified in the parameter. OTOH, `view-mode' has other pitfalls like the need for copying the parameter when splitting the window. >> The problem is that the information contained there might be already >> stale (the user might have done a lot of things in between). For help >> windows it makes sense to check whether the window still displays the >> help buffer and only if it does I proceed according to the information >> stored in the window parameter. For arbitrary buffers in non-dedicated >> windows I might just violate the principle of least surprise. > > I see no such problems for `view-return-to-alist', so maybe it won't > a problem for other buffers too. It does not have problems because you do it via `View-quit', hence the window is probably still the same window showing the same buffer. If you switch to another buffer in an earlier popped up help window, then having a later `unbury-buffer' delete that window might be surprising. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-17 10:20 ` martin rudalics @ 2010-06-17 20:38 ` Juri Linkov 2010-06-17 22:55 ` Lennart Borgman 2010-06-18 6:34 ` martin rudalics 0 siblings, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-17 20:38 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-17 20:38 ` Juri Linkov @ 2010-06-17 22:55 ` Lennart Borgman 2010-06-18 6:34 ` martin rudalics 1 sibling, 0 replies; 194+ messages in thread From: Lennart Borgman @ 2010-06-17 22:55 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, Stefan Monnier, Emacs On Thu, Jun 17, 2010 at 10:38 PM, Juri Linkov <juri@jurta.org> wrote: >>> I see no such problems for `view-return-to-alist', so maybe it won't >>> a problem for other buffers too. >> >> It does not have problems because you do it via `View-quit', hence the >> window is probably still the same window showing the same buffer. If >> you switch to another buffer in an earlier popped up help window, then >> having a later `unbury-buffer' delete that window might be surprising. > > I'm not sure this will be surprising because it will delete the window > when the Help buffer is displayed in it, not with some other buffer. > So when I see the Help buffer and type `q', I expect that it will delete > that window. Yes, if helped opened it. But not if help was just displayed in that window. Then I expect q to remove help and show what was there before. I simply expect q to restore the state if it is possible. However on thing that has disturbed me is that for example window configurations are restored after I have made changes to the temporary window configuration. That does not seem useful (except in the case of debugging which is very different). ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-17 20:38 ` Juri Linkov 2010-06-17 22:55 ` Lennart Borgman @ 2010-06-18 6:34 ` martin rudalics 2010-06-18 8:28 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-18 6:34 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> It does not have problems because you do it via `View-quit', hence the >> window is probably still the same window showing the same buffer. If >> you switch to another buffer in an earlier popped up help window, then >> having a later `unbury-buffer' delete that window might be surprising. > > I'm not sure this will be surprising because it will delete the window > when the Help buffer is displayed in it, not with some other buffer. > So when I see the Help buffer and type `q', I expect that it will delete > that window. My description was unclear. I meant: (1) Pop up the help window. (2) In that window display some other buffer. (3) Kill that other buffer. What Emacs now shall do with the window is unclear. If it does delete the window and step (3) happens some time after (1) the effect will be strange because the user already has forgotten about (1). If it does not delete the window the case where my step (3) is rewritten as (3') Switch back to the help buffer. will not delete the window. I solve this problem currently by checking whether the buffer in (3) is the buffer displayed by (1). But this doesn't solve the problem when (2) and (3) appear as (2") Reuse the window to display info. (3") Quit info. which likely should delete the window. [Note that making the help window weakly dedicated in step (1) will currently have (2") fail.] martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-18 6:34 ` martin rudalics @ 2010-06-18 8:28 ` Juri Linkov 2010-06-18 9:04 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-18 8:28 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > My description was unclear. I meant: > > (1) Pop up the help window. > > (2) In that window display some other buffer. > > (3) Kill that other buffer. > > What Emacs now shall do with the window is unclear. Of course, it should switch back to the help buffer without deleting the window. > (2") Reuse the window to display info. > > (3") Quit info. > > which likely should delete the window. 3" should not delete the window. Everything should work exactly as it already works in the simplest case: (0) Run `emacs -Q'. (1) Pop up the help window. `C-h f car RET C-x o' (2) Reuse the window to display info. `C-h i' (3) In that window display some other buffer. `C-h C-t' (4) Kill that other buffer. `C-x k RET' The previous buffer "*info*" is displayed in this window. (5) Quit info. `q' The previous buffer "*Help*" is displayed in this window. (6) Type `q' The window is deleted. IOW, we should not invent a new behavior, just fix some cases (that I mentioned earlier where selecting another windows messes up the global buffer list and thus detaches the buffer from its original window). I believe that using a window parameter `buffer-list' will help to fix this. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-18 8:28 ` Juri Linkov @ 2010-06-18 9:04 ` martin rudalics 2010-06-19 8:50 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-18 9:04 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-18 9:04 ` martin rudalics @ 2010-06-19 8:50 ` Juri Linkov 2010-06-19 13:47 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-19 8:50 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >>> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-19 8:50 ` Juri Linkov @ 2010-06-19 13:47 ` martin rudalics 2010-06-19 14:12 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-19 13:47 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-19 13:47 ` martin rudalics @ 2010-06-19 14:12 ` Juri Linkov 2010-06-19 18:56 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-19 14:12 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-19 14:12 ` Juri Linkov @ 2010-06-19 18:56 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-06-19 18:56 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 9:24 ` martin rudalics 2010-06-01 13:08 ` Stefan Monnier @ 2010-06-01 19:51 ` Juri Linkov 2010-06-02 13:00 ` martin rudalics 2010-06-03 18:52 ` Juri Linkov 2 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-01 19:51 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 19:51 ` Juri Linkov @ 2010-06-02 13:00 ` martin rudalics 2010-06-02 19:49 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-02 13:00 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-02 13:00 ` martin rudalics @ 2010-06-02 19:49 ` Juri Linkov 2010-06-03 8:57 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-02 19:49 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >>> Similar problems exist for `buffer-list' and `last-buffer'. >> >> I don't see the same problem in `buffer-list' because it has >> guards `FRAMEP (frame)' and `CHECK_FRAME (frame)'. > > Try evaluating > > (let ((list (list "*scratch*"))) > (set-frame-parameter nil 'buffer-list (setcdr list list)) > (buffer-list (selected-frame))) This is unfair ;-) You can break almost everything with a cyclic list. However, I'd like to fix the invalid frame case for `(other-buffer nil nil 1)' with: === modified file 'src/buffer.c' --- src/buffer.c 2010-05-27 23:30:11 +0000 +++ src/buffer.c 2010-06-02 19:49:04 +0000 @@ -1299,6 +1299,7 @@ (at your option) any later version. if (NILP (frame)) frame = selected_frame; + CHECK_FRAME (frame); tail = Vbuffer_alist; pred = frame_buffer_predicate (frame); -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-02 19:49 ` Juri Linkov @ 2010-06-03 8:57 ` martin rudalics 2010-06-03 14:22 ` Stefan Monnier 2010-06-03 18:54 ` Juri Linkov 0 siblings, 2 replies; 194+ messages in thread From: martin rudalics @ 2010-06-03 8:57 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> (let ((list (list "*scratch*"))) >> (set-frame-parameter nil 'buffer-list (setcdr list list)) >> (buffer-list (selected-frame))) > > This is unfair ;-) You can break almost everything with a cyclic list. But usually you can quit via C-g. This case has a special history: Once upon a time Vbuffer_alist "used to be a variable, but is no longer, to prevent lossage due to user rplac'ing this alist or its elements". Then eventually Richard decided to "not use Frassq, Fmemq or Fdelq since their loops allow quitting. Write a special loop by hand." which was still OK because Vbuffer_alist was no longer accessible from Elisp. Next we got frame local buffer lists and finally someone decided to allow setting a frame's buffer list from Elisp ... I think two things have to be done here: Remove the special constructs that don't allow quitting. They are hardly useful today. Moreover, there are routines operating on buffer lists that _do allow quitting_ like unrecord_buffer so the original motivation is moot anyway (unless we want unrecord_buffer use a construct like record_buffer). In addition we should disallow changing a frame's buffer and buried buffer lists by setting the corresponding frame's parameter. I think this was part of an attempt to make each and every frame related object part of a frame's parameters. But an application should not be allowed to alter the history of buffers shown on a particular frame. Let's leave such activities to politicians - that's what they get paid for. > However, I'd like to fix the invalid frame case for > `(other-buffer nil nil 1)' with: [...] Elementary. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 8:57 ` martin rudalics @ 2010-06-03 14:22 ` Stefan Monnier 2010-06-03 15:42 ` martin rudalics 2010-06-04 10:36 ` Richard Stallman 2010-06-03 18:54 ` Juri Linkov 1 sibling, 2 replies; 194+ messages in thread From: Stefan Monnier @ 2010-06-03 14:22 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 14:22 ` Stefan Monnier @ 2010-06-03 15:42 ` martin rudalics 2010-06-04 13:11 ` Stefan Monnier 2010-06-04 10:36 ` Richard Stallman 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-03 15:42 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 15:42 ` martin rudalics @ 2010-06-04 13:11 ` Stefan Monnier 2010-06-04 14:07 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-04 13:11 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs >>> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 13:11 ` Stefan Monnier @ 2010-06-04 14:07 ` martin rudalics 2010-06-04 16:59 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-04 14:07 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 14:07 ` martin rudalics @ 2010-06-04 16:59 ` Juri Linkov 2010-06-05 12:49 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-04 16:59 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 16:59 ` Juri Linkov @ 2010-06-05 12:49 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-06-05 12:49 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 14:22 ` Stefan Monnier 2010-06-03 15:42 ` martin rudalics @ 2010-06-04 10:36 ` Richard Stallman 2010-06-04 14:06 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: Richard Stallman @ 2010-06-04 10:36 UTC (permalink / raw To: Stefan Monnier; +Cc: juri, rudalics, emacs-devel > 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. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 10:36 ` Richard Stallman @ 2010-06-04 14:06 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-06-04 14:06 UTC (permalink / raw To: rms; +Cc: juri, Stefan Monnier, emacs-devel > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 8:57 ` martin rudalics 2010-06-03 14:22 ` Stefan Monnier @ 2010-06-03 18:54 ` Juri Linkov 2010-06-04 8:11 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-03 18:54 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 18:54 ` Juri Linkov @ 2010-06-04 8:11 ` martin rudalics 2010-06-04 16:57 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-04 8:11 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 8:11 ` martin rudalics @ 2010-06-04 16:57 ` Juri Linkov 2010-06-05 12:49 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-04 16:57 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 16:57 ` Juri Linkov @ 2010-06-05 12:49 ` martin rudalics 2010-06-05 19:47 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-05 12:49 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-05 12:49 ` martin rudalics @ 2010-06-05 19:47 ` Juri Linkov 2010-06-06 13:21 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-05 19:47 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> They implement tab-local buffer-list by modifying the frame-local >> buffer-list after switching the tab. > > Could you please explain in one or two sentences? Where can I find the > source of these tab-bars? Please see for example in the branch x-tabs/lisp/tab.el. >> The tab-bar functions implemented by Lisp packages use >> `modify-frame-parameters' to change `buffer-list' frame parameter. > > But wouldn't it make more sense to have tab-bar use its own list? Yes, it makes sense to have the following composite buffer-list: window-local buffer-list tab-local buffer-list frame-local buffer-list global buffer-list frame-local buried-buffer-list tab-local buried-buffer-list window-local buried-buffer-list But how would you implement tab-local buffer-list without modifying frame-local buffer-list? > Can tab-bar live with the fact that a user switches buffers without > using tab-bar and thus `select-window' changes the list? A user can switch buffers inside the same tab - this modifies the frame-local (tab-local) buffer-list. A user can switch tabs without using tab-bar - this updates the frame-local (tab-local) buffer-list with the buffer-list of another tab. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-05 19:47 ` Juri Linkov @ 2010-06-06 13:21 ` Stefan Monnier 2010-06-07 18:31 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-06 13:21 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-06 13:21 ` Stefan Monnier @ 2010-06-07 18:31 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-07 18:31 UTC (permalink / raw To: Stefan Monnier; +Cc: martin rudalics, Emacs >> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-01 9:24 ` martin rudalics 2010-06-01 13:08 ` Stefan Monnier 2010-06-01 19:51 ` Juri Linkov @ 2010-06-03 18:52 ` Juri Linkov 2010-06-04 8:11 ` martin rudalics 2 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-03 18:52 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-03 18:52 ` Juri Linkov @ 2010-06-04 8:11 ` martin rudalics 2010-06-04 17:09 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-04 8:11 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 8:11 ` martin rudalics @ 2010-06-04 17:09 ` Juri Linkov 2010-06-05 12:49 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-04 17:09 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs >> There is another case that is more annoying: >> >> 1. Run `emacs -q', the current buffer is "*scratch*". >> >> 2. Type `C-h i', the current buffer is "*info*". >> >> 3. Type `C-h C-t', the current buffer is "TODO". >> >> 4. Type `C-h C-n', the current buffer is "NEWS". >> >> 5. Type `C-x k RET', the current buffer is the previous buffer "TODO", good. >> >> 6. Type `C-x k RET', the current buffer is "*scratch*". Why? >> The previous buffer is "*info*", not "*scratch*"! > > This happened in revision 90833 of `pop-to-buffer' from 2008-09-13. > Since then `pop-to-buffer' doesn't reselect the selected window. > > The culprit is this conditional > > (unless (eq new-window old-window) > ;; `display-buffer' has chosen another window, select it. > > which does not select the *info* window because it was already selected > before but obviously doesn't record the *info* buffer either :-( > > I'm running my code without the conditional for more than two months > now so it shouldn't harm if you remove it as well. I tried to remove the conditional, but it doesn't help. Maybe some other your changes fixed that? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-04 17:09 ` Juri Linkov @ 2010-06-05 12:49 ` martin rudalics 2010-06-05 19:49 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-05 12:49 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs > I tried to remove the conditional, but it doesn't help. > Maybe some other your changes fixed that? [Indeed. Just that I had the fix in my build but no more in the source so it took me three hours to find out what really happened.] It's a longstanding bug in Fselect_window. At the time I changed `pop-to-buffer' I wasn't aware of it and thus only added to the confusion. Please do two things: In Fselect_window move the if (NILP (norecord)) record_buffer (w->buffer); up into the if (NILP (norecord)) { ++window_select_count; XSETFASTINT (w->use_time, window_select_count); } clause such that the latter reads as if (NILP (norecord)) { ++window_select_count; XSETFASTINT (w->use_time, window_select_count); record_buffer (w->buffer); } so the buffer gets recorded even if the selected window does not change. In addition, remove the conditional from `pop-to-buffer' as explained before. If you don't encounter problems, please check it in. martin PS: I'm not sure whether in Fselect_window this /* Go to the point recorded in the window. This is important when the buffer is in more than one window. It also matters when redisplay_window has altered point after scrolling, because it makes the change only in the window. */ { register int new_point = marker_position (w->pointm); if (new_point < BEGV) SET_PT (BEGV); else if (new_point > ZV) SET_PT (ZV); else SET_PT (new_point); } stuff should be moved in front of the if (EQ (window, selected_window)) return window; as well. Any ideas? ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-05 12:49 ` martin rudalics @ 2010-06-05 19:49 ` Juri Linkov 2010-06-05 21:58 ` Stefan Monnier 2010-06-06 10:38 ` martin rudalics 0 siblings, 2 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-05 19:49 UTC (permalink / raw To: martin rudalics; +Cc: Stefan Monnier, Emacs > if (NILP (norecord)) > { > ++window_select_count; > XSETFASTINT (w->use_time, window_select_count); > record_buffer (w->buffer); > } > > so the buffer gets recorded even if the selected window does not change. > > In addition, remove the conditional from `pop-to-buffer' as explained > before. If you don't encounter problems, please check it in. Thanks for finding the source of this bug. It works now. Stefan, is it ok to install this change? > PS: I'm not sure whether in Fselect_window this > > /* Go to the point recorded in the window. > This is important when the buffer is in more > than one window. It also matters when > redisplay_window has altered point after scrolling, > because it makes the change only in the window. */ > { > register int new_point = marker_position (w->pointm); > if (new_point < BEGV) > SET_PT (BEGV); > else if (new_point > ZV) > SET_PT (ZV); > else > SET_PT (new_point); > } > > stuff should be moved in front of the > > if (EQ (window, selected_window)) > return window; > > as well. Any ideas? But this will move it in front of Fset_buffer too. Is this right? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-05 19:49 ` Juri Linkov @ 2010-06-05 21:58 ` Stefan Monnier 2010-06-07 18:30 ` Juri Linkov 2010-06-06 10:38 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-05 21:58 UTC (permalink / raw To: Juri Linkov; +Cc: martin rudalics, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-05 21:58 ` Stefan Monnier @ 2010-06-07 18:30 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-07 18:30 UTC (permalink / raw To: Stefan Monnier; +Cc: martin rudalics, Emacs >>> 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-05 19:49 ` Juri Linkov 2010-06-05 21:58 ` Stefan Monnier @ 2010-06-06 10:38 ` martin rudalics 2010-06-07 1:12 ` Stefan Monnier 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-06 10:38 UTC (permalink / raw To: Juri Linkov; +Cc: Stefan Monnier, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-06 10:38 ` martin rudalics @ 2010-06-07 1:12 ` Stefan Monnier 2010-06-07 13:40 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-07 1:12 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-07 1:12 ` Stefan Monnier @ 2010-06-07 13:40 ` martin rudalics 2010-06-07 15:36 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-07 13:40 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-07 13:40 ` martin rudalics @ 2010-06-07 15:36 ` Stefan Monnier 2010-06-07 17:38 ` Lennart Borgman 2010-06-08 13:06 ` martin rudalics 0 siblings, 2 replies; 194+ messages in thread From: Stefan Monnier @ 2010-06-07 15:36 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-07 15:36 ` Stefan Monnier @ 2010-06-07 17:38 ` Lennart Borgman 2010-06-08 13:06 ` martin rudalics 1 sibling, 0 replies; 194+ messages in thread From: Lennart Borgman @ 2010-06-07 17:38 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, martin rudalics, Emacs On Mon, Jun 7, 2010 at 5:36 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> What I meant was that the current implementation gives very contrived >> semantics. > > I know. Maybe we should "fix it", as you implicitly suggested, by > simply always doing a set-buffer. It's fairly risky, kind of like > replacing every (save-excursion (set-buffer foo) bar) with > (with-current-buffer foo bar) ;-) Why is it risky? This is on the display level so to say and always associated with windows on the display. I think there will be no big surprises. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-07 15:36 ` Stefan Monnier 2010-06-07 17:38 ` Lennart Borgman @ 2010-06-08 13:06 ` martin rudalics 2010-06-08 20:19 ` Stefan Monnier 1 sibling, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-08 13:06 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > I know. Maybe we should "fix it", as you implicitly suggested, by > simply always doing a set-buffer. It's fairly risky, kind of like > replacing every (save-excursion (set-buffer foo) bar) with > (with-current-buffer foo bar) ;-) I haven't looked into the calls in xdisp.c but I hope you're right ;-) Vivisecting Fselect_window reveals at least three suspicious components. ------------------------------------------------------------------------ /* Store the current buffer's actual point into the old selected window. It belongs to that window, and when the window is not selected, must be in the window. */ if (!NILP (selected_window)) { ow = XWINDOW (selected_window); if (! NILP (ow->buffer)) set_marker_both (ow->pointm, ow->buffer, BUF_PT (XBUFFER (ow->buffer)), BUF_PT_BYTE (XBUFFER (ow->buffer))); } I suppose "current buffer" means the buffer displayed in the currently selected window which is not the window we are going to select. Why the heck do we care about storing `point' into that window's `window-point'? ------------------------------------------------------------------------ XBUFFER (w->buffer)->last_selected_window = window; IMHO it's a bug to not set last_selected_window when the selected window did not change but the buffer displayed in it did change. It means that when we remove the buffer from the window and display it in that window again Emacs will not go to the previous `window-point' but to `point'. ------------------------------------------------------------------------ /* Go to the point recorded in the window. This is important when the buffer is in more than one window. It also matters when redisplay_window has altered point after scrolling, because it makes the change only in the window. */ { register int new_point = marker_position (w->pointm); if (new_point < BEGV) SET_PT (BEGV); else if (new_point > ZV) SET_PT (ZV); else SET_PT (new_point); } It sets `point' to `window-point'. If the selected window didn't change but the buffer did, the buffer's `point' is not changed. Obviously, command_loop_1 will fix this eventually but any code running after the call of `select-window' will have `point' positioned as whether the selected window changed or not. ------------------------------------------------------------------------ Neither of these seems to have bothered anyone so far. But the problem Juri brought up wasn't noticed either - till now. martin ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-08 13:06 ` martin rudalics @ 2010-06-08 20:19 ` Stefan Monnier 2010-06-11 13:20 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-08 20:19 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-08 20:19 ` Stefan Monnier @ 2010-06-11 13:20 ` martin rudalics 2010-06-11 13:52 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-11 13:20 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-11 13:20 ` martin rudalics @ 2010-06-11 13:52 ` Stefan Monnier 2010-06-11 17:12 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-06-11 13:52 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-11 13:52 ` Stefan Monnier @ 2010-06-11 17:12 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-06-11 17:12 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 9:19 ` martin rudalics 2010-05-05 18:05 ` Juri Linkov @ 2010-05-05 18:19 ` Stefan Monnier 2010-05-06 8:22 ` martin rudalics 2010-05-08 3:09 ` Kevin Rodgers 2 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-05-05 18:19 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Ken Hori, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 18:19 ` Stefan Monnier @ 2010-05-06 8:22 ` martin rudalics 2010-05-06 13:04 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-06 8:22 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Ken Hori, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-06 8:22 ` martin rudalics @ 2010-05-06 13:04 ` Stefan Monnier 2010-05-06 14:59 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Stefan Monnier @ 2010-05-06 13:04 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Ken Hori, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-06 13:04 ` Stefan Monnier @ 2010-05-06 14:59 ` martin rudalics 2010-05-06 16:17 ` Stefan Monnier 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-06 14:59 UTC (permalink / raw To: Stefan Monnier; +Cc: Juri Linkov, Ken Hori, Emacs >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-06 14:59 ` martin rudalics @ 2010-05-06 16:17 ` Stefan Monnier 0 siblings, 0 replies; 194+ messages in thread From: Stefan Monnier @ 2010-05-06 16:17 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, Ken Hori, Emacs >>> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-05 9:19 ` martin rudalics 2010-05-05 18:05 ` Juri Linkov 2010-05-05 18:19 ` Stefan Monnier @ 2010-05-08 3:09 ` Kevin Rodgers 2010-05-08 13:54 ` martin rudalics 2 siblings, 1 reply; 194+ messages in thread From: Kevin Rodgers @ 2010-05-08 3:09 UTC (permalink / raw To: emacs-devel martin rudalics wrote: > > The point of set-window-configuration-from-sexp is to restore the > > configuration of windows, not to duplicate the functionality of > desktop.el. > > That's true from a theoretical point of view. It separates concerns in > a clear way and gives clean semantics. Hence I fully agree with you. > > Unfortunately, in personal practice, I'm suffering from a quite similar > problem. In particular, I display eldoc output on a per-window basis in > a one-line window below the code window (I hate eldoc output in the echo > area, I don't like it in the header line, and I very much hate tooltips. > Ideally, there would be a bottom-line right above the mode-line where I > could put it, but ...). Have you tried displaying a tooltip in that position, by let-binding tooltip-frame-parameters around the call to tooltip-show? ,----[ C-h f tooltip-show RET ] | tooltip-show is a compiled Lisp function in `tooltip.el'. | (tooltip-show text &optional use-echo-area) | | Show a tooltip window displaying text. | | Text larger than `x-max-tooltip-size' is clipped. | | If the alist in `tooltip-frame-parameters' includes `left' and `top' | parameters, they determine the x and y position where the tooltip | is displayed. Otherwise, the tooltip pops at offsets specified by | `tooltip-x-offset' and `tooltip-y-offset' from the current mouse | position. | | Optional second arg use-echo-area non-nil means to show tooltip | in echo area. | | [back] `---- -- Kevin Rodgers Denver, Colorado, USA ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-08 3:09 ` Kevin Rodgers @ 2010-05-08 13:54 ` martin rudalics 2010-05-08 15:42 ` Lennart Borgman 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-08 13:54 UTC (permalink / raw To: Kevin Rodgers; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-08 13:54 ` martin rudalics @ 2010-05-08 15:42 ` Lennart Borgman 2010-05-09 14:01 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Lennart Borgman @ 2010-05-08 15:42 UTC (permalink / raw To: martin rudalics; +Cc: Kevin Rodgers, emacs-devel On Sat, May 8, 2010 at 3:54 PM, martin rudalics <rudalics@gmx.at> wrote: >> Have you tried displaying a tooltip in that position, by let-binding >> tooltip-frame-parameters around the call to tooltip-show? > > You convinced me ;-) > > Only that `tooltip-show' displays the text in `tooltip' face, spoiling > everything. However, `x-show-tip' works fine and is much much cheaper > than the tribulations of `eldoc-display-message-no-interference-p' and > `eldoc-pre-command-refresh-echo-area'. How about adding that to the trunk? ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-08 15:42 ` Lennart Borgman @ 2010-05-09 14:01 ` martin rudalics 2010-05-09 14:21 ` Lennart Borgman 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-05-09 14:01 UTC (permalink / raw To: Lennart Borgman; +Cc: Kevin Rodgers, emacs-devel > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-09 14:01 ` martin rudalics @ 2010-05-09 14:21 ` Lennart Borgman 2010-05-09 15:01 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Lennart Borgman @ 2010-05-09 14:21 UTC (permalink / raw To: martin rudalics; +Cc: Kevin Rodgers, emacs-devel On Sun, May 9, 2010 at 4:01 PM, martin rudalics <rudalics@gmx.at> wrote: >> How about adding that to the trunk? > > We could add something like that eventually. However, I suppose that > most people would like to see the tooltip frame at the right of `point' > in some otherwise blank space of the screen. Does not this very much depend on the purpose of the tooltip? > This means that I probably > should be able to format argument lists and doc-strings vertically. > And, interaction with the mouse cursor would have to be evaluated too. > > Also, tooltips currently have quite a number of annoying features which > must be corrected first. Maybe a topmost frame is not the best frame style. I suppose "transient-for" (on w32 "owned") is better. This was discussed a bit in the thread below: http://comments.gmane.org/gmane.emacs.devel/124334 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-05-09 14:21 ` Lennart Borgman @ 2010-05-09 15:01 ` martin rudalics 0 siblings, 0 replies; 194+ messages in thread From: martin rudalics @ 2010-05-09 15:01 UTC (permalink / raw To: Lennart Borgman; +Cc: Kevin Rodgers, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-04-25 18:33 ` Window configurations (was: Gtk tabs in emacs, new branch) Juri Linkov 2010-04-26 16:16 ` Window configurations martin rudalics 2010-04-30 3:19 ` Window configurations (was: Gtk tabs in emacs, new branch) Ken Hori @ 2010-06-29 9:01 ` martin rudalics 2010-06-29 9:23 ` Juri Linkov 2010-06-29 20:01 ` Juri Linkov 2 siblings, 2 replies; 194+ messages in thread From: martin rudalics @ 2010-06-29 9:01 UTC (permalink / raw To: Juri Linkov; +Cc: 'Emacs' > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 9:01 ` martin rudalics @ 2010-06-29 9:23 ` Juri Linkov 2010-06-29 10:01 ` martin rudalics 2010-06-29 20:01 ` Juri Linkov 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-29 9:23 UTC (permalink / raw To: martin rudalics; +Cc: emacs-devel >> Do you plan to create a branch for your rewrite of window.c? >> It would be very interesting to look at it. > > I've now put up a branch called window-pub. Please have a look. Thank you! > The major aspects are > > - Internal windows exposed in Elisp > > - Window resizing moved to Elisp > > - Basic support for window groups and compound windows Could you put a short informal explanation of every aspect to a file (e.g. README.window-pub) in the window-pub branch, > ChangeLog entries are rudimentary. > > The branch does NOT incorporate any of > > - the window local buffer list implementation, > > - the new semantics for the second argument of `display-buffer', > > because I'm afraid that providing these will break things. It will take > some time to add them ;-) It's not terrible to break things in the branch ;-) -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 9:23 ` Juri Linkov @ 2010-06-29 10:01 ` martin rudalics 2010-06-29 10:37 ` Juanma Barranquero 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-29 10:01 UTC (permalink / raw To: Juri Linkov; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 10:01 ` martin rudalics @ 2010-06-29 10:37 ` Juanma Barranquero 2010-06-29 12:16 ` martin rudalics 0 siblings, 1 reply; 194+ messages in thread From: Juanma Barranquero @ 2010-06-29 10:37 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, emacs-devel 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 10:37 ` Juanma Barranquero @ 2010-06-29 12:16 ` martin rudalics 2010-06-29 20:14 ` Juanma Barranquero 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-29 12:16 UTC (permalink / raw To: Juanma Barranquero; +Cc: Juri Linkov, emacs-devel > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 12:16 ` martin rudalics @ 2010-06-29 20:14 ` Juanma Barranquero 0 siblings, 0 replies; 194+ messages in thread From: Juanma Barranquero @ 2010-06-29 20:14 UTC (permalink / raw To: martin rudalics; +Cc: Juri Linkov, emacs-devel On Tue, Jun 29, 2010 at 14:16, martin rudalics <rudalics@gmx.at> wrote: > you can make the modeline of a window disappear. This is intentional > for the following reason: When I drastically shrink a frame with the > window manager I prefer making windows without a modeline rather than > delete them. The modelines will reappear as soon as the frame grows > again. OK, this makes sense. > But, after > all, anyone who changes the value of a constant is on her own? Sure. Juanma ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 9:01 ` martin rudalics 2010-06-29 9:23 ` Juri Linkov @ 2010-06-29 20:01 ` Juri Linkov 2010-06-30 6:35 ` martin rudalics 1 sibling, 1 reply; 194+ messages in thread From: Juri Linkov @ 2010-06-29 20:01 UTC (permalink / raw To: martin rudalics; +Cc: 'Emacs' > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-29 20:01 ` Juri Linkov @ 2010-06-30 6:35 ` martin rudalics 2010-06-30 8:12 ` Juri Linkov 0 siblings, 1 reply; 194+ messages in thread From: martin rudalics @ 2010-06-30 6:35 UTC (permalink / raw To: Juri Linkov; +Cc: 'Emacs' > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Window configurations 2010-06-30 6:35 ` martin rudalics @ 2010-06-30 8:12 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-06-30 8:12 UTC (permalink / raw To: martin rudalics; +Cc: 'Emacs' > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-10 17:34 ` Angelo Graziosi 2010-04-10 18:03 ` Jan Djärv @ 2010-04-10 19:19 ` Stefan Monnier 1 sibling, 0 replies; 194+ messages in thread From: Stefan Monnier @ 2010-04-10 19:19 UTC (permalink / raw To: Angelo Graziosi; +Cc: Jan Djärv, Emacs > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 9:59 ` Angelo Graziosi 2010-04-02 15:10 ` Jan Djärv @ 2010-04-02 16:19 ` Uwe Siart 2010-04-02 18:31 ` Daniel Colascione 1 sibling, 1 reply; 194+ messages in thread From: Uwe Siart @ 2010-04-02 16:19 UTC (permalink / raw To: emacs-devel Angelo Graziosi <angelo.graziosi@alice.it> writes: > Clicking on the tab's 'X', should not close the file? It deletes only > the tab, the buffer being still 'visited' by Emacs. (I do not remember > a similar behavior with other applications using tabs.) The behaviour of other applications is not necessarily a draft for useful features. Emacs (luckily) has thousands of features where I do not remember a similar behavior with other applications. I would think of tabs as of a different kind of windows. In Emacs closing a window and killing a buffer are distinct actions. Tabs should behave the same. -- Uwe ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 16:19 ` Uwe Siart @ 2010-04-02 18:31 ` Daniel Colascione 2010-04-02 20:38 ` Stefan Monnier 2010-04-03 6:29 ` Uwe Siart 0 siblings, 2 replies; 194+ messages in thread From: Daniel Colascione @ 2010-04-02 18:31 UTC (permalink / raw To: Uwe Siart; +Cc: emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/2/10 12:19 PM, Uwe Siart wrote: > Angelo Graziosi <angelo.graziosi@alice.it> writes: > >> Clicking on the tab's 'X', should not close the file? It deletes only >> the tab, the buffer being still 'visited' by Emacs. (I do not remember >> a similar behavior with other applications using tabs.) > > The behaviour of other applications is not necessarily a draft for > useful features. On the other hand, being gratuitously different will just alienate users, especially new ones. When it comes to new users, programs aren't judged by what they can be configured to do, but what they do by default. > Emacs (luckily) has thousands of features where I do > not remember a similar behavior with other applications. Usually because Emacs predates these other applications. > I would think of tabs as of a different kind of windows. In Emacs > closing a window and killing a buffer are distinct actions. Tabs should > behave the same. > It seems the most natural thing to do is to kill the buffer iff the window killed by closing a tab is the last window showing the given buffer. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAku2N/gACgkQ17c2LVA10VutbgCfTsOS+49V3Q4os2iYnEFsBaxj IK0AoMsnz7j+iHJDTon45dws6pUNzf10 =Y1dV -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 18:31 ` Daniel Colascione @ 2010-04-02 20:38 ` Stefan Monnier 2010-04-03 6:29 ` Uwe Siart 1 sibling, 0 replies; 194+ messages in thread From: Stefan Monnier @ 2010-04-02 20:38 UTC (permalink / raw To: Daniel Colascione; +Cc: Uwe Siart, emacs-devel > 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 ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 18:31 ` Daniel Colascione 2010-04-02 20:38 ` Stefan Monnier @ 2010-04-03 6:29 ` Uwe Siart 2010-04-03 9:07 ` Uwe Siart 1 sibling, 1 reply; 194+ messages in thread From: Uwe Siart @ 2010-04-03 6:29 UTC (permalink / raw To: emacs-devel Daniel Colascione <daniel@censorshipresearch.org> writes: >> Emacs (luckily) has thousands of features where I do >> not remember a similar behavior with other applications. > > Usually because Emacs predates these other applications. This is a big advantage of Emacs over "these other applications". > It seems the most natural thing to do is to kill the buffer iff the > window killed by closing a tab is the last window showing the given > buffer. I disagree. Why should it be? In Emacs there can be buffers with information that I need over and over again. But I don't want do kill this information just because I don't need it in a window at the moment. Your rationale is to disable Emacs because "modern applications" are disabled and because "modern users" expect those disabilities. -- Uwe ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-03 6:29 ` Uwe Siart @ 2010-04-03 9:07 ` Uwe Siart 0 siblings, 0 replies; 194+ messages in thread From: Uwe Siart @ 2010-04-03 9:07 UTC (permalink / raw To: emacs-devel Uwe Siart <usenet@siart.de> writes: > I disagree. Why should it be? In Emacs there can be buffers with > information that I need over and over again. But I don't want do kill > this information just because I don't need it in a window at the moment. What about making it customizable by a variable like 'close-last-tab-kills-buffer' that can be set to t or nil? -- Uwe ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-01 16:52 Gtk tabs in emacs, new branch Angelo Graziosi 2010-04-01 17:45 ` Jan Djärv 2010-04-02 6:53 ` Jan Djärv @ 2010-04-02 6:53 ` Uwe Siart 2010-04-02 7:25 ` Jan Djärv 2010-04-02 12:19 ` Stephen J. Turnbull 2 siblings, 2 replies; 194+ messages in thread From: Uwe Siart @ 2010-04-02 6:53 UTC (permalink / raw To: emacs-devel Angelo Graziosi <angelo.graziosi@alice.it> writes: > Perhaps we need something like 'M-x tabs-mode' (by default possibly! > :-)) Please don't enable such stuff by default. The user should be able to decide by himself how many frames/windows/(tabs) he would like to open. Also IMO tabs are not that useful as many (windows) users think because there's only one tab visible at a time. Emacs' concept of frames and windows (and iswitchb-mode) is much better here. -- Uwe ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 6:53 ` Uwe Siart @ 2010-04-02 7:25 ` Jan Djärv 2010-04-04 11:01 ` Juri Linkov 2010-04-02 12:19 ` Stephen J. Turnbull 1 sibling, 1 reply; 194+ messages in thread From: Jan Djärv @ 2010-04-02 7:25 UTC (permalink / raw To: Uwe Siart; +Cc: emacs-devel Uwe Siart skrev: > Angelo Graziosi <angelo.graziosi@alice.it> writes: > >> Perhaps we need something like 'M-x tabs-mode' (by default possibly! >> :-)) > > Please don't enable such stuff by default. The user should be able to > decide by himself how many frames/windows/(tabs) he would like to open. > > Also IMO tabs are not that useful as many (windows) users think because > there's only one tab visible at a time. Emacs' concept of frames and > windows (and iswitchb-mode) is much better here. > It depends. Making many frames is no good if you don't have much screen space and want to view a large portion of your file. Many windows also reduces the amount of text you can view at once. Tabs have a role. Consider the use case of viewing 3 or 4 log files with very long lines at once. I currently do that by making Emacs fullscreen and switch buffers. Having tabs for this would be a small improvement, as the tabs give the file name and makes for faster switching. But I suspect long time Emacs users have developed habits that makes tabs less desirable. An iswitcht-mode for tabs would probably be a good idea though. Jan D. ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 7:25 ` Jan Djärv @ 2010-04-04 11:01 ` Juri Linkov 0 siblings, 0 replies; 194+ messages in thread From: Juri Linkov @ 2010-04-04 11:01 UTC (permalink / raw To: Jan Djärv; +Cc: Uwe Siart, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 194+ messages in thread
* Re: Gtk tabs in emacs, new branch 2010-04-02 6:53 ` Uwe Siart 2010-04-02 7:25 ` Jan Djärv @ 2010-04-02 12:19 ` Stephen J. Turnbull 1 sibling, 0 replies; 194+ messages in thread From: Stephen J. Turnbull @ 2010-04-02 12:19 UTC (permalink / raw To: Uwe Siart; +Cc: emacs-devel Uwe Siart writes: > Angelo Graziosi <angelo.graziosi@alice.it> writes: > > > Perhaps we need something like 'M-x tabs-mode' (by default possibly! > > :-)) > > Please don't enable such stuff by default. The user should be able to > decide by himself how many frames/windows/(tabs) he would like to > open. Opening many frames or windows is annoying to me, because I invariably have too many open when I shut down for whatever reason. and they can take up a lot of screen/frame real estate. If I'm going to have tabs for 99.9% of a session though, I'm just as happy having the tabs at startup as long as the top tab is sane (typically defined as "the selected tab in the selected frame at close-and-save time"). The extra 1.5 or 2 lines of text is almost never an issue. I think this is an even better candidate for "try as default and wait for screams of pain" than delete-selection-mode. People who hate it will only have to turn it off once. Many people who might love it won't find out about it for years if it's not default. BTW, at one time I had the same intuition you do. Then XEmacs put in tabs and enabled them by default. What I discovered is that at startup, the window I was working in *last* is a very good candidate for top tab, and it's at the top of buffer-list. What surprised me is that the second-to-last window was typically not a good guess for the second most important; rather it was often buried down the list at fifth or sixth. Tabs made it quite easy to find those precisely because they're in-your-face. iswitch and friends might make that advantage quite small for most users; I don't know. On the other hand, the actual cost is *very* small if you're going to enable tabs anyway. ^ permalink raw reply [flat|nested] 194+ messages in thread
end of thread, other threads:[~2010-06-30 8:12 UTC | newest] Thread overview: 194+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-01 16:52 Gtk tabs in emacs, new branch Angelo Graziosi 2010-04-01 17:45 ` Jan Djärv 2010-04-01 18:03 ` Juri Linkov 2010-04-01 20:18 ` Jan Djärv 2010-04-02 7:10 ` Jan Djärv 2010-04-01 20:51 ` Angelo Graziosi 2010-04-02 6:49 ` Jan Djärv 2010-04-02 9:21 ` Angelo Graziosi 2010-04-02 2:06 ` Stephen J. Turnbull 2010-04-02 7:00 ` Jan Djärv 2010-04-02 6:53 ` Jan Djärv 2010-04-02 9:59 ` Angelo Graziosi 2010-04-02 15:10 ` Jan Djärv 2010-04-02 16:55 ` Angelo Graziosi 2010-04-05 8:50 ` Angelo Graziosi 2010-04-10 12:44 ` Jan Djärv 2010-04-10 17:34 ` Angelo Graziosi 2010-04-10 18:03 ` Jan Djärv 2010-04-10 22:09 ` Angelo Graziosi 2010-04-11 5:45 ` Jan Djärv 2010-04-11 8:16 ` Angelo Graziosi 2010-04-11 10:52 ` Jan Djärv 2010-04-11 17:28 ` Angelo Graziosi 2010-04-11 18:33 ` Jan Djärv 2010-04-21 8:55 ` Juri Linkov 2010-04-21 9:46 ` David Kastrup 2010-04-21 15:43 ` Juri Linkov [not found] ` <jwv633k4rn2.fsf-monnier+emacs@gnu.org> 2010-04-22 8:16 ` Juri Linkov 2010-04-22 15:08 ` Jan Djärv 2010-04-23 8:33 ` Juri Linkov 2010-04-21 13:54 ` Angelo Graziosi 2010-04-21 15:45 ` Juri Linkov 2010-04-21 16:04 ` Jan Djärv 2010-04-22 8:14 ` Juri Linkov 2010-04-22 16:20 ` Juanma Barranquero 2010-04-24 18:45 ` Juri Linkov 2010-04-23 16:53 ` Drew Adams 2010-04-23 18:02 ` Juri Linkov 2010-04-23 18:28 ` Drew Adams 2010-04-24 9:17 ` Juri Linkov 2010-04-24 14:41 ` Drew Adams 2010-04-24 18:49 ` Juri Linkov 2010-04-24 19:24 ` Drew Adams 2010-04-25 5:36 ` Juri Linkov 2010-04-25 9:15 ` martin rudalics 2010-04-25 18:33 ` Window configurations (was: Gtk tabs in emacs, new branch) Juri Linkov 2010-04-26 16:16 ` Window configurations martin rudalics 2010-04-27 8:54 ` Juri Linkov 2010-04-27 12:54 ` martin rudalics 2010-04-27 18:03 ` Juri Linkov 2010-04-27 19:47 ` Info buffers in Desktop Juri Linkov 2010-04-28 7:12 ` Window configurations martin rudalics 2010-04-28 8:27 ` Juri Linkov 2010-04-27 19:55 ` Davis Herring 2010-04-28 7:12 ` martin rudalics 2010-04-28 14:50 ` Stefan Monnier 2010-04-28 8:35 ` Juri Linkov 2010-04-28 14:15 ` Davis Herring 2010-05-07 18:14 ` Juri Linkov 2010-04-30 3:19 ` Window configurations (was: Gtk tabs in emacs, new branch) Ken Hori 2010-04-30 20:33 ` Window configurations Stefan Monnier 2010-05-02 20:31 ` Juri Linkov 2010-05-02 23:34 ` Drew Adams 2010-05-03 0:50 ` Stefan Monnier 2010-05-03 0:57 ` Juri Linkov 2010-05-03 2:50 ` Stefan Monnier 2010-05-04 16:09 ` Juri Linkov 2010-05-05 6:41 ` Stephen J. Turnbull 2010-05-05 13:22 ` Stefan Monnier 2010-05-05 14:35 ` Stephen J. Turnbull 2010-05-05 21:59 ` Juri Linkov 2010-05-02 20:28 ` Juri Linkov 2010-05-03 3:31 ` Ken Hori 2010-05-04 16:12 ` Juri Linkov 2010-05-05 9:19 ` martin rudalics 2010-05-05 18:05 ` Juri Linkov 2010-05-06 8:21 ` martin rudalics 2010-05-06 20:47 ` Juri Linkov 2010-05-10 19:16 ` Juri Linkov 2010-05-11 7:01 ` martin rudalics 2010-05-11 16:45 ` Juri Linkov 2010-05-12 9:29 ` martin rudalics 2010-05-13 22:46 ` Juri Linkov 2010-05-14 6:59 ` martin rudalics 2010-05-16 22:51 ` Juri Linkov 2010-05-17 9:06 ` martin rudalics 2010-05-17 22:54 ` Juri Linkov 2010-05-18 12:07 ` martin rudalics 2010-05-31 17:28 ` martin rudalics 2010-05-31 18:39 ` Stefan Monnier 2010-05-31 19:12 ` Lennart Borgman 2010-05-31 20:23 ` Juri Linkov 2010-06-01 9:24 ` martin rudalics 2010-05-31 20:19 ` Juri Linkov 2010-06-01 3:13 ` Stefan Monnier 2010-06-01 9:25 ` martin rudalics 2010-06-01 12:58 ` Stefan Monnier 2010-06-01 9:24 ` martin rudalics 2010-06-01 13:08 ` Stefan Monnier 2010-06-01 14:02 ` Lennart Borgman 2010-06-01 16:04 ` martin rudalics 2010-06-01 19:20 ` Stefan Monnier 2010-06-02 12:59 ` martin rudalics 2010-06-02 14:08 ` Stefan Monnier 2010-06-03 8:55 ` martin rudalics 2010-06-01 19:54 ` Juri Linkov 2010-06-02 13:00 ` martin rudalics 2010-06-02 19:46 ` Juri Linkov 2010-06-03 8:55 ` martin rudalics 2010-06-03 18:55 ` Juri Linkov 2010-06-14 17:05 ` martin rudalics 2010-06-14 21:54 ` Juri Linkov 2010-06-15 7:08 ` martin rudalics 2010-06-15 21:31 ` Juri Linkov 2010-06-16 17:25 ` martin rudalics 2010-06-16 20:51 ` Juri Linkov 2010-06-17 7:58 ` martin rudalics 2010-06-17 8:42 ` Juri Linkov 2010-06-17 10:20 ` martin rudalics 2010-06-17 20:38 ` Juri Linkov 2010-06-17 22:55 ` Lennart Borgman 2010-06-18 6:34 ` martin rudalics 2010-06-18 8:28 ` Juri Linkov 2010-06-18 9:04 ` martin rudalics 2010-06-19 8:50 ` Juri Linkov 2010-06-19 13:47 ` martin rudalics 2010-06-19 14:12 ` Juri Linkov 2010-06-19 18:56 ` martin rudalics 2010-06-01 19:51 ` Juri Linkov 2010-06-02 13:00 ` martin rudalics 2010-06-02 19:49 ` Juri Linkov 2010-06-03 8:57 ` martin rudalics 2010-06-03 14:22 ` Stefan Monnier 2010-06-03 15:42 ` martin rudalics 2010-06-04 13:11 ` Stefan Monnier 2010-06-04 14:07 ` martin rudalics 2010-06-04 16:59 ` Juri Linkov 2010-06-05 12:49 ` martin rudalics 2010-06-04 10:36 ` Richard Stallman 2010-06-04 14:06 ` martin rudalics 2010-06-03 18:54 ` Juri Linkov 2010-06-04 8:11 ` martin rudalics 2010-06-04 16:57 ` Juri Linkov 2010-06-05 12:49 ` martin rudalics 2010-06-05 19:47 ` Juri Linkov 2010-06-06 13:21 ` Stefan Monnier 2010-06-07 18:31 ` Juri Linkov 2010-06-03 18:52 ` Juri Linkov 2010-06-04 8:11 ` martin rudalics 2010-06-04 17:09 ` Juri Linkov 2010-06-05 12:49 ` martin rudalics 2010-06-05 19:49 ` Juri Linkov 2010-06-05 21:58 ` Stefan Monnier 2010-06-07 18:30 ` Juri Linkov 2010-06-06 10:38 ` martin rudalics 2010-06-07 1:12 ` Stefan Monnier 2010-06-07 13:40 ` martin rudalics 2010-06-07 15:36 ` Stefan Monnier 2010-06-07 17:38 ` Lennart Borgman 2010-06-08 13:06 ` martin rudalics 2010-06-08 20:19 ` Stefan Monnier 2010-06-11 13:20 ` martin rudalics 2010-06-11 13:52 ` Stefan Monnier 2010-06-11 17:12 ` martin rudalics 2010-05-05 18:19 ` Stefan Monnier 2010-05-06 8:22 ` martin rudalics 2010-05-06 13:04 ` Stefan Monnier 2010-05-06 14:59 ` martin rudalics 2010-05-06 16:17 ` Stefan Monnier 2010-05-08 3:09 ` Kevin Rodgers 2010-05-08 13:54 ` martin rudalics 2010-05-08 15:42 ` Lennart Borgman 2010-05-09 14:01 ` martin rudalics 2010-05-09 14:21 ` Lennart Borgman 2010-05-09 15:01 ` martin rudalics 2010-06-29 9:01 ` martin rudalics 2010-06-29 9:23 ` Juri Linkov 2010-06-29 10:01 ` martin rudalics 2010-06-29 10:37 ` Juanma Barranquero 2010-06-29 12:16 ` martin rudalics 2010-06-29 20:14 ` Juanma Barranquero 2010-06-29 20:01 ` Juri Linkov 2010-06-30 6:35 ` martin rudalics 2010-06-30 8:12 ` Juri Linkov 2010-04-10 19:19 ` Gtk tabs in emacs, new branch Stefan Monnier 2010-04-02 16:19 ` Uwe Siart 2010-04-02 18:31 ` Daniel Colascione 2010-04-02 20:38 ` Stefan Monnier 2010-04-03 6:29 ` Uwe Siart 2010-04-03 9:07 ` Uwe Siart 2010-04-02 6:53 ` Uwe Siart 2010-04-02 7:25 ` Jan Djärv 2010-04-04 11:01 ` Juri Linkov 2010-04-02 12:19 ` Stephen J. Turnbull
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.