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

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

[Jambunathan K]

The info doc (see below) makes no mention of intervals/text properties.
It should mention what intervals.c actually does.

,---- From intervals.c
|   /* We run point-left and point-entered hooks here, if the
|      two intervals are not equivalent.  These hooks take
|      (old_point, new_point) as arguments.  */
`----


,---- (info "(elisp) Special Properties")
| `point-entered'
| `point-left'
|      The special properties `point-entered' and `point-left' record
|      hook functions that report motion of point.  Each time point
|      moves, Emacs compares these two property values:
| 
|         * the `point-left' property of the character after the old
|           location, and
| 
|         * the `point-entered' property of the character after the new
|           location.
| 
|      If these two values differ, each of them is called (if not `nil')
|      with two arguments: the old value of point, and the new one.
`----

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

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Mon, 09 Sep 2013 19:04:59 +0530
> 
> 
> The info doc (see below) makes no mention of intervals/text properties.
> It should mention what intervals.c actually does.

What exactly does it not mention now, and under which circumstances
will a Lisp programmer see that?

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

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jambunathan K <kjambunathan@gmail.com>
>> Date: Mon, 09 Sep 2013 19:04:59 +0530
>> 
>> 
>> The info doc (see below) makes no mention of intervals/text properties.
>> It should mention what intervals.c actually does.
>
> What exactly does it not mention now, 

About text properties.  They need to be different.

> and under which circumstances will a Lisp programmer see that?

Does this question mean when will point-entered and point-left hook be
used (or used at all)?  I suggest that you look at table.el, gomoku.el,
landmark.el et.al.
----------------------------------------------------------------

Copy the snippet below to *scratch* buffer and eval them.  (I assume
that your *scratch* buffer is in emacs-lisp-mode and is colorful)

Keep C-f-ing and C-b-ing and see what happens.

You will see that entered and left get triggered when you move from a
text that has one face to another, NOT when they have the same faces.

    (defun --point-entered (&rest args)
      (message "entered: %s" args))

    (defun --point-left (&rest args)
      (message "left: %s" args))

    (add-text-properties (point-min) (point-max) 
                         '(point-left --point-left
                                      point-entered --point-entered))

----------------------------------------------------------------

Doc (makes) an (incomplete and) incorrect claim that the triggering of
hook depends SOLELY on the value of point-left and point-entered
properties.  It is NOT so.  The values of TEXT PROPERTIES should be
DIFFERENT at the transition point.

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

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> About text properties.

I was thinking where the confusion was coming from...

For emphasis and your clarity

It is "text properties" taken as a WHOLE.  Comments in intervals.c terms
it as "intervals being equivalent"

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

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: 15312@debbugs.gnu.org
> Date: Tue, 10 Sep 2013 09:03:56 +0530
> 
> Copy the snippet below to *scratch* buffer and eval them.  (I assume
> that your *scratch* buffer is in emacs-lisp-mode and is colorful)
> 
> Keep C-f-ing and C-b-ing and see what happens.
> 
> You will see that entered and left get triggered when you move from a
> text that has one face to another, NOT when they have the same faces.
> 
>     (defun --point-entered (&rest args)
>       (message "entered: %s" args))
> 
>     (defun --point-left (&rest args)
>       (message "left: %s" args))
> 
>     (add-text-properties (point-min) (point-max) 
>                          '(point-left --point-left
>                                       point-entered --point-entered))

It is not clear to me where did you expect the hooks to be called,
based on the documentation.  Was it for every character? only at
point-min and point-max? something else?

And in any case, why do you assume this is a documentation bug, as
opposed to a bug in the implementation?

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

[Jambunathan K]

>>     (defun --point-entered (&rest args)
>>       (message "entered: %s" args))
>> 
>>     (defun --point-left (&rest args)
>>       (message "left: %s" args))
>> 
>>     (add-text-properties (point-min) (point-max) 
>>                          '(point-left --point-left
>>                                       point-entered --point-entered))
>
> It is not clear to me where did you expect the hooks to be called,
> based on the documentation.  

> Was it for every character? 

Based on documentation.  Yes, for every char.

> only at point-min and point-max? 

No.

> And in any case, why do you assume this is a documentation bug

I am not ASSUMING that it is a doc bug.  It IS a doc bug.  The doc IS
obviously not matching the implementation.

