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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4147 in the body.
You can then email your comments to 4147 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jamie Lokier <jamie <at> shareable.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.50: Info-search command strange behaviour
Date: Sat, 15 Aug 2009 04:49:57 +0100

In GNU Emacs 23.1.50.1 (i486-pc-linux-gnu, GTK+ Version 2.16.1)
 of 2009-07-31 on lansones, modified by Debian
 (emacs-snapshot package, version 1:20090730-1~jaunty1)
 (= the Ubuntu-PPA Jaunty package at the time of writing)


When searching through a manual with the 's' key, which invokes
Info-search, it has odd behaviour when the string isn't found.

Firstly, sometimes it shows the usual message about not finding the
string, but moves point forward by a few characters that have no
relationship with the search.  Point should remain in the same place.

Secondly, sometimes after entering the search regex, instead of
searching it says Wrong type argument: stringp, nil.

Here's how I can repeat it:

Start Emacs with no customisation:
    emacs -nw -Q

Invoke Info, go to the directory:
    C-h i

Search:
    s blahblah RET
    => Says it can't find it, and point does not move.

Go to the Emacs manual:
    m Emacs (emacs-snapshot) RET

Search:
    s blahblah RET
    => Says it can't find it, but moves point forward a few characters.

Go back to the Info directory:
    d

Search:
    s blahblah RET
    => Says "Wrong type argument: stringp, nil"


That's all.  It was the point moving that I found particularly odd,
when searching repeatedly for a term.  First point moved as expected
with each "s RET" sequence, but then it carried on moving after there
were no more occurrences which was confusing.  I noticed the error
after returning to the Info directory following that.


Thanks,
-- Jamie

Message #10 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jamie Lokier <jamie <at> shareable.org>, 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Sat, 15 Aug 2009 12:10:23 +0200

[Message part 1 (text/plain, inline)]

>     s blahblah RET
>     => Says it can't find it, but moves point forward a few characters.

I suppose something like the attached patch should cure that.

> Go back to the Info directory:
>     d
>
> Search:
>     s blahblah RET
>     => Says "Wrong type argument: stringp, nil"

