[Feature Discuss] Nested buffer

[Feature Discuss] Nested buffer

[fei xiaobo]

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

Hi all.

I am building a plan to implement *Nested buffer* in Emacs recently. Is it
a good ideal?

Nested buffer what I mean here is the sub-buffers which embedded in a host
buffer.

   - Nested/Embed buffer's content is linked to an arbitrary buffer.
   - Host buffer's content consists of the content of all the nested
   buffers.

If having this, we could embed multiple buffers' content into a host buffer
to get one virtual buffer. And, after updating the nested buffer's content,
the virtual host buffer's content is updated too. I think it will be
helpful for many special plugins.

Appreciated any comments or suggestion.

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

Re: [Feature Discuss] Nested buffer

[Stefan Monnier]

> I am building a plan to implement *Nested buffer* in Emacs recently.
> Is it a good idea?

Hard to have an opinion on this without some more detail of the intended
uses (e.g. examples of the "many special plugins") and the way you
intend to do it (e.g. how do you specify which buffer is nested
into which other and more specifically *where* in that other buffer).

My first reaction would be: way too hard to implement.


        Stefan

Re: [Feature Discuss] Nested buffer

[Brett Gilio]

fei xiaobo writes:

> Hi all.
>
> I am building a plan to implement *Nested buffer* in Emacs 
> recently. Is it
> a good ideal?
>
> Nested buffer what I mean here is the sub-buffers which embedded 
> in a host
> buffer.
>
>    - Nested/Embed buffer's content is linked to an arbitrary 
>    buffer.
>    - Host buffer's content consists of the content of all the 
>    nested
>    buffers.
>
> If having this, we could embed multiple buffers' content into a 
> host buffer
> to get one virtual buffer. And, after updating the nested 
> buffer's content,
> the virtual host buffer's content is updated too. I think it 
> will be
> helpful for many special plugins.
>
> Appreciated any comments or suggestion.

Could you provide a scenario where you would find this feature to 
be
useful? I am not casting it off, but I am having a hard time 
thinking of
what it could be used for that Emacs doesn't already do.


-- 
Brett M. Gilio
Free Software Foundation, Member
https://parabola.nu | https://emacs.org

Re: [Feature Discuss] Nested buffer

[Clément Pit-Claudel]

On 2018-07-23 16:11, Brett Gilio wrote:
> Could you provide a scenario where you would find this feature to be
> useful? I am not casting it off, but I am having a hard time thinking of
> what it could be used for that Emacs doesn't already do.

I think anything that was covered by the islands proposals a few months ago would be a good candidate, including mixed-mode buffers (HTML+JS+CSS) and documents that embed code snippets (e.g. org-mode buffers)

It's a very hard problem, though.

Re: [Feature Discuss] Nested buffer

[Phil Sainty]

On 2018-07-24 08:31, Clément Pit-Claudel wrote:
> I think anything that was covered by the islands proposals

That sprang to my mind too.  What is the current state of the
"islands" work?  Is it still just a discussion, or is there
code as well?

This new suggestion sounds rather like narrowed indirect buffers
(which we can do already), or perhaps an extension of that facility?

-Phil

RE: [Feature Discuss] Nested buffer

[Drew Adams]

> > I think anything that was covered by the islands proposals
> 
> This new suggestion sounds rather like narrowed indirect buffers
> (which we can do already), or perhaps an extension of that facility?

The new proposal sounds like nearly anything one might want
to imagine.  IOW, it sounds like nothing at all.  It needs
to be specified - nailed down quite a bit more, so people
can actually think about it, instead of just imagining stuff.

Re: [Feature Discuss] Nested buffer

[Harry Fei]

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

   - Case 1: Collect multiple narrowed-indirect-buffers to edit together.
   - Sometimes, when I am working on a large project repository (Maybe
      something like Chromium and AOSP), there are some codes highly related to
      each other which spread in multiple files. So I want to collect them
      together into a host buffer (embed narrow indirect buffer) when I read
      those code. After I understand the logic, I want to edit those
code in this
      host buffer directly(the content sync back to the origin buffer). Even
      more, I can use other editor functions, eg. string replace.
      - Here is the example of the buffer

=============================
Somes Note for the Foo releated code.

This is the Foo struct definition
---- Linked to Foo.h buffer----
struct Foo {
    int a,
    int b,
}
-----------------------------------------


Some function that use Foot
----------Linked to xxx.c ---------
void f1 (f: Foo) {
    ......
}
-----------------------------------------

----------Linked to yyy.c ---------
void f2 (f: Foo) {
    ......
}
-----------------------------------------

=============================


   - Case 2: Extend eshell or write a new shell
   - I want to execute my processes async in eshell by default. So I can
      run multiple processes simultaneously in just one session. The output of
      those process will be redirected into their own correlative
