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: master 91418d27e9: Add new functions for computing character metrics for windows Date: Sat, 30 Apr 2022 08:23:06 +0300 Message-ID: <83bkwj9mbp.fsf@gnu.org> References: <165123811050.20687.5215165731843845332@vcs2.savannah.gnu.org> <20220429131511.9BD62C01683@vcs2.savannah.gnu.org> <87v8usc7wz.fsf@gnus.org> <83czgzacfk.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14807"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, malsburg@posteo.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 30 07:23:55 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 1nkfaE-0003df-68 for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Apr 2022 07:23:54 +0200 Original-Received: from localhost ([::1]:42532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkfaD-0001Xj-2X for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Apr 2022 01:23:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfZR-0000AK-Nq for emacs-devel@gnu.org; Sat, 30 Apr 2022 01:23:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39390) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfZQ-0005kj-HV; Sat, 30 Apr 2022 01:23:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=l0iVpK1E1VZnq4FRMzO6V7+FSaJLIvQ0VgzBlnlorok=; b=nElqMxh9z1hd NpRd0WcnpVBs/laxLAVy+DETXBjn1p3oYd+wmrpXeQmBWA3ieOBupX0BXaMSgTYzbbHMkPgUxwEVc hkMfkDlGfxMx1Fg3sl0MOV1Bey9JYPMr+Zd29HhnWXTigOYV2Nx5SPVpuHdDA1b6DBom0xDEWLjfV OzdKQJ23lEcuVwDM6o+hKPvABSSgc+pMKsA85OC0zVS6xzIWgRia6apztxF0LfkiqC0wVTF4oAu18 dUoDvVodwrlIIc8c0VvChxax3d5acvL63cwtdt+o/KSM1e793HTk6swIZizLKXOE9M41wMP1JOdUj wdOsFsmauBQVMTpR555ghg==; Original-Received: from [87.69.77.57] (port=2458 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfZQ-0000vH-1m; Sat, 30 Apr 2022 01:23:04 -0400 In-Reply-To: (message from Stefan Monnier on Fri, 29 Apr 2022 16:40:03 -0400) 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:289027 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, malsburg@posteo.de, emacs-devel@gnu.org > Date: Fri, 29 Apr 2022 16:40:03 -0400 > > 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 mean that it isn't a variant of window-body-width. It has a different purpose and serves different use cases, as one can easily see from the discussion of the bug which led to the change. > I suspect that most potential users of this new function currently use > `window-body-width` (tho many others probably use something even less > adequate). We don't know what they use. I hope they use window-text-pixel-size. Some probably use window-width (see the bug report) or maybe window-edges. > >> Could we use a name that's "closer" then? > > Please suggest a better name. > > `window-body-width` sounds good to me ;-) I presumed this was a serious discussion. Apologies for my misunderstanding. If this is a serious discussion, then window-body-width is NOT a good name, because it basically would redefine what is a window's "body". > 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. I'm not sure I understand the assumption, and I don't think I agree. In any case, subtracting the line-number-width will give you what you want. > >> 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 Is there a difference? > which is why I suggest bringing them closer so there's a higher > chance that they're exposed to the choice. And you really think that exposing that will facilitate understanding? I think it will proliferate confusion instead. > >> 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`). Now multiply the number of units (3, and I'm not sure this is all) by the number of alternatives regarding which elements to exclude (4 by my count), and you get the total number of variations. Is it reasonable? > >> 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). See above.