FWIW this happens because in the

	      (with-current-buffer (marker-buffer Info-tag-table-marker)

form `Info-tag-table-marker' is nil and `with-current-buffer' expects
either a valid buffer or a string naming a buffer.  I don't know how
Info tags are handled so I leave this to someone more knowledgeable.

> That's all.  It was the point moving that I found particularly odd,
> when searching repeatedly for a term.  First point moved as expected
> with each "s RET" sequence, but then it carried on moving after there
> were no more occurrences which was confusing.  I noticed the error
> after returning to the Info directory following that.

martin

[info.el.diff (text/plain, inline)]

*** info.el.~1.562.~	2009-07-27 08:09:32.407806900 +0200
--- info.el	2009-08-15 11:18:33.578125000 +0200
***************
*** 1818,1825 ****
  		(signal 'search-failed (list regexp))))
  	  (if (not found)
  	      (progn (Info-read-subfile osubfile)
- 		     (goto-char opoint)
  		     (Info-select-node)
  		     (set-window-start (selected-window) ostart)))))
  
        (if (and (string= osubfile Info-current-subfile)
--- 1818,1825 ----
  		(signal 'search-failed (list regexp))))
  	  (if (not found)
  	      (progn (Info-read-subfile osubfile)
  		     (Info-select-node)
+ 		     (goto-char opoint)
  		     (set-window-start (selected-window) ostart)))))
  
        (if (and (string= osubfile Info-current-subfile)

Message #17 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Jamie Lokier <jamie <at> shareable.org>, 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Sat, 05 Dec 2009 02:48:27 +0200

>>     s blahblah RET
>>     => Says it can't find it, but moves point forward a few characters.
>
> I suppose something like the attached patch should cure that.

This patch works only when initially point was in the Top node,
and fails in other nodes.

The odd behavior when point moves forward by a few characters
is caused by breadcrumbs inserted to the Info buffer (the distance
point moves forward is the length of the breadcrumbs string).

Setting `Info-breadcrumbs-depth' to 0 fixes this problem.
But it is difficult to fix this when `Info-breadcrumbs-depth' > 0.

>> Go back to the Info directory:
>>     d
>> Search:
>>     s blahblah RET
>>     => Says "Wrong type argument: stringp, nil"
>
> FWIW this happens because in the
>
> 	      (with-current-buffer (marker-buffer Info-tag-table-marker)
>
> form `Info-tag-table-marker' is nil and `with-current-buffer' expects
> either a valid buffer or a string naming a buffer.  I don't know how
> Info tags are handled so I leave this to someone more knowledgeable.

For unknown reasons, `Info-current-subfile' is not nil in `dir'.
I'll take care of this bug.

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

Message #22 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 4147 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>, Jamie Lokier <jamie <at> shareable.org>
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Sat, 05 Dec 2009 21:50:22 +0200

>>>     s blahblah RET
>>>     => Says it can't find it, but moves point forward a few characters.
>
> The odd behavior when point moves forward by a few characters
> is caused by breadcrumbs inserted to the Info buffer (the distance
> point moves forward is the length of the breadcrumbs string).

To fix this one idea is to remove the breadcrumbs line on leaving
from the node, so breadcrumbs in all nodes located above the current
node will not affect the point position.  And in the case of getting
the current point position, subtract the length of breadcrumbs in
the current node.

> Setting `Info-breadcrumbs-depth' to 0 fixes this problem.
> But it is difficult to fix this when `Info-breadcrumbs-depth' > 0.
>
>>> Go back to the Info directory:
>>>     d
>>> Search:
>>>     s blahblah RET
>>>     => Says "Wrong type argument: stringp, nil"
>
> For unknown reasons, `Info-current-subfile' is not nil in `dir'.
> I'll take care of this bug.

This part of the bug report is fixed now.

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

Message #27 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Tue, 08 Dec 2009 22:12:33 +0200

>>>>     s blahblah RET
>>>>     => Says it can't find it, but moves point forward a few characters.
>>
>> The odd behavior when point moves forward by a few characters
>> is caused by breadcrumbs inserted to the Info buffer (the distance
>> point moves forward is the length of the breadcrumbs string).
>
> To fix this one idea is to remove the breadcrumbs line on leaving
> from the node, so breadcrumbs in all nodes located above the current
> node will not affect the point position.  And in the case of getting
> the current point position, subtract the length of breadcrumbs in
> the current node.

Another idea I've considered is using point positions relative to the
beginning of the node.  But to be able to fix this for Isearch in Info
we have to change semantics of Isearch variables like `isearch-other-end',
to use relative point positions.  This is too much trouble too.

The only sane way I see to fix this problem is:

1. not to insert breadcrumbs to the Info buffer;

2. display breadcrumbs in the header line;

3. not to hide next/prev/up navigation links in the first line
   of the node.

`Info-use-header-line' could provide an additional value `breadcrumbs'
that does this and set it by default.

If this is acceptable, I can prepare a patch.

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

Message #32 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Mon, 14 Dec 2009 23:54:16 +0200

> 1. not to insert breadcrumbs to the Info buffer;
>
> 2. display breadcrumbs in the header line;
>
> 3. not to hide next/prev/up navigation links in the first line
>    of the node.
>
> `Info-use-header-line' could provide an additional value `breadcrumbs'
> that does this and set it by default.

It seems better to leave next/prev/up navigation links in the header line
because on a long node it's more convenient to use navigation links in
the header because it doesn't scroll with the node buffer.

This suggests to put navigation links and breadcrumbs in the header line
on two lines.  But when I tried to do this, the header line displays
^J for the newline instead of displaying two lines.

Is this a limitation of the Emacs display engine?

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

Message #37 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>, 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Tue, 15 Dec 2009 00:00:02 +0100

> This suggests to put navigation links and breadcrumbs in the header line
> on two lines.  But when I tried to do this, the header line displays
> ^J for the newline instead of displaying two lines.
>
> Is this a limitation of the Emacs display engine?

I suppose you could cause some harm if you were able to work around that
limitation ;-)

martin

Message #42 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Tue, 15 Dec 2009 01:56:22 +0200

>> This suggests to put navigation links and breadcrumbs in the header line
>> on two lines.  But when I tried to do this, the header line displays
>> ^J for the newline instead of displaying two lines.
>>
>> Is this a limitation of the Emacs display engine?
>
> I suppose you could cause some harm if you were able to work around that
> limitation ;-)

Just the opposite is true: this limitation causes harm to users ;-)

For example, tabbar.el that uses the header line is overwritten
by Info's header line.  But with more than one header line
they would be able to coexist peacefully.

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

Message #47 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>, 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Tue, 15 Dec 2009 06:07:25 +0200

> From: Juri Linkov <juri <at> jurta.org>
> Date: Mon, 14 Dec 2009 23:54:16 +0200
> Cc: 
> 
> This suggests to put navigation links and breadcrumbs in the header line
> on two lines.  But when I tried to do this, the header line displays
> ^J for the newline instead of displaying two lines.
> 
> Is this a limitation of the Emacs display engine?

The display code assumes there's only one ``glyph row'' in the header
line, yes.  And likewise in the mode line.

Message #52 received at 4147 <at> emacsbugs.donarmstrong.com (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: Tue, 15 Dec 2009 09:16:37 +0100

> For example, tabbar.el that uses the header line is overwritten
> by Info's header line.  But with more than one header line
> they would be able to coexist peacefully.

If you can come up with a mechanism to put the contents of the header
line in a separate buffer I can easily write some code which displays
that buffer in an attached window - if necessary, with automatic height
adjustment.

martin

Message #57 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Wed, 16 Dec 2009 02:45:51 +0200

>> For example, tabbar.el that uses the header line is overwritten
>> by Info's header line.  But with more than one header line
>> they would be able to coexist peacefully.
>
> If you can come up with a mechanism to put the contents of the header
> line in a separate buffer I can easily write some code which displays
> that buffer in an attached window - if necessary, with automatic height
> adjustment.

It seems very easy to put the contents of the header line in a separate
buffer.  Do you intend to display that buffer using some mechanism other
than the header line?  I'm afraid this won't work for tabbar.el that relies
on the header line.

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

Message #62 received at 4147 <at> emacsbugs.donarmstrong.com (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: Wed, 16 Dec 2009 08:53:16 +0100

> It seems very easy to put the contents of the header line in a separate
> buffer.  Do you intend to display that buffer using some mechanism other
> than the header line?  I'm afraid this won't work for tabbar.el that relies
> on the header line.

I never looked at tabbar.el so I can't tell.  But suppose you can make
it work that whatever it displays via `header-line-format' goes to a
separate buffer - and obviously relays back any user input on that
buffer's contents to the tabbar dispatcher which is the harder part.
Then we could display that buffer in a window attached to some other
window including a frame's root window.  That way tabbar wouldn't
interfere any more with other modes using the header line like info or
ruler-mode.  Also, tabs could be displayed on the left or right of a
window.

Moreover, users could choose between a one-tabbar-per-frame and a
one-tabbar-per-window setting.  In the former case the tabbar would
vanish only when tabbars are switched off or the frame gets deleted,
just like the toolbar.  In the latter case, a tabbar would disappear
whenever the associated window gets deleted.

martin

Message #67 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Wed, 16 Dec 2009 11:17:59 +0200

> I never looked at tabbar.el so I can't tell.  But suppose you can make
> it work that whatever it displays via `header-line-format' goes to a
> separate buffer - and obviously relays back any user input on that
> buffer's contents to the tabbar dispatcher which is the harder part.

I think no need to relay back because a keymap click in a "header-line"
window will call a function that updates `header-line-format' whose new
content will be displayed in this window anyway.

> Then we could display that buffer in a window attached to some other
> window including a frame's root window.  That way tabbar wouldn't
> interfere any more with other modes using the header line like info or
> ruler-mode.  Also, tabs could be displayed on the left or right of a
> window.

This means we need extra buffer per every header-line.

> Moreover, users could choose between a one-tabbar-per-frame and a
> one-tabbar-per-window setting.  In the former case the tabbar would
> vanish only when tabbars are switched off or the frame gets deleted,
> just like the toolbar.  In the latter case, a tabbar would disappear
> whenever the associated window gets deleted.

I don't understand how do you intend to ensure that the tabbar
of the selected window doesn't disappear if the user types
`C-x 1' (`delete-other-windows')?

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

