22.1.50; newsticker and buffer-invisibility-spec:

22.1.50; newsticker and buffer-invisibility-spec:

[raman]

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.

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?


In GNU Emacs 22.1.50.21 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-08-18 on labrador
configured using `configure  '--prefix=/usr/local' '--with-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: nil

Major mode: Shell

Minor modes in effect:
  jabber-activity-mode: t
  dired-omit-mode: t
  dynamic-completion-mode: t
  shell-dirtrack-mode: t
  savehist-mode: t
  display-time-mode: t
  desktop-save-mode: t
  auto-insert-mode: t
  encoded-kbd-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t

Recent input:
h C-s RET ESC < ESC [ [ D C-x d C h * RET ESC > p f 
ESC < ESC > ESC [ [ D p p p p p p p p p n f ESC < C-s 
n e w s t i c k ESC m C-n C-e t C-n C-n C-n C-s C-s 
C-s C-s C-s C-s ESC m C-n C-h v i n v i s TAB ESC DEL 
i n v i TAB C-g C-n C-h v b u f f e r SPC i n v i TAB 
RET C-n C-s C-s C-n ESC [ [ D ESC [ [ D ESC [ [ D ESC 
x n e w s t i TAB s h o TAB n TAB s RET C-e m C-x 1 
C-n C-e x v 1 RET ESC < C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-e m C-n C-n ESC [ [ D ESC m ESC : b u f f e r - i 
n v i s i t b ESC DEL i n v i s i b i l i t y - s p 
e c RET ESC m C-e ESC v ESC : ( t e x t - p r o p ESC 
TAB i ESC TAB SPC ( p o i n t ) ) RET ESC m C-n ESC 
> C-p C-p RET p RET C-e m ESC m C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n q q C-x @ h m ' d q ESC x r e p o r t SPC e 
m TAB b TAB RET

Recent messages:
Saving...
Saving file /home/raman/mbox...
Wrote /home/raman/mbox
Sorting for index file...
Stuffing index file...
Writing index file...
Wrote /home/raman/.mbox.idx
Writing index file... done
nil
Loading emacsbug...done

 Thanks, 
 --Raman

-- 
Best Regards,
--raman

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

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

[Tassilo Horn]

raman <raman@users.sf.net> writes:

Hi,

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

I use newsticker every day and I don't see any problems.  How can I
reproduce your problems?

Bye,
Tassilo

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

[Stefan Monnier]

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

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

I don't know how to run the newsticker code to try it out, but the code
looks odd indeed: it presumes that the invisibility property can be a list
of values and that if one of those values is a member of
buffer-invisibility-spec then the text is invisible.  But in reality, the
invisible property is not treated as a list, its value (which could
presumably be a list, but that would be asking for trouble) is directly
looked up in buffer-invisibility-spec.
I.e. newsticker--lists-intersect-p (which is always called with
(get-text-property FOO 'invisible) as first arg and buffer-invisibility-spec
as second, so it should really be replaced by a new function
newsticker--invisible-p) should be newsticker--list-member-p or somesuch.

But fixing this function is not enough because the rest of the code makes
use of the nonexistent feature.  I've looked at the XEmacs-21.4.20 docstring
for buffer-invisibility-spec and it doesn't seem to document such an
extension either, so I have no idea in which circumstance this code
may work.

The problematic code was part of the 1.1 revision (checked in on 12 Sep
2005), so there's no change log to explain the problem.


        Stefan

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

[T. V. Raman]

This was a bug on my end.

>>>>> "Tassilo" == Tassilo Horn <tassilo@member.fsf.org> writes:
    Tassilo> raman <raman@users.sf.net> writes: Hi,
    Tassilo> 
    >> 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.
    >> 
    >> 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?
    Tassilo> 
    Tassilo> I use newsticker every day and I don't see any
    Tassilo> problems.  How can I reproduce your problems?
    Tassilo> 
    Tassilo> Bye, Tassilo
    Tassilo> 
    Tassilo> 
    Tassilo> 
    Tassilo> _______________________________________________
    Tassilo> Emacs-devel mailing list Emacs-devel@gnu.org
    Tassilo> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

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

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 <monnier@iro.umontreal.ca> 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 Emacs-devel@gnu.org
    Stefan> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

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

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

[Ulf Jasper]

"T. V. Raman" <raman@users.sf.net> writes:
> 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.

I'll have a look the next days.

Ulf

-- 
ANMERKUNG: Zwecks nicht notwendiges zu vermeiden verzögert und
Komplikationen, erinnern bitte sich deinen Hinweis und Kuponzahlen in
allen zu veranschlagen Korrespondenzen mit deinem Ansprüche Direktor.

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

[Ulf Jasper]

> "T. V. Raman" <raman@users.sf.net> writes:
>> 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.

Newsticker sets `buffer-invisibility-spec´ to a list like '(ATOM1
ATOM2 ... ATOMn). It also sets the 'invisible text property to a list
like ´(ATOMi ... ATOMk). If I understand the Elisp manual (for GNU
Emacs 22.1) correctly,
----------------------------------------------------------------------
 -- Variable: buffer-invisibility-spec
     This variable specifies which kinds of `invisible' properties
     actually make a character invisible.  Setting this variable makes
     it buffer-local.

    `t'
          A character is invisible if its `invisible' property is
          non-`nil'.  This is the default.

    a list
          Each element of the list specifies a criterion for
          invisibility; if a character's `invisible' property fits any
          one of these criteria, the character is invisible.  The list
          can have two kinds of elements:

         `ATOM'
               A character is invisible if its `invisible' property
               value is ATOM or if it is a list with ATOM as a member.

         `(ATOM . t)'
               A character is invisible if its `invisible' property
               value is ATOM or if it is a list with ATOM as a member.
               Moreover, if this character is at the end of a line and
               is followed by a visible newline, it displays an
               ellipsis.
----------------------------------------------------------------------
the usage of `buffer-invisibility-spec' and the 'invisible text
property is valid. In which case it is not "bizarre", not even "odd".

Ulf

-- 
ANMERKUNG: Zwecks nicht notwendiges zu vermeiden verzögert und
Komplikationen, erinnern bitte sich deinen Hinweis und Kuponzahlen in
allen zu veranschlagen Korrespondenzen mit deinem Ansprüche Direktor.

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

[Stefan Monnier]

>> "T. V. Raman" <raman@users.sf.net> writes:
>>> 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.

> Newsticker sets `buffer-invisibility-spec´ to a list like '(ATOM1
> ATOM2 ... ATOMn). It also sets the 'invisible text property to a list
> like ´(ATOMi ... ATOMk). If I understand the Elisp manual (for GNU
> Emacs 22.1) correctly,
[...]
> the usage of `buffer-invisibility-spec' and the 'invisible text
> property is valid. In which case it is not "bizarre", not even "odd".

Duh, you're absolutely right, and the C code agrees with the doc.
text-invisible-p needs to be updated accordingly.

Thanks for digging further and sorry for the false alarm,


        Stefan