Re: Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Jean Louis <bugs@gnu.support>]

* Drew Adams <drew.adams@oracle.com> [2024-05-15 23:57]:
> > I was of understanding that it is the regular
> > expression that decides what is on the point or not.
> 
> What regular expression?
> 
> Are you thinking of a regular expression that's
> checked to see if some particular kind of thing
> is at point, e.g. a regexp like the value of a
> var such as `thing-at-point-newsgroup-regexp'?
> 
> Such a regexp doesn't determine/define what "at
> point" means.

Maybe I have not call it right. I may explain it on the example:

;;; Thing at point 'iso-date

We assume that rcd-rx-iso-date ➜ "[[:digit:]][[:digit:]][[:digit:]][[:digit:]]-\\(?:0[[:digit:]]\\|1[0-2]\\)-\\(?:[0-2][[:digit:]]\\|3[01]\\)"

(defun rcd-tap-iso-date-start ()
  "Move point to the beginning of the ISO date."
  (when (thing-at-point-looking-at rcd-rx-iso-date)
    (goto-char (match-beginning 0))))

(defun rcd-tap-iso-date-end ()
  "Move point to the end of the ISO date."
  (when (thing-at-point-looking-at rcd-rx-iso-date)
    (goto-char (match-end 0))))

(put 'iso-date 'beginning-op 'rcd-tap-iso-date-start)
(put 'iso-date 'end-op 'rcd-tap-iso-date-end)

The definition of the thing at point is the one deciding what is the thing. And programmer is the one deciding where the thing actually begins. While user may have different view point where the thing at point begins, the actual definition is somewhere in the code and can be found and understood.

I could define that my ISO date is surrounded by spaces " 2024-05-16 " and user may assume that it is not: "2024-05-16", so the definition is in the code and left for programmers to decide how to define it. What if I wish that thing at point is anywhere on the line, regardless where is the cursor? While I did not try it out, I think that is quite feasible to do.

Then why try to make general STRICT, to try to affect specific random or indefinite definitions of code, instead, complaint or suggestion, patch on specific code can be made to make it stricter, or new code may be written to make that what other user wish to achieve.

> That movement is customizable (with properties
> `forward-op', `beginning-op', `end-op',
> `bounds-of-thing-at-point', `thing-at-point',
> and in other ways).  But the starting position
> is `(point)'; that's where the check is done.

Yes, I agree on everything you said with the exception not mentioned, and that is the consideration of programmer. Programmer may say that ISO date below is at point, when cursor or point is at X, and that ISO date shall be extracted or memorized, noted, etc. by follow up functions. It is matter of consideration.

..X.......................... 2024-05-16

ISO date need not be like below X to say that it is "at point" as it is matter of consideration. I see your words that you said the same what I am saying here.

2X24-05-16

> The bug is in `bounds-of-thing-at-point'.  It
> should be faithful to its name, and check only
> at (point), not at EITHER point OR (1- (point)).

1. The thing at point is defined by programmer.

2. What are bounds of thing at point is thus result of definition of programmer.

3. It implies that thing at point may be looking like having spaces or
   being forward or backwards from cursor, and still be considered at
   point, as that is defined by programmer.

I do not consider that a bug.

 2024-05-16

A cursors before the above ISO date is not captured, and after it, is not captured as thing at point.  I have tried it with M-: (thing-at-point 'iso-date), though I believe that other thing at point may be defined so to be sensed close to cursor, and that freedom is fine. What is the "bound" is defined by programmer not by function "bounds-of-thing-at-point".

> Even if the fix were to always check only at
> (1- (point)), instead of (point), it would be
> a legitimate fix for the problem caused by the
> ambiguity: there's _no way to determine whether_
> there's a thing at a given position.

I see that as freedom, and you see as ambiguity. Without looking into
the code and understanding it, isn't it all of the code at some point
ambiguity?

> IOW, it technically doesn't matter which single
> position is the "origin" for checking: (point)
> or (1- (point)) or whatever else.  The bug is
> that _no single_ position is used.

I see that function `thing-at-point-looking-at' is using function `point'. You are here expert, you see some bug there, and I see freedom of considerations.

> However, since "at point" does mean something
> in Emacs English, the proper fix is to always
> check starting from (point), not (1- (point))
> or any other position.

I did not experience that with the ISO date, so I do not see it is bug. Maybe it is, as I forgot what I did to make it work. But I do understand that other things at point are invoked when cursor is before it. And that is freedom to define it, it does not need to be strictly on the point.

My searchable text area maybe a line, not so? And I wish to capture or record that date on the line, while I did not make it so, it may be useful. Point could be anywhere far from the ISO date, and invoking function could capture the date. I find that useful.

> Either always-(point) or always-(1- (point))
> would be a fix.  But always-(point) is the
> better/proper fix, just because it accords
> with Emacs terminology.

Sure, but where is that (1- (point))? I did not find it. I was using this function below, and I do not see that. I tried searching for "(1- )" and did not find that reference, but found something for the URL https://www.EXAMPLE.comX - if I place cursor on X it will detect the URL. But that is because URL thing was defined that way to be detected. Maybe you should complain on that specific function to be changed, instead of trying to change general code in present and in future with STRICT. 

The function below has DISTANCE argument for those settings.

(defun thing-at-point-looking-at (regexp &optional distance)
  "Return non-nil if point is in or just after a match for REGEXP.
Set the match data from the earliest such match ending at or after
point.

Optional argument DISTANCE limits search for REGEXP forward and
back from point."
  (let* ((old (point))
         (beg (if distance (max (point-min) (- old distance)) (point-min)))
         (end (if distance (min (point-max) (+ old distance))))
         prev match)
    (save-excursion
      (goto-char beg)
      (while (and (setq prev (point)
                        match (re-search-forward regexp end t))
                  (< (match-end 0) old))
        (goto-char (match-beginning 0))
        ;; Avoid inflooping when `regexp' matches the empty string.
        (unless (< prev (point)) (forward-char))))
    (and match (<= (match-beginning 0) old (match-end 0)))))

What if I think of visible buffer as thing at point? Why not? Then I wish to capture specific text inside, and no matter where is cursor, it would work. I find that handy, useful.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/