Message #72 received at 4147 <at> emacsbugs.donarmstrong.com (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: Wed, 16 Dec 2009 16:04:02 +0100

> I think no need to relay back because a keymap click in a "header-line"
> window will call a function that updates `header-line-format' whose new
> content will be displayed in this window anyway.

But you want to display the buffer the tab stands for in the other
window and not in the window where the tab appears.  That has to be
handled.

> This means we need extra buffer per every header-line.

Yes.

> I don't understand how do you intend to ensure that the tabbar
> of the selected window doesn't disappear if the user types
> `C-x 1' (`delete-other-windows')?

Windows code can investigate all sorts of window parameters - in the
present case there would be parameters like "nodelete", "noresize",
"nosplit" and "noother" say.  Now consider a configuration like this

 --------------------
| T                  |
|--------------------|
| W                  |
|                    |
|                    |
|                    |
|                    |
 --------------------

where T is the tabbar window and W the window (live or internal) the
tabbar is attached to.  These windows share a parent window which
doesn't contain any other window.


The tabbar window T would have

nodelete 'this ... the only way to delete T is via `delete-window' with
  T as argument or `delete-other-windows' with any but T or W as
  argument.  C-x 1 invoked with either T or W selected will fill the
  frame with T and W and delete all other windows.  C-x 0 in T deletes T
  but leaves W alone.

noresize 'vertical ... means T cannot be resized vertically.

nosplit 'parent ... means C-x 2 on T will split the parent window of T
  and W instead.

noother t ... means `other-window' will skip T.  There should be a
  special command to cycle through the attached windows of W and back to
  W though.  But `other-window' and its clients should not try to pick a
  window like T.


The window W would have

nodelete 'parent ... means C-x 0 in W will delete both T and W.  C-x 1
  in W means only W and T will be left on their frame.  We could add the
  twist that on a frame containing W and T only C-x 1 in W deletes T.

nosplit 'parent ... is as above.


Note that parameter values like 'parent are transitive so you can
attach, for example, another window on the left like:

 -------------------------
| S  | T                  |
|    |--------------------|
|    | W                  |
|    |                    |
|    |                    |
|    |                    |
|    |                    |
 -------------------------

and have C-x 0 in W delete S, T and W (provided there is another window
left), C-x 0 in S or T behave as usual, and C-x 1 in S, T or W delete
all windows but S, T and W.

martin

Message #77 received at 4147 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>, <4147 <at> debbugs.gnu.org>,
        "'Juri Linkov'" <juri <at> jurta.org>
Subject: RE: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Wed, 16 Dec 2009 11:21:21 -0800

I don't really want to dive into this thread. I'll just note that it seems, from
a superficial look, like you guys might be getting a bit far afield. ;-)

The bug was about `s' in Info moving point when the search string is not found.
The problem is apparently that it moves forward the length of some breadcrumbs.

