From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: "Adobe Brackets like" editing in emacs Date: Thu, 20 Mar 2014 11:04:29 +0000 Message-ID: <87y505rv0i.fsf@newcastle.ac.uk> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395313478 30087 80.91.229.3 (20 Mar 2014 11:04:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 11:04:38 +0000 (UTC) Cc: Tom , emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 12:04:48 2014 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 1WQamF-0007Fm-5A for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 12:04:47 +0100 Original-Received: from localhost ([::1]:46292 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQamE-0000c8-Nx for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 07:04:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQam7-0000bm-O4 for emacs-devel@gnu.org; Thu, 20 Mar 2014 07:04:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQam3-0004hm-7V for emacs-devel@gnu.org; Thu, 20 Mar 2014 07:04:39 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:39950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQam3-0004fH-14; Thu, 20 Mar 2014 07:04:35 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129]) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1WQaly-00016l-Ad; Thu, 20 Mar 2014 11:04:30 +0000 Original-Received: from localhost (jangai.ncl.ac.uk [10.66.67.223]) (authenticated bits=0) by smtpauth-vm.ncl.ac.uk (8.13.8/8.13.8) with ESMTP id s2KB4UNJ028049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Mar 2014 11:04:30 GMT In-Reply-To: (Richard Stallman's message of "Wed, 19 Mar 2014 14:18:29 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:170611 Archived-At: Richard Stallman writes: > That implementation would be convenient if we want Emacs commands > to treat the two as separate windows. Is that what we want? > > Likewise with the proposal to use a tooltip-like frame for this. > > Likewise with the proposal to use display-strings for this. > > There are many ways to _show_ text from multiple files. The crucial > question is, how do we want editing commands to work in that mode? > That will constrain the possible implementations much more. > > We might want to create a C-level construct for showing parts of > various buffers as if they were a single buffer, and arrange for > editing primitives such as insert and delete to operate on > the underlying buffer for the part of the text where you do them. I think it might be worth considering whether we want something a bit more generic at a C-level. At the current time, the feature cannot be mimiced in Emacs because of the lack of an appropriate GUI feature (tooltips is the closest). My thought, is what we need is a new GUI feature that I call "mini-window". Essentially, this would be like a current window (with all the features would expect -- point, buffer and so on). But it would differ from a current window in that: a) it would have no or few decorations -- no border, no scrollbars, no mode line and b) it's positioning would be wrt another window -- it would either be positioned at one of the cardinal positions of an existing window or it would be positioned wrt a marker or an overlay in an existing buffer. The latter would scroll with the main buffer, the former would be static. With this GUI feature, we could implement quite a few other things. So, the multi-file editing would be use miniwindows positioned on a marker. Multi-mode editing could do the same (i.e a miniwindow with an indirect buffer in a different mode). Enhanced drop-down, tooltips for documentation could use the same feature (i.e. what would appear to be an in-window replacement for `with-help-window'). Other features would include the open and close hide/show markers down the left side of a buffer which Eli was talking about a few weeks ago -- I had a brief play with this and it *might* be possible with fringes but it's clunky. And yet another would be one of those displays showing an shrunken overview of the whole buffer, like sublime -- currently the closest to this is fisheye-with-thumbs http://www.emacswiki.org/emacs/FisheyeWithThumbs. For that matter, this could also be used to replace and reimplement the fringes. Just a thought -- in the ideal world an update to the C layer should give a generic toolkit that can then used in different ways. Phil