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: Mon, 07 Dec 2015 18:24:15 +0200 Message-ID: <838u56dy6o.fsf@gnu.org> References: <87mvttsvsj.fsf@fastmail.fm> <838u5cka88.fsf@gnu.org> <565F3441.1020707@gmx.at> <83610gjabz.fsf@gnu.org> <566086FA.6010603@gmx.at> <83h9jzi99p.fsf@gnu.org> <83d1umiq9u.fsf@gnu.org> <83lh9agtke.fsf@gnu.org> <834mfygihw.fsf@gnu.org> <83vb8dgbo6.fsf@gnu.org> <83si3hfhvy.fsf@gnu.org> <83bna4gajl.fsf@gnu.org> <83twnveewy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449505486 5708 80.91.229.3 (7 Dec 2015 16:24:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Dec 2015 16:24:46 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 07 17:24:37 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 1a5yab-0006Wi-0l for ged-emacs-devel@m.gmane.org; Mon, 07 Dec 2015 17:24:37 +0100 Original-Received: from localhost ([::1]:55339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5yaZ-0000MI-Q3 for ged-emacs-devel@m.gmane.org; Mon, 07 Dec 2015 11:24:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5yaQ-0000Ck-3T for emacs-devel@gnu.org; Mon, 07 Dec 2015 11:24:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5yaM-0001Fy-SH for emacs-devel@gnu.org; Mon, 07 Dec 2015 11:24:26 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:42419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5yaM-0001Fa-Je for emacs-devel@gnu.org; Mon, 07 Dec 2015 11:24:22 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NYZ00400XIPIZ00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 07 Dec 2015 18:24:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYZ004R9XKJCH30@a-mtaout22.012.net.il>; Mon, 07 Dec 2015 18:24:20 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:195948 Archived-At: > From: John Wiegley > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sun, 06 Dec 2015 16:29:01 -0800 > > > Now we are talking about going even farther into the fantasy land, and > > imagine packages that also want to control the order with which their stuff > > is displayed in the margins. Sounds like over-engineering to me, but if > > someone can show such packages, perhaps it's not fantasy after all. > > If the driving force behind this discussion is the inability of linum.el and > darkroom.el to play together, then I'm simply OK with them being incompatible > at this stage in Emacs' development. It is driven by inability of _any_ 2 packages to request margin space without stomping on the other package's needs. > I would much rather we solve the general case of dealing with window display > overall -- solving the multi-margin problem en passant -- than to invent new > APIs for a specific use case. > > It's OK if some things don't work -- even if it feels like they should. It's > better to wait for the right solution, then to scramble for an immediate > half-solution. I don't think we know what _is_ the right solution for the more general problem. We don't have any experience and AFAIK no packages that need such a solution. Anyway, I'm okay with trying to solve a more general case, if someone's got that itch, but I'd object to significant changes in the display engine on behalf of that, unless we have clear use cases that we want to support. The display engine already supports a gazillion minor features, many of which were almost unknown, until some inquiring minds discovered them, thought they were very cool, and are using each one of them in a couple of obscure packages, mostly unbundled, that are very precious to their users. So now we are in a situation where no significant cleanups are possible that won't cause bug reports about broken features, and adding new features is a royal pain. So I think we should be very cautious with adding non-trivial display features, and be sure they have important use cases backing them up that we want to support for the observable future.