bug#74890: 31.0.50; (thing-at-point 'string) raises error

[Jean Louis <bugs@gnu.support>]

* Drew Adams <drew.adams@oracle.com> [2024-12-16 03:49]:
> > > > Debugger entered--Lisp error: (wrong-type-argument characterp nil)
> > > >   char-syntax(nil)
> > > >   (eq (char-syntax (char-after)) 34)
> > >
> > > Please show a complete recipe, preferably starting from "emacs -Q".  I
> > > tried to reproduce this problem, but couldn't, which probably means
> > > some special steps are required to see it.
> > >
> > > I also don't understand your claims about "char after", because
> > > there's always something "after" point.
> 
> No, there's _not_ always something (some text) after
> point.  And that, I think, is what this report is about.
> From Jean's description, the only text in the buffer is
> `Hello', where that `o' char is the last char, and
> point is _after_, not on/at, that `o'.

That is right.

> I see the same thing with `emacs -Q' for Emacs 29.4,
> which is the latest Emacs release AFAIK:
> 
> Debugger entered--Lisp error: (wrong-type-argument characterp nil)
>   thing-at-point-bounds-of-string-at-point()
>   bounds-of-thing-at-point(string)
>   thing-at-point(string)
>   eval-expression((thing-at-point 'string) nil nil 127)
>   funcall-interactively(eval-expression (thing-at-point 'string) nil nil 127)
>   command-execute(eval-expression)

I do not have error in default Emacs with -Q with this version:
GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0) of 2024-12-05

> To me, this behavior makes sense since, per your recipe,
> there's _no character_ at point, and for thing-at-point
> to tell whether or not _the buffer text at point_
> represents a given type of thing or not there must at
> least be a char at point!

I am used to have silent thing-at-point, so I do not expect any
error. I expect the thing to be there or not, as  that is how I am
testing it with my functions. Errors shall be handled with underlying
functions IMHO.

> (You'll get the same error if you try thing-at-point
> in an empty buffer - no char at point to test.  I see
> that too with Emacs 29.4.)

Not on 31.0.50 as I have just tried it.

Or maybe you mean with your library?

> An alternative behavior - incorrect/poorer IMO - could
> conceivably be to return nil.  But to me (and to vanilla
> Emacs -Q for all releases I know of), that would be
> claiming that _there's text at point_ that does not
> represent such a thing.

If the function tests for thing to be "text at point", then yes.

Otherwise, no, as function is testing for something specific, in my
case it was (thing-at-point 'string) where by the default function
without thingatpt+.el does work, and with thingatpt+.el loaded, it
raises errors.

> Your Emacs bug #74890 says you're using an Emacs 31
> development version.  Emacs 30 hasn't even been released
> yet! 

Yes of course, the bug is reported for that version, not earlier.

> The bleeding edge bleeds, and I'm hoping Emacs 31's current failure
> to raise an error in this context is an ephemeral bug that'll be
> fixed before release.  (This is a regression - a
> backward-incompatible change.  But it may be intentional.)

I don't see how that should be bug, and it is actually only raising
error with thingatpt+.el loaded.

(thing-at-point 'string) should give me string or nil

Not error.

I am testing for string, I am not testing if there is text under the
point.

> If _released_ Emacs 31 thing-at-point changes the behavior
> to instead return nil, then I'll have to decide whether to
> follow suit.  My feeling, for now at least, is that that's
> poor behavior (a bug).  And if I go with that feeling then
> at most I'll perhaps provide an option to give users such
> (misguided) behavior if they so choose.

I am expecting you to understand, I am testing  with various functions
`thing-at-point' for specifics, if there is no text, that means that
specific is not there, and why should I get error as user of the function?

It is not error if something is not found!

So the underlying function shall be silently handled for the function
user.

I have been using thingatpt+.el for last 2 years basically, it
remained silent until this special case was discovered, as I was
improving the action button M-RET which verifies many different
things at point.

> To me, it's important that thing-at-point be usable _not_
> just to grab some text at point to use as a default value
> but - more importantly, if less commonly - to test whether
> there's a given type of thing at point, i.e., for
> _conditional/filtering_ behavior.  With such an outlook I
> think it's important for the testing to be doable and done
> on (duh!) text, i.e., a character at point.

It is usable as long as underlying functions do well. 

(thing-at-point 'url) will find URL, and not number for example or
UUID.

So if there is no URL or no UUID, one need not raise errors.

I hope you will come to same thinking.

> That such filtering behavior is important to me is also
> why my code returns nil when just _after_ a thing (not
> on/at a thing).

That is fine approach to me.

> When you can repro the bug with `thingatpt+.el', but not
> `emacs -Q', in an actual Emacs release (e.g. 31), please
> send me a mail with a recipe to repro it.  Thx.

$ emacs -Q

- open empty buffer C-x b akjsndjansjkdn

- evaluate (thing-at-point 'string) and it will return NIL

- I am moving to directory Drew Adams and then evalute:

(add-to-list 'load-path (expand-file-name "."))

- then evaluate (thing-at-point 'string) and it will raise error

-- 
Jean Louis