From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Fri, 31 Jul 2009 09:19:06 -0700 Message-ID: <1249057146.6160.40.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <1248280114.7109.33.camel@dell-desktop.example.com> <4A67593D.6020908@gmx.at> <1248289454.7109.47.camel@dell-desktop.example.com> <4A682C53.2080307@gmx.at> <1248375083.15583.9.camel@dell-desktop.example.com> <4A6970B8.7000006@gmx.at> <4A6AC7EA.2010007@gmx.at> <4A6B3CE2.8070404@gmx.at> <4A6C72BE.5080207@gmx.at> <1248628716.5952.11.camel@dell-desktop.example.com> <4A6C961E.3030805@gmx.at> <1248633292.5952.21.camel@dell-desktop.example.com> <4A6D4BE3.9080102@gmx.at> <1248710762.6165.28.camel@dell-desktop.example.com > <4A6DDB8D.2070601@gmx.at> <1248717944.6165.47.camel@dell-desktop.example.com> <4A6EAAE4.3090309@gmx.at> <1248794312.5971.7.camel@dell-desktop.example.com> <4A7010F8.90308@gmx.at> <1248895321.5922.54.camel@dell-desktop.example.com> <4A7162CF.6030209@gmx.at> <1248973286.6257.34.camel@dell-desktop.example.com> <4A72B47E.9060608@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249057170 17427 80.91.229.12 (31 Jul 2009 16:19:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jul 2009 16:19:30 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, Stefan Monnier , acm@muc.de, drew.adams@oracle.com, Miles Bader To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 31 18:19:22 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MWupF-00079G-37 for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2009 18:19:21 +0200 Original-Received: from localhost ([127.0.0.1]:52305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWupE-0002va-Eu for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2009 12:19:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWupA-0002vM-I8 for emacs-devel@gnu.org; Fri, 31 Jul 2009 12:19:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWup6-0002uU-4O for emacs-devel@gnu.org; Fri, 31 Jul 2009 12:19:16 -0400 Original-Received: from [199.232.76.173] (port=48677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWup5-0002uR-VV for emacs-devel@gnu.org; Fri, 31 Jul 2009 12:19:12 -0400 Original-Received: from smtp121.iad.emailsrvr.com ([207.97.245.121]:41703) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MWup3-0001jl-Lz; Fri, 31 Jul 2009 12:19:09 -0400 Original-Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id ECC9D1B40C1; Fri, 31 Jul 2009 12:19:08 -0400 (EDT) Original-Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 3F0BD1B40C0; Fri, 31 Jul 2009 12:19:07 -0400 (EDT) In-Reply-To: <4A72B47E.9060608@gmx.at> X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113461 Archived-At: Martin, Thank you for the time you've taken. I, at least, found your input helpful (see below). On Fri, 2009-07-31 at 11:08 +0200, martin rudalics wrote: > Mixing concepts like frames, windows and fringes is beyond my > imagination. FWIW, it's a simple point. You raised concern that if the edit area is regarded as the same frame as the frame that owns the window system window, full width edit area windows won't be as wide as the frame. I pointed out that that the redisplay code already has support for that situation in the form of fringes. (That answers the question for width. I'm less certain how height works out.) > > Again, I don't see why "fringe" doesn't already > > handle this. > I don't see why and how it does. You asked how a macro that checks to see if a window is full width would work and I explained how it might work with minimal changes to the redisplay engine. > Sorry, that's too much Infrastructural complexity for my taste so I > shall give up here. You'll have to talk this over with someone else. Please feel no need to apologize. Again, allow me to thank you for the time you took and especially for your pointed question about the full width window macro. That question helped orient me better towards the relevant redisplay code. Not to perpetuate an argument but just to sum up my view, for what it's worth: At the elisp and command level, one of two concepts must bear the brunt of newly added complexity: frames or windows. Windows are already the more complicated abstraction. They are the more venerable. They are the more commonly encountered at the command level. Window configurations are an area ripe for improvement and complicating windows for the sake of control panels will make that improvement harder. Frames are a simpler abstraction upon which less relies. The command set encourages fewer, weaker assumptions by users about how frames work. So, adding the new complexity mainly to frames seems a better idea. It better fits the mental model that users already have. It better preserves some of the longest lasting and most successful parts of the elisp interface. Additionally, it has been mentioned that if we have "window groups", there will follow desire to make them visually distinct. It seems to me that this will introduce a mechanism isomorphic to frame properties, and yet strangely, arbitrarily distinct from frame properties. Additionally, in "other applications", control panels often have elements such as toolbars - just as do Emacs frames. Having used such applications, I'm inclined to think that that's a nice feature. Adding toolbar support to window groups would be another way in which the question arises: "Why aren't these frames? Isn't this a redundant abstraction?" I can think of but one advantage to window groups instead of attached frames and that is simply that *initially* window groups can probably be implemented without touching the redisplay code. That is not a small advantage, I'm sure. The price for claiming that advantage seems a bit too high, to me. -t