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: "Adobe Brackets like" editing in emacs Date: Wed, 19 Mar 2014 18:36:49 +0200 Message-ID: <838us69mce.fsf@gnu.org> References: <87txav5jnz.fsf@lifelogs.com> <87d2hi5p6n.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395247008 7316 80.91.229.3 (19 Mar 2014 16:36:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 16:36:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 17:36:57 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 1WQJU7-0001qg-9D for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 17:36:55 +0100 Original-Received: from localhost ([::1]:42619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJU6-0005KV-TP for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 12:36:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJTy-0005Ea-EC for emacs-devel@gnu.org; Wed, 19 Mar 2014 12:36:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQJTt-0003W3-5d for emacs-devel@gnu.org; Wed, 19 Mar 2014 12:36:46 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:48881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJTs-0003Vi-Of for emacs-devel@gnu.org; Wed, 19 Mar 2014 12:36:41 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N2O00100Z461R00@mtaout28.012.net.il> for emacs-devel@gnu.org; Wed, 19 Mar 2014 18:36:36 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2O00O4MZGZOG30@mtaout28.012.net.il> for emacs-devel@gnu.org; Wed, 19 Mar 2014 18:36:35 +0200 (IST) In-reply-to: <87d2hi5p6n.fsf@lifelogs.com> 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.184 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:170549 Archived-At: > From: Ted Zlatanov > Date: Wed, 19 Mar 2014 08:49:04 -0400 > > On Wed, 19 Mar 2014 00:00:56 -0400 Richard Stallman wrote: > > TZ> A quick peek+edit in a #include in C, or "use My::Module" in Perl (where > TZ> you can say `perldoc -l My::Module' to find the module file), etc. would > TZ> be handy. > > RS> We already have such features, but they display the other file in > RS> another buffer. Why is it useful to put them in one buffer? > > So you don't have to switch buffers (and mental context). Most of the > time in C I'm flipping between a .h and a .c file. I don't get it: switching between adjacent windows is a single keystroke away (bind it to a key, if you are annoyed by "C-x o"). And with the kind of windmove.el, it's a non-issue, as you switch with a cursor motion command. So why do we need to invent some fancy new display feature, when we already have everything that is needed? As for mental context: you need to switch it anyway, since you are editing a different chunk of text, right? > This feature would work well for *short* includes, IMO. With long > includes you lose context and nothing is gained. Exactly. So why use it for short includes, or any includes? > I would make an analogy here to Literate Programming, where you > interweave documentation within the code. We're talking about > interweaving included snippets to build a dynamic whole. This is not what was requested, AFAIU, but if that's what you want, then make a mode which allows you to edit all the files in a single buffer, and then saves each one to its file. Again, one buffer with "normal" display is enough. > That's a UI design question and could be up to the implementation, not > in Emacs. I personally would like something akin to a folding editor > with clear delineation (maybe statically indented N spaces, like your > quotations) but would have to experiment to find the best interface. > It's definitely not going to look like anything we have today. Sounds over-engineering to me. At the very least, I would suggest a fully-functional prototype that uses adjacent windows, before we decide if some other UI feature is needed. The only infrastructure that seems to be ready for Brackets-like display is display strings. Of course, you'd have to provide keybindings that will emulate editing inside the display string, but that could be done just once, as some infrastructure in Lisp. Cannot say that I like this idea, but there you are.