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

Previous Next

Package: emacs;

Reported by: Tino Calancha <f92capac <at> gmail.com>

Date: Tue, 1 Sep 2015 01:57:01 UTC

Severity: minor

Found in version 24.5

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Tino Calancha <tino.calancha <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 21391 <at> debbugs.gnu.org,
 tino.calancha <at> gmail.com
Subject: Re: bug#21391: 24.5; `thing-at-point' should return a string
Date: Fri, 11 Nov 2016 19:07:15 +0900 (JST)

On Thu, 10 Nov 2016, Dmitry Gutov wrote:

> On 10.11.2016 21:59, Eli Zaretskii wrote:
>
>> Because currently they can call thing-at-point without defining
>> foo-at-point.  AFAIU, you suggest to deny them this possibility, and
>> force them to define foo-at-point for every foo.
>
> They'll really have to do that only for string-unrepresentable foos.
>
> Like currently (thing-at-point 'symbol) returns a string, whereas 
> (symbol-at-point) returns an interned symbol. That's nothing new.
Indeed, this sounds the right usage for me, and for an user who has 
read the part of the manual refering to `thing-at-point'.

If i want the list object i call `list-at-point', and if i just want the
text representation i would call (thing-at-point 'list).

The fact that we have that duality in the code, i.e.

I) (thing-at-point 'foo)
II) (foo-at-point)

in some sense is asking for I) and II) returning two different things.
I find it easier if I) always return a string.
Note also that we don't need to define one version II) per each THING: 
just in the few cases where it has sense to return the THING with a 
different type than a string.  We already have defined all II) functions
in `thingatpt.el'.




This bug report was last modified 4 years and 329 days ago.

Previous Next


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