From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Federico Tedin Newsgroups: gmane.emacs.bugs Subject: bug#38317: Buffer-local variables don't work as history for read-from-minibuffer Date: Wed, 27 Nov 2019 19:50:00 +0100 Message-ID: <87h82pw3vr.fsf@gmail.com> References: <87eey0lxxm.fsf@gmail.com> <87v9rcqbls.fsf@gnus.org> <5a0c68d0-4d25-bf8d-fbe8-f106b0f92210@gmx.at> <875zjareo1.fsf@gnus.org> <874kyu72kl.fsf@gmail.com> <87wobq5gs0.fsf@gmail.com> <87o8wyl2wa.fsf@gmail.com> <87k17lfscs.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="249744"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: 38317@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 27 19:55:39 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ia2TT-0012kI-Hz for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Nov 2019 19:55:39 +0100 Original-Received: from localhost ([::1]:41860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ia2TM-0004v9-SS for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Nov 2019 13:55:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49252) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ia2P2-00014H-05 for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 13:51:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ia2P0-0007wk-RV for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 13:51:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50237) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ia2P0-0007wJ-DO for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 13:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ia2P0-0003PW-Bk for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2019 13:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Federico Tedin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Nov 2019 18:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38317 X-GNU-PR-Package: emacs Original-Received: via spool by 38317-submit@debbugs.gnu.org id=B38317.157488061313041 (code B ref 38317); Wed, 27 Nov 2019 18:51:02 +0000 Original-Received: (at 38317) by debbugs.gnu.org; 27 Nov 2019 18:50:13 +0000 Original-Received: from localhost ([127.0.0.1]:56210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ia2OD-0003OG-7g for submit@debbugs.gnu.org; Wed, 27 Nov 2019 13:50:13 -0500 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:36941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ia2OB-0003O2-IY for 38317@debbugs.gnu.org; Wed, 27 Nov 2019 13:50:11 -0500 Original-Received: by mail-wr1-f52.google.com with SMTP id g7so7251240wrw.4 for <38317@debbugs.gnu.org>; Wed, 27 Nov 2019 10:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=sO4doUxv2I9wtUrrn7zRuk+HXGelWyZeu/z81j+at2o=; b=ITZkgwGJ18HIZr0iQTxumo4EqOYvnt+fsoGKCRq7CqSbyY1ZcYpi0uv+OP4WpuKNXI tsN5H7XiLGq4L4KD4kPcerw8sh8ApotlWBuL7YxVaw99i+mP0iE80mSxULzmFj8FGMjk /4Q6nLe8YkyxXvPRF8rzuM1tjq6VkfpQ2Y+5DCV2s906ec7jQHKVXNeKnsARkTf52Cql dXoqMQJzM0cMDmrbz1sAiof8XUNg4mMGIRgGKvxlmXnHB8VkJnhDZE8o5HNWQyzAagFx uiLs5zf5+jY/BqaVaEVs0FbwqJB1mRherrd8BddG3ZLpFdYF2mWHDHSarUx2QPUh9VAu 1ZEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=sO4doUxv2I9wtUrrn7zRuk+HXGelWyZeu/z81j+at2o=; b=NacgLcfoM2tiWmQZAEGPDfmE4vNttK3YLr6+iS3JdzwCcM2ZSWvIxOTFvLDrbcVz1f xUi/vVuwAjo/5w8j6F//dfiE8IP6uClnaLTNqN4utmlecrvjPprSvkN6wJx7Op7cAP2+ QVSKQHFOysXQrDNnPlOHc1sptBFfUQ40l9Be36Zqfi6hgbEz+IFuwZGLwdx00NVvljEw Wm9ME+6NZJgQPPhLGRv0nlJ1p3QAe2LfqB3grjjcb9s9Wzc8Rm1pI8PfzuEz4Uo47z7+ zjyF0woc6KciPdQG9Jmd9dc72frtSQJ04SwtDBKgEpcQVyLMOM8o2ElM3ADYaazQ5g9h CJMg== X-Gm-Message-State: APjAAAXMEh33ox5fo64yDMopmANR1DV/5UoBbkVUknSBGXQaunq1Iy3Q PvcxGn69xO64xfQ2RPDKX+IdrU03aQc= X-Google-Smtp-Source: APXvYqxfT2os3rw5KrY9yuQyzZ+42UqnE+1Iev90f7igWXB/saoTOzQ1AooH8ZRh5TnQIPDHkisVNg== X-Received: by 2002:a5d:4445:: with SMTP id x5mr45911923wrr.341.1574880605190; Wed, 27 Nov 2019 10:50:05 -0800 (PST) Original-Received: from lead ([2a02:8109:8ac0:2ff0:918e:a083:2c78:74e5]) by smtp.gmail.com with ESMTPSA id w7sm19392534wru.62.2019.11.27.10.50.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Nov 2019 10:50:04 -0800 (PST) In-Reply-To: <87k17lfscs.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 27 Nov 2019 12:53:23 +0100") 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:172550 Archived-At: > I haven't tested the code, but it makes sense to me. I do wonder > whether there are any instances of the variables that are local to the > minibuffer... but I guess that's unlikely? I agree that it would be unlikely. I am not sure what the use-case for having a history local to the minibuffer itself would be. It makes much more sense for the history to be global or to be determined by the context i.e. the current buffer (like I want to do with `goto-line'). >> +** 'read-from-minibuffer' now works with buffer-local history variables >> +The HIST argument of 'read-from-minibuffer' now works correctly with >> +buffer-local variables. This means that different buffers can have >> +their own separated input history list if desired. > > This should probably be documented in the manual, too? > > The patch otherwise looks good to me. Thanks. In what part of the manual would you document this? I was thinking of either in: 1) The "Minibuffer History" section (but it doesn't mention the actual HIST variable anywhere in there, though, and never mentions any specific minibuffer-reading function) 2) In "Reading Text Strings with the Minibuffer", in the entry for `read-from-minibuffer' (right before the link to "Minibuffer History"). Maybe if we add it there users can then infer that other minibuffer commands with a HIST argument also accept buffer-local values. Should I update the docstring for `read-from-minibuffer' as well? I would like to add two things: that the value can be buffer-local, and that the newly read item will be added to the history list. IMO this wasn't clear enough so I ended up calling `add-to-history' myself, which was redundant since `read_minibuf' does that already.