GNU bug report logs - #21391
24.5; `thing-at-point' returns error when called with arguments 'number t

Previous Next

Full log

Message #184 received at 21391 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Eli Zaretskii <eliz <at> gnu.org>, Tino
 Calancha <tino.calancha <at> gmail.com>
Cc: 21391 <at> debbugs.gnu.org
Subject: RE: bug#21391: 24.5; `thing-at-point' should return a string
Date: Sun, 13 Nov 2016 18:43:52 -0800 (PST)

> > I can suggest adding a new function, with the features you
> > mention.   We could even deprecate thing-at-point and advise
> > to use the new one instead.
> 
> In this vein, I would propose deprecating `thing-at-point' in favor
> of `bounds-of-thing-at-point', which should provide all the necessary
> information for a `buffer-substring' call anyway (when it works).

This is really going from bad to worse.  But I can't say I'm
surprised.

Eli suggested to keep the behavior backward-compatible, rather
than ensuring that the return value is a string.  That is a
reasonable approach.  It's OK by me.

It is the 2nd of the 3 approaches I described as reasonable 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21391#52):

d> 2. Make `thing-at-point', as before, return just what the
      firat `if' clause returns, if that clause is taken.
      IOW, move the removal of text properties (from non-nil
      NO-PROPERTIES) into the second `if' clause.

Can we please just do that, and stop f__ing with thingatpt?

I also suggested that we do this, in that case:

d> Point out, in the doc, that `t-a-p', like `form-at-point'
   and its callers, can return a Lisp THING of any kind OR a
   string naming such a THING, and that the former case is
   realized via property `thing-at-point' on the THING-argument
   symbol.

That's important.  The use of symbol property `thing-at-point'
is one of the most important features of library `thingatpt.el'.
Pointing out `thing-at-point' in the doc without pointing out
this feature is letting users down.

Each of the 3 approaches I described is reasonable.  What is
not so reasonable are the kinds of changes you are suggesting
now.

If you are really entertaining removing existing functionality
then I would suggest you remove (deprecate) the NO-PROPERTIES
argument that was added fairly recently.  It is unnecessary,
and its addition was apparently completely gratuitous.
Did that action correspond to a bug fix or a user request?
I cannot imagine that it did.

Are we going to start adding a NO-PROPERTIES arg to _every_
function that can return a string?  If not, why does it make
sense here?  How hard is it to remove the properties of a
string?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.