From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#31676: 27.0.50; More helpful error message for unescaped character literals Date: Fri, 19 Apr 2019 17:53:50 +0200 Message-ID: References: <837en9uyaq.fsf@gnu.org> <83k1r7sw7m.fsf@gnu.org> <87tveuusng.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="234914"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , 31676@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 19 17:55:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hHVr5-000z1O-JV for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Apr 2019 17:55:11 +0200 Original-Received: from localhost ([127.0.0.1]:58210 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHVr4-0003pG-GR for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Apr 2019 11:55:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHVqx-0003ot-JE for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 11:55:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHVqw-00016O-Ki for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 11:55:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59205) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hHVqw-00016I-HM for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 11:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hHVqw-0005Gt-C8 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 11:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Apr 2019 15:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31676 X-GNU-PR-Package: emacs Original-Received: via spool by 31676-submit@debbugs.gnu.org id=B31676.155568924920176 (code B ref 31676); Fri, 19 Apr 2019 15:55:02 +0000 Original-Received: (at 31676) by debbugs.gnu.org; 19 Apr 2019 15:54:09 +0000 Original-Received: from localhost ([127.0.0.1]:44516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHVq4-0005FM-Uh for submit@debbugs.gnu.org; Fri, 19 Apr 2019 11:54:09 -0400 Original-Received: from mail-ot1-f53.google.com ([209.85.210.53]:40575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHVq3-0005Ew-C0 for 31676@debbugs.gnu.org; Fri, 19 Apr 2019 11:54:07 -0400 Original-Received: by mail-ot1-f53.google.com with SMTP id t8so4659272otp.7 for <31676@debbugs.gnu.org>; Fri, 19 Apr 2019 08:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4gZK3jdpN9trHd0zGoiQ8R+UDOl+LHw1S2jUD31W2Xw=; b=WPJXSUp9e3Zm1zU6+CeSum8+dzzJzP+o5HNuarbssQwMNGmEIR5WPG7jnRYBQVv60L JPWy7XauxQwOAm05kWGPKEOArY7rLBZjz7YfWBMqOh6sHaX7elDjocaeuQa6LqvSGp0C syoIrETxvEu8ldyKMFpoIACpS7skiqhUCyRTzc6bn+11unwdZDgqfv6mI/h1OWq+heT+ Q+ME28yO+dDoeQEI/l5fW0GGYfe350gY+pEzvKxmXFS4XNfPL72g+gSEeNsaeCwifhEA lfScvgziFzVNRBhghbDFnynWpQmMSywEpyvwWeQMpv6UrsBsBZBef05Exi8WXCFgRgxx 146g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4gZK3jdpN9trHd0zGoiQ8R+UDOl+LHw1S2jUD31W2Xw=; b=A92g+/aTY9OxGOhiCDXgDRvvP0JXU4LFqDX1ityhFMzfwFIHpRFr7TuF9LI61v+1tw 8EA22zJ969SDjlxxuNS+dSxuw64tMXKZYkGtYHIShxZbE36FAGH7+zWM1vhDh8HQ7VE3 eyyhod892tqVR596+2kNLG9H5g2/s36h9n+D3gb7s4+7g2xNV9Z7n1WVFeVlv9ghtvRA oF2wcvT8KES/ZfLmu4jMcCiYSILE0/QZIDJ19hpG9MPrqxyQmRNUIYXTFTBw9Bv3hA4H UJkWu+R/kwwFJdwOQ3YHrZquUbJj6PjwpidoqjKuWIQaVvFpKTsktRVHZWRlt+zT7r94 dPBw== X-Gm-Message-State: APjAAAWmuUH20/SJMKiCm9+twDB2+tkOVSeLoWdDKK3Rn3E8sddg4mRs kplnpFSAbDzGU7B/Ed1KkPbwV6NLGFiJs9ulwJI= X-Google-Smtp-Source: APXvYqxL1H31aHdBC7t8/vLwxuvd3dX1IlM8yiQYpvdZUUOi9J+wkXH1FchjxPYKmyq7Xko1bGJmfVqCek3ORW4+fh8= X-Received: by 2002:a05:6830:1559:: with SMTP id l25mr2563715otp.355.1555689241251; Fri, 19 Apr 2019 08:54:01 -0700 (PDT) In-Reply-To: <87tveuusng.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157849 Archived-At: Am Fr., 19. Apr. 2019 um 13:43 Uhr schrieb Noam Postavsky : > > Philipp Stephani writes: > > >> > The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the > >> > variable and having some Lisp function access it (the latter would have one additional internal symbol). > > >> Why does it need an uninterned variable? > > > > It doesn't need to be uninterned, but it's cleaner that way because no > > other code can access the variable. > > > >> And if it does, why cannot > >> it create a symbol that is not in obarray? > > > > That's what the patch does. > > The patch uninterns a symbol after it's interned in the obarray. I > think the question is, why put the symbol in the obarray in the first > place? Just a C static variable would do (although this would require > an additional (trivial) C function, to use with record_unwind_protect > instead of specbind). See for example Vloads_in_progress. > Ah, I see. There's no specific reason for this specific implementation, it's just the simplest one. Since we have a few cases where we need uninterned variables/functions (I see 6 existing calls to unintern in the C source code), how about extending DEFVAR/defsubr to allow uninterned symbols? That would make the implementation of these cases more obvious.