Re: 22.1.50; newsticker and buffer-invisibility-spec:

[T. V. Raman]

Its bizarre use of buffer-invisibility-spec was triggering a bug
in the context of Emacspeak. I've fixed my code to work around it
-- but it would be good to get newsticker fixed up to match
emacs' use of buffer-invisibility-spec.



>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:
    >> I've not used newsticker in a while, and I noticed today
    >> that there seems to be a problem with the way
    >> buffer-invisibility-spec is getting handled in newsticker
    >> buffers.
    Stefan> 
    >> Could someone who can see the display look at it and
    >> confirm that there is a problem, or that it is indeed
    >> doing the right thing so I can chase this down further?
    Stefan> 
    Stefan> I don't know how to run the newsticker code to try it
    Stefan> out, but the code looks odd indeed: it presumes that
    Stefan> the invisibility property can be a list of values and
    Stefan> that if one of those values is a member of
    Stefan> buffer-invisibility-spec then the text is invisible.
    Stefan> But in reality, the invisible property is not treated
    Stefan> as a list, its value (which could presumably be a
    Stefan> list, but that would be asking for trouble) is
    Stefan> directly looked up in buffer-invisibility-spec.
    Stefan> I.e. newsticker--lists-intersect-p (which is always
    Stefan> called with (get-text-property FOO 'invisible) as
    Stefan> first arg and buffer-invisibility-spec as second, so
    Stefan> it should really be replaced by a new function
    Stefan> newsticker--invisible-p) should be
    Stefan> newsticker--list-member-p or somesuch.
    Stefan> 
    Stefan> But fixing this function is not enough because the
    Stefan> rest of the code makes use of the nonexistent
    Stefan> feature.  I've looked at the XEmacs-21.4.20 docstring
    Stefan> for buffer-invisibility-spec and it doesn't seem to
    Stefan> document such an extension either, so I have no idea
    Stefan> in which circumstance this code may work.
    Stefan> 
    Stefan> The problematic code was part of the 1.1 revision
    Stefan> (checked in on 12 Sep 2005), so there's no change log
    Stefan> to explain the problem.
    Stefan> 
    Stefan> 
    Stefan>         Stefan
    Stefan> 
    Stefan> 
    Stefan> _______________________________________________
    Stefan> Emacs-devel mailing list address@hidden
    Stefan> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  address@hidden
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: address@hidden
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs