emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: search in Info should not find "File", "Node" etc. in header


From: Drew Adams
Subject: RE: search in Info should not find "File", "Node" etc. in header
Date: Sun, 31 Oct 2004 12:35:46 -0800

Yes, I believe that may be a different bug, which I reported on 10/04
(subject line "In info, search for \btop\b finds end of last node name under
header if node is child of Top). That bug might already be in the process of
being fixed (see email from RMS, 10/07, below).

I don't know how things are implemented, so I don't know if fixing these
things is a reasonable thing to try now. Even if it's not worth the effort,
however, it's good to be aware of the bugs, I think.

Ignoring implementation difficulties, my point is that we should be able
somehow to separate _content_ in a manual from _structural and navigational
artifacts_ that support that content.

If such artifacts take the form of tags (for lack of a better word) that are
present, physically, in the buffer text, then perhaps a text property could
be added to the tag text so that the tags are not seen by search operations.
Your patch code makes me think that such an "invisible" property might
already be present. And your explanation makes me think that your fix might
take care of both bugs (search finding text such as "top" in the header line
and positioning cursor after the header; search finding text such as "file"
in the line following the header line).

Again, I'm ignorant of the actual implementation, so I don't pretend to
propose a solution.


-----Original Message-----From: Juri Linkov

> It's quite another thing to argue that 1) this bug has always been there
(so
> it's OK), 2) this isn't a bug (though it's an annoyance), or 3) fixing
this
> bug would mean treating a special implementation case.
>
> Call it an "annoyance" if you like. I call it a bug. The navigational
> keywords have no business being searched.

I would not call it a bug.  However, there is a real bug:
when `Info-use-header-line' is `t', part of the Info header
(prev/up/next links) is moved to the header line.  But Info-search
still searches in the hidden header parts, and when it finds a string
in the hidden part of the header it places the point at the end of the
header even if the found string is not visible there.

Fixing this bug requires adding complex code which takes into
account the value of `Info-use-header-line' and skips some parts
of the header line.  This looks wrong to me.  I think it's better
to skip the whole header line with the following simple change...

-----Original Message-----From: Richard Stallman

    The node has "top" in it...in the _info file_. The visible text of the
node
    does not contain the word "top". Users think in terms of what they see.

I am convinced.  If someone wants to change this, please go ahead.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]