emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Adobe Brackets like" editing in emacs


From: Eli Zaretskii
Subject: Re: "Adobe Brackets like" editing in emacs
Date: Wed, 19 Mar 2014 18:36:49 +0200

> From: Ted Zlatanov <address@hidden>
> Date: Wed, 19 Mar 2014 08:49:04 -0400
> 
> On Wed, 19 Mar 2014 00:00:56 -0400 Richard Stallman <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]