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: Tick Reduction Date: Fri, 19 Nov 2021 08:58:11 -0500 Message-ID: References: <87bl2hyzca.fsf@gnus.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="5640"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Emacs developers To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 19 15:14:32 2021 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 1mo4eu-0001GA-22 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 15:14:32 +0100 Original-Received: from localhost ([::1]:52036 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo4es-00014Q-Ju for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 09:14:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo4PG-0008Ec-Ci for emacs-devel@gnu.org; Fri, 19 Nov 2021 08:58:22 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54363) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo4PD-000253-TG for emacs-devel@gnu.org; Fri, 19 Nov 2021 08:58:21 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E971E80530; Fri, 19 Nov 2021 08:58:14 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 114AB803D6; Fri, 19 Nov 2021 08:58:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1637330293; bh=UuFeUYQaBB42PY+hmvDQJBizMaCCZg+vraihigMvYcI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=azA+I6eH4JbB4hNXTlcw0onUM60OnHVi/GYcmFG28X9JcRcbzlRHExxu92kvWVCnv eBKaSNOVR9R85EAFAkHqncj2PesW0rrCODqxOFQ+7/1tZK3PNwnNJNO0AL5w7LYVkA KmWW/eEp34WchSTx9PtkgNejuk35KxwNU5uq2tslZxpZFFoY/WrViq8f5ohHMRML6G ZCFE0LMeLqqiiLQO+FJ5hztbxM5PUOsVRRf7ZND9Go70eeMLmQZmq3lpuoyF6wCQso S5Wcvs31MHZk8GTV44IlUAF+BLMpw5/tKj98l9TiC4YW2rRndKwZJsbGfaqGjUoFp9 /EH6Pl2KuM0ww== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E085212085F; Fri, 19 Nov 2021 08:58:12 -0500 (EST) In-Reply-To: <87bl2hyzca.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 18 Nov 2021 21:37:41 +0100") 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 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:279763 Archived-At: > And, of course, we could also consider using proportional fonts for the > non-code prose bits: On a docstring like that of `pcase` the result is a bit poor. Also, it makes line lengths vary even more; as a result, it ends up crying for re-filling the text. Especially since, while most lines end up shorter when displayed with proportional fonts, occasionally some lines end up longer, causing line-wrapping. Clearly, we would benefit from a formal markup language (and one which includes some way to align text into columns). Note that for the column display, I think we actually need an extension to the current `space` thingy on the `display` property which is able to align columns even without the buffer's data telling the redisplay at which precise pixel position it should be aligned (instead it should just add space until the columns are visually aligned). Stefan "happy user of proportional font for the mode-line, and not so happy user of proportional fonts for docstrings"