"Adobe Brackets like" editing in emacs

"Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

Hi, 

my name is Arthur, and I just subscribed to this list. Though I am new to this list, I am not so new to Emacs.I have just a question/thought about a feature I would like see in Emacs, hope you don't mind. 

Lately Adobes Brackets editor has got some popularity (It seems to be pretty much Emacs on javascript). I am not really into using it full time, since I am good with Emacs, but I do like the idea of mulitple file editing in one buffer. It is like context-aware multi-file editing or what it should be called. They use it to edit css or javascript while editing html file, så that one does not have to switch between buffers/files. It seems pretty handy, and I would kind-a like to see implementation for C/C++ (macros, templates) and so on.

I think it shouldn't be impossible to do now, since Emacs already can split window and show multiple buffers. How difficult would it be to add a mode/feature to "expand" a buffer (split window) under the current line and load exact part of a file with of course correct langauge mode and so on. I guess semantic package would be needed since it seems to be similar context awareness as it is needed for code completition.

I am not knowledgable about Emacs internals, so I don't really know where to hack, but wonder if something similar is already implemented or "on the way".


 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1597 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

     I am not really into using it full time, since I am good with
     Emacs, but I do like the idea of mulitple file editing in one
     buffer. It is like context-aware multi-file editing or what it
     should be called. They use it to edit css or javascript while
     editing html file,

The easier way to do this in Emacs would be to do it at the C level.
It would be fairly straightforward that way.

But why is it useful to put multiple files in one buffer?
Can you describe a use case more precisely?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

Thanks for the fast answer.

Well it is pretty similar to what is called "intellisense", but it does not pop-up in a new window and offers code editing rather than code completition. 
For example while editing html, if one clicks on an element, code for css-style property for that element is displayed direclty below under the line
of the code for that tag and one can edit that particular piece of css. They call it "quick edit". It is a bit faster way to work since one does not have to switch between files. For example I personally usually have html file in one window + css or javacript file in another window, Emacs been split horisontally in two windows. Similary I usually have .h and .c files in two windows with horisontaly split emacs. But if I want to edit them still have to switch ctrl+x o and to scroll to correct place to change the code. 

In brackets they bring the relevant piece of code under the line below the cursor, and it "feels" like part of same file, they "paste it in"
in the editing buffer. Rather than user looking in files for part of code to edit, the editor brings the relevant part to the user. It is simply a
bit of automation for the user - text editor doing stuff for us. 

I am not sure if I am really that good in explaining, english is not my first (or second) language. They do have a simple descrition on their webbpage how it works: http://brackets.io/index.html and there is a picture of it in action: http://dev.brackets.io/preso/intro/assets/features/brackets-quick-edit-js.PNG

There are several videos on youtube of functionality in the action, here is one: https://www.youtube.com/watch?v=yw0QB2dnbJ4 (skip to 5:40 for the relevant part).

best regards 
/a

> Date: Tue, 18 Mar 2014 15:01:14 -0400
> From: rms@gnu.org
> To: arthur.miller@live.com
> Subject: Re: "Adobe Brackets like" editing in emacs
> CC: emacs-devel@gnu.org
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>      I am not really into using it full time, since I am good with
>      Emacs, but I do like the idea of mulitple file editing in one
>      buffer. It is like context-aware multi-file editing or what it
>      should be called. They use it to edit css or javascript while
>      editing html file,
> 
> The easier way to do this in Emacs would be to do it at the C level.
> It would be fairly straightforward that way.
> 
> But why is it useful to put multiple files in one buffer?
> Can you describe a use case more precisely?
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 3607 bytes --]

RE: "Adobe Brackets like" editing in emacs

[Stephen J. Turnbull]

arthur miller writes:

 > Thanks for the fast answer.

 > For example while editing html, if one clicks on an element, code
 > for css-style property for that element is displayed direclty below
 > under the lineof the code for that tag and one can edit that
 > particular piece of css.

Which CSS property?  The "C" in CSS stands for "cascading".  That is,
there may be a style attribute on the current element, there may be a
style element in the document, and there may be multiple rel=style
links in the document, any of which might be what you're editing.  Or
you might actually be creating a style attribute on the element.

 > They call it "quick edit".

Is it trademarked? ;-)

 > It is a bit faster way to work since one does not have to switch
 > between files.

Uh, if it's in an external stylesheet you *must* switch files.  I
assume you mean you don't have to switch *windows*?

