From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: RE: "Adobe Brackets like" editing in emacs Date: Wed, 19 Mar 2014 13:53:37 +0100 Message-ID: References: , <87txav5jnz.fsf@lifelogs.com>, , <87d2hi5p6n.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_e931caf8-2a09-4b90-a8b9-3f9cfb55709c_" X-Trace: ger.gmane.org 1395233622 21759 80.91.229.3 (19 Mar 2014 12:53:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 12:53:42 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 13:53:52 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 1WQG0G-0007Iy-5a for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 13:53:52 +0100 Original-Received: from localhost ([::1]:41040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQG0F-0003XZ-Sv for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 08:53:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQG08-0003O5-3s for emacs-devel@gnu.org; Wed, 19 Mar 2014 08:53:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQG03-0005Xy-C2 for emacs-devel@gnu.org; Wed, 19 Mar 2014 08:53:44 -0400 Original-Received: from dub0-omc4-s22.dub0.hotmail.com ([157.55.2.97]:8918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQG03-0005Xl-2i for emacs-devel@gnu.org; Wed, 19 Mar 2014 08:53:39 -0400 Original-Received: from DUB111-W95 ([157.55.2.73]) by dub0-omc4-s22.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Mar 2014 05:53:37 -0700 X-TMN: [AwfV3FEUno6OCyG2CG/fydoDSZnP91KC] X-Originating-Email: [arthur.miller@live.com] Importance: Normal In-Reply-To: <87d2hi5p6n.fsf@lifelogs.com> X-OriginalArrivalTime: 19 Mar 2014 12:53:37.0418 (UTC) FILETIME=[3EB166A0:01CF4372] X-detected-operating-system: by eggs.gnu.org: Windows XP X-Received-From: 157.55.2.97 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:170524 Archived-At: --_e931caf8-2a09-4b90-a8b9-3f9cfb55709c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it sounds reasonable. We could have a limit on how big snippets are= "inlined" in the buffer=2C for example 20 lines of code=2C or 50 or someth= ing like that. What about combining with feature like folding=2C so that lo= nger function=2C classes etc are brought in as folded? Below is a picture how they have implemented in Bracktes=2C but nothing say= s that Emacs has to implement same way. I would be fine with just different= color on background for inlined code=2C but even if it was not such featur= es=2C just brining in the code would be nice. http://dev.brackets.io/preso/intro/assets/features/brackets-quick-edit-js.P= NG > To: emacs-devel@gnu.org > From: tzz@lifelogs.com > Subject: Re: "Adobe Brackets like" editing in emacs > Date: Wed=2C 19 Mar 2014 08:49:04 -0400 >=20 > On Wed=2C 19 Mar 2014 00:00:56 -0400 Richard Stallman wrote= :=20 >=20 > TZ> A quick peek+edit in a #include in C=2C or "use My::Module" in Pe= rl (where > TZ> you can say `perldoc -l My::Module' to find the module file)=2C e= tc. would > TZ> be handy. >=20 > RS> We already have such features=2C but they display the other file in > RS> another buffer. Why is it useful to put them in one buffer? >=20 > 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. This feature would > work well for *short* includes=2C IMO. With long includes you lose > context and nothing is gained. >=20 > I would make an analogy here to Literate Programming=2C where you > interweave documentation within the code. We're talking about > interweaving included snippets to build a dynamic whole. >=20 > RS> What does it look like=2C to have multiple files in one buffer? >=20 > That's a UI design question and could be up to the implementation=2C not > in Emacs. I personally would like something akin to a folding editor > with clear delineation (maybe statically indented N spaces=2C 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. >=20 > Ted >=20 >=20 = --_e931caf8-2a09-4b90-a8b9-3f9cfb55709c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think it sounds reasonable. We= could have a limit on how big snippets are "inlined" in the buffer=2C for = example 20 lines of code=2C or 50 or something like that. What about combin= ing with feature like folding=2C so that longer function=2C classes etc are= brought in as folded?

Below is a picture how they have implemented = in Bracktes=2C but nothing says that Emacs has to implement same way. I wou= ld be fine with just different color on background for inlined code=2C but = even if it was not such features=2C just brining in the code would be nice.=

http://dev.bra= ckets.io/preso/intro/assets/features/brackets-quick-edit-js.PNG

=
>=3B To: emacs-devel@gnu.org
>=3B From: tzz@lifelogs.com
>= =3B Subject: Re: "Adobe Brackets like" editing in emacs
>=3B Date: Wed= =2C 19 Mar 2014 08:49:04 -0400
>=3B
>=3B On Wed=2C 19 Mar 2014 0= 0:00:56 -0400 Richard Stallman <=3Brms@gnu.org>=3B wrote:
>=3B >=3B TZ>=3B A quick peek+edit in a #include in C=2C or "use My::M= odule" in Perl (where
>=3B TZ>=3B you can say `perldoc -l My::Mo= dule' to find the module file)=2C etc. would
>=3B TZ>=3B be hand= y.
>=3B
>=3B RS>=3B We already have such features=2C but they = display the other file in
>=3B RS>=3B another buffer. Why is it us= eful to put them in one buffer?
>=3B
>=3B So you don't have to s= witch buffers (and mental context). Most of the
>=3B time in C I'm fl= ipping between a .h and a .c file. This feature would
>=3B work well = for *short* includes=2C IMO. With long includes you lose
>=3B context= and nothing is gained.
>=3B
>=3B I would make an analogy here t= o Literate Programming=2C where you
>=3B interweave documentation with= in the code. We're talking about
>=3B interweaving included snippets = to build a dynamic whole.
>=3B
>=3B RS>=3B What does it look l= ike=2C to have multiple files in one buffer?
>=3B
>=3B That's a = UI design question and could be up to the implementation=2C not
>=3B i= n Emacs. I personally would like something akin to a folding editor
>= =3B with clear delineation (maybe statically indented N spaces=2C like your=
>=3B quotations) but would have to experiment to find the best interf= ace.
>=3B It's definitely not going to look like anything we have toda= y.
>=3B
>=3B Ted
>=3B
>=3B
= --_e931caf8-2a09-4b90-a8b9-3f9cfb55709c_--