Juri proposed a couple of approaches to fixing that which sounded reasonable to
me, the simplest seemingly to just back up the length of the breadcrumbs
afterward (or perhaps use point minus that length to begin with). Sure, maybe
things are not quite as simple as that - I haven't looked into it.

But it seems like you are now off into the deep woods, redesigning plenty of
things. Maybe you headed off the simple track when Juri said this:

 The only sane way I see to fix this problem is:
 1. not to insert breadcrumbs to the Info buffer;
 2. display breadcrumbs in the header line;
 3. not to hide next/prev/up navigation links in the first line
    of the node.

It's not obvious to me why that would be the only sane approach. Or the
simplest, to fix this (minor) problem. From there you went on to multiple-line
header lines, display engine limitations, interactions with tab bars, new
design/implementation for header lines using special windows and buffers, etc.

Are you just having fun, or is this really how you will approach fixing this
bug? ;-)

I don't mean to suggest that your efforts are misguided. As I said, I haven't
followed this closely at all, and you guys are both solid and you know what
you're doing. I'd just suggest that you _might_ want to take a step back and
reconsider what the problem and goal are.

HTH.

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Fri, 18 Dec 2009 01:34:14 +0200

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

A divider is not necessary when buffers in the header windows are displayed
with the `header-line' face.  With this face they will clearly stand out
from the main window.

Currently I tried to experiment with the header window but immediately was
thrown back by the presence of the modeline.  With the modeline this looks
very ugly.  Do you know how to remove the modeline from the header window?

I see some code in Emacs used for compatibility with XEmacs uses a property
`has-modeline-p', but it seems this is only for frames, not windows.

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

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

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 4147 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Thu, 17 Dec 2009 03:31:50 +0200

