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: A solution to display completion candidates after point in a minibuffer Date: Fri, 02 Oct 2020 15:24:00 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36458"; 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: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 02 21:25:40 2020 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 1kOQgV-0009ND-TX for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 21:25:40 +0200 Original-Received: from localhost ([::1]:52308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOQgU-0004GW-Vu for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 15:25:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOQf7-0003Jx-Vi for emacs-devel@gnu.org; Fri, 02 Oct 2020 15:24:14 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45310) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOQf4-00074R-0c for emacs-devel@gnu.org; Fri, 02 Oct 2020 15:24:12 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E61C880408; Fri, 2 Oct 2020 15:24:07 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BF9DC80917; Fri, 2 Oct 2020 15:24:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1601666641; bh=x0ecB7xWeA8lGBQsHx7KP4ZOoRnmkGkmhFDIWFMtfqE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=aD8PDilI42MMvfsPsErWlwNjUi3sCTH6Bh1Fa+g4cpJX1rs37npzxwl797SLdqq1i WtOyrZJpubkUEVegv5A7FNyEh6HZ71JqCmVuhzz4a5x4hJyj8wWZpMsC4R1b20PGIm 6IeBw1stP/VPDR31plZo/cnqU7d3aNiYj970SayYlbB5akoaZs3KNRz8Bk1lki5ZCH h419imKxFg6QndPJF4Jq/+cKBzR4K1IdaihxNQLStEK1F3CGD7uikaJ6qy1zCwH9Dh D7oRxb1NPTaorJrMPF6Z6JFqGvT4KwtCtrKiqSJQmgh22X1Aj/k8MJntn4mCEbz+// kQlKr49B4oGHg== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6A8AF12066F; Fri, 2 Oct 2020 15:24:01 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Fri, 02 Oct 2020 17:17:03 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/02 15:24:08 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] 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:256965 Archived-At: >> I think you should better define the problem you're trying to solve. > This problem is known to those who have been working on workarounds to > circumvent it: displaying completion candidates in the minibuffer after > prompt, without hiding the prompt. This description is not helpful because it is too vague. E.g. it's not clear what you mean by "prompt". is it really just the `minibuffer-prompt`? If so, why do you specifically care about the prompt? I usually find it more important to see the candidates than the prompt (the prompt is important at the beginning, before you start writing your answer, but after that it loses a lot of its importance). Also, what do you mean by "without hiding the prompt". There are cases where there's no other option than to hide the prompt, so which cases are you specifically interested in? Also, what if some of the prompt is visible but not all, is that a problem you're concerned with, or not? > (let (w bd) > (setq w 60) > (setq bd (concat (temporary-file-directory) (make-string w ?a) "/")) AKA (let ((w 60) (bd (expand-file-name (make-string w ?a) (temporary-file-directory)))) > (dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t)) > (setq default-directory bd) > (set-frame-height nil 20) > (set-frame-width nil (+ (length bd) 10)) > (icomplete-mode) > (setq icomplete-separator "\n") > (call-interactively 'insert-file)) [ FWIW, I just tried it in my local Emacs where I replaced the ad-hoc `resize_mini_window` scrolling with the use of `scroll-conservatively`, and I get the behavior that you seem to prefer. ] [ Side note: I had sent a better recipe for that using a repetition of `foo/..` so as to avoid having to create any new files or directories. ] Thanks. Indeed, this recipe shows a problem where the prompt is not displayed at all right at the beginning of the interaction, so the unwary user won't get to see what the prompt says without extra effort. At the same time, the text that is displayed (i.e. without the prompt but with one more line of candidates) is arguably a better choice when the user knows what the prompt says (as would be the case for me when I call `insert-file`). So while I would tend to agree that showing the first line would probably be better it's debatable. At least, I don't think this minor difference warrants the kind of code you're proposing. >> Also this has some problematic aspects: >> - it focuses all its energy on showing the text before point, which is >> often the right choice, but not always. > Indeed, that's not always the right choice, which is why this solution > does this if, and only if, the buffer-local variable > start-display-at-beginning-of-minibuffer has been set, in > minibuffer-setup-hook. But it depends on other factors than "displaying the minibuffer". It can vary over the lifetime of the very same minibuffer. >> - There's of course a risk of inf-loop if (set-window-start nil (1- end)) >> leads to (pos-visible-in-window-p end nil t) returning nil. How/when could >> this happen, I'm not completely sure, but it doesn't seem impossible. > In practice it's not possible, unless the width of the Emacs frame is so > small that setting window-start near point (at point-1) would still leave > point invisible. It doesn't seem impossible even with a wide window. I think risky situations would include cases where point is right after a newline, and/or where tall glyphs are involved (either via face settings, or images, ...). >> Now, I know experience shows that it does work at least in some cases, but >> if so I think the code should come with a clear comment explaining why >> that warning doesn't apply here (and maybe the corresponding C code should >> also get a comment explaining the properties/invariants/berhaviors that it >> preserves and that make such uses work, so we don't break it by accident). > This I cannot do, alas, I'm not an expert. I tried this solution > extensively, on different Emacs versions. Perhaps there are cases where it > does not work, but I doubt it. I'd be uneasy using such code without some vague understanding about *why* it works. >> Actually, it seems like your code would allow to do that by running some >> icomplete code at the end of your `set-window-start-at-begin` to truncate >> the overlay's text according to where the text is truncated. > That's possible, thanks for the idea, I'll try to see if this can be > done. But I'm not sure, because modifying the contents of the buffer > would mean that redisplay would be called again, which would again set > window-start to another value. Which is the kind of reason where we'd benefit from knowing *why* it works. >>> 7. (add-hook 'post-command-hook >>> 'start-display-at-beginning-of-minibuffer) is necessary only with >>> variable width faces, but it is does not harm to use it with fixed >>> width faces. >> I don't understand why the kind of face in use would make a difference >> w.r.t needing to use `post-command-hook`. > I don't understand it either, alas. An example, which does not work without > start-display-at-beginning-of-minibuffer in post-command-hook with Emacs > 26.3 (but works without it with Emacs 27.1): Thanks for the example. I think this highlights the need to better understand how/why this works. Stefan