From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#29279: Sharing the margins Date: Mon, 13 Nov 2017 23:16:15 +0200 Message-ID: References: <0a54e927-cab1-1f1d-4996-85bb36949a33@yandex.ru> <83375imbaa.fsf@gnu.org> <83o9o6kp61.fsf@gnu.org> <83h8tykm99.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1510607837 26896 195.159.176.226 (13 Nov 2017 21:17:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 21:17:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: 29279@debbugs.gnu.org, Joost Kremers To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 13 22:17:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEM6O-0006KB-4n for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 22:17:08 +0100 Original-Received: from localhost ([::1]:56358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEM6S-0004oa-1G for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 16:17:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEM6M-0004hx-6a for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEM6J-000175-0q for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58507) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEM6I-00016w-Sf for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eEM6I-0008EP-I7 for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 16:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Nov 2017 21:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29279 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29279-submit@debbugs.gnu.org id=B29279.151060778731589 (code B ref 29279); Mon, 13 Nov 2017 21:17:02 +0000 Original-Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 21:16:27 +0000 Original-Received: from localhost ([127.0.0.1]:38954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEM5i-0008DQ-Iz for submit@debbugs.gnu.org; Mon, 13 Nov 2017 16:16:27 -0500 Original-Received: from mail-wm0-f42.google.com ([74.125.82.42]:35457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEM5g-0008DD-Jk for 29279@debbugs.gnu.org; Mon, 13 Nov 2017 16:16:24 -0500 Original-Received: by mail-wm0-f42.google.com with SMTP id y80so17430784wmd.0 for <29279@debbugs.gnu.org>; Mon, 13 Nov 2017 13:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rl9Rze5pEf21JEKE/GsiLvpHRs9//JSk+WEKXU8bJ2E=; b=TR2sCHHnm5kLMFScBe+pt5TY9EHAfV+9YgiG+bFHcihM5mMEsgJTsttVPCRZEDILbe 9I3ZkBvbjS3/SAOJwzRSAA3x0lPKp8iTBGzmOLdsUu2aHP8n9qHXV0LuTt8Xblf8u68P 3pTLuaDmLkU5Sw8X23mcIwHvlUwmGKdhO7oUr74Jbn/qksePpeK+e0/33Zj2hZJgUrVq bIQQ0XdefBGXaSMzIjEcBqQcsmjm3C2B+/+UpJxh5FbV7UU/WYUEiWaKotSA4jk2ATRz qU9Zv8eV9hR5sZXHkeWNvwuDGDj1/qcswX9jCH0+/MAY4Y6gYQXNzprojN0xcT7MVf82 gdvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rl9Rze5pEf21JEKE/GsiLvpHRs9//JSk+WEKXU8bJ2E=; b=c4uZoQZMqA3Pyv8AWQ/CAIO/mZ9hFTvpNjvzAGxppFYkBAE1cf8/SwB+2RQDpe+Lmu vyE0ZE38bIrqXS/09/PF3WGzbybHsco0GmNfpdg+EZbm4UNIzmpV1RIjVLagDI3xL1o7 LCwFnkT5YWADjterFmiT9VaCHXnhnhUP6rINIMLh8x/F5dXt67bjR/HTN2vPnjiYRAaR RS6zrtrH9/FMGpB0im45ZKVXjIpMcn6nN+W21h/yCrktI20G6CPRdZVXb2wABmNGBNVu 1OTWNd7IcHXjXztgRSHRk21FFY5xcSLC3vvVo3IoIYijzymm22+xsxRmbzqUqGwHRl0d 8giQ== X-Gm-Message-State: AJaThX6TmJC8xqM5i4nx3hSjr+Tsg44Bubr2kgFPvda3vXcWXaOsasOZ 0q74jJIrS8JHrxJMnhMUnwL+/bEm X-Google-Smtp-Source: AGs4zMZYJumjUK3O7+tjTGK9dJkomui0k4SHGaEs+wZy61kVUFPkomtujK2aCLGxdGEiSGVJWefZ1Q== X-Received: by 10.80.153.197 with SMTP id n5mr14418050edb.281.1510607778639; Mon, 13 Nov 2017 13:16:18 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id 23sm13305740edx.8.2017.11.13.13.16.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 13:16:17 -0800 (PST) In-Reply-To: <83h8tykm99.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139858 Archived-At: On 11/13/17 9:32 PM, Eli Zaretskii wrote: >> OK, but why "maximum width"? workroom-mode wanted to set the total >> width, but if we want to describe what will happen with the column in >> question, the value sounds more like "minimum total width". > > Indeed, I meant to write "total", not "maximum". I see. >>> Yes, set-window-margins will most probably be reimplemented by calling >>> the above. >> >> Which area will the left-margin specs be drawn on, then? Ones without >> any particular symbol specified. > > Either without any symbol, or with nil, or with some invented symbol. > Something ti figure out as part of the implementation. I think set-window-margins, and the nil/unknown symbols should work with the 'default' symbol. And it will have the ordinal = 0. Then, older packages that are not updated to use the new API can fight between themselves for the use of the default column, but the winner can peacefully coexist with the packages using the new API. >> Having ORDINAL = 0 mean something else, not so great. Especially if the >> result is to have the padding in this column, necessary to reach the >> specified total width. > > My idea was not to create a column, just make sure the total width is > no less than the requested value. Which means some of the requested > columns will be wider than requested, I guess. It would probably look not too great. Just like 'text-align: justify' often works bad on web pages. So I'd personally prefer to have all padding on one side. Then, unless people disagree, setting the total width could be made into a separate call. With three arguments: side, width and the side from which to pad (inside/outside, for instance). >> I imagine workroom-mode might have a idea where they want the padding to >> end up (to the left or to the right of all columns). So instead of >> co-opting the ORDINAL argument to mean "cols will total cols" > > We need to study the needs of potential users, no doubt, before > finalizing the API. Inviting Joost into the discussion. >>> It will also be somewhat slower. >> >> We should probably measure before discarding this idea. > > The slowdown will be caused by resizing of the margins (and all the > window-configuration-change-hooks that triggers). Doesn't the use of the special area trigger the window configuration changes as well, in similar situations? After all, it also changes the accessible window body width, right?