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 21:16:30 +0200 Message-ID: References: <0a54e927-cab1-1f1d-4996-85bb36949a33@yandex.ru> <83375imbaa.fsf@gnu.org> <83o9o6kp61.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 1510600631 11862 195.159.176.226 (13 Nov 2017 19:17:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 19:17:11 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: 29279@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 13 20:17:05 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 1eEKED-0002lF-35 for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 20:17:05 +0100 Original-Received: from localhost ([::1]:55986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEKEK-0002hR-AX for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 14:17:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEKED-0002gW-V7 for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:17:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEKEA-0004pN-Rp for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:17:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58417) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEKEA-0004p9-N5 for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eEKEA-0005Pz-Ee for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14: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 19: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.151060060120791 (code B ref 29279); Mon, 13 Nov 2017 19:17:02 +0000 Original-Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:16:41 +0000 Original-Received: from localhost ([127.0.0.1]:38864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEKDn-0005PD-Tj for submit@debbugs.gnu.org; Mon, 13 Nov 2017 14:16:41 -0500 Original-Received: from mail-wr0-f170.google.com ([209.85.128.170]:56838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEKDm-0005Ou-2A for 29279@debbugs.gnu.org; Mon, 13 Nov 2017 14:16:38 -0500 Original-Received: by mail-wr0-f170.google.com with SMTP id q66so15371737wrb.13 for <29279@debbugs.gnu.org>; Mon, 13 Nov 2017 11:16:38 -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=7VONMmq5IefiK+gq6PHrilWrg651LId96b+BJj4cn68=; b=h+SIHcYIw1RCNSxDm/swPlUcWOtDSNvOAC6SpyR4LVU90dX3C2sd0zv918F7HWfp6M 0FmgwR7Wr6RqWYPu4+7s3aONbYGXphbpOd1sg/fLMk7FOSAbaxjiIKWmkUoXG5agkRaz 5NiiQ/iIqLe7gEvvPgTrUCK7jnX9UAfxyDZpWOqGbjR11k6dm8IS4dYCAg3JWkeULytk UKapDpTVhqueTw9OjD1IH/1XzSRd2FmYGQz80QWnHFEqVDgufj/1KaHaszpY1S0q5tsK VSEU3gquLlwclvcOCx6jlmci9IDCeiedNTidxtQgnwjz+kRZcwqujh/5/GcW21OZffhg sDaQ== 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=7VONMmq5IefiK+gq6PHrilWrg651LId96b+BJj4cn68=; b=dMWXp9VTD2qowa/XAhldI+Au42TIxa6izOZ4oZiMoHFBmAcL8RY5A+u/oyggxSyh0s JOpVgitOGaWsiAEgf8irrXnynkXbilWqrSM71+rzylb3gL3oAFf8/socqpK4MTwsAItQ lkogfngDHl7QRR+XP2rxtMoPWx0tKvUdkjoUk3qaD1dv52gryX/VaYcCmmvCTdCspu20 KOtL6TBdtu4csPqdYUpRRL+BiG2VPmbY3a+/+h5UtfXB+7P10msKwKvGxCVYUnnqVauo I3CEenAFdRj8Vrc4um7XaVoLOk8e6onzR8GIM+dxqVVgIQNiivNn5LBxc1DyZUJeWt/B 99eA== X-Gm-Message-State: AJaThX7e43b6ImI+t8lFjDi0F314BFdVKhQhuDkuj2KPBGbvZmx29+Ix 5noFKbNh7kSiltl1p3oVoIwqGSwq X-Google-Smtp-Source: AGs4zMbd67L3tv15CY53MJa9wbZ7HNux5OpxGlov3lO3ffPNW6P5vnPIy4YceJLQsOde8A42e5oamw== X-Received: by 10.223.200.132 with SMTP id k4mr7791397wrh.215.1510600592058; Mon, 13 Nov 2017 11:16:32 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id s12sm39829789wrc.89.2017.11.13.11.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 11:16:31 -0800 (PST) In-Reply-To: <83o9o6kp61.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:139846 Archived-At: On 11/13/17 8:29 PM, Eli Zaretskii wrote: >> I'm not sure I understand the "Zero means ..." passage, though. > > That's your "total width" thing, for margin users that just want to > set the overall width of the margins without displaying anything > there. Like Joost Kramer's visual-fill-column and similar packages. 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". >> In addition to signifying a neutral position, does it supposed to switch >> the meaning of this function into something that >> set-right-margin/set-left-margin can call, for backward compatibility? > > 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. >> Seems like a wart, using ORDINAL this way. And what's going to happen >> when somebody else calls window-margin-add with non-zero ORDINAL? Will >> the end result depend on which call happens first? > > Yes. And the result is returned, so the caller knows that. If you > have better ideas for requesting a particular position in the margin, > let's hear them. Having ORDINAL to be a number is totally fine to me. 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. 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" >> Here's an interesting question: after such an API is added, will it be >> feasible to re-implement display-line-numbers-mode using a margin >> column, instead of the special separate area? > > Yes. But using margins from Emacs internals means that the > window-parameters which hold the column specs will change behind the > back of the Lisp applications, which I'm not sure is a Good Thing. I was thinking more along the lines of being able to specify a spec-returning function (that uses the current buffer position), instead of only using the text properties. But changing the margins directly sounds faster. Maybe not an entirely good thing, but certainly an improvement for the authors of third-party code. > It will also be somewhat slower. We should probably measure before discarding this idea.