Re: bug in forward-visible-line: Patch

[Luc Teirlinck]

Stefan Monnier wrote:

   BTW, how about a `invisible-p' function that does above ?

Might be useful.  A correct version of the above, of course.  I
personally also see something wrong with it, but not the same thing
you seem to see.

   Especially since the above is wrong (the assq might match a cons
   cell like (foo . nil) which says that it's *not* invisible).

I do not believe that is what is wrong with it.

Documentation string of buffer-invisibility-spec:

    buffer-invisibility-spec's value is 
    ((silly)
     nonsense)

    Local in buffer killerstuff; global value is t
    Automatically becomes buffer-local when set in any fashion.

    Invisibility spec of this buffer.  The default is t, which means
    that text is invisible if it has a non-nil `invisible' property.
    If the value is a list, a text character is invisible if its
    `invisible' property is an element in that list.  If an element is
    a cons cell of the form (PROP . ELLIPSIS), then characters with
    property value PROP are invisible, and they have an ellipsis as
    well if ELLIPSIS is non-nil.


Note that the documentation string says that (foo . nil) means
that the character will get no ellipsis but will still be invisible.
I tried it out, it is true. (silly) above is equivalent with (silly
. nil) and silly newlines were invisible.

The documentation string above is wrong about something else, however.
Newlines with invisibility property '(aha ihi oho silly mia) are
invisible too, even though according to the documentation string they
should not be.  The documentation string should be corrected.

The (in as far as I know) correct description of buffer-invisibility-spec
can be found in C-h i g (elisp)Invisible Text.  forward-visible-line
fails to recognize newlines with invisible property '(aha ihi oho
silly mia) as invisible, even though they are.  That is what I believe
is wrong with the above code.

   A lot of code uses t as an invisible value that is assumed to
   always be invisible and nil for the opposite.  A recent change
   makes buffer-invisibility-spec always contain t so that t should
   indeed always be invisible,

What exactly do you mean?  After I reset buffer-invisibility-spec
without any problems to the above value, newlines with invisibility
property t became visible.  As long as that is the actual behavior,
forward-visible-line should treat them as such.  

   where the change is that nil and t are special values that do
   not depend on buffer-invisibility-spec.

In as far as t is concerned, only if the actual behavior would change,
not with the present behavior.

Sincerely,

Luc.