> Juri proposed a couple of approaches to fixing that which sounded
> reasonable to me, the simplest seemingly to just back up the length of
> the breadcrumbs afterward (or perhaps use point minus that length to
> begin with). Sure, maybe things are not quite as simple as that -
> I haven't looked into it.

Of course, things are not simple.  First, there is no single place where
to put code to execute on leaving a node.  This place is needed to add
code to remove breadcrumbs from the current node on leaving it because
otherwise breadcrumbs in all nodes above the current node will add their
lengths to the point's position in the current node.

A second problem is that all Info functions assume that point at the
cursor corresponds to the file position.  Finding all places in Info
that use point and recalculating the point's position based on the
length of the breadcrumbs is a big task.  Basically, this means
redesigning of the Info browser.

If you think this is simple, then please send a patch that fixes
this bug. ;-)

> I don't mean to suggest that your efforts are misguided. As I said,
> I haven't followed this closely at all, and you guys are both solid
> and you know what you're doing. I'd just suggest that you _might_ want
> to take a step back and reconsider what the problem and goal are.

The goal is to design a new window infrastructure that supports window
groups.  This is necessary for ECB and also solves many related problems
like using multiple header lines and tabbar, etc.  Now is the right time
to think about new design.  This bug was just an incentive to do this.

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

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

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

>> This means we need extra buffer per every header-line.
>
> Yes.

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.

> Windows code can investigate all sorts of window parameters - in the
> present case there would be parameters like "nodelete", "noresize",
> "nosplit" and "noother" say.

I think you design of using window parameters is clean and flexible.

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

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: 4147 <at> debbugs.gnu.org, 'martin rudalics' <rudalics <at> gmx.at>
Subject: RE: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Thu, 17 Dec 2009 07:26:38 -0800

> The goal is to design a new window infrastructure that supports window
> groups.  This is necessary for ECB and also solves many 
> related problems like using multiple header lines and tabbar, etc.
> Now is the right time to think about new design.  This bug was just
> an incentive to do this.

Thanks for your explanation.

In that case, I'd suggest that emacs-devel is the right place to discuss such
redesign. IOW, leave the bug unfixed until the requisite design change allows
fixing it, and discuss the design change in the dev mailing list, not just in
this bug thread.

