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

Previous Next

Full log

View this message in rfc822 format

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

On Fri, 11 Nov 2016, Eli Zaretskii wrote:

>> Cc: 21391 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 11 Nov 2016 16:46:14 +0200
>>
>> On 11.11.2016 16:35, Eli Zaretskii wrote:
>>
>>>> The current implementation makes the things harder to understand.
>>>> Currently one user need to read the source code to know the actual
>>>> type this function returns.
>>>
>>> If that's a problem, let's improve the doc string (and the manual, if
>>> needed) to make this more clear.
>>
>> Improve how? By saying that the function behaves in a variety of ways,
>> solely depending on which `thing' it is passed?
>
> Improve it by describing whatever it is that is evident from the code
> that is not evident from the doc string.
>
>> That won't make it much clearer, or make it easier to follow code that
>> uses `thing-at-point'.
>
> I don't understand why.  It's not like we don't have other functions
> that can return different kinds of objects.
Yes, and it's a good thing when it results in a simpler code.
I don't think in this case it makes a simpler code or a code
easier to follow, kinda the opposite.
I don't think we actually need a polymorphic function here with the 
bizarre behaviour pointed out in my previous email.  Instead of document
its counter-intuitive behaviour, i would go for fixing the function to do
just one obvious thing.  It would save the users time reading the manual.
It's a change for better, a good thing.  We will have a better 
function.  Everyone will be happy with this.

Previous Next

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