For your style of editing to be efficient, does it really have to be
in the same window, or would it be OK if it popped up in a tooltip-
like, undecorated window very close to the point you click on?  Unlike
a tooltip, which tries to stay out of the way, it would always appear
in exactly the same place, though.  (I ask because I think I would
prefer a separate popup window, perhaps with a different background,
to transiently inserting text in the current buffer.  I think I would
want that window immediately below the modified element's open tag.)

 > I am not sure if I am really that good in explaining, english is
 > not my first (or second) language.

Your explanation is perfectly understandable, but you should avoid
giving examples which don't help much.  For example, intellisense:

 > Well it is pretty similar to what is called "intellisense", but it
 > does not pop-up in a new window and offers code editing rather than
 > code completition.

In other words, it has nothing in common with intellisense, except
that it's context-sensitive.  If you don't have the word "context-
sensitive", I can understand why you'd use intellisense as an example,
but it didn't help me at all because the context that intellisense
uses (a partial word from the same program) is rather different from
the context used here (a cross-file link).

I would use the analogy of a link in a web page, except that instead
of your focus jumping to the linked content (which is annoying and
inefficient for a transient activity), the linked content is "pulled"
to your focus point temporarily.  

Re: "Adobe Brackets like" editing in emacs

[Ivan Andrus]

On Mar 18, 2014, at 10:18 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

>> For example while editing html, if one clicks on an element, code
>> for css-style property for that element is displayed direclty below
>> under the lineof the code for that tag and one can edit that
>> particular piece of css.
> 
> Which CSS property?  The "C" in CSS stands for "cascading".  That is,
> there may be a style attribute on the current element, there may be a
> style element in the document, and there may be multiple rel=style
> links in the document, any of which might be what you're editing.  Or
> you might actually be creating a style attribute on the element.

I haven’t used it, but I think it grabs _all_ relevant styles.  Gathering them from across several files, and putting them in a single editable place.  

-Ivan

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On Wed, Mar 19, 2014 at 3:01 PM, Ivan Andrus <darthandrus@gmail.com> wrote:

> On Mar 18, 2014, at 10:18 PM, Stephen J. Turnbull <stephen@xemacs.org>
> wrote:
>
> >> For example while editing html, if one clicks on an element, code
> >> for css-style property for that element is displayed direclty below
> >> under the lineof the code for that tag and one can edit that
> >> particular piece of css.
> >
> > Which CSS property?  The "C" in CSS stands for "cascading".  That is,
> > there may be a style attribute on the current element, there may be a
> > style element in the document, and there may be multiple rel=style
> > links in the document, any of which might be what you're editing.  Or
> > you might actually be creating a style attribute on the element.
>
> I haven’t used it, but I think it grabs _all_ relevant styles.  Gathering
> them from across several files, and putting them in a single editable place.
>
> -Ivan
>

Is not that a very difficult part? It requires tight integration with the
webbrowser (or a framework within Emacs for CSS+HTML).

[-- Attachment #2: Type: text/html, Size: 2093 bytes --]

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

Hmm, njah, are u sure?

I think it would be enough to look into included files, but yes it probably needs integration with programming modes; but probably not more than to know 
what mode to load based on edited code. That info is available though for moste modes; for example in C/C++ included code is usually C/C++. Inline assembly can be deduced by directives in the code.

In case of webb languages, for example there are usually declarations and link-types in header, or is definition itself in the file btween <scrypt> or <style>

Since compliers are not that clever by themselves there is usually some kind of in the code itself that emacs might use?

From: lennart.borgman@gmail.com
Date: Wed, 19 Mar 2014 16:03:34 +0100
Subject: Re: "Adobe Brackets like" editing in emacs
To: darthandrus@gmail.com
CC: stephen@xemacs.org; rms@gnu.org; arthur.miller@live.com; emacs-devel@gnu.org

On Wed, Mar 19, 2014 at 3:01 PM, Ivan Andrus <darthandrus@gmail.com> wrote:


On Mar 18, 2014, at 10:18 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:





>> For example while editing html, if one clicks on an element, code

>> for css-style property for that element is displayed direclty below

>> under the lineof the code for that tag and one can edit that

>> particular piece of css.

>

> Which CSS property?  The "C" in CSS stands for "cascading".  That is,

> there may be a style attribute on the current element, there may be a

> style element in the document, and there may be multiple rel=style

> links in the document, any of which might be what you're editing.  Or

> you might actually be creating a style attribute on the element.



I haven’t used it, but I think it grabs _all_ relevant styles.  Gathering them from across several files, and putting them in a single editable place.



-Ivan


Is not that a very difficult part? It requires tight integration with the webbrowser (or a framework within Emacs for CSS+HTML). 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2873 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

On Wed, Mar 19, 2014 at 4:16 PM, arthur miller <arthur.miller@live.com>wrote:

> Hmm, njah, are u sure?
>

Yes. ;-)

In case of webb languages, for example there are usually declarations and
> link-types in header, or is definition itself in the file btween <scrypt>
> or <style>
>

The rules are quite complicated, actually. You have to look closely at
media queries etc.


>
> ------------------------------
> From: lennart.borgman@gmail.com
> Date: Wed, 19 Mar 2014 16:03:34 +0100
>
> Subject: Re: "Adobe Brackets like" editing in emacs
> To: darthandrus@gmail.com
> CC: stephen@xemacs.org; rms@gnu.org; arthur.miller@live.com;
> emacs-devel@gnu.org
>
>
> On Wed, Mar 19, 2014 at 3:01 PM, Ivan Andrus <darthandrus@gmail.com>wrote:
>
> On Mar 18, 2014, at 10:18 PM, Stephen J. Turnbull <stephen@xemacs.org>
> wrote:
>
> >> For example while editing html, if one clicks on an element, code
> >> for css-style property for that element is displayed direclty below
> >> under the lineof the code for that tag and one can edit that
> >> particular piece of css.
> >
> > Which CSS property?  The "C" in CSS stands for "cascading".  That is,
> > there may be a style attribute on the current element, there may be a
> > style element in the document, and there may be multiple rel=style
> > links in the document, any of which might be what you're editing.  Or
> > you might actually be creating a style attribute on the element.
>
> I haven’t used it, but I think it grabs _all_ relevant styles.  Gathering
> them from across several files, and putting them in a single editable place.
>
> -Ivan
>
>
> Is not that a very difficult part? It requires tight integration with the
> webbrowser (or a framework within Emacs for CSS+HTML).
>

[-- Attachment #2: Type: text/html, Size: 5501 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Ivan Andrus]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Mar 19, 2014, at 9:03 AM, Lennart Borgman <lennart.borgman@gmail.com>
wrote:

On Wed, Mar 19, 2014 at 3:01 PM, Ivan Andrus <darthandrus@gmail.com> wrote:

> On Mar 18, 2014, at 10:18 PM, Stephen J. Turnbull <stephen@xemacs.org>
> wrote:
>
> >> For example while editing html, if one clicks on an element, code
> >> for css-style property for that element is displayed direclty below
> >> under the lineof the code for that tag and one can edit that
> >> particular piece of css.
> >
> > Which CSS property?  The "C" in CSS stands for "cascading".  That is,
> > there may be a style attribute on the current element, there may be a
> > style element in the document, and there may be multiple rel=style
> > links in the document, any of which might be what you're editing.  Or
> > you might actually be creating a style attribute on the element.
>
> I haven't used it, but I think it grabs _all_ relevant styles.  Gathering
> them from across several files, and putting them in a single editable place.
>
> -Ivan
>

Is not that a very difficult part? It requires tight integration with the
webbrowser (or a framework within Emacs for CSS+HTML).


I definitely think that is hard, but also the _useful_ part.  Having it in
the same buffer is eye candy, but doesn't seem that much better than a
separate buffer IMHO (not to discourage anyone).  Something along the lines
of wgrep.el, but bringing in the correct portions of buffers intelligently
would be awesome.  Brackets does it for html/css, but I would like it for
C++, elisp, and other modes as well.  e.g. I think it would be really nice
to have a buffer with every occurrence of some function/object to be able
to edit them all in a single place.  But finding everything is non-trivial,
see for example the recent clang vs gcc vs CEDET thread. :-)

-Ivan

[-- Attachment #2: Type: text/html, Size: 2698 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

On Wed, Mar 19, 2014 at 4:31 PM, Ivan Andrus <darthandrus@gmail.com> wrote:

> On Mar 19, 2014, at 9:03 AM, Lennart Borgman <lennart.borgman@gmail.com>
> wrote:
>
> On Wed, Mar 19, 2014 at 3:01 PM, Ivan Andrus <darthandrus@gmail.com>wrote:
>
>> On Mar 18, 2014, at 10:18 PM, Stephen J. Turnbull <stephen@xemacs.org>
>> wrote:
>>
>> >> For example while editing html, if one clicks on an element, code
>> >> for css-style property for that element is displayed direclty below
>> >> under the lineof the code for that tag and one can edit that
>> >> particular piece of css.
>> >
>> > Which CSS property?  The "C" in CSS stands for "cascading".  That is,
>> > there may be a style attribute on the current element, there may be a
>> > style element in the document, and there may be multiple rel=style
>> > links in the document, any of which might be what you're editing.  Or
>> > you might actually be creating a style attribute on the element.
>>
>> I haven’t used it, but I think it grabs _all_ relevant styles.  Gathering
>> them from across several files, and putting them in a single editable place.
>>
>> -Ivan
>>
>
> Is not that a very difficult part? It requires tight integration with the
> webbrowser (or a framework within Emacs for CSS+HTML).
>
>
> I definitely think that is hard, but also the _useful_ part.  Having it in
> the same buffer is eye candy, but doesn’t seem that much better than a
> separate buffer IMHO (not to discourage anyone).  Something along the lines
> of wgrep.el, but bringing in the correct portions of buffers intelligently
> would be awesome.  Brackets does it for html/css, but I would like it for
> C++, elisp, and other modes as well.  e.g. I think it would be really nice
> to have a buffer with every occurrence of some function/object to be able
> to edit them all in a single place.  But finding everything is non-trivial,
> see for example the recent clang vs gcc vs CEDET thread. :-)
>
> -Ivan
>

Then I think Emacs must move in the direction of much tighter integration
with compilers and environments. Tighter integration with the environments
probably means allowing Emacs to be used as a plugin (in the browser in
this case).

[-- Attachment #2: Type: text/html, Size: 4352 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Then I think Emacs must move in the direction of much tighter
 > integration with compilers and environments.  Tighter integration
 > with the environments probably means allowing Emacs to be used as a
 > plugin (in the browser in this case).

I don't really see that.  In the great majority of cases there's about
one file to worry about (a CSS file accessed from a <link rel=stylesheet>).

Sure, we could do better with huge integration, but the point now is
more to get something (anything!) working.  Many Emacs users will also
be able to deal with the concept of configuring for their use case (do
you have on-the-fly style changes in a script? very well, configure
that script as an auxiliary file to search for such changes).  And so
on.  Leverage our users' skills to make life better for them, then
worry about putting Eclipse and Mozilla plugins out of business.

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Wed, Mar 19, 2014 at 5:20 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

> Lennart Borgman writes:
>
>  > Then I think Emacs must move in the direction of much tighter
>  > integration with compilers and environments.  Tighter integration
>  > with the environments probably means allowing Emacs to be used as a
>  > plugin (in the browser in this case).
>
> I don't really see that.  In the great majority of cases there's about
> one file to worry about (a CSS file accessed from a <link rel=stylesheet>).
>

With media queries, of course. They are very important today.

So careful parsing is still required (even in the case with just one CSS
file).

[-- Attachment #2: Type: text/html, Size: 1309 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On Wed, Mar 19, 2014 at 5:37 PM, Lennart Borgman
<lennart.borgman@gmail.com>wrote:

> On Wed, Mar 19, 2014 at 5:20 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
>
>> Lennart Borgman writes:
>>
>>  > Then I think Emacs must move in the direction of much tighter
>>  > integration with compilers and environments.  Tighter integration
>>  > with the environments probably means allowing Emacs to be used as a
>>  > plugin (in the browser in this case).
>>
>> I don't really see that.  In the great majority of cases there's about
>> one file to worry about (a CSS file accessed from a <link
>> rel=stylesheet>).
>>
>
> With media queries, of course. They are very important today.
>
> So careful parsing is still required (even in the case with just one CSS
> file).
>

But on the other hand that careful parsing could be made into an advantage.
I just know a few environments for hunting CSS-rules. In those I have seen
no simple way to see how the different media queries apply to the element I
am looking at. Quite inconvenient actually. (I assume it is coming soon,
though.)

[-- Attachment #2: Type: text/html, Size: 2272 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Emacs can be used as a plugin in a browser whose license is
GPL-compatible.  However, you wouldn't really want Emacs to die each
time you end a browser session.  It is better to have the browser talk
to emacsclient or something like emacsclient.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

As I think more of it, I can see it as a folding of code. Emacs already supports folding of code (with a minor mode) which
I don't use so much. "Quick edit" could be seen as code folding, from different files; for example if we call a macro in .c file
defined in some .h file, one could invoke a "quick edit" to "fold-out" a macro, edit it and continue on with coding .c file.

Or if we call an elisp function, we could "unfold it" in place, edit it, and continue on with the code where function was called.

Hope it offers some more clarification and use-case scenario.

> Date: Tue, 18 Mar 2014 15:01:14 -0400
> From: rms@gnu.org
> To: arthur.miller@live.com
> Subject: Re: "Adobe Brackets like" editing in emacs
> CC: emacs-devel@gnu.org
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>      I am not really into using it full time, since I am good with
>      Emacs, but I do like the idea of mulitple file editing in one
>      buffer. It is like context-aware multi-file editing or what it
>      should be called. They use it to edit css or javascript while
>      editing html file,
> 
> The easier way to do this in Emacs would be to do it at the C level.
> It would be fairly straightforward that way.
> 
> But why is it useful to put multiple files in one buffer?
> Can you describe a use case more precisely?
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2205 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Alan Schmitt]

Hello Arthur,

arthur miller <arthur.miller@live.com> writes:

> As I think more of it, I can see it as a folding of code. Emacs already
> supports folding of code (with a minor mode) which
> I don't use so much. "Quick edit" could be seen as code folding, from
> different files; for example if we call a macro in .c file
> defined in some .h file, one could invoke a "quick edit" to "fold-out" a
> macro, edit it and continue on with coding .c file.
>
> Or if we call an elisp function, we could "unfold it" in place, edit it,
> and continue on with the code where function was called.
>
> Hope it offers some more clarification and use-case scenario.

Does it have to be in the same buffer? In other words, if a command
opened the definition of the current function/css class/tag in a new
window, with the cursor positioned at the definition, would it be
sufficient? I watched the video, and I don't see why the definition has
to be unfolded in the current buffer.

Alan

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

I was thinking of the split-window as emacs already has it built in. It would be probably
possible to code something with semantic. Or opening in a pop-up window, like new emacs window.
Or maybe doing some connection between two buffers something similar with multiple cursors, probably
some other way as well.

But putting it below the line currently edited in same buffer, without any special borders is probably most user
friendly if one thinks in term of human-computer interaction. It is less eye and attention distracting. Editing in another
window requires one to split attention and to eventually close the window after (which probably could be automated too).
There are also borders, scrollbars etc to consider if opened in another buffer/window.

It is kind-of subtle, but quite relevant difference for the workflow if the content of another file is brought directly in the buffer
as if the content is part of same file. 

It might also be just my subjective feeling and perception at the moment :).


> From: alan.schmitt@polytechnique.org
> To: arthur.miller@live.com
> CC: rms@gnu.org; emacs-devel@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> Date: Tue, 18 Mar 2014 22:29:17 +0100
> 
> Hello Arthur,
> 
> arthur miller <arthur.miller@live.com> writes:
> 
> > As I think more of it, I can see it as a folding of code. Emacs already
> > supports folding of code (with a minor mode) which
> > I don't use so much. "Quick edit" could be seen as code folding, from
> > different files; for example if we call a macro in .c file
> > defined in some .h file, one could invoke a "quick edit" to "fold-out" a
> > macro, edit it and continue on with coding .c file.
> >
> > Or if we call an elisp function, we could "unfold it" in place, edit it,
> > and continue on with the code where function was called.
> >
> > Hope it offers some more clarification and use-case scenario.
> 
> Does it have to be in the same buffer? In other words, if a command
> opened the definition of the current function/css class/tag in a new
> window, with the cursor positioned at the definition, would it be
> sufficient? I watched the video, and I don't see why the definition has
> to be unfolded in the current buffer.
> 
> Alan
 		 	   		   		 	   		  

[-- Attachment #2: Type: text/html, Size: 2781 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Tom]

arthur miller <arthur.miller <at> live.com> writes:

> But putting it below the line currently edited in same buffer, without 
> any special borders is probably most userfriendly if one thinks in 
> term of human-computer interaction. It is less eye and attention
> distracting. 

You could emulate something similar with windows. If this view is only
temporary while the editing is progress then the code could split the
current window below the relevant line, hide the mode line temporarily,
so there is no distracting ui element between the referring code and
the referred code and put the definition in the bottom window.

This would look very much like the screenshot, and when the user quits
this special temporary editing view then windows/mode lines/etc would
be restored to their original state.

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    You could emulate something similar with windows. If this view is only
    temporary while the editing is progress then the code could split the
    current window below the relevant line, hide the mode line temporarily,
    so there is no distracting ui element between the referring code and
    the referred code and put the definition in the bottom window.

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.

Should they give errors if applied to regions that
stretch from one file to another?  That would be easy to do
and would sidestep hard problems that perhaps don't need
to be solved.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Phillip Lord]

Richard Stallman <rms@gnu.org> 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

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 5187 bytes --]

Couldn't feature be mimicked if a widow is split in 3 parts horsontally, with follow mode, so
that first and last window display original file, and window in the middle new file?

Something like this in this mockup: http://nextpoint.se/bc/e1.png

(Sorry my darkc harcoal theme is kind-a not very pedagogic indeed).

I would be fine with implementation like this, if I could say mark a property and have shortcut to automatically
bring in function/class member/property/etc in window below, and when I am done to remove the window.

It does not even have to split window, it could just divide into two windows, one with original file, and one with
new file, and when editing is done, just close window with new buffer. Possibly one could add a list of all files with
the property as in Brackets. Here is another screen of a possible mockup: http://nextpoint.se/bc/e2.png  (ignore data 
in buffers of course).

