* bug#4147: 23.1.50: Info-search command strange behaviour
@ 2009-08-15 3:49 Jamie Lokier
2009-08-15 10:10 ` martin rudalics
2011-10-06 3:41 ` Glenn Morris
0 siblings, 2 replies; 25+ messages in thread
From: Jamie Lokier @ 2009-08-15 3:49 UTC (permalink / raw)
To: emacs-pretest-bug
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-08-15 3:49 bug#4147: 23.1.50: Info-search command strange behaviour Jamie Lokier
@ 2009-08-15 10:10 ` martin rudalics
2009-12-05 0:48 ` Juri Linkov
2011-10-06 3:41 ` Glenn Morris
1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2009-08-15 10:10 UTC (permalink / raw)
To: Jamie Lokier, 4147
[-- 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)
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-08-15 10:10 ` martin rudalics
@ 2009-12-05 0:48 ` Juri Linkov
2009-12-05 19:50 ` Juri Linkov
0 siblings, 1 reply; 25+ messages in thread
From: Juri Linkov @ 2009-12-05 0:48 UTC (permalink / raw)
To: martin rudalics; +Cc: 4147, Jamie Lokier
>> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-05 0:48 ` Juri Linkov
@ 2009-12-05 19:50 ` Juri Linkov
2009-12-08 20:12 ` Juri Linkov
0 siblings, 1 reply; 25+ messages in thread
From: Juri Linkov @ 2009-12-05 19:50 UTC (permalink / raw)
To: 4147; +Cc: Jamie Lokier
>>> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-05 19:50 ` Juri Linkov
@ 2009-12-08 20:12 ` Juri Linkov
2009-12-14 21:54 ` Juri Linkov
0 siblings, 1 reply; 25+ messages in thread
From: Juri Linkov @ 2009-12-08 20:12 UTC (permalink / raw)
To: 4147
>>>> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-08 20:12 ` Juri Linkov
@ 2009-12-14 21:54 ` Juri Linkov
2009-12-14 23:00 ` martin rudalics
2009-12-15 4:07 ` Eli Zaretskii
0 siblings, 2 replies; 25+ messages in thread
From: Juri Linkov @ 2009-12-14 21:54 UTC (permalink / raw)
To: 4147
> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-14 21:54 ` Juri Linkov
@ 2009-12-14 23:00 ` martin rudalics
2009-12-14 23:56 ` Juri Linkov
2009-12-15 4:07 ` Eli Zaretskii
1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2009-12-14 23:00 UTC (permalink / raw)
To: Juri Linkov, 4147
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-14 23:00 ` martin rudalics
@ 2009-12-14 23:56 ` Juri Linkov
2009-12-15 8:16 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Juri Linkov @ 2009-12-14 23:56 UTC (permalink / raw)
To: martin rudalics; +Cc: 4147
>> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-14 23:56 ` Juri Linkov
@ 2009-12-15 8:16 ` martin rudalics
2009-12-16 0:45 ` Juri Linkov
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2009-12-15 8:16 UTC (permalink / raw)
To: Juri Linkov; +Cc: 4147
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-15 8:16 ` martin rudalics
@ 2009-12-16 0:45 ` Juri Linkov
2009-12-16 7:53 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Juri Linkov @ 2009-12-16 0:45 UTC (permalink / raw)
To: martin rudalics; +Cc: 4147
>> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-16 0:45 ` Juri Linkov
@ 2009-12-16 7:53 ` martin rudalics
2009-12-16 9:17 ` Juri Linkov
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2009-12-16 7:53 UTC (permalink / raw)
To: Juri Linkov; +Cc: 4147
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-16 7:53 ` martin rudalics
@ 2009-12-16 9:17 ` Juri Linkov
2009-12-16 15:04 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Juri Linkov @ 2009-12-16 9:17 UTC (permalink / raw)
To: martin rudalics; +Cc: 4147
> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-16 9:17 ` Juri Linkov
@ 2009-12-16 15:04 ` martin rudalics
2009-12-16 19:21 ` Drew Adams
[not found] ` <87my1ibip3.fsf@mail.jurta.org>
0 siblings, 2 replies; 25+ messages in thread
From: martin rudalics @ 2009-12-16 15:04 UTC (permalink / raw)
To: Juri Linkov; +Cc: 4147
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-16 15:04 ` martin rudalics
@ 2009-12-16 19:21 ` Drew Adams
[not found] ` <87my1ibip3.fsf@mail.jurta.org>
1 sibling, 0 replies; 25+ messages in thread
From: Drew Adams @ 2009-12-16 19:21 UTC (permalink / raw)
To: 'martin rudalics', 4147, 'Juri Linkov'
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <87my1ibip3.fsf@mail.jurta.org>]
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-12-14 21:54 ` Juri Linkov
2009-12-14 23:00 ` martin rudalics
@ 2009-12-15 4:07 ` Eli Zaretskii
1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2009-12-15 4:07 UTC (permalink / raw)
To: Juri Linkov, 4147
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#4147: 23.1.50: Info-search command strange behaviour
2009-08-15 3:49 bug#4147: 23.1.50: Info-search command strange behaviour Jamie Lokier
2009-08-15 10:10 ` martin rudalics
@ 2011-10-06 3:41 ` Glenn Morris
1 sibling, 0 replies; 25+ messages in thread
From: Glenn Morris @ 2011-10-06 3:41 UTC (permalink / raw)
To: 4147-done
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2011-10-06 3:41 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-15 3:49 bug#4147: 23.1.50: Info-search command strange behaviour Jamie Lokier
2009-08-15 10:10 ` martin rudalics
2009-12-05 0:48 ` Juri Linkov
2009-12-05 19:50 ` Juri Linkov
2009-12-08 20:12 ` Juri Linkov
2009-12-14 21:54 ` Juri Linkov
2009-12-14 23:00 ` martin rudalics
2009-12-14 23:56 ` Juri Linkov
2009-12-15 8:16 ` martin rudalics
2009-12-16 0:45 ` Juri Linkov
2009-12-16 7:53 ` martin rudalics
2009-12-16 9:17 ` Juri Linkov
2009-12-16 15:04 ` martin rudalics
2009-12-16 19:21 ` Drew Adams
[not found] ` <87my1ibip3.fsf@mail.jurta.org>
[not found] ` <4B29E99D.9060501@gmx.at>
2009-12-17 23:34 ` Juri Linkov
[not found] ` <4B2B318A.7010300@gmx.at>
2009-12-19 0:30 ` Juri Linkov
2009-12-19 9:09 ` martin rudalics
2009-12-21 0:34 ` Juri Linkov
2009-12-21 8:21 ` martin rudalics
2009-12-19 0:45 ` Juri Linkov
2009-12-19 9:09 ` martin rudalics
2009-12-21 0:36 ` Juri Linkov
2009-12-21 8:21 ` martin rudalics
2009-12-15 4:07 ` Eli Zaretskii
2011-10-06 3:41 ` Glenn Morris
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).