From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.bugs Subject: bug#74890: 31.0.50; (thing-at-point 'string) raises error Date: Mon, 16 Dec 2024 09:12:47 +0300 Message-ID: References: <874j352vwz.fsf@lco2.mail-host-address-is-not-set> <86cyhsre61.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36438"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.12 (2023-09-09) Cc: 74890@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 16 07:14:16 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tN4Mx-0009MV-Gg for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 07:14:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tN4Ml-0003nG-Rc; Mon, 16 Dec 2024 01:14:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tN4Mk-0003n0-Cw for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 01:14:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tN4Mk-0004M0-3w for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 01:14:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:Mime-Version:References:From:Date:To:Subject; bh=jXgnk752HWHkIjJiBgSOtFLYIauc0fhRQnJYNleZ2BY=; b=YzanED/bNB7cv9l+/REH4ou0SM4n9RfIcwV+84KTy5UPLARBkvTkIDzsrqR9T4IsZMjNGDXO+KKWbOA4AgSajWuiUtbDHDmF4LrW1GPP1BAcU6JgGUPZ14T2S4ihaHg2Sf2Nb2UQdzPvyEPOc0JF2oIYOW7SV2Fd+NYWKoUkjLAsinqP2acU6AVq0f2JnThR7LlRfbX6h1plk9l9dkdH/Y/XcugsZ81uHo1wTHdQbMPnd67c/MRNvV+aOr4zqGLN3xCM/HWTztF59uAuGb31U/aqO828aQfj7kn6+OjxDNlqnDCPvFxctQ1cFplNGGkrEztr/WPJjADTQ/9YbILcRg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tN4Mj-0004Ku-MG for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 01:14:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jean Louis Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Dec 2024 06:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74890 X-GNU-PR-Package: emacs Original-Received: via spool by 74890-submit@debbugs.gnu.org id=B74890.173432959116587 (code B ref 74890); Mon, 16 Dec 2024 06:14:01 +0000 Original-Received: (at 74890) by debbugs.gnu.org; 16 Dec 2024 06:13:11 +0000 Original-Received: from localhost ([127.0.0.1]:53188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN4Lu-0004JS-Rf for submit@debbugs.gnu.org; Mon, 16 Dec 2024 01:13:11 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:50415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN4Lr-0004JF-LD for 74890@debbugs.gnu.org; Mon, 16 Dec 2024 01:13:08 -0500 Original-Received: from localhost ([::ffff:41.75.190.172]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001BF24.00000000675FC4EF.000765D1; Sun, 15 Dec 2024 23:13:02 -0700 Content-Disposition: inline In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297156 Archived-At: * Drew Adams [2024-12-16 03:49]: > > > > 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'. That is right. > 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) I do not have error in default Emacs with -Q with this version: GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0) of 2024-12-05 > 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! I am used to have silent thing-at-point, so I do not expect any error. I expect the thing to be there or not, as that is how I am testing it with my functions. Errors shall be handled with underlying functions IMHO. > (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.) Not on 31.0.50 as I have just tried it. Or maybe you mean with your library? > 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. If the function tests for thing to be "text at point", then yes. Otherwise, no, as function is testing for something specific, in my case it was (thing-at-point 'string) where by the default function without thingatpt+.el does work, and with thingatpt+.el loaded, it raises errors. > Your Emacs bug #74890 says you're using an Emacs 31 > development version. Emacs 30 hasn't even been released > yet! Yes of course, the bug is reported for that version, not earlier. > 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.) I don't see how that should be bug, and it is actually only raising error with thingatpt+.el loaded. (thing-at-point 'string) should give me string or nil Not error. I am testing for string, I am not testing if there is text under the point. > 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. I am expecting you to understand, I am testing with various functions `thing-at-point' for specifics, if there is no text, that means that specific is not there, and why should I get error as user of the function? It is not error if something is not found! So the underlying function shall be silently handled for the function user. I have been using thingatpt+.el for last 2 years basically, it remained silent until this special case was discovered, as I was improving the action button M-RET which verifies many different things at point. > 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. It is usable as long as underlying functions do well. (thing-at-point 'url) will find URL, and not number for example or UUID. So if there is no URL or no UUID, one need not raise errors. I hope you will come to same thinking. > 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). That is fine approach to me. > 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. $ emacs -Q - open empty buffer C-x b akjsndjansjkdn - evaluate (thing-at-point 'string) and it will return NIL - I am moving to directory Drew Adams and then evalute: (add-to-list 'load-path (expand-file-name ".")) - then evaluate (thing-at-point 'string) and it will raise error -- Jean Louis