Couldn't it be done with elisp already? Maybe there is something similar? For example, C-X C-F shows a buffer with
completitions, which disappears when completition is done. It does not have to be exactly as in Brackets. 

I see it just as a faster way to work with files; let editor bring in files and correct place to edit, under the cursor, 
rather than user bring cursor to switch between buffers, files and finding place to edit. Even
 if it is not difficult to 
press C-X o, I use it all the time, this is 
indeed a bit of time saver. Think also of pressing C-X C-F and typing
 file names. 
When in different folders, one has to switch to another 
buffer or to edit folder name in minibuffer and so on.

Isn't difficult part more semanitc one - to find relevant data in other files. Emacs needs ctags or CEDET, to
implement functionality like jumping to variable declarations and funtion definitions. As said, I am not so knowledgable
about Emacs internals and writing modes; my knowledge of elisp and Emacs internals is sadly limited to edit .emacs file.
I am just an user; that is why I am asking experts in this list for opinion and help :). Hope you bear with me.

> From: phillip.lord@newcastle.ac.uk
> To: rms@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> Date: Thu, 20 Mar 2014 11:04:29 +0000
> CC: adatgyujto@gmail.com; emacs-devel@gnu.org
> 
> Richard Stallman <rms@gnu.org> 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
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 5952 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Couldn't feature be mimicked if a widow is split in 3 parts horsontally, with follow mode, so
    that first and last window display original file, and window in the middle new file?

If the sort of display made by Brackets is useful,
I think it would be better to implement it at the C level
so that we could make it look as nice as it does in Brackets.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:
>     Couldn't feature be mimicked if a widow is split in 3 parts horsontally,
> with follow mode, so
>     that first and last window display original file, and window in the middle
> new file?
>
> If the sort of display made by Brackets is useful,
> I think it would be better to implement it at the C level
> so that we could make it look as nice as it does in Brackets.

Also, so that it looks *different* from having a window split into 3
parts, so that the behaviour coming from it is expected.

Phil

Re: "Adobe Brackets like" editing in emacs

[chad]