> as opposed to a bug in the implementation?

Well, if you want to promote this report to a bug in implementation, I
have no reservations.  But the onus is in on YOU to argue on what counts
it can be deeemed as a bug in implementation.

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

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: 15312@debbugs.gnu.org
> Date: Wed, 11 Sep 2013 15:25:56 +0530
> 
> > And in any case, why do you assume this is a documentation bug
> 
> I am not ASSUMING that it is a doc bug.  It IS a doc bug.  The doc IS
> obviously not matching the implementation.

When 2 things don't match, one or the other might need to be fixed,
and additional arguments are generally needed to decide which one.

> the onus is in on YOU to argue on what counts it can be deeemed as a
> bug in implementation.

Very simple: it doesn't make any sense to me to call the hooks when
the value of each property does not change as point moves.

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

[Jambunathan K]

Eli

> Info (point-entered, point-left): Doc incomplete, hence incorrect

You asked for a wall-of-text.  Here you go.

----------------------------------------------------------------
Imagery:


If a hotel is interested in taking visitors why should it even care how
it is painted or that it be painted differently from the neighbouring
hotels?

----------------------------------------------------------------
Unask the question:


Consider the following scenario?

    1. The WHOLE buffer has the SAME point-visited property.
    2. The whole buffer has NO OTHER text properties applied to it.

Under the above conditions, can the user use the point-visited property
achieve a sensible behaviour.

The answer is an emphatic YES.  Read on.

----------------------------------------------------------------

On relevance and expedience:


You are making a WRONG ASSUMPTION that text properties MUST flip-flop.

The flip-flopping of text properties is a mere chunking trick to
rate-limit point visited calls.  It is a requirement IMPOSED FROM
OUTSIDE (and which can usually be met in practice) but is not GERMANE to
the problem at hand.


----------------------------------------------------------------

What (usually) are text properties, in this context?

In this context, the text properties act as a pre-computed syntactic
context.  The requirement that properties flip-flop is but a way of
saying that a stretch of text be syntactically different from the
surrounding text.


----------------------------------------------------------------

Can uniqueness be expressed in other ways, apart from text properties?


