From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Better handling of window margins Date: Wed, 02 Dec 2015 19:53:59 +0200 Message-ID: <838u5cka88.fsf@gnu.org> References: <87mvttsvsj.fsf@fastmail.fm> <83k2oxj7d6.fsf@gnu.org> <565F2DD3.9020400@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1449078904 3308 80.91.229.3 (2 Dec 2015 17:55:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Dec 2015 17:55:04 +0000 (UTC) Cc: joostkremers@fastmail.fm, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 02 18:54:54 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a4Bc5-0008Dz-8h for ged-emacs-devel@m.gmane.org; Wed, 02 Dec 2015 18:54:45 +0100 Original-Received: from localhost ([::1]:59629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Bc4-0003G0-Nj for ged-emacs-devel@m.gmane.org; Wed, 02 Dec 2015 12:54:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Bc0-0003Fq-Me for emacs-devel@gnu.org; Wed, 02 Dec 2015 12:54:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4Bbv-0006h0-28 for emacs-devel@gnu.org; Wed, 02 Dec 2015 12:54:39 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:49692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Bbu-0006go-M0 for emacs-devel@gnu.org; Wed, 02 Dec 2015 12:54:35 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NYQ00B00RSXO000@mtaout24.012.net.il> for emacs-devel@gnu.org; Wed, 02 Dec 2015 19:46:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYQ0066TS23AO60@mtaout24.012.net.il>; Wed, 02 Dec 2015 19:46:51 +0200 (IST) In-reply-to: <565F2DD3.9020400@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195771 Archived-At: > Date: Wed, 02 Dec 2015 18:43:47 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org >=20 > > For the first issue, IMO it isn't enough to specify just one val= ue, > > the required margin width. You need also to specify the width o= f the > > stuff, if any, that is displayed in the margin. (This will have= to be > > specified in pixels, because you can display images and pixel-gr= anular > > stretches of white space in the margins.) For example, linum-mo= de > > will specify a margin width of N columns, and display width of t= he > > same N columns in pixels. >=20 > How would this work with scaled text? Not sure what problem bothers you. set-window-margins interpret its argument as the number of character cells. Converting from pixels, i= f needed, is simple. If worse comes to worst, the requesting mode can use the likes of string-width to compute that. > > . for splitting the window with "C-x 2" and "C-x 3", the mode = could > > simply invoke the correct splitting function itself >=20 > When two modes simultaneously use the margins, which splitting func= tion > would be chosen? It's up to the mode that wants to support splitting in any non-trivia= l manner. The mode knows exactly what are its needs, so it is free of the guesswork. In any case, the same problem exists if this is somehow guessed. The infrastructure cannot know enough about the modes to make a decision. > > . for splitting the window as result of some command calling > > display-buffer, we could expect the modes to customize the > > display-buffer-* variables to control how the window is spli= t (if > > there are currently no features/variables to that effect, we= should > > add them) >=20 > When two modes simultaneously use the margins, which buffer display > function would be chosen? The same problem exists with the proposed solution, doesn't it? > And how would we handle functions like =E2=80=98set-window-fringes= =E2=80=99 or > =E2=80=98set-frame-width=E2=80=99? Hey, one problem at a time, please!