On 21 Mar 2014, at 04:36, Phillip Lord <phillip.lord@newcastle.ac.uk> wrote:
> 
> Also, so that it looks *different* from having a window split into 3
> parts, so that the behaviour coming from it is expected.

I don’t disagree that it looks nice in Brackets, but having poked at it a bit, I think I’d be confused about what was going on without the line numbers displayed, which might be an issue for emacs. Something to see once we have an implementation, I guess.

~Chad

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If display with line numbers is useful, we could improve that part
of Emacs too.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Stefan]

> shrunken overview of the whole buffer, like sublime -- currently the
> closest to this is fisheye-with-thumbs
> http://www.emacswiki.org/emacs/FisheyeWithThumbs.

There's also minimap.el (in GNU ELPA).


        Stefan

Re: "Adobe Brackets like" editing in emacs

[Phillip Lord]

Stefan <monnier@iro.umontreal.ca> writes:

>> shrunken overview of the whole buffer, like sublime -- currently the
>> closest to this is fisheye-with-thumbs
>> http://www.emacswiki.org/emacs/FisheyeWithThumbs.
>
> There's also minimap.el (in GNU ELPA).

Didn't know about this. Now imagine the *minimap* window on the left of
the window to which is associates (say blah.el) but with the modeline of
blah.el extending under both, and scrollbars also to the left of
*minimap*. Editing commands in blah.el would still behave as now.

That minimap.el exists and works shows that elisp is fast enough for the
task of maintaining the contents.

Likewise, compare for example the documentation display capability of light-table....

http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/

to that of CIDER

https://github.com/clojure-emacs/cider

Essentially, it's the same thing, but the lack of borders or decorations
means that the interface for light table is much more pleasing.

Phil

Re: "Adobe Brackets like" editing in emacs

[Ted Zlatanov]

On Thu, 20 Mar 2014 11:04:29 +0000 phillip.lord@newcastle.ac.uk (Phillip Lord) wrote: 

PL> My thought, is what we need is a new GUI feature that I call
PL> "mini-window". Essentially, this would be like a current window (with
PL> all the features would expect -- point, buffer and so on). But it would
PL> differ from a current window in that: a) it would have no or few
PL> decorations -- no border, no scrollbars, no mode line and b) it's
PL> positioning would be wrt another window -- it would either be positioned
PL> at one of the cardinal positions of an existing window or it would be
PL> positioned wrt a marker or an overlay in an existing buffer. The latter
PL> would scroll with the main buffer, the former would be static.

For the (a) piece, see
http://permalink.gmane.org/gmane.emacs.devel/140353 (discussion of a
just-the-text Emacs frame) that got some good results in X.

Ted

Re: "Adobe Brackets like" editing in emacs

[Phillip Lord]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 20 Mar 2014 11:04:29 +0000 phillip.lord@newcastle.ac.uk (Phillip Lord) wrote: 
>
> PL> My thought, is what we need is a new GUI feature that I call
> PL> "mini-window". Essentially, this would be like a current window (with
> PL> all the features would expect -- point, buffer and so on). But it would
> PL> differ from a current window in that: a) it would have no or few
> PL> decorations -- no border, no scrollbars, no mode line and b) it's
> PL> positioning would be wrt another window -- it would either be positioned
> PL> at one of the cardinal positions of an existing window or it would be
> PL> positioned wrt a marker or an overlay in an existing buffer. The latter
> PL> would scroll with the main buffer, the former would be static.
>
> For the (a) piece, see
> http://permalink.gmane.org/gmane.emacs.devel/140353 (discussion of a
> just-the-text Emacs frame) that got some good results in X.


I think we are talking at cross-purposes. When I said "window" I mean
"window-as-in-emacs" rather than "frame".

What I was hoping to achieve was something like the attached. The help
window is a mini-window embedded in the bottom left and tied to
cancel-timer bit of the text.


Phil


[-- Attachment #2: emacs-miniwindow.png --]
[-- Type: image/png, Size: 83225 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Ted Zlatanov]

On Tue, 18 Mar 2014 15:01:14 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> The easier way to do this in Emacs would be to do it at the C level.
RS> It would be fairly straightforward that way.

RS> But why is it useful to put multiple files in one buffer?
RS> Can you describe a use case more precisely?

A quick peek+edit in a #include in C, or "use My::Module" in Perl (where
you can say `perldoc -l My::Module' to find the module file), etc. would
be handy.

Ted

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    A quick peek+edit in a #include in C, or "use My::Module" in Perl (where
    you can say `perldoc -l My::Module' to find the module file), etc. would
    be handy.

We already have such features, but they display the other file in
another buffer.	  Why is it useful to put them in one buffer?

What does it look like, to have multiple files in one buffer?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Vibhav Pant]

From what I can see, this would require the usage of a "tooltip-like"
text editing interface, which should be easy to implement for Emacs
builds using a windowing system, though making it work for the text
interface should be pretty hard.

On Wed, Mar 19, 2014 at 9:30 AM, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     A quick peek+edit in a #include in C, or "use My::Module" in Perl (where
>     you can say `perldoc -l My::Module' to find the module file), etc. would
>     be handy.
>
> We already have such features, but they display the other file in
> another buffer.   Why is it useful to put them in one buffer?
>
> What does it look like, to have multiple files in one buffer?
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
>
>



-- 
Vibhav Pant
vibhavp@gmail.com

Re: "Adobe Brackets like" editing in emacs

[Tom]

Vibhav Pant <vibhavp <at> gmail.com> writes:

> 
> From what I can see, this would require the usage of a "tooltip-like"
> text editing interface, which should be easy to implement for Emacs
> builds using a windowing system, though making it work for the text
> interface should be pretty hard.

For windowing systems it could also be done with a popup frame
which is positioned there where the cursor is and disappears
like a tooltip when not needed.

Re: "Adobe Brackets like" editing in emacs

[Stephen J. Turnbull]

Vibhav Pant writes:
 > >From what I can see, this would require the usage of a "tooltip-like"
 > text editing interface, which should be easy to implement for Emacs
 > builds using a windowing system, though making it work for the text
 > interface should be pretty hard.

I believe that Emacs already supports popup menus and tabs in the
text interface, so those tools can probably be abstracted and reused
for this purpose.

Re: "Adobe Brackets like" editing in emacs

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 19 Mar 2014 18:15:13 +0900
> Cc: Richard Stallman <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> I believe that Emacs already supports popup menus and tabs in the
> text interface, so those tools can probably be abstracted and reused
> for this purpose.

As far as menus are concerned: not easily: the C-level infrastructure
is not exposed to Lisp except through functions that pop menus and
dialogs.

Re: "Adobe Brackets like" editing in emacs

[Eli Zaretskii]

> Date: Wed, 19 Mar 2014 09:39:27 +0530
> From: Vibhav Pant <vibhavp@gmail.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> >From what I can see, this would require the usage of a "tooltip-like"
> text editing interface, which should be easy to implement for Emacs
> builds using a windowing system

No, it's not easy.  Tooltip frames are very special frames, so
using it for general-purpose display, let alone for editing, will need
some tinkering with the internals in C.  Not rocket science, granted,
but not as easy as throwing together some mode in Lisp.

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

Here is a picture of how it looks like: 

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

I don't know if they have trademark for "quick edit" :-), but since they actually develop Brackets as open source, I hope they keep their terms open source as well. I also hope they didn't patented :).

As Stephan wrote, it could be seen as analogy to a link, but instead of visiting a link the text is pulled into the current buffer under the cursor. I used "intellisense" analogy because I was thinking of context awareness indeed, not of the looks. But link analaogy is indeed better.

I think difference of editing in new window, versus pulling piece of buffer into same window, makeing seemles illusion of editing same file, is workflow 
enhacement. If I may take freedom to allude on another such workflow enhacement, I would compare it to difference between Vi and Emacs, and "direct  text" editing as in Emacs compared to "command mode" editing as in Vi. I think it is such kind of a difference. 


> Date: Wed, 19 Mar 2014 00:00:56 -0400
> From: rms@gnu.org
> To: emacs-devel@gnu.org
> CC: emacs-devel@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     A quick peek+edit in a #include in C, or "use My::Module" in Perl (where
>     you can say `perldoc -l My::Module' to find the module file), etc. would
>     be handy.
> 
> We already have such features, but they display the other file in
> another buffer.	  Why is it useful to put them in one buffer?
> 
> What does it look like, to have multiple files in one buffer?
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2500 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Phillip Lord]

