From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] completions-max-height Date: Tue, 8 Mar 2022 11:32:27 +0100 Message-ID: <20220308103227.olrz7dvajgieyeep@Ergus> References: <20220307210740.veiocemir46mmerk.ref@Ergus> <20220307210740.veiocemir46mmerk@Ergus> <87v8wpxvkj.fsf@posteo.net> <87fsntvxg6.fsf@protesilaos.com> <3723C952-ECE7-467B-AE89-73EB0819B7F0@aol.com> <878rtk3k6m.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Protesilaos Stavrou , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 08 11:37:20 2022 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 1nRXDU-0008yb-K6 for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Mar 2022 11:37:20 +0100 Original-Received: from localhost ([::1]:56360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nRXDT-0007Rr-74 for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Mar 2022 05:37:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRX9a-0004Hx-Nw for emacs-devel@gnu.org; Tue, 08 Mar 2022 05:33:19 -0500 Original-Received: from sonic306-1.consmr.mail.bf2.yahoo.com ([74.6.132.40]:36140) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nRX9X-0003pJ-FS for emacs-devel@gnu.org; Tue, 08 Mar 2022 05:33:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1646735591; bh=8uN9iAr5Xa2MbPNP5ww6h4CMfMZV9HlvoA3HDMuxwJo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=Srr2mYUTziJX7vrhl/h3/9GfKE/GsdvYix37WyO3l7R/Yxw0kIiV2yF/Mplq0kBSUPzHbDcoYz3wq6jmyVfQk69kRKbHj1F+8Dc55s3GBlyMK7XyjN0iN7HT4+aJ8bBDi4S9dTMVjxqgAOhYrcJ3UTTQfSVMtuywAL01D0oUDWXJf8GHklmTwE8uwtzN+1PtYWgw1cOc6TjfItP3qJzr3FPVyLeyod1SHBx51V6ErBNRUSE/EhOEDjTt7NlP7SZurY+bCf3LfeND2vM4V2xAXOSRW2/qpWJTubThnMhOd0fwzTzaHzDh1uglQAon9m88XuJjUee1QWxpoHrSSaF30Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646735591; bh=Z+9uEQkL2zhCLQm0Nof7SmRXNaNBbGEbhGuBM53WRbp=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=t2UCdVFJ3YJIXlOxJ0e95Jo4mTtad5P+/auQRIgP8V1wrENZZ5B2YKWCd8UChApXSs9KnA4DwDT0v1NbU3DCOw60qiiUFQQHcVe6hS5Rh5G5O48gRO0eplibDcsMPWBVNxLrWwQ3mfxZrWZFu2DusrHL+c3aPcJyaG6kOQUeN5GO18c5n8gQ63oMXLjOpmf5IRYXdApdcV3WgpPkI9VJFs/D13iVBf6vNZ5lssSS7gCqwgMIsdrhfTTPsYxnOFGrLMWDos2ZDfihGgrPG95sltJFFG+16rttwdgQOVxuMVANSxdcPKaZjHesbKz2dVUn4+PsyI44E0/+QgjzjCzmdg== X-YMail-OSG: Txgsi1EVM1m5Adz_pS_JfbbE1OSV1NLthCMHs2l6YhDwKWBbNXe13QmHjsCE38m .mkh4Zw60LS2Vd73Nc5N8V6bwVSSaWqrvspYoUimHVJctZqMvPtQ0SA35I.B5JipIEVwGcPk2l9O lIcC8bzZKL_KwE1yZvjlCXbNFqZR7iWLzqaUk.JGClvtiL5QIgXJT6ye6MwPhL.Sz6pVh1X1kUYq 9WvR_7RFPCEt_l4M.T5nRY7iSmXVeKbfBdVUAZKv.jPNgol.c36.q06jtR61pDvRYEIsZQokcVLp jBz4mB0oHoc_DXanjFlrGqL1INKamPDD6SaZ07YPatIgp1FijZKmMhiORO9PL4N.ODS9PGkI3lCX 1qd.TXrr88MAbWX0.Ouj4M7ytOx0usd8pTRw5GXeqVW6rKmAyI7BBFC6XrS5e8n4V_HNF8BLe6Zl zxgqkW3UJhi_5.OylDcNSUzMmjbT.1qcNTx9KZNLd2vRd5OEHaOxlNWBIOLlubz72E7k7_4NWuSU 0auF7USo8P81nx3Kp5S_1l8uZKW2iwdl_JxUySG6QEbr_01o_3IWMAxAb0Bo6cqYa5xSN6vUk_uS BN0gFNvAJF8l0.cosPF21yRZniP_XaHNtUIl9m63WtMlp4Jd4sNMXegN0WBImnE7y2EQkfiU1bYM YtpaMOF.958pibs6PSqX09jRN05zU0ZmHqpF9oNTUX2MaBbwQFQsOsskBLra9bd4C0RJOIHK5R59 oDwV1VYTiq1pJI5ixSKdkdnzLFJvY32foLAsbj4ShJICpsVD8vxFh.BoiBb18DbEeVmhu0XnE24U 8YRuV3CF2.tjaNq495wdovGsOgJ0eT4ueJFTa06nvY X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Tue, 8 Mar 2022 10:33:11 +0000 Original-Received: by kubenode501.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8fb8631fd3d3abd657d05f2f7270cb94; Tue, 08 Mar 2022 10:33:05 +0000 (UTC) Content-Disposition: inline In-Reply-To: <878rtk3k6m.fsf@posteo.net> X-Mailer: WebService/1.1.19797 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.132.40; envelope-from=spacibba@aol.com; helo=sonic306-1.consmr.mail.bf2.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:286920 Archived-At: On Tue, Mar 08, 2022 at 08:47:13AM +0000, Philip Kaludercic wrote: >Ergus writes: > >> I understand your intention, but in practice making this more complex >> is useless. The mini buffer is always down and making the completions >> to move somewhere else is uncomfortable and may require more >> lisp/emacs knowledge to change the default behavior from the >> user. Which is completely the opposite to my intention. Actually this >> same result may be reached with an advise as I discussed on yesterday >> on emacs help. But a simple custom is better. >> >> I am totally fine if you propose something else more general if that don't forces the user to write a function to change a simple height. > >What I proposed would just require something like > > (setq completion-display-buffer-option '(display-buffer-at-bottom (window-height . 10))) > I got the point but if you look at the original code there are conditions that will need to be set to not change the current default behavior (because that always ends in arguments from long time users that want some specific detail of the previous behavior), for example: temp-buffer-resize-mode or (eq (selected-window) (minibuffer-window)). We can go around them, but it may be a more complex patch I am not willing to do because I don't see the utility of a completions window in any other place than where it goes now (next to the minibuffer). In a best case the new variable will need to be something like: `completion-display-from-minibuffer-options` and parse them with some if-else here and there to apply the position only when (eq (selected-window) (minibuffer-window)) but provide a default value in case the user didn't specify it and the height only when not temp-buffer-resize-mode (or condition it as the new function does). >> On March 8, 2022 6:13:13 AM GMT+01:00, Protesilaos Stavrou wrote: >>>On 2022-03-07, 22:10 +0000, Philip Kaludercic wrote: >>> >>>> Ergus writes: >>>> >>>>> Hi: >>>>> >>>>> Do you think that this may be added to vanilla? >>>> >>>> IMO it would be better if this could be generalised to something like >>>> completion-display-buffer-action, so that you can decide where and how >>>> the completion buffer is displayed. Though I am uncertain if this might >>>> have unintended side effects, as the behaviour seems to have been >>>> hard-coded for a while. >>> >>>I agree with Philip. Or go a step further and just let the Completions >>>behave like other buffers so the user can contol its placement and >>>parameters via the display-buffer-alist. > >You can do so now too, but I don't think that that would be an argument >to just have the completion buffer behave like other buffers, >considering that there are certainly many who are used to its current >behaviour. > >>>-- >>>Protesilaos Stavrou >>>https://protesilaos.com >>> > >-- > Philip Kaludercic >