From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master 8fd97b1 1/2: Fix warning generated by indian.el + quail.el Date: Wed, 24 Feb 2021 16:19:03 -0500 Message-ID: References: <20210224193216.21758.72611@vcs0.savannah.gnu.org> <20210224193217.F016720B28@vcs0.savannah.gnu.org> <87k0qx5gda.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28087"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 24 22:20:10 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lF1Zp-0007Bf-7i for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Feb 2021 22:20:09 +0100 Original-Received: from localhost ([::1]:53100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lF1Zo-0005sr-9d for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Feb 2021 16:20:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lF1Yr-0005Jc-I8 for emacs-devel@gnu.org; Wed, 24 Feb 2021 16:19:10 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38884) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lF1Yp-0007o0-05 for emacs-devel@gnu.org; Wed, 24 Feb 2021 16:19:08 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5872E441706; Wed, 24 Feb 2021 16:19:05 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E48B5441501; Wed, 24 Feb 2021 16:19:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1614201543; bh=Natt7op9O4wP6uPjqKuEv2wv1Nub9mqSUasODeWACjs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=X6dQ/ceUeY0Od1Rp7RhCqY1vcqbOYeU/KtWcoZuEbkecKeOjV2akBV0XjEyRYhSSi XMWYv6nEggwh+LAp1B8mdnxYSR+YIZxJrRysaF847y5bkLnR3WRZEd4wxvVw8nHkzo H4wD8CZ9N2fb5NHy+wqNoSm/Z2vEViyvNXRrX+d6JUBzvof5MbQNW/qK//jHjpYpCJ eZaAXvsMkyQ7VJo+RbdoqLasWAXhK/jKZmnhWYPiwScBbSiIPKeYkWVN5rQzDGZia6 0rS/fk97nouE6ksNBX5jOG5ZV7ePPy9GTPl/Eb77E3fCV5OSzaxU71NvemP9ijSPa1 1DFIqOuF9R6ZA== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ECCAA120310; Wed, 24 Feb 2021 16:19:03 -0500 (EST) In-Reply-To: <87k0qx5gda.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 24 Feb 2021 22:02:25 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265594 Archived-At: >> Would the patch below fix this problem more directly? > > [...] > >> - (while (re-search-forward "^[ \t]*(quail-define-package" nil t) >> + (while (re-search-forward "^[ \t]*(quail-define-package[ \t\n]*\"" nil t) > > I'm not sure? This all ends up as a (register-input-method ...) call, > which is a function, from which I inferred that literal strings aren't > necessarily required here (i.e., that you can quail-define-package with > a variable name as the first element). But IIRC those that we want to extract are specifically those that are already "fully computed". In theory we could miss some things like (let ((name "foo")) (quail-define-package name ...)) but that seems very unlikely. Stefan