That is kind of useful -- basically you are including a second file into
the current editing context so you can edit in-place as it were.

I've been working on a tool called "linked-buffer" which allows me to
edit two files (with somewhat different contents) at the same time. The
same technique might work here -- you would need to put the text of
interest into the buffer, then ensure any changes to that would
percolate backward to the main file.

Phil

arthur miller <arthur.miller@live.com> writes:

> Here is a picture of how it looks like: 
>
> http://dev.brackets.io/preso/intro/assets/features/brackets-quick-edit-js.PNG
>
> I don't know if they have trademark for "quick edit" :-), but since they
> actually develop Brackets as open source, I hope they keep their terms open
> source as well. I also hope they didn't patented :).
>
> As Stephan wrote, it could be seen as analogy to a link, but instead of
> visiting a link the text is pulled into the current buffer under the cursor. I
> used "intellisense" analogy because I was thinking of context awareness
> indeed, not of the looks. But link analaogy is indeed better.
>
> I think difference of editing in new window, versus pulling piece of buffer into same window, makeing seemles illusion of editing same file, is workflow 
> enhacement. If I may take freedom to allude on another such workflow
> enhacement, I would compare it to difference between Vi and Emacs, and "direct
> text" editing as in Emacs compared to "command mode" editing as in Vi. I think
> it is such kind of a difference.

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Here is a picture of how it looks like: 

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

It appears that this displays a portion of another file in the middle
of the file you are editing.  Right?

How do editing commands behave in that situation?
Does that editor have keyboard editing commands?
For instance, do arrow keys normally move through the file?
If so, what do the arrow keys do in that mode?
Do they move into, through, and out of the portion of the other file?
If you search in that mode, does it search through the text that is visible?

What happens if you try to select a region with one end
inside one file and the other end in another file?
Can you do that?  If so, what happens if you delete that region?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]

Yepp, you are definitely right.

They just overlay a window over the buffer.

To answer the questions:

* arrow keys move normally through the file as if the overlay window was not there
* arrow keys don't move into the file, nor do they move outside the file once the window get the focus
* arrow keys behave just as normally as they do in a files, the context is switched by pressing with a mouse 
   cursor inside the new buffer (I don't know if there is a command/shortcut to do it without mouse, I don't use 
   brackets - I am just curious about it).
* search is working as if they are separate files; it searches in the buffer with focus
* text selection is also behaving as if they are separate buffers: it continues through buffer below the overlay or not going
   outside of overlay buffer. - also it is not possible to select text across files

Here are some screenshots I took with selection, search and also to show how they display code with same name but in different
files:

http://nextpoint.se/bc/b1.png
http://nextpoint.se/bc/b2.png
http://nextpoint.se/bc/b3.png
http://nextpoint.se/bc/b4.png
http://nextpoint.se/bc/b5.png

Of course, just because Brackets does it one way or another, does not mean Emacs has to do same way.


> Date: Wed, 19 Mar 2014 14:17:58 -0400
> From: rms@gnu.org
> To: arthur.miller@live.com
> CC: emacs-devel@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     Here is a picture of how it looks like: 
> 
>     http://dev.brackets.io/preso/intro/assets/features/brackets-quick-edit-js.PNG
> 
> It appears that this displays a portion of another file in the middle
> of the file you are editing.  Right?
> 
> How do editing commands behave in that situation?
> Does that editor have keyboard editing commands?
> For instance, do arrow keys normally move through the file?
> If so, what do the arrow keys do in that mode?
> Do they move into, through, and out of the portion of the other file?
> If you search in that mode, does it search through the text that is visible?
> 
> What happens if you try to select a region with one end
> inside one file and the other end in another file?
> Can you do that?  If so, what happens if you delete that region?
> 
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 3265 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    To answer the questions:

    * arrow keys move normally through the file as if the overlay
      window was not there
    * arrow keys don't move into the file, nor do they move outside
      the file once the window get the focus
    * arrow keys behave just as normally as they do in a files, the
      context is switched by pressing with a mouse

In that case, it would be easy to implement this at the display level.

    Of course, just because Brackets does it one way or another, does
    not mean Emacs has to do same way.

That is true.  But if that is what people find useful, we may as well
do that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Ted Zlatanov]

On Wed, 19 Mar 2014 00:00:56 -0400 Richard Stallman <rms@gnu.org> 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.  This feature would
work well for *short* includes, IMO.  With long includes you lose
context and nothing is gained.

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.

RS> What does it look like, to have multiple files in one buffer?

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.

Ted

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

I think it sounds reasonable. We could have a limit on how big snippets are "inlined" in the buffer, for example 20 lines of code, or 50 or something like that. What about combining with feature like folding, so that longer function, classes etc are brought in as folded?

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

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

> To: emacs-devel@gnu.org
> From: tzz@lifelogs.com
> Subject: Re: "Adobe Brackets like" editing in emacs
> Date: Wed, 19 Mar 2014 08:49:04 -0400
> 
> On Wed, 19 Mar 2014 00:00:56 -0400 Richard Stallman <rms@gnu.org> 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.  This feature would
> work well for *short* includes, IMO.  With long includes you lose
> context and nothing is gained.
> 
> 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.
> 
> RS> What does it look like, to have multiple files in one buffer?
> 
> 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.
> 
> Ted
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2746 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > 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, IMO.  With long includes you lose
 > context and nothing is gained.

I don't think that need be true.  It could be designed so lYou don't
get the whole include, you get the relevant snippet.  Eg, in C

 int
 add (float x, float y)     <- decide to change prototype, type C-c M-p
[int add_ints (int addend1, int addend1);]

where the [] indicate either an undecorated popup (frame, window,
tooltip) or a transient insert in the buffer with point "trapped"
inside until you type C-c C-c).

 > 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.

That may be useful but I don't think that's what the OP has in mind
(it's called "quick edit", after all, not "interleaved edit").  I'm
pretty sure the snippet is not supposed to stay around.

 > It's definitely not going to look like anything we have today.

Customize, except less heavyweight compared to a popup customize
buffer.  Other recursive edits (minibuffer-at-point, anyone?)

Re: "Adobe Brackets like" editing in emacs

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Wed, 19 Mar 2014 08:49:04 -0400
> 
> On Wed, 19 Mar 2014 00:00:56 -0400 Richard Stallman <rms@gnu.org> 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.

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    RS> What does it look like, to have multiple files in one buffer?

    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.

Alas, saying "it could be anything" fails to give us any concrete help
in finding something it could be.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Ted Zlatanov]

On Wed, 19 Mar 2014 14:18:17 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
RS> [[[ whether defending the US Constitution against all enemies,     ]]]
RS> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

RS> What does it look like, to have multiple files in one buffer?

TZ>     That's a UI design question and could be up to the implementation, not
TZ>     in Emacs.  I personally would like something akin to a folding editor
TZ>     with clear delineation (maybe statically indented N spaces, like your
TZ>     quotations) but would have to experiment to find the best interface.
TZ>     It's definitely not going to look like anything we have today.

RS> Alas, saying "it could be anything" fails to give us any concrete help
RS> in finding something it could be.

OK, but I didn't say that.  I said what it could look like without
mimicking Brackets' look.

See below for an analogy to book formatting, which can provide lots of
ideas for what it could be.

On Wed, 19 Mar 2014 18:36:49 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>

>> 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.

EZ> I don't get it: switching between adjacent windows is a single
EZ> keystroke away (bind it to a key, if you are annoyed by "C-x o").

