From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Raffaele Ricciardi Newsgroups: gmane.emacs.help Subject: Re: thing-at-point: inconsistent behaviour? Date: Thu, 16 Aug 2012 18:12:28 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1345137316 19986 80.91.229.3 (16 Aug 2012 17:15:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2012 17:15:16 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 16 19:15:16 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T23f7-00008L-W3 for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Aug 2012 19:15:14 +0200 Original-Received: from localhost ([::1]:41257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T23f6-0000nH-71 for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Aug 2012 13:15:12 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 72 Original-X-Trace: individual.net F83My7jLOn8jMlVPYV/KJA86Dqn1SHLE9mFfVlIIHoDdHZ6fm1zI9e8Pv+PQSwL+ec Cancel-Lock: sha1:Pkpx88GfGICNa1DjyGXwnirpOrI= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: Original-Xref: usenet.stanford.edu gnu.emacs.help:194004 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:86372 On 08/16/2012 05:24 PM, Andreas Röhler wrote: > Am 16.08.2012 17:48, schrieb Barry Margolin: >> In article , >> Andreas Röhler wrote: >> >>> Am 15.08.2012 21:00, schrieb Raffaele Ricciardi: >>>> On 08/15/2012 07:34 PM, Barry Margolin wrote: >>>> > In article , >>>> > Raffaele Ricciardi wrote: >>>> > >>>> >> Hello there, >>>> >> >>>> >> the documentation of `thing-at-point' states that such function >>>> returns >>>> >> "the >>>> >> thing around or next to point". This is not the case with either >>>> >> (thing-at-point >>>> >> 'symbol) or (thing-at-point 'sexp), for they both may return >>>> the thing >>>> >> before >>>> >> point. Try it with the following snippet (! symbolizes the >>>> point): >>>> > >>>> > Doesn't "next to" include both immediately before and >>>> immediately after? >>>> >>>> I stand corrected after having consulted a dictionary. Then it is >>>> (thing-at-point 'list) that is misbehaving. >>>> >>> >>> >>> hmm, IMHO you was right. Here is the code >>> >>> (defun symbol-at-point () >>> "Return the symbol at point, or nil if none is found." >>> (let ((thing (thing-at-point 'symbol))) >>> (if thing (intern thing)))) >>> >>> last line don't return the thing as delivered by thing-at-point but the >>> result of (intern thing) >>> >>> that way breaking consistency. >> >> That function has nothing to do with the problem he's reporting. It's >> just an extra utility function that makes use of thing-at-point to >> return something that may be useful in certain situations. >> > > okay, as it happens it's for years in my mind: that symbol-at-point > breaks consistency. > > Another approach to give the reasons: > > IMO basically two ways of returns are feasible by such a thing-at-point > library > > - deliver objects from editing perspective, i.e as buffer-substrings > - deliver objects for use in programs When you are looking for a buffer substring, you call `bounds-of-thing-at-point'; when you are looking for a string result, you call `thing-at-point'; when you want the result as a sexp, you call the specialized function. > Not to expect is changing the computers internal state already when > picking an object by thing-at-point. > That's what is done by "intern" however. Indeed this is an undesirable side effect of `symbol-at-point' calling `intern'. Could `intern' be replaced with `make-symbol'?