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