From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: A solution to display completion candidates after point in a minibuffer Date: Fri, 02 Oct 2020 17:17:03 +0000 Message-ID: References: Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="-212064758-1435148763-1601656932=:4600" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14215"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 02 19:21:49 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 1kOOke-0003ZE-Kd for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 19:21:48 +0200 Original-Received: from localhost ([::1]:57118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOOkd-0004E0-N6 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 13:21:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOOgG-0007wA-Gu for emacs-devel@gnu.org; Fri, 02 Oct 2020 13:17:16 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:53581) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOOgD-00018X-KM for emacs-devel@gnu.org; Fri, 02 Oct 2020 13:17:16 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 092HH6nN027209 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 2 Oct 2020 17:17:07 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 092HH9cm001649; Fri, 2 Oct 2020 17:17:09 GMT In-Reply-To: Content-ID: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/02 11:36:43 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:256958 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---212064758-1435148763-1601656932=:4600 Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Stefan, Thank you for your feedback! > > 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=20 circumvent it: displaying completion candidates in the minibuffer after=20 prompt, without hiding the prompt. > > AFAIK the main issue ("when there are too many completion candidates,=20 > the minibuffer prompt is hidden") has been solved by Eli > No it has not. It has been solved in a partial way, which means that it=20 will still be necessary to use workarounds to solve it in a clean,=20 user-friendly way. I sent a simple recipe on bug#43572, which=20 demonstrates why Eli's solution is incomplete: emacs -Q (let (w bd) (setq w 60) (setq bd (concat (temporary-file-directory) (make-string w ?a) "/")) (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)) This recipe works with Emacs 24, 25, 26, 27 and 28, except that=20 "(temporary-file-directory)" should be "temporary-file-directory" (without= =20 parentheses) in Emacs 24 and 25. > > [ I sightly tweaked your code ] > Thanks, your modified version works fine. > > Also this has some problematic aspects: > > - it focuses all its energy on showing the text before point, which is=20 > often the right choice, but not always. > Indeed, that's not always the right choice, which is why this solution=20 does this if, and only if, the buffer-local variable=20 start-display-at-beginning-of-minibuffer has been set, in=20 minibuffer-setup-hook. > > - There's of course a risk of inf-loop if (set-window-start nil (1-=20 > end)) leads to (pos-visible-in-window-p end nil t) returning nil.=20 > How/when could this happen, I'm not completely sure, but it doesn't seem= =20 > impossible. > In practice it's not possible, unless the width of the Emacs frame is so=20 small that setting window-start near point (at point-1) would still leave= =20 point invisible. > > - `window-scroll-functions` says explicitly: > > Warning: Do not use this feature to alter the way the window is=20 > scrolled. It is not designed for that, and such use probably won=A2t=20 > work. > Yes, I know ;-) > > Now, I know experience shows that it does work at least in some cases,=20 > but if so I think the code should come with a clear comment explaining=20 > why that warning doesn't apply here (and maybe the corresponding C code= =20 > should also get a comment explaining the=20 > properties/invariants/berhaviors that it preserves and that make such=20 > uses work, so we don't break it by accident). > This I cannot do, alas, I'm not an expert. I tried this solution=20 extensively, on different Emacs versions. Perhaps there are cases where=20 it does not work, but I doubt it. >> 2. The only drawback of the above solution is that is is not possible=20 >> to display an ellipsis ("...") at the end of the completion candidates= =20 >> list, to indicate that some completion candidates are not displayed.=20 >> It seems to me that this is a minor limitation. > > Actually, it seems like your code would allow to do that by running some= =20 > icomplete code at the end of your `set-window-start-at-begin` to=20 > 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.= =20 But I'm not sure, because modifying the contents of the buffer would mean= =20 that redisplay would be called again, which would again set window-start=20 to another value. >> 7. (add-hook 'post-command-hook=20 >> 'start-display-at-beginning-of-minibuffer) is necessary only with=20 >> variable width faces, but it is does not harm to use it with fixed=20 >> width faces. > > I don't understand why the kind of face in use would make a difference=20 > w.r.t needing to use `post-command-hook`. > I don't understand it either, alas. An example, which does not work=20 without start-display-at-beginning-of-minibuffer in post-command-hook with= =20 Emacs 26.3 (but works without it with Emacs 27.1): emacs -Q (let (w bd) (setq w 60) (setq bd (concat temporary-file-directory (make-string w ?a) "/")) (dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t)) (setq default-directory bd) (set-frame-width nil 80) (set-frame-height nil 30) (icomplete-mode 1) (setq icomplete-separator "\n") (add-hook 'minibuffer-setup-hook (lambda () (buffer-face-mode t))) (set-face-attribute 'variable-pitch nil :height 1.2) (call-interactively 'insert-file))) ---212064758-1435148763-1601656932=:4600--