I have, but looking in *two* places is a kind of context switch and
clutters the display with more windows.  I also use `last-buffer' a lot,
but that's also a context switch.  Maybe not for you, but please allow
me a preference for the luxury of uninterrupted reading and editing.

(A sidebar window that shows included files dynamically would be useful
too, so please don't see this as a discounting of such a feature.  But
today's Emacs doesn't do this dynamically, that's key.)

EZ> So why do we need to invent some fancy new display feature, when we
EZ> already have everything that is needed?

I didn't say it has to be fancy or new, but maybe some C-level code
would help to make it more seamless.

EZ> As for mental context: you need to switch it anyway, since you are
EZ> editing a different chunk of text, right?

It's almost exactly like having extra information inlined or at the
bottom of the page or at the end of the whole text.  All three have a
purpose, and all three are commonly used (in the form of parenthetical
comments or sidebars, regular footnotes, and endnotes/bibliographies).
Here I am discussing inlined information, without making a case against
the other two ways to attach information.  Maybe we can draw inspiration
from these long-standing conventions of text formatting to improve
Emacs.

>> This feature would work well for *short* includes, IMO.  With long
>> includes you lose context and nothing is gained.

EZ> Exactly.  So why use it for short includes, or any includes?

I have tried to explain.

>> 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.

EZ> This is not what was requested, AFAIU, but if that's what you want,
EZ> then make a mode which allows you to edit all the files in a single
EZ> buffer, and then saves each one to its file.  Again, one buffer with
EZ> "normal" display is enough.

That might work.  See the later discussion in this thread.

EZ> Sounds over-engineering to me.  At the very least, I would suggest a
EZ> fully-functional prototype that uses adjacent windows, before we
EZ> decide if some other UI feature is needed.

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?

On Wed, 19 Mar 2014 23:38:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:

>> 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.

SJT> That may be useful but I don't think that's what the OP has in mind
SJT> (it's called "quick edit", after all, not "interleaved edit").  I'm
SJT> pretty sure the snippet is not supposed to stay around.

I don't care for the snippet when it's not in view, so whether it stays
or goes away is not important to me.  When I get near the include point,
I'd like to see it somehow.

Ted

Re: "Adobe Brackets like" editing in emacs

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 20 Mar 2014 02:23:55 -0400
> 
> EZ> I don't get it: switching between adjacent windows is a single
> EZ> keystroke away (bind it to a key, if you are annoyed by "C-x o").
> 
> I have, but looking in *two* places is a kind of context switch and
> clutters the display with more windows.

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?

> I also use `last-buffer' a lot, but that's also a context switch.

Nothing a simple minor mode couldn't handle.

> EZ> Sounds over-engineering to me.  At the very least, I would suggest a
> EZ> fully-functional prototype that uses adjacent windows, before we
> EZ> decide if some other UI feature is needed.
> 
> 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?

I didn't ask for anything.  I suggested to have this feature first
based on the existing infrastructure, i.e. in another window.  This
should be easy to implement, and will allow collecting user experience
which we currently lack.  Then decision of whether we need a new UI,
and which one, will be based on something, rather than on thin air.

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), and the specific feature we
are discussing here is not the only one, maybe even not the most
important one, 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., but still insist that the UI feature should look and feel the
same, without even trying.  Does this make a lot of sense?

Re: "Adobe Brackets like" editing in emacs

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 20 Mar 2014 02:23:55 -0400
>> 
>> EZ> I don't get it: switching between adjacent windows is a single
>> EZ> keystroke away (bind it to a key, if you are annoyed by "C-x o").
>> 
>> I have, but looking in *two* places is a kind of context switch and
>> clutters the display with more windows.
>
> 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?

The mode line, independent scrolling and scroll bars, no isearch across
them, and a few other things.  The mode line (or something looking like
it) would likely even be a pretty separator, and it would be reasonably
cool to, say, toggle minor modes independently by clicking on the "mode
line" and have independent line number display.  However, this mode line
would have to behave like buffer content and scroll on- and off-screen
all under the control of a single large scrollbar rather than having a
scroll bar on its own.  And isearch would need to go through either
buffer in the proper order and so on.

So I doubt that multiple windows will really fit the bill here.

-- 
David Kastrup

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

> EZ> I don't get it: switching between adjacent windows is a single
> EZ> keystroke away (bind it to a key, 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, 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, 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, instead of pressing C-x o to switch to another buffer, one press 
(hypotetically) C-x e, and the correct file with correct position opens under the cursor. 

Before one can use C-x o, user has to open correct file and split window, and than once switched to another
buffer, find the right spot in the file. Now imagine if all of those small steps are gone, and we can open 
say main file, and from there automatically be pointed to correct files and positions in file on request as needed.

It may be possible with just a minor mode; I would be fine with that too, I am just looking for functionality, not the looks,
albeit looks might be helpful to make less distraction.

It is just some thoughts :).

> Date: Thu, 20 Mar 2014 18:28:44 +0200
> From: eliz@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> To: emacs-devel@gnu.org
> 
> > From: Ted Zlatanov <tzz@lifelogs.com>
> > Date: Thu, 20 Mar 2014 02:23:55 -0400
> > 
> > EZ> I don't get it: switching between adjacent windows is a single
> > EZ> keystroke away (bind it to a key, if you are annoyed by "C-x o").
> > 
> > I have, but looking in *two* places is a kind of context switch and
> > clutters the display with more windows.
> 
> 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?
> 
> > I also use `last-buffer' a lot, but that's also a context switch.
> 
> Nothing a simple minor mode couldn't handle.
> 
> > EZ> Sounds over-engineering to me.  At the very least, I would suggest a
> > EZ> fully-functional prototype that uses adjacent windows, before we
> > EZ> decide if some other UI feature is needed.
> > 
> > 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?
> 
> I didn't ask for anything.  I suggested to have this feature first
> based on the existing infrastructure, i.e. in another window.  This
> should be easy to implement, and will allow collecting user experience
> which we currently lack.  Then decision of whether we need a new UI,
> and which one, will be based on something, rather than on thin air.
> 
> 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), and the specific feature we
> are discussing here is not the only one, maybe even not the most
> important one, 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., but still insist that the UI feature should look and feel the
> same, without even trying.  Does this make a lot of sense?
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 4045 bytes --]

Re: "Adobe Brackets like" editing in emacs

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Eli Zaretskii writes:
> I suggested to have this feature first based on the existing
> infrastructure, i.e. in another window.  This should be easy to
> implement, and will allow collecting user experience which we
> currently lack.  Then decision of whether we need a new UI, and which
> one, will be based on something, rather than on thin air.

OK, I've hacked up a little demonstrator. Load the attached file and
eval-buffer it (preferably with 'emacs -Q', that's how I tested it).
Then move point over an Emacs function; hitting 'C-c e' will open the
quick-edit window with the function's definition, and 'C-c c' will close
it.

Problems I've noticed so far:

- mode-line-format is buffer-local, so you cannot deactivate it only for
  the upper window. That means, while in quick-edit, you will have no
  mode-line at all.

- You cannot set a different background color for a complete window. You
  can only do that with an overlay, but that will only cover the parts
  with text.

- Of course, you can easily mess things up be leaving/closing the window
  otherwise.

In a nutshell, it'd be nice to have something like 'window-local'
variables for this.

-David


[-- Attachment #2: quick-edit-demo.el --]
[-- Type: application/emacs-lisp, Size: 1571 bytes --]

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

I am trying to test the demo, but it asks me about Emacs C sources? Does it mean 
I have to download source code to check this demo out?

I also get error if window is too small:

Debugger entered--Lisp error: (error "Window #<window 7 on quick-edit-demo.el> too small for splitting")
  signal(error ("Window #<window 7 on quick-edit-demo.el> too small for splitting"))
  error("Window %s too small for splitting" #<window 7 on quick-edit-demo.el>)
  byte-code("\b\204\222

Would be cool to test it :).

> From: deng@randomsample.de
> To: eliz@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> Date: Thu, 20 Mar 2014 17:59:50 +0100
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii writes:
> > I suggested to have this feature first based on the existing
> > infrastructure, i.e. in another window.  This should be easy to
> > implement, and will allow collecting user experience which we
> > currently lack.  Then decision of whether we need a new UI, and which
> > one, will be based on something, rather than on thin air.
> 
> OK, I've hacked up a little demonstrator. Load the attached file and
> eval-buffer it (preferably with 'emacs -Q', that's how I tested it).
> Then move point over an Emacs function; hitting 'C-c e' will open the
> quick-edit window with the function's definition, and 'C-c c' will close
> it.
> 
> Problems I've noticed so far:
> 
> - mode-line-format is buffer-local, so you cannot deactivate it only for
>   the upper window. That means, while in quick-edit, you will have no
>   mode-line at all.
> 
> - You cannot set a different background color for a complete window. You
>   can only do that with an overlay, but that will only cover the parts
>   with text.
> 
> - Of course, you can easily mess things up be leaving/closing the window
>   otherwise.
> 
> In a nutshell, it'd be nice to have something like 'window-local'
> variables for this.
> 
> -David
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2451 bytes --]

Re: "Adobe Brackets like" editing in emacs

[David Engster]

arthur miller writes:
> I am trying to test the demo, but it asks me about Emacs C sources? Does it
> mean
> I have to download source code to check this demo out?

If you want to edit a core function which is written in C, yes.

Try one written in Elisp, like `split-window-vertically' or
`narrow-to-defun'.

> I also get error if window is too small:
>
> Debugger entered--Lisp error: (error "Window #<window 7 on quick-edit-demo.el>
> too small for splitting")

Yes. It's just a quick hack, after all. :-)

-David

RE: "Adobe Brackets like" editing in emacs

[arthur miller]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

Si si, works fine :). I think it is good enough visually to be classified as "quick edit". 
Cool demo

> From: deng@randomsample.de
> To: arthur.miller@live.com
> CC: emacs-devel@gnu.org
> Subject: Re: "Adobe Brackets like" editing in emacs
> Date: Thu, 20 Mar 2014 18:41:39 +0100
> 
> arthur miller writes:
> > I am trying to test the demo, but it asks me about Emacs C sources? Does it
> > mean
> > I have to download source code to check this demo out?
> 
> If you want to edit a core function which is written in C, yes.
> 
> Try one written in Elisp, like `split-window-vertically' or
> `narrow-to-defun'.
> 
> > I also get error if window is too small:
> >
> > Debugger entered--Lisp error: (error "Window #<window 7 on quick-edit-demo.el>
> > too small for splitting")
> 
> Yes. It's just a quick hack, after all. :-)
> 
> -David
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1257 bytes --]

[-- Attachment #2: quickedit.png --]
[-- Type: image/png, Size: 105615 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Johan Bockgård]

David Engster <deng@randomsample.de> writes:

> - You cannot set a different background color for a complete window. You
>   can only do that with an overlay, but that will only cover the parts
>   with text.

You can do it (in Emacs 24) by remapping the default face.

    (setq-local face-remapping-alist '((default . highlight)))
    (redraw-display)

Re: "Adobe Brackets like" editing in emacs

[David Engster]

Johan Bockgård writes:
> David Engster <deng@randomsample.de> writes:
>
>> - You cannot set a different background color for a complete window. You
>>   can only do that with an overlay, but that will only cover the parts
>>   with text.
>
> You can do it (in Emacs 24) by remapping the default face.
>
>     (setq-local face-remapping-alist '((default . highlight)))
>     (redraw-display)

I did not know that (obviously). Thanks!

-David

Re: "Adobe Brackets like" editing in emacs

[Ted Zlatanov]

On Thu, 20 Mar 2014 18:28:44 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 20 Mar 2014 02:23:55 -0400
>> 
EZ> I don't get it: switching between adjacent windows is a single
EZ> keystroke away (bind it to a key, if you are annoyed by "C-x o").
>> 
>> I have, but looking in *two* places is a kind of context switch and
>> clutters the display with more windows.

EZ> How is another window different from having contents of another file
EZ> inserted into the same window?  The only difference is the mode line
EZ> between them -- is that really such a big deal?

David Kastrup explained it better than I could.

>> I also use `last-buffer' a lot, but that's also a context switch.

