bug#4147: 23.1.50: Info-search command strange behaviour

bug#4147: 23.1.50: Info-search command strange behaviour

[Jamie Lokier]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

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

 >     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


[-- Attachment #2: info.el.diff --]
[-- Type: text/plain, Size: 725 bytes --]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Drew Adams]

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.

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

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

[-- Attachment #2: test.el --]
[-- Type: application/emacs-lisp, Size: 1340 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Juri Linkov]

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

bug#4147: 23.1.50: Info-search command strange behaviour

[martin rudalics]

 > 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

bug#4147: 23.1.50: Info-search command strange behaviour

[Eli Zaretskii]

> From: Juri Linkov <juri@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.

bug#4147: 23.1.50: Info-search command strange behaviour

[Glenn Morris]

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.