Just a suggestion.

Message #92 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: Fri, 18 Dec 2009 08:38:50 +0100

> A divider is not necessary when buffers in the header windows are displayed
> with the `header-line' face.  With this face they will clearly stand out
> from the main window.

In many cases a divider is not needed.  However, with undistinguishable
faces it might be good to have one.  BTW, how are tabs displayed on
text-only terminals?  Also, what additional support is needed to display
a toolbar in a header window?

> Currently I tried to experiment with the header window but immediately was
> thrown back by the presence of the modeline.  With the modeline this looks
> very ugly.  Do you know how to remove the modeline from the header window?

Does (setq mode-line-format nil) not do that?

martin

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>, 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Fri, 18 Dec 2009 11:49:01 +0200

> From: Juri Linkov <juri <at> jurta.org>
> Date: Fri, 18 Dec 2009 01:34:14 +0200
> Cc: 4147 <at> debbugs.gnu.org
> 
> Currently I tried to experiment with the header window but immediately was
> thrown back by the presence of the modeline.  With the modeline this looks
> very ugly.  Do you know how to remove the modeline from the header window?

Does it help to set mode-line-format to nil?

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

From: Juri Linkov <juri <at> jurta.org>
To: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Sat, 19 Dec 2009 02:45:52 +0200

[Message part 1 (text/plain, inline)]

[I'm not sure whether all sent mails in this thread already arrived after
the transition period, but let's hope that nothing will be lost.]

Meanwhile, I wrote a small proof of concept that works surprisingly well.

All next/prev/up navigations links work from the "header-line" window
without additional efforts thanks to the following existing code in
Info-next/Info-prev/Info-up:

    (or (eq major-mode 'Info-mode) (pop-to-buffer "*info*"))

that after clicking on a link in the "header-line" window moves the
current focus from the "header-line" window to the window with the
Info buffer.  (The links are not yet displayed as blue underlined text,
but nevertheless work well).

The breadcrumbs links don't do this, so they currently don't work.

[test.el (application/emacs-lisp, inline)]

[Message part 3 (text/plain, inline)]

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

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Sat, 19 Dec 2009 02:30:01 +0200

> In many cases a divider is not needed.  However, with undistinguishable
> faces it might be good to have one.

In this case we could display Ersatz divider, e.g. the bottom line
of the upper window fontified with a different face.

> BTW, how are tabs displayed on text-only terminals?

They are correctly displayed as text lines.

> Also, what additional support is needed to display a toolbar in
> a header window?

Using the same design, a toolbar could be displayed in a separate window
above the header window.

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

Message #107 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: Sat, 19 Dec 2009 10:09:22 +0100

> In this case we could display Ersatz divider, e.g. the bottom line
> of the upper window fontified with a different face.

Anyway it would be nice to have horizontal dividers by default so an
application could suppress displaying the mode-line more easily.

>> BTW, how are tabs displayed on text-only terminals?
>
> They are correctly displayed as text lines.

And how would we do the Ersatz divider stuff there?

> Using the same design, a toolbar could be displayed in a separate window
> above the header window.

I never looked at the toolbar code.  Is there anything that mandates the
existence of one single toolbar on an Emacs frame?  Especially for Info
buffers it would be nice to have a toolbar window right above the Info
window.

martin

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

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

> All next/prev/up navigations links work from the "header-line" window
> without additional efforts thanks to the following existing code in
> Info-next/Info-prev/Info-up:
>
>     (or (eq major-mode 'Info-mode) (pop-to-buffer "*info*"))

Would this work with cloned Info buffers?  In any case `pop-to-buffer'
is way too fragile to be generally useful.

> that after clicking on a link in the "header-line" window moves the
> current focus from the "header-line" window to the window with the
> Info buffer.  (The links are not yet displayed as blue underlined text,
> but nevertheless work well).

The code should suppress displaying scrollbars in header-windows.

