From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#43405: Tool bar item doesn't align to the right edge Date: Tue, 22 Sep 2020 17:14:18 +0200 Message-ID: References: <87sgbloe5z.fsf@mail.linkov.net> <83een5bkja.fsf@gnu.org> <87v9ghlc5c.fsf@mail.linkov.net> <83d02pbhny.fsf@gnu.org> <87een4qi9i.fsf_-_@mail.linkov.net> <837dsw9mpu.fsf@gnu.org> <87r1r3ncwq.fsf@mail.linkov.net> <83a6xq995x.fsf@gnu.org> <831rj07c0j.fsf@gnu.org> <83v9gc5u94.fsf@gnu.org> <83sgbg5sg2.fsf@gnu.org> <83v9gb4g2a.fsf@gnu.org> <83a6xjx86z.fsf@gnu.org> <83r1qtx4dg.fsf@gnu.org> 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="28352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43405@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 22 17:15:39 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kKk14-0007EJ-BC for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Sep 2020 17:15:38 +0200 Original-Received: from localhost ([::1]:42828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKk13-0007W3-BF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Sep 2020 11:15:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKk0U-0007Vr-8B for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2020 11:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKk0T-0005rL-Rx for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2020 11:15:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKk0T-0003DY-NK for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2020 11:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Sep 2020 15:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43405 X-GNU-PR-Package: emacs Original-Received: via spool by 43405-submit@debbugs.gnu.org id=B43405.160078767112308 (code B ref 43405); Tue, 22 Sep 2020 15:15:01 +0000 Original-Received: (at 43405) by debbugs.gnu.org; 22 Sep 2020 15:14:31 +0000 Original-Received: from localhost ([127.0.0.1]:32887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKjzy-0003CR-Me for submit@debbugs.gnu.org; Tue, 22 Sep 2020 11:14:31 -0400 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:52814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKjzv-0003CC-6Q for 43405@debbugs.gnu.org; Tue, 22 Sep 2020 11:14:30 -0400 Original-Received: by mail-wm1-f48.google.com with SMTP id q9so3731213wmj.2 for <43405@debbugs.gnu.org>; Tue, 22 Sep 2020 08:14:27 -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 :mime-version:content-transfer-encoding; bh=6ULw1i12T7tD+JTSsr3EHsdMYQxMv24hsEZEnUJKVWE=; b=ZFA4dpVPo6IL0QYiCp4joYyD/zH7uf6f5roa0SdegMqG+yFBMF0xUkGAJXr2w/Nfhb a9LMmv1HaugZ15XvhC5g4Oo3AVkfVaGEGIAWx6aP8X+DN+/k/SucdGkU+7JdlYJOo9oS izo0G7HGKKUItknUrOT8//URziD9UVWAXOu5PhpvNIBqegUxxUY2MCwClv7W54zNHEme PCdY6CYitV/nX2d+affd0LPXgc7c3T4p6/bZXyXAvtE9/3fRHZKOkdPJ7DUtgLvdsrzr qaMIFZd+1uzeQddWc4IUqY2RRPHsepw4cJNzZ+6/6D4vUOheUZdj6OGqM0Xk/vlrAth7 7DrA== 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:mime-version:content-transfer-encoding; bh=6ULw1i12T7tD+JTSsr3EHsdMYQxMv24hsEZEnUJKVWE=; b=VT2OyKLzXxtsfdQ0P/hmp2451WVMgrO8MRwmQPsfLEb7Ar5U8CY7LcyQlTnSQ/zLig WM8eS9Nr3FWPXFEK37BKDbOrR6bWi8Ld86VP2idb6Sl9mlyAuY2BOFjaGzAi9iVb6m+v Ti/sZhapMHAtOQUsf9DHax0hTDZWh+gCdqPRwBTj9ncEyY3OR/Xj5ownLeY3XW9v7I9l N9uZo6t/YYwaB9wMjtw+3unfB7GhNIoTBb7qQ2LXzCcQ3Wld1te56oyJNFn+gsSVci4h prVm8UK3xsmOOTKsc2rP81FQuUKABCp3QdQEEuxUAHGrXg1pBKNl+PFI/l5UpZ0+qKO4 j/xw== X-Gm-Message-State: AOAM531Wvx89462+ehQkD2NgSgDnr4pp0pjgmbMs+qIGL3Uysm5/n7+r JvcdmUZ3opFsdCcJRz455Nc= X-Google-Smtp-Source: ABdhPJyK/4OtZqtPwgUN9XibnijERT73lky+hmQDjRIROFzWdn37VItyOuk5UZMxS3VIocm9+KGN5A== X-Received: by 2002:a1c:66c4:: with SMTP id a187mr1521339wmc.148.1600787661099; Tue, 22 Sep 2020 08:14:21 -0700 (PDT) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:90b8:9745:bf3d:1ff5]) by smtp.gmail.com with ESMTPSA id d18sm27002538wrm.10.2020.09.22.08.14.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2020 08:14:19 -0700 (PDT) In-Reply-To: <83r1qtx4dg.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 22 Sep 2020 17:39:23 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:188701 Archived-At: >>>>> On Tue, 22 Sep 2020 17:39:23 +0300, Eli Zaretskii said: >> From: Robert Pluim >> Cc: 43405@debbugs.gnu.org, juri@linkov.net >> Date: Mon, 21 Sep 2020 22:07:51 +0200 >>=20 Eli> I'd first try to repeat what we do for :align-to support: insert a Eli> stretch glyph of a suitable width, computed using it->last_visible= _x Eli> and the width of the image for the button that has to be Eli> right-justified. See produce_stretch_glyph (except that most of i= t is Eli> not relevant, since :align-to supports a lot of functionalities). >>=20 >> OK, that would work, but then you could only right justify a single >> item, which would be different from what you can do with the GTK tool >> bar Eli> No, it will work with more than one as well, you just need to loop Eli> twice over all the buttons and keep track of all those which shoul= d be Eli> right-justified. OK, we=CA=BCre saying the same thing with different words: everything to the right of this stretch glyph needs its width calculated (and its x-coordinate adjusted) >> (and I see no reason to restrict this to tool bar buttons, I see >> at least org-mode wants to right-justify headline tags) Eli> What are "headline tags" in Org, and how are they related? Org headlines look like this: * This is a headline :tag1:tag2:tag3 The tags are right justified by default, but this is done by inserting spaces, which fails with non-monospace fonts. There=CA=BCs a patch to org-mode to do this by instead inserting a space with an :align-to property, but that code has to calculate the value to specify in lisp, which I strongly suspect will turn out to be slow, hence doing it in redisplay would be better (and perhaps more likely to be accurate). Eli> Your original description said: >> So let's assume we do this by exending the display spec to allow >>=20 >> '(:right-justify t) >>=20 >> which would mean to move everything on this line as far to the right >> in the window as possible. Eli> "Everything on this line" on which line? Sorry, everything on this line after whatever element has that display spec. Everything before stays where it is (and only the first :right-justify property found in the line is acted upon). Eli> Do you mean you want to display an entire screen line justified to= the Eli> right? Then we already do something like that with R2L lines Eli> (although there we also reorder display elements, something you do= n't Eli> need here). No, I just want to be able to produce: This is text This is right justified And have the "This is right justified" stay right justified as the window size and line content changes (unless the user deletes that stretch glyph in the middle). If the line became longer than could be displayed in the available window width, then I think the stretch glyph in the middle would just be treated as a single space (and hence line continuation/truncation would work as normal). Robert