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 12:32:51 +0100 Message-ID: <87imbogb6k.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> <87tuv9eygk.fsf@gmail.com> 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="31197"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org, casouri@gmail.com, spacibba@aol.com, juri@linkov.net To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 13:34:19 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 1kPOl1-0007xX-0B for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 13:34:19 +0200 Original-Received: from localhost ([::1]:48444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPOl0-0007Ex-1E for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 07:34:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPOjj-0006R6-Kl for emacs-devel@gnu.org; Mon, 05 Oct 2020 07:32:59 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:38947) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kPOjh-0006w5-10; Mon, 05 Oct 2020 07:32:59 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id u16so177899wml.4; Mon, 05 Oct 2020 04:32:55 -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=yLa0ZkY6XO0nNeZGBxiitvZE25JhhMj6Dt8HD6vBzsQ=; b=Wi++32WxIj6zAr9AwSrlZw1odGo9qL0+pdz5/qyZV0IoAU2rTGzdiS6B5Mr2z8V2bU dA8P1NFI9Kn1FdNlWwXXVcIUfMPPAhRHSaXx35dYio9gxejnLmMu2BY12jhnmySKSyUE RN2ZOcC+S8K1+1lBOtTI48IZzmBvhdY4mM4CPI185T+KcsYu7LNoMVpcwH90uVRF79WT mx2baGxTMPkr+YCKF2VROn519uXT+93yDik41bZc37pedPNmEOu7t1was03HTyrlFzXF kA8VLgQ1QCZike2eMsGYBVRF26oV9DJUJloujdhZnpDVqsy/6cwo9Wepv++e4vB0/uRU bJZw== 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=yLa0ZkY6XO0nNeZGBxiitvZE25JhhMj6Dt8HD6vBzsQ=; b=L3iZLj4WhZ3RPDtXct7v6YMS63SX8kuBOzzqnglIRPYPXyVb1wpq6mFpUzWt+acQed 03Jz1knGbAUFQbaCMH/eeEUrHhl0r5/yI1mAjFjzQ4s4/6wYRGMZ6CSg9YpmRjaaNK9Y UbGm1INQe0pJya4qtx+4wAKzk7csNiE5aG5cjQnrJd/WSjLEeSn3ubCxugG3+OxfrTSq Yyp/MfOlK2t2vQjKEv+b1PP6P1dA5+UjKgmE35UupUSkxXAqO9BWmO5XaG7rLalD/JJ3 thhkWFfOpDtpdgJL3xBU0VbSYdcf+peBbGBC3GBAkk15YJeIIj5YY8dPHAHMWKgxwFlG 3ltA== X-Gm-Message-State: AOAM533AOd56pEVTQPRe25J2NsqSTcvGq194sLRCcdozQ7em4dUecn1h hsaFff9LWYDFJXTVWI8pbkItwhAxh4o= X-Google-Smtp-Source: ABdhPJxJLNoi6KeEVsdxiPsesqB6u4uRBNxhqOTzOxpYLSBAqIZKLiEeax01dOacTvro1UO+lYP7Ng== X-Received: by 2002:a1c:c28a:: with SMTP id s132mr16295919wmf.67.1601897574148; Mon, 05 Oct 2020 04:32:54 -0700 (PDT) Original-Received: from krug (89-180-147-115.net.novis.pt. [89.180.147.115]) by smtp.gmail.com with ESMTPSA id b11sm12691769wrt.38.2020.10.05.04.32.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 04:32:52 -0700 (PDT) In-Reply-To: (Gregory Heytings's message of "Mon, 05 Oct 2020 11:02:17 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x334.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:257108 Archived-At: Gregory Heytings writes: >>> 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. >> > > This is feasible, but IMHO very (and needlessly) difficult. Basically > you need to work with pixel dimensions, and recalculate everything > manually: first calculate the (maximal) size of the miniwindow (given > the user preferences, in particular max-mini-window-height), then > calculate the size of its contents with window-text-pixel-size. You > should add one character (or line) at at time, and recalculate the new > size each time. Yes, as far as I understand, in the general case, it must be one character at a time, since each character might have a different pixel width. At some point there is a cutoff and things are not displayed anymore. I was hoping that that knowledge, which is held somehere in the system at some point, could be imparted to the application. Anyway, whatever the mechanism (notification or painstaking calculation), we should first write a function that does this. That is the bugfix in my opinion. Then we can work on simplifying that function's implementation, if it turns out to be slow or problematic. Jo=C3=A3o