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

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

bug#15312: Info (point-entered, point-left): Doc incomplete, hence incor


From: Jambunathan K
Subject: bug#15312: Info (point-entered, point-left): Doc incomplete, hence incorrect
Date: Fri, 13 Sep 2013 21:50:20 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Sorry, I don't understand what you are saying about the original issue
>> with point-entered/left.  Are you saying that the code works
>> correctly, or are you saying it has a bug?
>
> That the code that uses the `point-entered/left' property (just like
> the code that uses the other mentioned properties like `display',
> `mouse-face', ...) considers runs of characters with the same property
> value as belonging together; which means that the text-property is used
> to specify a kind of interval.

    (mapc
     (lambda (s)
       (insert (propertize s  'mouse-face font-lock-comment-face)))
     '("ab" "cd"))

The intention of the programmer in the above case MAY have been to treat
"ab" and "cd" differently.  

But the way Emacs deals with them, it considers "abcd" as a single
stretch and they are highlighted together.

    (insert (propertize "ab"  'mouse-face font-lock-comment-face))
    (insert (propertize "cd"  'mouse-face font-lock-function-name-face))

> Clearly, this disagrees with:
>
>     ,----  (info "(elisp) Not Intervals")
>     | "What are the properties of this character?"  So we have decided these
>     | are the only questions that make sense; we have not implemented asking
>     | questions about where intervals start or end.
>     `----
>
> And actually the above text is incorrect/incomplete in the sense that
> next-single-property-change clearly implements a functionality that lets
> you "ask questions about where intervals start or end".

I don't really don't treat documentation as bible, because I am not a
Christian.  Actually I am a pagan.

My argument is that and has been this:

1. Documentation is incomplete.

2. IRL, two hotels belonging to different owners sitting on adjacent
   plots is unlikely look the same and painted the with same color.  

   I don't consider implementation as buggy.  Implementation has it's
   limitations but the limitations are reasonable.  

   The limitations should be documented.  Also, there are gotchas.

3. In a parsed-context, the parser can easily identify "the span" of a
   given character.  So insisting that there be text properties other
   than point-entered could be limiting.  

   In the example cited, the point-entered propery is ALWAYS ON meaning
   it is mode-local or buffer-local.

>         Stefan





reply via email to

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