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

[Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

> When I removed loading of Drew's thingatpt+ I could not observe this
> problem anymore.
> 
> I just think it is related to function from that library `tap-bounds-of-
> string-at-point'

Hi Jean,

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)

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!

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

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.

Your Emacs bug #74890 says you're using an Emacs 31
development version.  Emacs 30 hasn't even been released
yet!  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.)

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.

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.

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

One day, vanilla Emacs opted to return a thing that's just
before, not at point.  I disagreed with that change when
it was made, but was overruled.  I think it's due to a
shortsighted opinion that the only use for thing-at-point
is to grab some text for use as a default value - not _at_
point, but _near_ point.  For that use case thingatpt+.el
provides different functions: *-near[est]-point.  Those
functions let you specify what you mean by "near".

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.