martin

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Mon, 21 Dec 2009 02:34:38 +0200

>> In this case we could display Ersatz divider, e.g. the bottom line
>> of the upper window fontified with a different face.
>
> Anyway it would be nice to have horizontal dividers by default so an
> application could suppress displaying the mode-line more easily.
>
>>> BTW, how are tabs displayed on text-only terminals?
>>
>> They are correctly displayed as text lines.
>
> And how would we do the Ersatz divider stuff there?

For example, with the `inverse-video' face attribute, like we do for the
`mode-line' face.

>> Using the same design, a toolbar could be displayed in a separate
>> window above the header window.
>
> I never looked at the toolbar code.  Is there anything that mandates
> the existence of one single toolbar on an Emacs frame?

The toolbar is represented by a propertized string created by
`build_desired_tool_bar_string'.  It is only the frame parameter
`tool_bar_window' that mandates one toolbar per frame.

> Especially for Info buffers it would be nice to have a toolbar window
> right above the Info window.

It could be created by the same means as the header-line window.

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

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 4147 <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Mon, 21 Dec 2009 02:36:59 +0200

>> All next/prev/up navigations links work from the "header-line" window
>> without additional efforts thanks to the following existing code in
>> Info-next/Info-prev/Info-up:
>>
>>     (or (eq major-mode 'Info-mode) (pop-to-buffer "*info*"))
>
> Would this work with cloned Info buffers?  In any case `pop-to-buffer'
> is way too fragile to be generally useful.

Actually, it works with cloned Info buffers as well due to some magic
of defining a key binding like

    (define-key keymap [header-line mouse-1] 'Info-next)

where `header-line' defines that a mouse click operates on the original
window instead of the header-line window where a link was clicked.

>> that after clicking on a link in the "header-line" window moves the
>> current focus from the "header-line" window to the window with the
>> Info buffer.  (The links are not yet displayed as blue underlined text,
>> but nevertheless work well).
>
> The code should suppress displaying scrollbars in header-windows.

Do you know how to suppress scrollbars on a per window/buffer basis?

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

Message #119 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: Mon, 21 Dec 2009 09:21:46 +0100

> The toolbar is represented by a propertized string created by
> `build_desired_tool_bar_string'.  It is only the frame parameter
> `tool_bar_window' that mandates one toolbar per frame.

The one toolbar per frame concept is built into most toolbar handling
routines like note_tool_bar_highlight and some "if drawing a tool-bar
window, draw it over the internal border at the top of the window" stuff
I don't understand completely yet.  All these look fairly trivial though
at first glance.

martin

Message #122 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: Mon, 21 Dec 2009 09:21:53 +0100

> Do you know how to suppress scrollbars on a per window/buffer basis?

Good question: For a particular window use

(set-window-scroll-bars window 0)

see Elisp manual section 38.14 "Scroll Bars".  The same section also
says that it's possible to control scrollbars for indiviudal buffers by
setting `scroll-bar-mode' but I don't see how.  So you have to use
something like

(setq vertical-scroll-bar nil)

which takes effect only after a buffer gets displayed the next time.

martin

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

From: Glenn Morris <rgm <at> gnu.org>
To: 4147-done <at> debbugs.gnu.org
Subject: Re: bug#4147: 23.1.50: Info-search command strange behaviour
Date: Wed, 05 Oct 2011 23:41:56 -0400

Version: 23.2

Jamie Lokier wrote:

> Start Emacs with no customisation:
>     emacs -nw -Q
>
> Invoke Info, go to the directory:
>     C-h i
>
> Search:
>     s blahblah RET
>     => Says it can't find it, and point does not move.
>
> Go to the Emacs manual:
>     m Emacs (emacs-snapshot) RET
>
> Search:
>     s blahblah RET
>     => Says it can't find it, but moves point forward a few characters.

I see this in 23.1 but not 23.2, so it looks like this was fixed.

Previous Next

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