EZ> Nothing a simple minor mode couldn't handle.

Please don't take any of my comments as feature requests.  RMS asked for
comments and I provided my thoughts and experience.  I think it's
especially important to look at Literate Programming and general text
formatting for inspiration.  I like the direction David Engster took
with his quick hack.

EZ> Look at this another way: someone suggests that we adopt a "cool
EZ> feature" seen in another editor.  That editor is for editing HTML
EZ> (which is hardly the main focus of Emacs), and the specific feature we
EZ> are discussing here is not the only one, maybe even not the most
EZ> important one, in Brackets -- just look at the videos on their site.
EZ> Suddenly we are all sure this will be seemingly cool for editing C/C++
EZ> etc., but still insist that the UI feature should look and feel the
EZ> same, without even trying.  Does this make a lot of sense?

I agree with you that we shouldn't mimic things others have implemented,
that's not traditionally where Emacs shines.

I also think a way to see and edit information inline without the
distraction of context-switching is clearly useful.  See `eldoc-mode'
for instance, and as others have mentioned, tooltips.

Finally, I clearly remember the loooooong discussions about Eclipse
perspectives.  They clearly didn't fit Emacs' model, in the end, judging
by the lack of interest.  That IMO was a case of the featuritis chasimus
that concerns you, and I certainly hope imitating Brackets is not
another.

Ted

Re: "Adobe Brackets like" editing in emacs

[Matthew Leach]

Ted Zlatanov <tzz@lifelogs.com> writes:

[...]

> I have, but looking in *two* places is a kind of context switch and
> clutters the display with more windows.  I also use `last-buffer' a lot,
> but that's also a context switch.  Maybe not for you, but please allow
> me a preference for the luxury of uninterrupted reading and editing.

Perhaps one way to mitigate the context switch is to narrow the newly
created window to the construct in question?  For instance, If we "jump"
to C macro, say, then narrow the buffer to only show the contents of
that macro.
-- 
Matt

Re: "Adobe Brackets like" editing in emacs

[Josh]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Tue, Mar 18, 2014 at 9:00 PM, Richard Stallman <rms@gnu.org> wrote:

