Re: "Adobe Brackets like" editing in emacs

[Ted Zlatanov <tzz@lifelogs.com>]

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