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: Thu, 20 Mar 2014 17:43:14 +0100 Message-ID: References: , <87txav5jnz.fsf@lifelogs.com>, <87d2hi5p6n.fsf@lifelogs.com>, <87wqfp4cck.fsf@lifelogs.com>,<837g7o96mb.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_529bbe16-02a1-4f5d-8c64-11fa4384071c_" X-Trace: ger.gmane.org 1395333811 4642 80.91.229.3 (20 Mar 2014 16:43:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 16:43:31 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 17:43:36 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 1WQg48-0003Em-5W for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 17:43:36 +0100 Original-Received: from localhost ([::1]:48288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQg47-0000KQ-QM for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 12:43:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQg3z-0000Jv-GM for emacs-devel@gnu.org; Thu, 20 Mar 2014 12:43:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQg3u-0006Fg-9M for emacs-devel@gnu.org; Thu, 20 Mar 2014 12:43:27 -0400 Original-Received: from dub0-omc2-s35.dub0.hotmail.com ([157.55.1.174]:12579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQg3o-0006DW-Ff; Thu, 20 Mar 2014 12:43:16 -0400 Original-Received: from DUB111-W128 ([157.55.1.137]) by dub0-omc2-s35.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Mar 2014 09:43:15 -0700 X-TMN: [q1wXQwIsHmbA9havcDplMqA52kp0kbUu] X-Originating-Email: [arthur.miller@live.com] Importance: Normal In-Reply-To: <837g7o96mb.fsf@gnu.org> X-OriginalArrivalTime: 20 Mar 2014 16:43:15.0195 (UTC) FILETIME=[7D4D14B0:01CF445B] X-detected-operating-system: by eggs.gnu.org: Windows XP X-Received-From: 157.55.1.174 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:170633 Archived-At: --_529bbe16-02a1-4f5d-8c64-11fa4384071c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > EZ> I don't get it: switching between adjacent windows is a single > EZ> keystroke away (bind it to a key=2C if you are annoyed by "C-x o")Of = course it is not difficult to switch between windows with a shortcut or C-x= o=2C but look att this way: It is not difficult to press 'v' to enter "visual mode" or 'i' to enter ins= ert mode in Vim. Yet=2C we take it for granted in almost all modern text editors that certain features are always "present= ". No new editor is constructed to not be able to edit text in "immidiate mode" if I may call it so. If you look back at requested feature=2C instead of pressing C-x o to switc= h to another buffer=2C one press=20 (hypotetically) C-x e=2C and the correct file with correct position opens u= nder the cursor.=20 Before one can use C-x o=2C user has to open correct file and split window= =2C and than once switched to another buffer=2C find the right spot in the file. Now imagine if all of those smal= l steps are gone=2C and we can open=20 say main file=2C and from there automatically be pointed to correct files a= nd positions in file on request as needed. It may be possible with just a minor mode=3B I would be fine with that too= =2C I am just looking for functionality=2C not the looks=2C albeit looks might be helpful to make less distraction. It is just some thoughts :). > Date: Thu=2C 20 Mar 2014 18:28:44 +0200 > From: eliz@gnu.org > Subject: Re: "Adobe Brackets like" editing in emacs > To: emacs-devel@gnu.org >=20 > > From: Ted Zlatanov > > Date: Thu=2C 20 Mar 2014 02:23:55 -0400 > >=20 > > EZ> I don't get it: switching between adjacent windows is a single > > EZ> keystroke away (bind it to a key=2C if you are annoyed by "C-x o"). > >=20 > > I have=2C but looking in *two* places is a kind of context switch and > > clutters the display with more windows. >=20 > How is another window different from having contents of another file > inserted into the same window? The only difference is the mode line > between them -- is that really such a big deal? >=20 > > I also use `last-buffer' a lot=2C but that's also a context switch. >=20 > Nothing a simple minor mode couldn't handle. >=20 > > EZ> Sounds over-engineering to me. At the very least=2C I would sugges= t a > > EZ> fully-functional prototype that uses adjacent windows=2C before we > > EZ> decide if some other UI feature is needed. > >=20 > > You're asking for a fully-functional prototype of an alternative UI > > because a possible UI sounds like overengineering to you after a brief > > discussion? >=20 > I didn't ask for anything. I suggested to have this feature first > based on the existing infrastructure=2C i.e. in another window. This > should be easy to implement=2C and will allow collecting user experience > which we currently lack. Then decision of whether we need a new UI=2C > and which one=2C will be based on something=2C rather than on thin air. >=20 > Look at this another way: someone suggests that we adopt a "cool > feature" seen in another editor. That editor is for editing HTML > (which is hardly the main focus of Emacs)=2C and the specific feature we > are discussing here is not the only one=2C maybe even not the most > important one=2C in Brackets -- just look at the videos on their site. > Suddenly we are all sure this will be seemingly cool for editing C/C++ > etc.=2C but still insist that the UI feature should look and feel the > same=2C without even trying. Does this make a lot of sense? >=20 = --_529bbe16-02a1-4f5d-8c64-11fa4384071c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B EZ>=3B I don't get it: = switching between adjacent windows is a single
>=3B EZ>=3B keys=
troke away (bind it to a key=2C if you are annoyed by "C-x o")
Of cour= se it is not difficult to switch between windows with a shortcut or C-x o= =2C but look att this way:

It is not difficult to press 'v' to enter= "visual mode" or 'i' to enter insert mode in Vim. Yet=2C we take it for gr= anted
in almost all modern text editors that certain features are always= "present". No new editor is constructed
to not be able to edit text in = "immidiate mode" if I may call it so.

If you look back at requested = feature=2C instead of pressing C-x o to switch to another buffer=2C one pre= ss
(hypotetically) C-x e=2C and the correct file with correct position = opens under the cursor.

Before one can use C-x o=2C user has to ope= n correct file and split window=2C and than once switched to another
buf= fer=2C find the right spot in the file. Now imagine if all of those small s= teps are gone=2C and we can open
say main file=2C and from there automa= tically be pointed to correct files and positions in file on request as nee= ded.

It may be possible with just a minor mode=3B I would be fine wi= th that too=2C I am just looking for functionality=2C not the looks=2C
a= lbeit looks might be helpful to make less distraction.

It is just so= me thoughts :).

>=3B Date: Thu=2C 20 Mar 2014 18:28:44 +0200<= br>>=3B From: eliz@gnu.org
>=3B Subject: Re: "Adobe Brackets like" e= diting in emacs
>=3B To: emacs-devel@gnu.org
>=3B
>=3B >= =3B From: Ted Zlatanov <=3Btzz@lifelogs.com>=3B
>=3B >=3B Date: = Thu=2C 20 Mar 2014 02:23:55 -0400
>=3B >=3B
>=3B >=3B EZ>= =3B I don't get it: switching between adjacent windows is a single
>= =3B >=3B EZ>=3B keystroke away (bind it to a key=2C if you are annoyed = by "C-x o").
>=3B >=3B
>=3B >=3B I have=2C but looking in *t= wo* places is a kind of context switch and
>=3B >=3B clutters the di= splay with more windows.
>=3B
>=3B How is another window differe= nt from having contents of another file
>=3B inserted into the same wi= ndow? The only difference is the mode line
>=3B between them -- is th= at really such a big deal?
>=3B
>=3B >=3B I also use `last-buf= fer' a lot=2C but that's also a context switch.
>=3B
>=3B Nothin= g a simple minor mode couldn't handle.
>=3B
>=3B >=3B EZ>=3B= Sounds over-engineering to me. At the very least=2C I would suggest a
= >=3B >=3B EZ>=3B fully-functional prototype that uses adjacent window= s=2C before we
>=3B >=3B EZ>=3B decide if some other UI feature is= needed.
>=3B >=3B
>=3B >=3B You're asking for a fully-funct= ional prototype of an alternative UI
>=3B >=3B because a possible UI= sounds like overengineering to you after a brief
>=3B >=3B discussi= on?
>=3B
>=3B I didn't ask for anything. I suggested to have th= is feature first
>=3B based on the existing infrastructure=2C i.e. in = another window. This
>=3B should be easy to implement=2C and will all= ow collecting user experience
>=3B which we currently lack. Then deci= sion of whether we need a new UI=2C
>=3B and which one=2C will be base= d on something=2C rather than on thin air.
>=3B
>=3B Look at thi= s another way: someone suggests that we adopt a "cool
>=3B feature" se= en in another editor. That editor is for editing HTML
>=3B (which is = hardly the main focus of Emacs)=2C and the specific feature we
>=3B ar= e discussing here is not the only one=2C maybe even not the most
>=3B = important one=2C in Brackets -- just look at the videos on their site.
&= gt=3B Suddenly we are all sure this will be seemingly cool for editing C/C+= +
>=3B etc.=2C but still insist that the UI feature should look and fe= el the
>=3B same=2C without even trying. Does this make a lot of sens= e?
>=3B
= --_529bbe16-02a1-4f5d-8c64-11fa4384071c_--