[MonoDevelop] Feature-REQ: Virtual buffers
Thu, 08 Jan 2004 12:01:25 -0500
I have to say I like the idea, and im going to most likely use this
email in the context of a TODO list. The idea is surely worth exploring.
However, as it seems to imply a fairly large contextual change to
certain pieces of the framework (Some parts of what you are wanting are
there, others are not), its not something we will be working on right
On Thu, 2004-01-08 at 02:23, Lars Thomas Denstad wrote:
> I'm new to the list (as I guess we all are), and I have a
> The feature would apply to the text-editor/internal buffer handling.
> The suggestions is made without any knowledge of the current internal
> structure of #D or MonoDevelop (perhaps it's already there?).
> In lack of a better description, I call the feature "virtual buffers",
> which basically means that instead of just being able to edit buffers
> that map to physical files, the editor allows you to treat part of
> another buffer as a buffer (subbuffer), or multiple other buffers as a
> single buffer (a superbuffer).
> Typically, the structure would look like this:
> / | \
> / | \
> / | \
> / | \
> PhysicalBuffer SubBuffer SuperBuffer
> The Window to the developer is through the IBuffer interface, which
> presents all kinds of buffers ~similarly.
> Examples of use:
> The introduction of virtual buffers opens up for a number of
> possibilities when it comes to enhancing the convenience editing files.
> Here are some examples.
> When loading a project, provide a superbuffer containing all files in
> the project. This allows you to do simple project-wide search/replace
> without coding specifially for this kind of functionality in the IDE;
> search/replace-operations would go directly on the superbuffer.
> If you're (God forbid) working with a language like C++, imagine opening
> just "class" instead of "class.hpp" and "class.cpp". The IDE
> automatically opens the hpp and cpp files for you, and provide three
> buffers; "class" (superbuffer), "class.hpp", "class.cpp". Now, while
> editing the "class" superbuffer, pressing "M-<"/Home/"take me to the top
> of the document" will take you to the top of class.hpp, while pressing
> "M->"/"End"/"take me to the bottom of document" will take you to the
> bottom of class.cpp. The two files will edit as one in the superbuffer,
> keeping the need to repeatedly change buffers to get an overview of a
> class to a minimum. The view in the editor should graphically indicate
> the end of one physical buffer and the introduction of another in the
> superbuffer-view, but it should be a simple CUP/CDOWN for the caret to
> move over one; they should have no impact except visual. As above, a
> search/replace would apply to both the .hpp and .cpp-file if done in the
> This could also come in handy if editing a class that implements many
> interfaces; to be able to keep the interface-definitions "at the top of
> the file" for reference.
> Documentation writing
> I'm currently trying to participate in the monkeyguide documentation
> project, and frequently find myself mixing HTML (which is the canonical
> documentation format) and C#.
> This usually starts out as C# directly in the HTML, embraced by <pre
> class="code">-blocks, but after a while my conscience urges me to try to
> actually compile the code to make sure the stuff works. It starts out as
> a couple of
> $ cat > testcode.cs
> [Paste with RMB]
> ..and then I keep editing in the HTML-file to add more features as I go
> along. This becomes boring, stupid, and I kick myself in the teeth for
> being too lazy to open testcode.cs itself in emacs and then re-inserting
> the code when I'm happy with it.
> Now, what I really want to do is:
> <pre class="code">
> // --------------------------- <-- Indicate start of subbuffer
> // My little C#-program
> // ---------------------------
> <-- Indicate end of subbuffer
> Then scoot on over to the subbuffer and edit the C#-code. The subbuffer
> will then enable C#-mode instead of HTML mode at my command.
> When I edit the subbuffer, I am _really_ editing the buffer that the
> subbuffer is a part of, it just doesn't get in my way. I should of
> course also be able to save the subbuffer as "testcode.cs", compile this
> code (from the shell or from the IDE), but when I'm done, both buffers
> are magically in sync, and I go on with my documentation without any
> It would also be nice to be able to keep a different editor "mode" on
> the subbuffer when looking at the superbuffer, to get correct
> syntax-hiliting and indenting, etc.
> It's not hard to think of more examples where this feature would be