buffers. Then I
      want to embed those output buffers into the eshell buffer just to fake a
      normal shell experience.
      - Here is the example (in a Imaginary eshell). The two process's
      output is updated simultaneously.

============================================

/home/aaa/work: npm
start
(Enter here to execute non-exitable program)
---------------------- Output of `npm start` ------------------------
XXX server is listen on 8000
request [GET]: .......................
request [GET]: ........................
-------------------------------------------------------------------------------
/home/aaa/work: curl
localhsot:8000/foo
(Then Enter here to execute a curl)
---------------------- Output of `curl localhost:8000.....`
------------------------
...........................
...........................
...........................
...........................
-------------------------------------------------------------------------------
/home/aaa/work: |

(Then we can execute more command here )

============================================

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

Re: [Feature Discuss] Nested buffer

[Óscar Fuentes]

Harry Fei <tiziyuanfang@gmail.com> writes:

>    - Case 1: Collect multiple narrowed-indirect-buffers to edit together.
>    - Sometimes, when I am working on a large project repository (Maybe
>       something like Chromium and AOSP), there are some codes highly related to
>       each other which spread in multiple files. So I want to collect them
>       together into a host buffer (embed narrow indirect buffer) when I read
>       those code. After I understand the logic, I want to edit those
> code in this
>       host buffer directly(the content sync back to the origin buffer). Even
>       more, I can use other editor functions, eg. string replace.

Something like this would be very convenient.

In my case, often I have to work on some feature that touches certain
areas of several source files and, at the same time, create and edit
several test cases, each on one file. Having everything on the same
buffer will save lots of buffer switching, while at the same time
providing a compact "work area" that eases reading and editing.

Re: [Feature Discuss] Nested buffer

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 24 Jul 2018 09:16:05 +0200
> 
> Harry Fei <tiziyuanfang@gmail.com> writes:
> 
> >    - Case 1: Collect multiple narrowed-indirect-buffers to edit together.
> >    - Sometimes, when I am working on a large project repository (Maybe
> >       something like Chromium and AOSP), there are some codes highly related to
> >       each other which spread in multiple files. So I want to collect them
> >       together into a host buffer (embed narrow indirect buffer) when I read
> >       those code. After I understand the logic, I want to edit those
> > code in this
> >       host buffer directly(the content sync back to the origin buffer). Even
> >       more, I can use other editor functions, eg. string replace.
> 
> Something like this would be very convenient.
> 
> In my case, often I have to work on some feature that touches certain
> areas of several source files and, at the same time, create and edit
> several test cases, each on one file. Having everything on the same
> buffer will save lots of buffer switching, while at the same time
> providing a compact "work area" that eases reading and editing.

Any reason why several windows side by side couldn't serve the same
purpose?  (You can disable the mode line if that gets in the way.)

Re: [Feature Discuss] Nested buffer

[Ihor Radchenko]

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

> Any reason why several windows side by side couldn't serve the same
> purpose?  (You can disable the mode line if that gets in the way.)
>

For example, it would not be possible to fold/hide the content, like in
org-mode or hideshow.




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Feature Discuss] Nested buffer

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Something like this would be very convenient.
>> 
>> In my case, often I have to work on some feature that touches certain
>> areas of several source files and, at the same time, create and edit
>> several test cases, each on one file. Having everything on the same
>> buffer will save lots of buffer switching, while at the same time
>> providing a compact "work area" that eases reading and editing.
>
> Any reason why several windows side by side couldn't serve the same
> purpose?  (You can disable the mode line if that gets in the way.)

That is what I do when the number of affected areas is small, but...

1. The screen has limited space.

2. Arranging the windows takes time and is fragile (commands like
`compile' and derivatives changes the layout, temporally or permanently;
you are forced to use another frame for magit, gnus...).

3. Editing a single buffer is more natural and convenient. Things like
"replace this with that" would be automatically narrowed to the contents
of the virtual buffer.

I see the OP's proposal as a method for achieving narrowing at the file
level (Emacs already has buffer-level narrowing): pick some files, put
them (or parts of them) on the same buffer, and proceed as if you were
working on a mini-project written on a single file.

My first impression about his proposal was kind of "meh", but the more I
think about it, the more interesting it looks.

Re: [Feature Discuss] Nested buffer

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I see the OP's proposal as a method for achieving narrowing at the file
> level

/s/file level/filesystem level/

Re: [Feature Discuss] Nested buffer

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 24 Jul 2018 22:54:21 +0800
> 
> > Any reason why several windows side by side couldn't serve the same
> > purpose?  (You can disable the mode line if that gets in the way.)
> >
> 
> For example, it would not be possible to fold/hide the content, like in
> org-mode or hideshow.

Maybe I don't understand what you mean by fold/hide, but isn't
narrowing relevant?

Re: [Feature Discuss] Nested buffer

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 24 Jul 2018 16:59:11 +0200
> 
> > Any reason why several windows side by side couldn't serve the same
> > purpose?  (You can disable the mode line if that gets in the way.)
> 
> That is what I do when the number of affected areas is small, but...
> 
> 1. The screen has limited space.

Not nowadays.

> 2. Arranging the windows takes time and is fragile (commands like
> `compile' and derivatives changes the layout, temporally or permanently;
> you are forced to use another frame for magit, gnus...).