Yes.  With parsers, it is possible to infer a context JUST-IN-TIME.
Should parsers be expected to decorated text?  Not necessary.  There
could be reasons why parsers don't decorate text.  One reason could be
that it is young.  One example, is the Org parser.  (Font-locking and
the ppss stuff is just a poor man's parser)

----------------------------------------------------------------

Stop the bullshit.  Give an example?

See
http://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00425.html

    (add-hook 'org-mode-hook
              (lambda nil
                (setq-local default-text-properties
                            '(point-entered org-link-entered-maybe))))

    (defun org-link-entered-maybe (op np)
      (when (derived-mode-p 'org-mode)
        ;; (message "In org-link-entered-maybe")
        (let* ((inhibit-point-motion-hooks t)
               (ctx (org-element-context)))
          (when (eq 'link (org-element-type ctx))
            (tooltip-show (org-element-property :raw-link ctx)
                          (not 'use-echo-area))))))


In the above example, the context - that the character is part of a link
- is computed JIT to pop open a tooltip that shows the underlying URL.

----------------------------------------------------------------

Can text properties express rich context with less OVERHEADS?


Text properties (typically) break the text in to pieces.  They can
express UNIQUENESS.  Can they express the much richer, UNIQUENESS and
CONTAINMENT - I am an Org link, within the second item, of the third
level list within 4 th level heading - in a fully-synced manner.

I think the answer is NO.

Since Text Properties are pre-computed text, it becomes messy to keep
them in SYNC with an ever-changing text.

Expressed simply, JIT eliminates the caches and problems associated with
it.

----------------------------------------------------------------

In what ways can a character be special?


A character can be special for the following reasons

1. Syntactic:  It's position in the buffer text - A hyperlink, variable
   name etc.

2. Spatial: A character that belongs to the margins.  i.e., to the left
   of `left-margin'.


----------------------------------------------------------------


Text properties cannot express spatial uniqueness


Can text properties be used for expressing spatial uniqueness?  Good
luck with it.  

----------------------------------------------------------------

Spatial uniqueness and text properties. 


I am noting this only because this was the primary motivation to explore
point-visited properties in first place.

    How to edit a left-marginned text and make sure that point never
    rests on the margin area.  Think of a diary or a todo item.  They
    are a MIX of indented and un-indented text.

Left-marginned text, no problem?

    (setq left-margin 16)
    (setq indent-line-function 'indent-to-left-margin)

I want C-p and C-n to actively seek indented text.  No problem.

    C-x C-n

I want C-a not to actively rest within on text area and NEVER stray in
to the margins.  I am at a total loss here.  How will I do it?  


1. Play with tangibility of `\n +'.  I need to mess with
   `indent-line-function'.  I don't want to keep decorating and
   un-decorating a character for spatial reasons.

2. Let me look at other possiblities.  Ha! point-entered and point-left
   looks interesting. 

   ;; Within point-entered property.
   (if ( < (current-column) left-margin)
       (goto-char left-margin))

   This is very wonderful, I don't even have to set the goal column.

3. Hmm! Doesn't work.  Why?  Because document sucks?

----------------------------------------------------------------
   

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

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> You asked for a wall-of-text.  Here you go.

From a philosphical standpoint, the Info manual makes the following
observation.

,----  (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.
`----

I think this is relevant to the discussion at hand.

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

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: 15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 11:45:57 +0530
> 
> Jambunathan K <kjambunathan@gmail.com> writes:
> 
> > You asked for a wall-of-text.  Here you go.
> 
> >From a philosphical standpoint, the Info manual makes the following
> observation.
> 
> ,----  (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.
> `----
> 
> I think this is relevant to the discussion at hand.

Sorry, I don't see how it is relevant.  The issue at hand is not what
are text properties and what they aren't in general.  The issue is
specifically how point-entered and point-left hooks should be called,
and on what conditions.

Your references to a comment in intervals.c is a methodological
mistake, because (a) it takes an implementation peculiarity as a sign
of something that should be present in the documentation, and (b) it
side-tracks the discussion into the area of "intervals" and what they
are, something that the Lisp level should be oblivious to.

So I suggest to return to the Lisp level, where there are no
intervals, only text properties that are present or absent at certain
buffer positions.

To make my point clear: it makes very little sense to me to invoke the
motion hooks depending on whether some other text properties changed
as well.  Motion hooks should have no relation whatsoever to any other
text property, such as face or whatever.

So, to me, the code definitely has some bug, the question is which one
and how to fix it.  It is not easy to know how to fix it, because the
documentation is ambiguous and can be interpreted in more than one way
(of which you picked up one).  We should agree on the interpretation
before we decide how to fix the code and the doc.

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

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

> To make my point clear: it makes very little sense to me to invoke the
> motion hooks depending on whether some other text properties changed
> as well.  Motion hooks should have no relation whatsoever to any other
> text property, such as face or whatever.

We are talking about the same thing.

> So, to me, the code definitely has some bug, the question is which one
> and how to fix it.  It is not easy to know how to fix it, because the
> documentation is ambiguous and can be interpreted in more than one way
> (of which you picked up one).  We should agree on the interpretation
> before we decide how to fix the code and the doc.

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

[Stefan Monnier]

> ,----  (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.
> `----

We should indeed amend the above: while text-properties indeed only
apply to individual characters, and are not intervals (contrary to
overlays), there are several places where we consider runs of
consecutive characters that share the same property value (and more
specifically, we use `eq' as the equality predicate in those cases).

This is the case for example for `mouse-face' since we don't just want
to highlight the character under the mouse.

It's also the case for point-entered/left, otherwise "entering/leaving"
is kind of meaningless (remember that point is never in/on a character,
but always between 2 characters).

It can be important to know how the boundaries of such regions is
determined (i.e. by checking `eq'uality of property value of consecutive
characters), since it is sometimes necessary to copy such a value in
order to explicitly split such an "interval" (e.g. if two consecutive
words need to use `mouse-face' with the same face, but where the two
words should not be highlighted together).

Other than the above 3 properties, I also know of `display',
`font-lock-multiline', and `jit-lock-defer-multiline' behaving in
this way.  Any other?

I think rather than "intervals", we could call those "runs".


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 09:12:49 -0400
> 
> > ,----  (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.
> > `----
> 
> We should indeed amend the above: while text-properties indeed only
> apply to individual characters, and are not intervals (contrary to
> overlays), there are several places where we consider runs of
> consecutive characters that share the same property value (and more
> specifically, we use `eq' as the equality predicate in those cases).
> 
> This is the case for example for `mouse-face' since we don't just want
> to highlight the character under the mouse.
> 
> It's also the case for point-entered/left, otherwise "entering/leaving"
> is kind of meaningless (remember that point is never in/on a character,
> but always between 2 characters).

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?

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

[Stefan Monnier]

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

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


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kjambunathan@gmail.com,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 11:15:10 -0400
> 
> > 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.

Sorry, I'm still in the dark.  Does the code presented in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15312#11 work correctly
and as expected, or does it not?  If the latter, what would you expect
that code to do instead?

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

Actually, it doesn't disagree, if you keep in mind what RMS meant when
he wrote that text (intervals can and do overlap, while runs of text
properties cannot).  But IMO that is a completely different issue.
The original issue raised by this report was about point-entered/left
hooks, and the code presented in the above URL illustrates the issue.
I suggest that we solve that issue first.

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

[Stefan Monnier]

> Sorry, I'm still in the dark.  Does the code presented in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15312#11 work correctly
> and as expected, or does it not?

AFAICT, yes, it works fine.  The problem is one of documentation.

>> 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".
> Actually, it doesn't disagree, if you keep in mind what RMS meant when
> he wrote that text (intervals can and do overlap, while runs of text
> properties cannot).

Right.  But it just goes to show that the situation is more subtle.
We should describe it more fully.

> But IMO that is a completely different issue.

IMO it is this exact issue.

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

you mean
     
    (dolist (s '("ab" "cd"))
      (insert (propertize s  'mouse-face font-lock-comment-face)))

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

Yes, exactly.  If you want them to appear separate you need to arrange
for the value to be non-eq, e.g.:

    (dolist (s '("ab" "cd"))
      (insert (propertize s  'mouse-face (list font-lock-comment-face))))


-- Stefan

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

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Sorry, I'm still in the dark.  Does the code presented in
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15312#11 work correctly
>> and as expected, or does it not?
>
> AFAICT, yes, it works fine.  The problem is one of documentation.

Turn off font-locking :-).  It wouldn't work.

> Jambunathan wrote:
>>    (mapc
>>     (lambda (s)
>>       (insert (propertize s  'mouse-face font-lock-comment-face)))
>>     '("ab" "cd"))
>
> you mean
>      
>     (dolist (s '("ab" "cd"))
>       (insert (propertize s  'mouse-face font-lock-comment-face)))

Is that a convention or there is more to it?  They do the same thing,
right?

If you ask me, the fact there are two chunks can be inferred by saying
that they were added as two different calls.

>> 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.
>
> Yes, exactly.  If you want them to appear separate you need to arrange
> for the value to be non-eq, e.g.:
>
>     (dolist (s '("ab" "cd"))
>       (insert (propertize s  'mouse-face (list font-lock-comment-face))))

You are cloning a face here?

Are there any workarounds when the value of the text property is a
function or a value type.  How can we have clones of a function (or a
symbol)?  How can we clone a value type like Integer?  May be there is a
way to turn a Value in to a Object? (In C# world, it is called "Boxing")

> -- Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kjambunathan@gmail.com,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 12:28:14 -0400
> 
> > Sorry, I'm still in the dark.  Does the code presented in
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15312#11 work correctly
> > and as expected, or does it not?
> 
> AFAICT, yes, it works fine.

Then please explain why it makes sense to call or not call these hooks
depending on whether some other unrelated text property changed at
point.

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

[Stefan Monnier]

>> > Sorry, I'm still in the dark.  Does the code presented in
>> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15312#11 work correctly
>> > and as expected, or does it not?
>> AFAICT, yes, it works fine.
> Then please explain why it makes sense to call or not call these hooks
> depending on whether some other unrelated text property changed at
> point.

Hmm... I missed that part.  So it's sensitive to the C-level division
into "struct interval"?  That would be a bug, indeed.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kjambunathan@gmail.com,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 13:18:37 -0400
> 
> >> > Sorry, I'm still in the dark.  Does the code presented in
> >> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15312#11 work correctly
> >> > and as expected, or does it not?
> >> AFAICT, yes, it works fine.
> > Then please explain why it makes sense to call or not call these hooks
> > depending on whether some other unrelated text property changed at
> > point.
> 
> Hmm... I missed that part.  So it's sensitive to the C-level division
> into "struct interval"?  That would be a bug, indeed.

The problem, as I see it, is here:

  /* We run point-left and point-entered hooks here, if the
     two intervals are not equivalent.  These hooks take
     (old_point, new_point) as arguments.  */
  if (NILP (Vinhibit_point_motion_hooks)
      && (! intervals_equal (from, to)
	  || ! intervals_equal (fromprev, toprev)))
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The intervals_equal test causes the whole code below that to be
skipped if each one of the point-entered and point-left properties
don't change between position POS and POS+1, and no other properties
change between those two positions.  When some other property does
change between those two positions, the hooks are called if
point-entered is different from point-left.  (Personally, I think this
test is just an attempt to optimize costly text property comparisons
when they are not necessary.)

To get this right, we need to decide what is the correct behavior in
this case.  Do we want the hooks to be called for each point motion,
or do we want them to be called only at point-min and point-max?

The documentation is not 100% clear, but it seems to imply that the
hooks shall be called for each movement, because point-entered is
different from point-left.  FWIW, this behavior won't make sense to
me, because there's no reason for point-entered and point-left to be
identical in the general case: each one of them reacts to a different
event.  But that's me.

Depending on what we think should be the correct behavior, we may or
may not need to fix the documentation.

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

[Stefan Monnier]

> (Personally, I think this test is just an attempt to optimize costly
> text property comparisons when they are not necessary.)

Agreed.

> To get this right, we need to decide what is the correct behavior in
> this case.  Do we want the hooks to be called for each point motion,
> or do we want them to be called only at point-min and point-max?

I think the correct thing to do is too costly for an operation that's
performed every time we move point.

The right thing to do is to declare point-entered and point-left
properties as obsolete and replace them by something like cursor-entered
and cursor-left properties which are only checked at command boundaries
(or better, checked just before redisplay).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kjambunathan@gmail.com,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 16:32:16 -0400
> 
> > To get this right, we need to decide what is the correct behavior in
> > this case.  Do we want the hooks to be called for each point motion,
> > or do we want them to be called only at point-min and point-max?
> 
> I think the correct thing to do is too costly for an operation that's
> performed every time we move point.

So you think in this specific situation the hooks need indeed be
called for each point move?  Or did you mean something else as "the
correct thing"?

Perhaps we need to step back and talk about the situations where these
hooks are supposed to be used.  Because I cannot see any sense in
calling the hooks when the values of these properties don't change.
Maybe you already thought about all that, and the conclusion is the
same, but I think for the record it is important to have the
discussion here.

> The right thing to do is to declare point-entered and point-left
> properties as obsolete and replace them by something like cursor-entered
> and cursor-left properties which are only checked at command boundaries
> (or better, checked just before redisplay).

Redisplay can be forced as part of a command.

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

[Stefan Monnier]

> Perhaps we need to step back and talk about the situations where these
> hooks are supposed to be used.  Because I cannot see any sense in
> calling the hooks when the values of these properties don't change.

Agreed, but the code also runs the hook when the value of the
`point-entered' does not change but the value of some unrelated
property changes.  That is an error.

>> The right thing to do is to declare point-entered and point-left
>> properties as obsolete and replace them by something like cursor-entered
>> and cursor-left properties which are only checked at command boundaries
>> (or better, checked just before redisplay).
> Redisplay can be forced as part of a command.

I know, and I think that for most uses of these kinds of properties we'd
also want to run the hook when redisplay is called in the middle of
a command (e.g. in the middle of query-replace).  Note that we'd probably
also want to run the hook when redisplay is short-circuited by pending input.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: kjambunathan@gmail.com, 15312@debbugs.gnu.org
> Date: Mon, 16 Sep 2013 12:15:27 -0400
> 
> > Perhaps we need to step back and talk about the situations where these
> > hooks are supposed to be used.  Because I cannot see any sense in
> > calling the hooks when the values of these properties don't change.
> 
> Agreed, but the code also runs the hook when the value of the
> `point-entered' does not change but the value of some unrelated
> property changes.  That is an error.

Of course.  But I was trying to say that we should formulate a clear
specification for when these hooks shall be called.  What the manual
says now makes little sense to me (and is also somewhat vague).

> >> The right thing to do is to declare point-entered and point-left
> >> properties as obsolete and replace them by something like cursor-entered
> >> and cursor-left properties which are only checked at command boundaries
> >> (or better, checked just before redisplay).
> > Redisplay can be forced as part of a command.
> 
> I know, and I think that for most uses of these kinds of properties we'd
> also want to run the hook when redisplay is called in the middle of
> a command (e.g. in the middle of query-replace).  Note that we'd probably
> also want to run the hook when redisplay is short-circuited by pending input.

Calling this from redisplay might need some non-trivial protocol,
because the hook can legitimately move point, which will re-enter
redisplay, which will call the hook...

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

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> 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

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

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 21:50:20 +0530
> 
>     (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.

That's not because of the text properties, but because mouse-highlight
implementation is explicitly coded that way.

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

[Stefan Monnier]

> That's not because of the text properties, but because mouse-highlight
> implementation is explicitly coded that way.

It's done elsewhere, indeed, but to the user the end-result is the same:
the text-properties end up describing an interval-ish thing.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jambunathan K <kjambunathan@gmail.com>,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 13:19:54 -0400
> 
> > That's not because of the text properties, but because mouse-highlight
> > implementation is explicitly coded that way.
> 
> It's done elsewhere, indeed, but to the user the end-result is the same:
> the text-properties end up describing an interval-ish thing.

Interval-ish and "intervals" are not the same.  Intervals can (and do)
overlap, and they actually represent a tree of text extents.  Text
properties cannot overlap.

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

[Stefan Monnier]

>> > That's not because of the text properties, but because mouse-highlight
>> > implementation is explicitly coded that way.
>> It's done elsewhere, indeed, but to the user the end-result is the same:
>> the text-properties end up describing an interval-ish thing.
> Interval-ish and "intervals" are not the same.  Intervals can (and do)
> overlap, and they actually represent a tree of text extents.  Text
> properties cannot overlap.

I the manual, we do not formally define "interval", so I think that
something that describes a contiguous sequence of characters *is* an
interval in that context, even if it's not necessarily an
interval-in-the-particular-sense-discussed-nearby.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kjambunathan@gmail.com,  15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 16:35:09 -0400
> 
> >> > That's not because of the text properties, but because mouse-highlight
> >> > implementation is explicitly coded that way.
> >> It's done elsewhere, indeed, but to the user the end-result is the same:
> >> the text-properties end up describing an interval-ish thing.
> > Interval-ish and "intervals" are not the same.  Intervals can (and do)
> > overlap, and they actually represent a tree of text extents.  Text
> > properties cannot overlap.
> 
> I the manual, we do not formally define "interval", so I think that
> something that describes a contiguous sequence of characters *is* an
> interval in that context, even if it's not necessarily an
> interval-in-the-particular-sense-discussed-nearby.

Then perhaps the right place for some such text is in "Property
Search", where those "intervals" are called "chunks of text that have
the same property value".

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

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: 15312@debbugs.gnu.org
> Date: Fri, 13 Sep 2013 10:52:25 +0530
> 
> > Info (point-entered, point-left): Doc incomplete, hence incorrect
> 
> You asked for a wall-of-text.

No, I didn't.  Sorry, didn't read past this point.  Maybe my other
message hits the point; if not, please consider being more concise
and on-topic next time.

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

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]


Eli

Eli Zaretskii <eliz@gnu.org> writes:

> No, I didn't.  Sorry, didn't read past this point.  Maybe my other
> message hits the point; if not, please consider being more concise and
> on-topic next time.

This is an insult.

I invite you to look at my topmost post and comparte that to your
postmortem.  It points to the precise position in intervals.c which
creates an unexpected behaviour.

FYI, I was interested in moving Overlays to Interval trees and add
support for Text layers.  I am attaching some notes on Overlays that I
took, just so that you know I not bull-shitting.  Due to various
developments on this and related mailing lists, I have put that work on
hold.

Now, I am positively certain that if I continue to be part of this list
and the "other" mailing lists, I only come across as someone who as no
self-respect.

So Good bye to this list,

Jambunathan K.


[-- Attachment #2: Overlays.png --]
[-- Type: image/png, Size: 30125 bytes --]

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

[Jambunathan K]

No thanks for working on this.  

OP here.  Closed.