GNU bug report logs - #4147
23.1.50: Info-search command strange behaviour

Previous Next

Full log

Message #95 received at 4147 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Thu, 17 Dec 2009 09:19:41 +0100

> However, it's not clear how to combine header lines from different modes
> for the same buffer (e.g. Info, ruler, and tabbar) - whether to put them
> on separate lines in one buffer displayed in one header window, or to display
> them in separate windows and buffers, i.e. one extra buffer/window for every
> mode - one header buffer/window for the ruler, one for the tabbar, etc.

As a rule of thumb I think we should continue to handle a mode like
`ruler-mode' via `header-line-format' because that mode should hardly
ever need more than one line and is always tied to a live window.  Also
as designer of `ruler-mode' I'd probably dislike sharing a window with a
mode like tabbar that is not directly related to the current buffer,
uses a different design for displaying its objects, a different overlay
or text properties approach, ...

Tabs should go to a separate header window that would also stay around
when the user switches to another buffer in the associated main window.
And we could easily attach a tabs window to an internal window like the
root window of a frame thus always spanning the entire width of a frame.
That is, a tabs window attached to a single live window would list the
buffers the user is supposed to switch to in that window.  A tabs window
attached to a group of windows would list the buffers the user is
supposed to switch to in that group.  A tabs window attached to the
frame root window would list all buffers to switch to in that frame.
(IMHO the by far most difficult part of tabbars is to choose a good
strategy for which buffers should appear first in a sequence of tabs.)

So we should probably try to identify the non-conflicting users of the
current header-line-format approach (I suppose Info and ruler-mode are
non-conflicting) and decide what to do with the rest.  That is, decide
whether those want separate windows or share one header window with
other modes.  As far as Info and the problem at hand are concerned a
separate Info header window might be useful.  But we should coordinate
this with any speedbar window showing the info titles on the left of the
main window and must handle cloned Info buffers correctly.

The windows handling code would allow to add to/remove from any number
of header/footer windows to a single main window.  What I currently
don't have is a suitable divider - header windows won't have a modeline,
I presume.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.