>     A quick peek+edit in a #include in C, or "use My::Module" in Perl
> (where
>     you can say `perldoc -l My::Module' to find the module file), etc.
> would
>     be handy.
>
> We already have such features, but they display the other file in
> another buffer.   Why is it useful to put them in one buffer?
>
> What does it look like, to have multiple files in one buffer?


One possibility, which may not be optimal but which does have
the distinct advantage of already being implemented, is Magnar
Sveen's multifiles.el[0] library, inspired by this[1] question.

Incidentally, I've often wished for the inverse functionality,
i.e. the ability to conveniently partition a file-visiting buffer into a
set of indirect buffers, which could then have different major
modes, buffer-local variable values, minor modes, etc.  Maybe
someone will tell me that this, too, already exists :)

[0] https://github.com/magnars/multifiles.el
[1]
http://www.reddit.com/r/emacs/comments/10gc9u/can_i_have_multiple_parts_of_buffers_in_one_super/

Josh

[-- Attachment #2: Type: text/html, Size: 2534 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Mathias Dahl]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

Hi Arthur,

This is a very interesting feature! Not only would it be useful for the
scenario described by you and others in this thread, but I also think it
would be useful for temporarily showing definitions from another place in
the same file that you are editing. Sure, there are tooltips, overlays and
whatnot that can do the same thing ("intellisense") but sometimes actually
seeing the full definition right where you are might be useful. No need to
jump back and forth, with a key you could show the definition of a function
where you are, and with another key it would be hidden. You would be able
to copy pieces of text from it and whatever. That being said, I have never
ever seen a feature like this before, and that could be an indication that
it is not actually useful, or no-one has thought of a crazy idea before the
Adobe people did it...

/Mathias


On Tue, Mar 18, 2014 at 2:29 PM, arthur miller <arthur.miller@live.com>wrote:

> Hi,
>
> my name is Arthur, and I just subscribed to this list. Though I am new to
> this list, I am not so new to Emacs.I have just a question/thought about a
> feature I would like see in Emacs, hope you don't mind.
>
> Lately Adobes Brackets editor has got some popularity (It seems to be
> pretty much Emacs on javascript). I am not really into using it full time,
> since I am good with Emacs, but I do like the idea of mulitple file editing
> in one buffer. It is like context-aware multi-file editing or what it
> should be called. They use it to edit css or javascript while editing html
> file, så that one does not have to switch between buffers/files. It seems
> pretty handy, and I would kind-a like to see implementation for C/C++
> (macros, templates) and so on.
>
> I think it shouldn't be impossible to do now, since Emacs already can
> split window and show multiple buffers. How difficult would it be to add a
> mode/feature to "expand" a buffer (split window) under the current line and
> load exact part of a file with of course correct langauge mode and so on. I
> guess semantic package would be needed since it seems to be similar context
> awareness as it is needed for code completition.
>
> I am not knowledgable about Emacs internals, so I don't really know where
> to hack, but wonder if something similar is already implemented or "on the
> way".
>
>
>

[-- Attachment #2: Type: text/html, Size: 2777 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]

I have tested Brackets a bit the latest days, using it beside Emacs. It was
not as integrated to the browser as I thought, but it is still useful. I
have used it to edit CSS files and mixed files. It looks up all the places
that it think might apply to an element in HTML. Unfortunately it does not
seem to have one of those features I really would like: Parsing CSS media
queries. It does not tell me which media query is used where and what the
limits are for them. It does not even show the media queries at all in the
Quick Edit (which is the feature we are discussing).

I think it is the same for CSS classes.

I guess they just stopped the development before implementing such useful
features. It is of course quite a bit more complex to implement that part,
both on the parsing level and UI level.

Still, it is useful. And implementing those simple features in Emacs would
not be that hard, I think. A crucial part would be to setup the connection
between different files. (A little bit of that is in nXhtml.)

And yes, it could be used with other languages too. Perhaps it can be
useful for class-based languages, but that requires good parsing.



On Wed, Mar 26, 2014 at 10:21 PM, Mathias Dahl <mathias.dahl@gmail.com>wrote:

> Hi Arthur,
>
> This is a very interesting feature! Not only would it be useful for the
> scenario described by you and others in this thread, but I also think it
> would be useful for temporarily showing definitions from another place in
> the same file that you are editing. Sure, there are tooltips, overlays and
> whatnot that can do the same thing ("intellisense") but sometimes actually
> seeing the full definition right where you are might be useful. No need to
> jump back and forth, with a key you could show the definition of a function
> where you are, and with another key it would be hidden. You would be able
> to copy pieces of text from it and whatever. That being said, I have never
> ever seen a feature like this before, and that could be an indication that
> it is not actually useful, or no-one has thought of a crazy idea before the
> Adobe people did it...
>
> /Mathias
>
>
> On Tue, Mar 18, 2014 at 2:29 PM, arthur miller <arthur.miller@live.com>wrote:
>
>> Hi,
>>
>> my name is Arthur, and I just subscribed to this list. Though I am new to
>> this list, I am not so new to Emacs.I have just a question/thought about a
>> feature I would like see in Emacs, hope you don't mind.
>>
>> Lately Adobes Brackets editor has got some popularity (It seems to be
>> pretty much Emacs on javascript). I am not really into using it full time,
>> since I am good with Emacs, but I do like the idea of mulitple file editing
>> in one buffer. It is like context-aware multi-file editing or what it
>> should be called. They use it to edit css or javascript while editing html
>> file, så that one does not have to switch between buffers/files. It seems
>> pretty handy, and I would kind-a like to see implementation for C/C++
>> (macros, templates) and so on.
>>
>> I think it shouldn't be impossible to do now, since Emacs already can
>> split window and show multiple buffers. How difficult would it be to add a
>> mode/feature to "expand" a buffer (split window) under the current line and
>> load exact part of a file with of course correct langauge mode and so on. I
>> guess semantic package would be needed since it seems to be similar context
>> awareness as it is needed for code completition.
>>
>> I am not knowledgable about Emacs internals, so I don't really know where
>> to hack, but wonder if something similar is already implemented or "on the
>> way".
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4503 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 4280 bytes --]

I just took a closer look to see if someone did not make a better version
of Brackets since brackets lacks a lot of functionality. Google did. They
integrated something like it in the browser. Take a look at Workspaces here
and test it in Chrome. Amazing.

Chrome DevTools Revolutions 2013 - HTML5 Rocks
http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/


On Wed, Mar 26, 2014 at 10:35 PM, Lennart Borgman <lennart.borgman@gmail.com
> wrote:

> I have tested Brackets a bit the latest days, using it beside Emacs. It
> was not as integrated to the browser as I thought, but it is still useful.
> I have used it to edit CSS files and mixed files. It looks up all the
> places that it think might apply to an element in HTML. Unfortunately it
> does not seem to have one of those features I really would like: Parsing
> CSS media queries. It does not tell me which media query is used where and
> what the limits are for them. It does not even show the media queries at
> all in the Quick Edit (which is the feature we are discussing).
>
> I think it is the same for CSS classes.
>
> I guess they just stopped the development before implementing such useful
> features. It is of course quite a bit more complex to implement that part,
> both on the parsing level and UI level.
>
> Still, it is useful. And implementing those simple features in Emacs would
> not be that hard, I think. A crucial part would be to setup the connection
> between different files. (A little bit of that is in nXhtml.)
>
> And yes, it could be used with other languages too. Perhaps it can be
> useful for class-based languages, but that requires good parsing.
>
>
>
> On Wed, Mar 26, 2014 at 10:21 PM, Mathias Dahl <mathias.dahl@gmail.com>wrote:
>
>> Hi Arthur,
>>
>> This is a very interesting feature! Not only would it be useful for the
>> scenario described by you and others in this thread, but I also think it
>> would be useful for temporarily showing definitions from another place in
>> the same file that you are editing. Sure, there are tooltips, overlays and
>> whatnot that can do the same thing ("intellisense") but sometimes actually
>> seeing the full definition right where you are might be useful. No need to
>> jump back and forth, with a key you could show the definition of a function
>> where you are, and with another key it would be hidden. You would be able
>> to copy pieces of text from it and whatever. That being said, I have never
>> ever seen a feature like this before, and that could be an indication that
>> it is not actually useful, or no-one has thought of a crazy idea before the
>> Adobe people did it...
>>
>> /Mathias
>>
>>
>> On Tue, Mar 18, 2014 at 2:29 PM, arthur miller <arthur.miller@live.com>wrote:
>>
>>> Hi,
>>>
>>> my name is Arthur, and I just subscribed to this list. Though I am new
>>> to this list, I am not so new to Emacs.I have just a question/thought about
>>> a feature I would like see in Emacs, hope you don't mind.
>>>
>>> Lately Adobes Brackets editor has got some popularity (It seems to be
>>> pretty much Emacs on javascript). I am not really into using it full time,
>>> since I am good with Emacs, but I do like the idea of mulitple file editing
>>> in one buffer. It is like context-aware multi-file editing or what it
>>> should be called. They use it to edit css or javascript while editing html
>>> file, så that one does not have to switch between buffers/files. It seems
>>> pretty handy, and I would kind-a like to see implementation for C/C++
>>> (macros, templates) and so on.
>>>
>>> I think it shouldn't be impossible to do now, since Emacs already can
>>> split window and show multiple buffers. How difficult would it be to add a
>>> mode/feature to "expand" a buffer (split window) under the current line and
>>> load exact part of a file with of course correct langauge mode and so on. I
>>> guess semantic package would be needed since it seems to be similar context
>>> awareness as it is needed for code completition.
>>>
>>> I am not knowledgable about Emacs internals, so I don't really know
>>> where to hack, but wonder if something similar is already implemented or
>>> "on the way".
>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5401 bytes --]

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I just took a closer look to see if someone did not make a better version
    of Brackets since brackets lacks a lot of functionality. Google did. They
    integrated something like it in the browser. Take a look at Workspaces here
    and test it in Chrome. Amazing.

Is it free software?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

On Fri, Mar 28, 2014 at 4:26 PM, Richard Stallman <rms@gnu.org> wrote:
>
>     I just took a closer look to see if someone did not make a better version
>     of Brackets since brackets lacks a lot of functionality. Google did. They
>     integrated something like it in the browser. Take a look at Workspaces here
>     and test it in Chrome. Amazing.
>
> Is it free software?
>

It looks complicated. For the rendering engine, webkit (http://www.webkit.org/):

"WebKit is open source software with portions licensed under the
LGPLand BSD licenses. Complete license and copyright information can
be found within the code."

But the tools I was writing about is part of Google Chromium
(http://www.chromium.org/).

Re: "Adobe Brackets like" editing in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    But the tools I was writing about is part of Google Chromium
    (http://www.chromium.org/).

I guess that is free software, but has some drawbacks in how it is
maintained, because Chrome is nonfree.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: "Adobe Brackets like" editing in emacs

[Lennart Borgman]

On Sun, Mar 30, 2014 at 1:24 AM, Richard Stallman <rms@gnu.org> wrote:
>
>     But the tools I was writing about is part of Google Chromium
>     (http://www.chromium.org/).
>
> I guess that is free software, but has some drawbacks in how it is
> maintained, because Chrome is nonfree.


I think what Google is doing there is very good. They are integrating
the browser, editing tools, structural view and editing, browser
parsers etc.

This integrating makes it possible to make a much more powerful UI (in
this case, I mean). That is why I wanted people to have a look at it.
(And I guess Brackets was abandon because it lacks this possibility.)

Integrating is a very hard game, but necessary to compete here. I
think it would be nice to have an Emacs window there inside Chrome,
but the way to achieve that is not very short currently.