I just create a new frame for that, and use that frame only for such
special situations.  All the other buffers live on other frames, so
popping buffers don't bother me.

> I see the OP's proposal as a method for achieving narrowing at the file
> level (Emacs already has buffer-level narrowing): pick some files, put
> them (or parts of them) on the same buffer, and proceed as if you were
> working on a mini-project written on a single file.
> 
> My first impression about his proposal was kind of "meh", but the more I
> think about it, the more interesting it looks.

If you say so.  Volunteers are welcome to come up with patches that
implement this cleanly.

RE: [Feature Discuss] Nested buffer

[Drew Adams]

> The new proposal sounds like nearly anything one might want
> to imagine.  IOW, it sounds like nothing at all.  It needs
> to be specified - nailed down quite a bit more, so people
> can actually think about it, instead of just imagining stuff.

For starters, define "nested".  Any restrictions on
nesting?  More than one level of nesting possible?

Zone/"buffer" overlap possible?  Narrowed indirect
buffers can have overlapping content, for example.
They can even hold the entire buffer contents.  (The
word "nested" doesn't suggest this possibility, but
who knows what was intended?)

Define just what the things are that get nested,
and what they are nested in (same kind of thing?).
Are they really buffers? pieces of buffers? views
of buffers?  Define how they can be nested - just
what "nesting" means here.

If this is going to lead to anything, there needs
to be more flesh, I think: either some more
specification or some beginning code to think about.

Contrast Alan's detailed description of "islands".
That led to some interesting discussion because
it was fairly complete, detailed, and clear.  The
current suggestion is, so far, just two words:
"nested" and "buffer".

Re: [Feature Discuss] Nested buffer

[Alan Mackenzie]

Hello, Phil.

On Tue, Jul 24, 2018 at 11:15:20 +1200, Phil Sainty wrote:
> On 2018-07-24 08:31, Clément Pit-Claudel wrote:
> > I think anything that was covered by the islands proposals

> That sprang to my mind too.  What is the current state of the
> "islands" work?  Is it still just a discussion, or is there
> code as well?

Neither, really.  :-(  I still think it is a sound proposal, but the
amount of work involved in implementing it would be so immense that it
would take a team of three to six people to do it.  It would certainly be
beyond my abilities to do on my own.  My feeling, when the topic was
under discussion, was that the requisite enthusiasm and commitment wasn't
there.  To be honest, that would be expecting rather a lot.

A project of that size would inevitably involve coordination, and other
project management things, like agreeing on interfaces, and possibly
having deadlines and such.  There's no experience of anything like this
in the Emacs project, at least, not that I'm aware of.

So I don't think that the "islands" proposal is going to get implemented.
Which is a pity.

[ .... ]

> -Phil

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Feature Discuss] Nested buffer

[Stefan Monnier]

> I think anything that was covered by the islands proposals a few months ago
> would be a good candidate, including mixed-mode buffers (HTML+JS+CSS) and
> documents that embed code snippets (e.g. org-mode buffers)

But having those chunks represented as nested buffers only solves the
problem of "which buffer-local variables to use when", which is
basically the easy problem (and it does it in a pretty hard way).
It doesn't solve the issue of interaction between chunks at the boundary
(which is the part that mostly requires coordination via some
standardized protocol).


        Stefan

Re: [Feature Discuss] Nested buffer

[Stefan Monnier]

> In my case, often I have to work on some feature that touches certain
> areas of several source files and, at the same time, create and edit
> several test cases, each on one file. Having everything on the same
> buffer will save lots of buffer switching, while at the same time
> providing a compact "work area" that eases reading and editing.

BTW, this sounds like a problem that could be solved also with something
like Phil Lord's `lentic`.


        Stefan

Re: [Feature Discuss] Nested buffer

[Van L]

>> Any reason why several windows side by side couldn't serve the same
>> purpose?  (You can disable the mode line if that gets in the way.)
>> 
> 
> For example, it would not be possible to fold/hide the content, like in
> org-mode or hideshow.

Is what it is a global virtual buffer for webbing relevant line spans from files to work on all at once?

A use case might be to extract lines of code and documentation for commenting and presentation to a judge in a software audit of VW Audi’s Dieselgate affair.