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: master 91418d27e9: Add new functions for computing character metrics for windows Date: Fri, 29 Apr 2022 16:40:03 -0400 Message-ID: References: <165123811050.20687.5215165731843845332@vcs2.savannah.gnu.org> <20220429131511.9BD62C01683@vcs2.savannah.gnu.org> <87v8usc7wz.fsf@gnus.org> <83czgzacfk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27660"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: larsi@gnus.org, malsburg@posteo.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 29 22:41:56 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 1nkXR6-0006yx-2y for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Apr 2022 22:41:56 +0200 Original-Received: from localhost ([::1]:37968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkXR4-0000Xr-JJ for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Apr 2022 16:41:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48660) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkXPT-0008B6-Tg for emacs-devel@gnu.org; Fri, 29 Apr 2022 16:40:15 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35281) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkXPQ-0002Zv-GZ; Fri, 29 Apr 2022 16:40:14 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EFE6580677; Fri, 29 Apr 2022 16:40:06 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6472B80626; Fri, 29 Apr 2022 16:40:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651264805; bh=zK3HEvoODHGM+BiqtlaCXEPJJytHAyQh+1z8zvpbHlI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=bU3Zdqk+vZQT364ZAglV2DqUGHG/jXaIXStM1rLKOurHy1SR0ukgWlObx2lC5ZfYv dtTZMkKLbQYiysItCtA9FW/6LbMrGg0T1uqnv5kf/mxpRzx/FbIYPq+3hFpOLvLmp+ +sL3PkBjNCVqyg9jQ2rpXkHA8YRubFbJBfNlVwCYgK0VWXbj8kBXcxQnYRheGdA+R1 vbMgeySf4oLKgfKnJqgv4N0hqq28AoHTFGohn4bZnVixm4CgGaNqwuzsofnmlIkBCC i8pYSFR1nfeD2mFWKCw/+dq2Sz3VXmlafKp53yxSPBb2XUk3oP5F7S3FJb/TE+IBx6 UeIzT1uG0XNTQ== Original-Received: from alfajor (modemcable063.211-21-96.mc.videotron.ca [96.21.211.63]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 303831204B4; Fri, 29 Apr 2022 16:40:05 -0400 (EDT) In-Reply-To: <83czgzacfk.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Apr 2022 22:59:11 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca 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, 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:289020 Archived-At: Eli Zaretskii [2022-04-29 22:59:11] wrote: >> So, really it's just another variant of `window-body-width`? > Not really, no. I'm not sure what you mean by that. I suspect that most potential users of this new function currently use `window-body-width` (tho many others probably use something even less adequate). >> Could we use a name that's "closer" then? > Please suggest a better name. `window-body-width` sounds good to me ;-) BTW, I notice that `window-max-characters-per-line` doesn't deduct the space used by `display-line-number-mode`, whereas I'd expect most(?) users of that function to want to take this into account. >> We should try and "bring together" all the window-foo-width variants so >> as to try and reduce the probability that someone uses the wrong one by >> accident. > The latter part is impossible. Most Lisp programmers don't understand > the fine details and issues with different measures of "window-width", > and it's infeasible to teach them all that complexity. In my experience the main problem is not so much that they don't understand those details but that they're not even aware of them, which is why I suggest bringing them closer so there's a higher chance that they're exposed to the choice. >> Not completely sure what "bring together" should mean here. Could be >> merge them into a single function with an extra argument describing >> which elements to include/exclude in the count, or it could be to place >> them all under the `window-width-` prefix, or includes links >> between them in their docstrings, ... >> And of course clearly describe the differences between them. > > IMNSHO, that way lies madness. There are too many variations and too > many special cases. It doesn't have to offer notably more choices. I'd imagine a "window width" function with 2 args, one specifying the unit (e.g. pixels, the frame chars, or some face's chars) and another specifying which elements to include/exclude (with a handful of options corresponding to: the outer size, the size actually usable to display text coming from the buffer, and a few options in-between; i.e. corresponding to the existing functions `window-width`, `window-body-width`, `window-max-characters-per-line`, `window-text-width`, `window-total-width`). >> Maybe in this case, instead of introducing a new function we should >> refine the "pixelwise" arg of `window-body-width` so we can choose >> between pixelwise, or based on the size of the frame's font, or based on >> the size of a particular face's font? > Why does it make sense to complicate a single API instead of having N > simpler APIs that do the different jobs? I don't think it would complicate the API. > What practical problem will this solve? Try and reduce the confusion for programmers like me who find it difficult to even figure out which are the available options (e.g. I'm still not sure the above list of alternative functions is exhaustive). Stefan