From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: on helm substantial differences Date: Wed, 25 Nov 2020 21:16:10 +0200 Organization: LINKOV.NET Message-ID: <87360x8cxx.fsf@mail.linkov.net> References: <87ima5he8j.fsf@mail.linkov.net> <87mtzfzt9a.fsf@mail.linkov.net> <87lfezd8r0.fsf@mail.linkov.net> <87k0uj58ub.fsf@mail.linkov.net> <87lfey28us.fsf@tcd.ie> <87ft56h6sr.fsf@mail.linkov.net> <87y2iybe27.fsf@mail.linkov.net> <873614ido7.fsf@mail.linkov.net> <83tutkz1ea.fsf@gnu.org> <83sg94z0ku.fsf@gnu.org> <87zh3aqxa7.fsf@mail.linkov.net> <83sg92xdz6.fsf@gnu.org> <87sg914wlp.fsf@mail.linkov.net> <83lfetxvuv.fsf@gnu.org> <87blfp2luy.fsf@mail.linkov.net> <83im9wwyae.fsf@gnu.org> <87r1ohepvu.fsf@mail.linkov.net> <83im9tsad9.fsf@gnu.org> 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="34664"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: spacibba@aol.com, bugs@gnu.support, andreyk.mad@gmail.com, emacs-devel@gnu.org, contovob@tcd.ie, rudalics@gmx.at, monnier@iro.umontreal.ca, ghe@sdf.org, drew.adams@oracle.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 25 20:33:42 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 1ki0Xt-0008uT-Pk for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 20:33:41 +0100 Original-Received: from localhost ([::1]:49580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki0Xs-000392-Mg for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 14:33:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51258) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki0VM-0001GU-86 for emacs-devel@gnu.org; Wed, 25 Nov 2020 14:31:04 -0500 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:49067) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki0VF-0005Me-C4; Wed, 25 Nov 2020 14:31:04 -0500 X-Originating-IP: 91.129.99.98 Original-Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98]) (Authenticated sender: juri@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id E24341BF205; Wed, 25 Nov 2020 19:30:46 +0000 (UTC) In-Reply-To: <83im9tsad9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Nov 2020 17:51:30 +0200") Received-SPF: pass client-ip=217.70.183.201; envelope-from=juri@linkov.net; helo=relay8-d.mail.gandi.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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:259801 Archived-At: >> To align the second column, 'completion--insert-strings' >> inserts " \t" with `(display (space :align-to ,column)). >> >> So when completions use \t to separate a character from its name, >> then the two-column layout schematically looks like this: >> >> character1 \t name1 \t with :align-to character2 \t name2 >> >> And tab-width doesn't align properly \t between character2 and name2. > > I don't think I understand why. Maybe the value of :align-to needs > tuning? If not, what is the problem here? Tuning means adding :align-to to all '\t'? E.g.: character1 (\t :align-to) name1 (\t :align-to) character2 (\t :align-to) name2 But the caller doesn't know the value for the third :align-to. So instead of this, the caller should calculate :width, e.g.: character1 (\t :width) name1 (\t :align-to) character2 (\t :width) name2 >> It seems font-get-glyphs can't be used because on wide characters it >> returns nil: >> >> (font-get-glyphs (font-at (point)) 0 1 "𒐫") >> => [nil] > > Is this with point on that wide character? Got it. When point is on the character, everything works fine, and this code: (let ((max-width 0)) (dotimes (c #x1FFFF) (insert c) (let* ((font (font-at (1- (point)))) (glyphs (when font (font-get-glyphs font 0 1 (string c))))) (when (and glyphs (aref glyphs 0)) (setq max-width (max max-width (aref (aref glyphs 0) 4))))) (delete-char -1)) (ceiling max-width (frame-char-width))) correctly returns 8, i.e. tab-width for the widest character. The problem is that this code requires to be run in the selected buffer. When enclosed in 'with-temp-buffer', it raises an error: Debugger entered--Lisp error: (error "Specified window is not displaying the current buffer") font-at(1) This is a pretty bad limitation. Maybe better to pre-calculate widths of all characters and generate a mapping from char to its width. This will also improve performance - the above code takes 15 seconds.