|
From: Marcelo V. <va...@us...> - 2007-01-30 04:41:27
|
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" |