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 12:32:14 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21553"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Gregory Heytings To: Gregory Heytings via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 02 18:38:48 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 1kOO52-0005VZ-1N for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 18:38:48 +0200 Original-Received: from localhost ([::1]:54906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOO50-0001P4-Vj for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 12:38:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kONyp-0002hw-TJ for emacs-devel@gnu.org; Fri, 02 Oct 2020 12:32:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23154) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kONyl-0003nc-Ei for emacs-devel@gnu.org; Fri, 02 Oct 2020 12:32:23 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 19483440958; Fri, 2 Oct 2020 12:32:18 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 37FAD440741; Fri, 2 Oct 2020 12:32:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1601656336; bh=DyoXBFZnI15p/xCIV32/uub36yZpkjJI2NJj1TRlWpo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=UzM+KE//a7tS+w7ulC8kjinSljO6LWauJLluGlXi0eHpoGDCUIzBR3qpxG9Kr5w7q 6/vioHVP+zTWDO85UTrq090PXVyjgbJQPXsMNhmUOIkTHSnYV/QmgLXU60l/yXwmV1 aLv5RAddK+bf9SeIH3NX+Rkad4jpTg4pGYcy5t7CUomSKp1fwoLGscoPUjpB/ZViMv q/vz76dcPvaMz5vz4fkqOzvtbsCODVg7lzl919yL/bEYJFQuDGsZ7vdSAh7u90jK7Y KePLYsrAqEirv3kXv2eeEKuz7IfaA5E6cROHv8ht378h+sU6+2kTdbSVNQJEcPwlRt Bliomv7mgbqlg== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E288A120346; Fri, 2 Oct 2020 12:32:15 -0400 (EDT) In-Reply-To: (Gregory Heytings via's message of "Fri, 02 Oct 2020 15:36:37 +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 12:08:31 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:256956 Archived-At: I think you should better define the problem you're trying to solve. AFAIK the main issue ("when there are too many completion candidates, the minibuffer prompt is hidden") has been solved by Eli, so without some concrete cases where the result is still unsatisfactory it's difficult to know what "better" means. The code can't guess what should happen in all cases currently because the information for that is simply not available, so it remains a balancing act based on heuristics. [ I sightly tweaked your code ] > (defvar-local start-display-at-beginning-of-minibuffer nil) > (defun start-display-at-beginning-of-minibuffer (&rest args) > (when (and start-display-at-beginning-of-minibuffer (minibufferp)) > (set-window-start-at-begin (point-min) (point)))) > (defun set-window-start-at-begin (beg end) > (set-window-start nil beg) > (unless (pos-visible-in-window-p end nil t) > (set-window-start-at-begin (+ beg (/ (- end beg) 2)) end))) > (add-hook 'window-scroll-functions #'start-display-at-beginning-of-minibu= ffer) > (add-hook 'post-command-hook #'start-display-at-beginning-of-minibuffer) This might indeed give a reasonable behavior in practice, but I'm not sure it's better than what we have now. 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. - 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 impossibl= e. - `window-scroll-functions` says explicitly: Warning: Do not use this feature to alter the way the window is scrolled. It is not designed for that, and such use probably won=E2=80=99t work. 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). > 2. The only drawback of the above solution is that is is not possible to > display an ellipsis ("...") at the end of the completion candidates li= st, > to indicate that some completion candidates are not displayed. It see= ms > to me that this is a minor limitation. 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. > 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`. Stefan