Re: [ jEdit-users ] Plugins under development

[Marcelo V. <va...@us...>]

Hi Slava,

Slava Pestov wrote:
> I was asking for an explanation why you'd want non-file buffers in  
> the first place.

Other than the explanations I've been using since I started this
side-discussion? :-)

Look, if what you think is that this belongs in console's system shell
and not in a buffer, and that all the features that a buffer has that
the console shell doesn't are not enough to justify this, there's little
I can do to change your mind.

I've used the emacs-style "interactive app in a buffer" several times
and I think it's a great idea. Unless you want to replicate all the
functionality a buffer has in Console's shell, you'd be losing a lot by
not having things like searching, completion, a powerful API for plugins
to use, and even syntax highlighting.

The gdb interface was just one example. I've also used the "emacs shell"
for interactive lisp (not emacs list, but actually running gnucl inside
an emacs "buffer") and it really made my life a lot easier (I started to
do it on jEdit, using gnucl in Console, but it was a lot more painful).

And of course I know I'm free to implement this myself :-), and I
probably will think hard about doing so if I start heavily using gdb
again (up to now it's been pretty light at my new job), but I'd like
other people's input if they think this is a good/bad idea, things I
might be missing, etc.

The current "buffer is a file" paradigm doesn't make this impossible, it
just makes it less transparent than it should be. To make jEdit and the
plugins happy, you'll always have to fake that the data you are editing
is from a file and not from somewhere else.

-- 
Marcelo Vanzin
va...@us...
"Life is too short to drink cheap beer"