From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: feature/icomplete-vertical Date: Mon, 05 Oct 2020 11:52:59 +0100 Message-ID: <87tuv9eygk.fsf@gmail.com> References: <20200912133311.6ujtgczj6wyclufy@Ergus> <20200920130435.heye7bk73pm252km@Ergus> <83sgbczj0i.fsf@gnu.org> <83lfh4zfml.fsf@gnu.org> <838sd4z6lz.fsf@gnu.org> <20201001164804.mqqyxtet4ttweuyv@Ergus> <83blhhdy3w.fsf@gnu.org> <87d01xghmt.fsf@gmail.com> <83sgatc8er.fsf@gnu.org> <83mu11c78j.fsf@gnu.org> 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="16862"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: ghe@sdf.org, spacibba@aol.com, emacs-devel@gnu.org, casouri@gmail.com, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 12:54:33 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 1kPO8X-0004J8-Dn for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 12:54:33 +0200 Original-Received: from localhost ([::1]:58840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPO8W-0002zz-CY for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 06:54:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPO78-0001ct-Oi for emacs-devel@gnu.org; Mon, 05 Oct 2020 06:53:08 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:44607) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kPO76-0001dx-4h; Mon, 05 Oct 2020 06:53:06 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id t9so360451wrq.11; Mon, 05 Oct 2020 03:53:03 -0700 (PDT) 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:content-transfer-encoding; bh=btTvDQAoEi7lHPJgi8Xbf1+hCTzfpJN4LyUEJ2oK5Ts=; b=O3F8XC1qFT4KB5PSdCzz9NwAtEOdRZbpEdH3RS1PM+cWDNF3swuR2FjjNU717UzvUP wSlXpdHO+LFUK86PuUZoC3pXVIT+mE67AMXjpva4YeG00j8fGZYCWiqCqb+tp+6K5Kyv 7cPTNgxSrvJIl7OaED0zed8R6s0d+nEfRlQ9eMnyaZJMtDVS7P3UR8Au74Kq5Ow3KQiq q9EtBmbS63fF+RYzb2iiEMYOrcGoDZSwehT8lzyyoByFbPy5o8jLjIU63WqV72DrNS0z 34ssDyeNAyKQSOoRGGSsVi6hMDR5dBshluhkyYu7dH7WGrwMNbsQvLq+B/U/pVHq8q9t iaZg== 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:content-transfer-encoding; bh=btTvDQAoEi7lHPJgi8Xbf1+hCTzfpJN4LyUEJ2oK5Ts=; b=M+YCukHlcmqCFlau8l7HZb0oGqWR9NvQpMzeH0nfoz6shuneYg5SS7afTZLn6nP+9e HrL67QIaNU+aSxnGOZGUdIJmn7LiqwGvVMnlB5pV4FPCXuVPTkbqa/UsJGHvA+c6cVIJ H6uiL7MC+x7+g+nggkcVmugwacYCXYzS/FKwE1uHDc4IhFhf8Zd+jocQQK6qa6sMYyV8 ODGXfz+hX8nbUPP1+0VZPZYraujcrCG6GjmbkuM2/7HX8z/kQHkndwAdae5xV2uK1G+O h2TStCFLNE6VBdDy8IVr9/65lTGCHvMk4Hb8hJ1ls1MQfpFnP775gHnLcz1X7e2y1JcO jXqA== X-Gm-Message-State: AOAM530xEs4W7zP8yCv/NAAOiM97YnpZJ+ajXcUzSXM7NVBI3Gh3ZyRN lTP1ySTvbJYTNSOnG/liWSUtwW+wgzU= X-Google-Smtp-Source: ABdhPJwit6t0Sun2GcTdBj0Kaf5C1xzf2dRVktjXBA1dt5Odk6IqW0cv+T9IHspLNNfcZtkRcl7p3w== X-Received: by 2002:adf:e8c3:: with SMTP id k3mr17259037wrn.228.1601895181931; Mon, 05 Oct 2020 03:53:01 -0700 (PDT) Original-Received: from krug ([89.180.147.115]) by smtp.gmail.com with ESMTPSA id l4sm13811643wrc.14.2020.10.05.03.53.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 03:53:00 -0700 (PDT) In-Reply-To: <83mu11c78j.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Oct 2020 13:11:40 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x434.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, 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:257101 Archived-At: Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Date: Mon, 5 Oct 2020 10:57:35 +0100 >> Cc: Gregory Heytings , Ergus , Juri Linko= v ,=20 >> Yuan Fu , emacs-devel >>=20 >> > Or a lot of completion candidates. >>=20 >> That's odd, I've been C-x C-f'ing to directories with "a lot" of files >> and I don't notice any problems. What size of "lot" did you have in >> mind? > > More than can be displayed, one candidate on each line, by the frame's > dimensions, I guess. I've certainly got more than that, and the problem doesn't happen. >> Though maybe the responsible for the truncation can provide a=20 >> way (a hook, a variable, a function?) for the user of the minibuffer to = select=20 >> the appropriate hint. My point here is that this variable/function shou= ldn't=20 >> be called icomplete-truncation-hint, but rather mini-window-truncation-h= int. > > The code which displays the min-window is more-or-less the generic > Emacs window-display code, it doesn't care that not all of the stuff > fits in the window. That's the code that honours max-mini-window-height, right? Though that doesn't seem to be what's kicking in here, I believe it should be. Anyway, I think it's reasonable to suggest I think, that whoever is truncating the display has someway of notifying the client (whoever requested the display), that truncation happened, or is about to happen. > If an application wants to fit the buffer in the window, or display > some hint about truncation, it's the application's business to do > these things. I guess you can argue that, but this implies there are ways to predict truncation (since being notified of it seems to be what you're opposed to). So how is the application to know if its n lines, of lengths L =3D {l1, ..., li, ..., ln}, it wants to display (not necessarily by buffer insertion) in the mini-window need truncation and starting in which line? Does it need to perform calculations with max-mini-window-height? If so, is there a "canonical" way to perform these calculations that accounts for fontsizes, frame widths, etc? To be clear, I find this information useful for other domais, notably designing the way the Eldoc should show information in the echo area. Jo=C3=A3o