From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/icomplete-vertical Date: Mon, 05 Oct 2020 14:45:56 +0300 Message-ID: <83h7r8dhfv.fsf@gnu.org> 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> <87tuv9eygk.fsf@gmail.com> <83k0w5c4yt.fsf@gnu.org> <87mu10gbjs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4778"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, spacibba@aol.com, emacs-devel@gnu.org, casouri@gmail.com, juri@linkov.net To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 13:47:06 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 1kPOxM-00013b-0w for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 13:47:04 +0200 Original-Received: from localhost ([::1]:32854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPOxL-0004wQ-2F for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 07:47:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPOwJ-0004Te-6h for emacs-devel@gnu.org; Mon, 05 Oct 2020 07:45:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57021) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPOwG-0000Lp-It; Mon, 05 Oct 2020 07:45:56 -0400 Original-Received: from [176.228.60.248] (port=2553 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kPOwF-0001fP-V3; Mon, 05 Oct 2020 07:45:56 -0400 In-Reply-To: <87mu10gbjs.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Mon, 05 Oct 2020 12:24:55 +0100) 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:257110 Archived-At: > From: João Távora > Cc: ghe@sdf.org, spacibba@aol.com, juri@linkov.net, casouri@gmail.com, > emacs-devel@gnu.org > Date: Mon, 05 Oct 2020 12:24:55 +0100 > > Truncation is being given something to display, such as here: > > (let ((minibuffer-setup-hook (lambda () > (insert (format "one\ntwo\nthree\nfour"))))) > (read-minibuffer "hey")) > > and _not_ actually displaying it becasue of some window size constraint. > > > There are ways. They aren't necessarily easy, but if your application > > does care about not everything being visible in a window, the > > application must do something about it, because the "normal" Emacs > > display doesn't treat partial display of a buffer as something > > special, since that is what happens all the time in Emacs. > > Right. But is there a very large cost in implementing a mechanism of > notification that applications can optionally subscribe to take action > when this common thing happens to them? I don't think the cost is large, but someone needs to do the writing. Emacs was never designed to display completions this way, so it's not surprising these mechanisms weren't implemented until now. > This function exists to allow Lisp programs to adjust the buffer text > so that it fits visually in WINDOW. > > I don't know how to use the function to do this. In other words, I have > some buffer text and I would like to know: > > 1) If it fits in WINDOW; > 2) If it doesn't, where is the cutoff, as a text position. Basically, remove lines one by one until it fits. We could write a similar function to do what you want, but please note that such a function will not understand the semantics of the text, so it could suggest truncating it at some place which makes no sense. If the caller would like a smarter 'service", we will have to come up with some method of telling the function where it makes sense to truncate the text.