What I really envy emacs

[Scara Maccai]

I would REALLY like a vim interface to gdb.

clewn/pyclewn are nice, but only work with gvim (and have problems
under Solaris).

Is there any way to use gdb with vim the "emacs" way?
Any undergoing project that is trying to achieve that?

[Albie]

An incendiary choice of words there.

I don't know anything regarding vim's debugging abilities myself, but I
have noticed that debugger integration rates fairly high on the
requested features page (http://www.vim.org/sponsor/vote_results.php),
so if it isn't there now, it could be around soon!

--

[ Albie Janse van Rensburg ~ http://morph.telspace.co.za ]

Where there is much light there is also much shadow.
-- Goethe

[naquad]

I have a more global thoughts: it would be very nice if vim have a console access. Sort of emacs split buffer with system console.

2008/9/11 Albie <albi...@gmail.com>

[Tim Chase]

> I have a more global thoughts: it would be very nice if vim have a console
> access. Sort of emacs split buffer with system console.

I use "screen" for this, running Vim in one "screen"
window/session, and running my console/debugger/chat/mail/lynx in
other windows/sessions of "screen". More recent (read
"non-ancient") versions of "screen" also allow for splitting the
display so that you can see your code and your debugging at the
same time. By using vim-in-screen rather than console-in-vim it
allows me to multiplex anything consistently even if I don't have
Vim open at the time. I've tried console-in-editor before, and
it doesn't offer any advantages over editor-in-multiplexer.

Just my $0.02 on the matter,

-tim

[naquad]

I know about screen's splits, but it's awful, I can't use it :(
But I really like in-editor shells.

2008/9/11 Tim Chase <v...@tim.thechases.com>

[Scara Maccai]

> I use "screen" for this, running Vim in one "screen"
> window/session, and running my console/debugger/chat/mail/lynx in
> other windows/sessions of "screen".  

Sorry, can't follow you.
How can you follow the code, setting breakpoints etc with your
solution?

The problem I have is that I can run gdb and vim in a different
terminal, but they won't "talk" to each other.

Maybe I didn't got what you mean by "screen".

[Tim Chase]

>> I use "screen" for this, running Vim in one "screen"
>> window/session, and running my console/debugger/chat/mail/lynx in
>> other windows/sessions of "screen".
>
> Sorry, can't follow you.
> How can you follow the code, setting breakpoints etc with your
> solution?
>
> The problem I have is that I can run gdb and vim in a different
> terminal, but they won't "talk" to each other.

Hmm...well I try to avoid C/C++ unless I absolutely have to use
it, writing most of my code in Python. As such, I just use "pdb"
(which I understand to be based off the ideas behind "gdb"), and
within pdb I can list my code, add/remove breakpoints there, and
step through my code. It sounds like you understand screen, so
it's likely my misunderstanding of the abilities of gdb.

-tim

[Scara Maccai]

> It sounds like you understand screen, so
> it's likely my misunderstanding of the abilities of gdb.
>

I can do everything I want in gdb: setting a breakpoint, listing the
code...
but outside vim!

What I want is simple: while I'm using vim I want to set a breakpoint
in the code I see;
or, while I'm debugging, I want to see where a function is defined, or
the code I'm about to execute without calling every single time

"list"

I can do that with emacs...

[vincent]

I prefer to use screen + dvtm. because dvtm support more convenient
windows spliting functionality, for example, vertical spliting etc.

It is almost perfect to use screen together with dvtm although dvtm
is not very mature now.

Sorry, this is a bit out of topic, just point out dvtm here and hope
it is useful for you.

Vincent

[Charles Campbell]

There's also gdbvim: http://www.vim.org/scripts/script.php?script_id=1386

Regards,
Chip Campbell

[Scara Maccai]

> There's also gdbvim:http://www.vim.org/scripts/script.php?script_id=1386

Thank you, I can try that, but it still need X (gvim).
Basically, it seems to me that the only way of interfacing gdb is
using a "vim server": every app out there that interfaces gvim with
gdb uses it.

I think it's pretty bad that there is no way to launch an app inside
vim and have vim "talk" to it...

[Erik Falor]

Be that as it may, it is against Vim's design goals.

:help design-not

There are some things that Vim is designed to excel at, and other things it is designed not to attempt.  Vim is meant to be lean and fast rather than a kitchen sink.

There are times when I, too, wish that features X, Y, and Z would be added to Vim.  But by understanding the design goals that Vim is trying to achieve I can appreciate (though not necessarily agree with) the sacrifices Bram and the other developers need to make.

--
Erik Falor
Registered Linux User #445632 http://counter.li.org

[Scara Maccai]

> Be that as it may, it is against Vim's design goals.
>
> :help design-not

I can see that, but then:

"To use Vim with gdb see: http://www.agide.org and http://clewn.sf.net"

So I don't understand why

controlling a process or being controlled by a process is fine if you
are using X

BUT

it's wrong if you are not using X...

[Chris Burkhardt]

Look into VimGDB. I've not used it, but it's a patch for Vim that I'm pretty
sure adds what you want ("It provides all Emacs features and some more[...]").
It's based on the same code as Clewn, but doesn't require an X server as far as
I can tell.

http://skawina.eu.org/mikolaj/vimgdb/

That page has good info, but the patch is for Vim 6.2. A more up-to-date version
is available from the Clewn website:

http://sourceforge.net/project/showfiles.php?group_id=111038&package_id=120238

It is a patch against vim 7.1, but I imagine would apply against 7.2 without
much hassle.

There was a discussion in 2004 about adding the Vimgdb patch to the main Vim
tree which is interesting (you can read Bram's position on your complaint of not
having good debugger integration):

http://tech.groups.yahoo.com/group/vimdev/message/35536

- Chris Burkhardt

[Gary Johnson]

That's not entirely true. The ":cscope add" command, for example,
launches cscope as a coprocess. Other :cscope commands then talk to
this cscope coprocess by sending commands to pipe and reading the
results from another pipe.

Exchanging data with another application through a pair of pipes to
its stdin and stdout is pretty simple, though, and doesn't meet the
interface requirements of all applications.

Regards,
Gary

[Penz]

Hi

Could you please post a link to DTVM where I can find more
information?

Thanks
Penz

[Scara Maccai]

> That's not entirely true.  The ":cscope add" command, for example,
> launches cscope as a coprocess.  Other :cscope commands then talk to
> this cscope coprocess by sending commands to pipe and reading the
> results from another pipe.

Well, that's 100% true, but that can happen because cscope support is
built into vim.
I don't see why that can be built into vim while a gdb interface
can't...

I think I'm trying to re-say something that has been already told:
(thanks Chris Burkhardt for the link):

http://tech.groups.yahoo.com/group/vimdev/message/35536

In other words: what is supposed to be "ok to be part of vim" and what
is not?
I guess the moltitude of different approaches out there to have a gdb
integration
(none of which solves all the problems) and the high frequence of the
requests
(http://www.vim.org/sponsor/vote_results.php) would say that sooner or
later that
should become a module in vim...

Anyway, I LOVE vim. I would never say that the coders did a bad job!

[dfishb...@gmail.com]

Coming into the middle of this thread.

I believe the netbeans interface is being enhanced. They also wanted to rename it to something generic. I think gdb is using this interface.

Really it should be the generic socket interface to Vim for this type of stuff. That way nothing has to be built into Vim, they can build using this interface.

If I have state something incorrect, I am sure someone will correct me.

Dave

Sent from my BlackBerry device on the Rogers Wireless Network

[Manu Hack]

http://www.brain-dump.org/projects/dvtm/

I just found that out. I'm a screen user. I just tried dvtm and it
was nice. It can be run in screen so you can have differeent layoff
for each window of screen. A little OT now. :)

manu

[Chris Burkhardt]

dfishb...@gmail.com wrote:

> Coming into the middle of this thread.
>
> I believe the netbeans interface is being enhanced. They also wanted
> to rename it to something generic. I think gdb is using this
> interface.

Yes, but the OP's complaint is that the netbeans interface is only available for
gvim (and not console vim). Will the improved interface remove that restriction?

- Chris Burkhardt

[Efraim Yawitz]

On Fri, Sep 12, 2008 at 5:17 PM, Erik Falor <ewf...@gmail.com> wrote:
>
> Be that as it may, it is against Vim's design goals.
> :help design-not
> There are some things that Vim is designed to excel at, and other things it
> is designed not to attempt. Vim is meant to be lean and fast rather than a
> kitchen sink.

I just want to add my voice to those who approve of those goals. Just
adding "one more feature" is the way to ruin the best programs. Vim
is the ultimate editor, and keeping it just an editor (with unlimited
editing capabilities, but not other things) is the way to make sure
that it will stay that way.

In any case, in the context of the original subject, what is wrong
with running Emacs for this purpose, and still editing the code in
vim? I work this way all the time with Visual Studio and vim,
following the debugging in VS but never touching any code there, and
doing all editing in vim, and it's very convenient. (I'm assuming
that Emacs can detect when a file has changed outside of it, the way
VS does, and notify you.)

BTW, does anyone actually use Emacs these days? (I tried it many
times, and I think the main thing that always turned me off was the
juvenile documentation which seems to have been written by Stallman in
his youth and never brought up to any higher level of maturity.)

Ephraim

[Scara Maccai]

> I just want to add my voice to those who approve of those goals.  Just
> adding "one more feature" is the way to ruin the best programs.  Vim
> is the ultimate editor, and keeping it just an editor (with unlimited
> editing capabilities, but not other things) is the way to make sure
> that it will stay that way.

That's not 100% true. Vim it's not just an editor.
You have "quickfix" commands; you have cscope integration.
It's something more. Now: the tricky part is to decide how much more!

> In any case, in the context of the original subject, what is wrong
> with running Emacs for this purpose, and still editing the code in
> vim?  I work this way all the time with Visual Studio and vim,
> following the debugging in VS but never touching any code there, and
> doing all editing in vim, and it's very convenient.

it's a very complicated way of working. It means you will end up
learning 2 things (I have no idea how to open a file in emacs, let
alone finding a tag etc etc).
Plus, when you find a bug with the debugger, you are usually already
in the file that needs to be changed at the right time;
or, when you want to try something after you wrote it, you already are
where you want to put your breakpoint.

Vimgdb seems to fit me well; but it's an external implementation, who
can guarantee it will always there?

[Edward Peschko]

All,

Yes embedding an editor (or other apps) into vi would be helpful, yes
this would be a killer application (one that I have sorely missed
several times). In short, it is a generic extension to the whole
editor concept, where, instead of thinking as a *file* as an object
for editing, one thinks of a *process buffer* as a source for editing
- and it would indeed be a very powerful thing.

Yet for some reason, it has gotten an extremely bad name - that in
doing it, it would add tons of code bloat to the vim core.

The ironic things are that:

- it has already been done in the most part (http://www.wana.at/vimshell)
- it is an extremely small and clean patch (~3000 lines)

Furthermore, with the modal editing that vim provides, it would make a
lot cleaner an interface to any shells or editors than emacs ever
provided, because there are no issues as to who would get input from
the user.

However, because it is not standard, this patch has been buried in
obscurity. Nobody develops for it because it has far too small an
audience.

I can only hope that the attitude about this changes. I feel like I'm
stuck at a local minima - ie: that I've had so much training in vim
that I can't 'jump ship', yet I look at my companions using eclipse
(and other IDEs) and wonder if I can afford not to use the bells and
whistles that they provide (one of the largest ones being debugger
integration).

Ed

[François Beaubert]

Hi all,

Ed, I'm with you ! And I think we are not the only ones ... have a look at the requested features page (http://www.vim.org/sponsor/vote_results.php) and it's just under our nose.
Why vimshell is not proposed to be integrated in the core of vim development ?

Francois

2008/9/15 Edward Peschko <hor...@gmail.com>

[Anton Sharonov]

Ed, you have mentioned you have competing with eclipse IDE. But there
is more productive way - integrating with IDE. As an illustration
there is pretty matured project of on-going integration with eclipse:
eclim [1]. Only thing I really miss at the moment with it is a
"headed" feature (now eclim only run's "headless" so one is unable to
run eclipse and eclim simultaneously on the same eclipse workspace).

[1] http://eclim.sourceforge.net/

[Edward Peschko]

Anton -

Thanks, I'll check it out.

But I still maintain that having shell integration with vim is a
killer app. Eclipse is extremely limited in the systems that it does
support (ie: only windows/linux/macosx), and it almost exclusively
runs as a GUI. (but even with these limitations, this integration is
good to know about, so thanks again)

I want something that can act as an IDE over a ssh session, one that I
am both familiar with in interacting with and which I can program for
those environments which aren't quite standard (eg. the solaris
debugger w/dbx).

Right now, for this purpose I have a confusing semi-workable
combination of screen and vim for this purpose.. But I really, really
want to be able to program for my own environments in vimscript - to
screen scrape a gdb (or perl debugger) session to control a vim
session, go to the corresponding file based off of gdb output, edit,
and restart. I also want to be able to print a large data structure
and be able to search through it with a simple regex.

Ed

[Moshe Kamensky]

Hi,

I don't know about any project, but it seems rather easy to implement
using (for example) the perl interface and the Devel::GDB perl module

Moshe

* Scara Maccai <ultim...@gmail.com> [11/09/08 10:45]:

>
> I would REALLY like a vim interface to gdb.
>
> clewn/pyclewn are nice, but only work with gvim (and have problems
> under Solaris).
>
> Is there any way to use gdb with vim the "emacs" way?
> Any undergoing project that is trying to achieve that?
>

> --~--~---------~--~----~------------~-------~--~----~
> You received this message from the "vim_use" maillist.
> For more information, visit http://www.vim.org/maillist.php
> -~----------~----~----~----~------~----~------~--~---
>

[Teemu Likonen]

Efraim Yawitz wrote (2008-09-15 14:13 +0300):

> Vim is the ultimate editor, and keeping it just an editor (with
> unlimited editing capabilities, but not other things) is the way to
> make sure that it will stay that way.

Sometimes it's difficult to tell where the editor ends and other
features begin. I'd say that Vim already has many of such "other things"
and it has long time ago stopped being only an editor. Anyway, from what
I have read (and tried small things myself) Emacs seems to be more
intelligent in syntax highlighting, code indenting, formatting and other
context-sensitive things. I'm a pure Vim guy but in some things Emacs is
"more ultimate", even as a text editor. It includes more unlimitedness.

> BTW, does anyone actually use Emacs these days?

Many people do.

[François Ingelrest]

On Mon, Sep 15, 2008 at 20:30, Edward Peschko <hor...@gmail.com> wrote:
> The ironic things are that:
>
> - it has already been done in the most part (http://www.wana.at/vimshell)
> - it is an extremely small and clean patch (~3000 lines)
>
> Furthermore, with the modal editing that vim provides, it would make a
> lot cleaner an interface to any shells or editors than emacs ever
> provided, because there are no issues as to who would get input from
> the user.

I must say that being able to run a real shell in (G)Vim would be an
awesome feature, but I can understand the arguments against doing
that.

[bill lam]

On Mon, 15 Sep 2008, Edward Peschko wrote:
> The ironic things are that:
>
> - it has already been done in the most part (http://www.wana.at/vimshell)
> - it is an extremely small and clean patch (~3000 lines)

3000 lines of patch is "extremely small" ?

--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

[Efraim Yawitz]

On Tue, Sep 16, 2008 at 7:59 AM, Teemu Likonen <tlik...@iki.fi> wrote:
>
> Anyway, from what
> I have read (and tried small things myself) Emacs seems to be more
> intelligent in syntax highlighting, code indenting, formatting and other
> context-sensitive things. I'm a pure Vim guy but in some things Emacs is
> "more ultimate", even as a text editor. It includes more unlimitedness.

I'd be very interested in some specific examples of what you mean, but
in any case this really underlines my comment about the documentation.
If all this power is there, it seems to be inaccessible to anyone who
doesn't want to read through all the Lisp code, at the very minimum.
>

[Mikael Jansson]

>
> I believe the netbeans interface is being enhanced. They also wanted to rename it to something generic. I think gdb is using this interface.
>

Where is work happening on that?

> Really it should be the generic socket interface to Vim for this type of stuff.  That way nothing has to be built into Vim, they can build using this interface.
>

Yes, asynchronous socket communication in Vim would be *so* great
instead of to write proxy daemons translating between NetBeans and the
other application's native interface.

--
Mikael Jansson
http://mikael.jansson.be/hacking/limp

[Mikael Jansson]

On Sep 15, 1:13 pm, "Efraim Yawitz" <efraim.yaw...@gmail.com> wrote:

> On Fri, Sep 12, 2008 at 5:17 PM, Erik Falor <ewfa...@gmail.com> wrote:
>
> > Be that as it may, it is against Vim's design goals.
> > :help design-not
> > There are some things that Vim is designed to excel at, and other things it
> > is designed not to attempt.  Vim is meant to be lean and fast rather than a
> > kitchen sink.
>
> I just want to add my voice to those who approve of those goals.  Just
> adding "one more feature" is the way to ruin the best programs.  Vim
> is the ultimate editor, and keeping it just an editor (with unlimited
> editing capabilities, but not other things) is the way to make sure
> that it will stay that way.
>

False.

Giving programmers the ability to use asynchronous events does not in
any way ruin the user experience.

[Noah Spurrier]

On 2008-09-15 14:13+0300, Efraim Yawitz wrote:
>
>On Fri, Sep 12, 2008 at 5:17 PM, Erik Falor <ewf...@gmail.com> wrote:
>>
>> Be that as it may, it is against Vim's design goals.
>> :help design-not
>> There are some things that Vim is designed to excel at, and other things it
>> is designed not to attempt. Vim is meant to be lean and fast rather than a
>> kitchen sink.
>
>I just want to add my voice to those who approve of those goals. Just
>adding "one more feature" is the way to ruin the best programs. Vim
>is the ultimate editor, and keeping it just an editor (with unlimited
>editing capabilities, but not other things) is the way to make sure
>that it will stay that way.

That's a broad argument against any new feature since all new versions
add at least "one more feature". Without some common sense behind that
then why create any new versions? "Vim is perfect! Bram can go home
now!" ...well, maybe not; although, I bet we probably agree on the
same qualities that makes Vim appealing to us.

I think despite the claim of 'design-not' that Vim has in fact come to
include quite a lot of kitchen sink features. I don't call this bloat
because Vim has chosen each new feature wisely. Each new feature does
a lot with a relatively small footprint.

I think a more "enlightened" way to update the design-not goals would
be to say that Vim will strive to get the most utility out of any new
features and will avoid fat features that are useful only to very
specific or rare use cases. A non satirical way to say this:
"Features that allow other features to be built as plugins are
the best features of all! :-)"

Adding a feature that would allow Vim to interact with a child
application seems like a great way to allow plugin writers to build
all sorts of tools that satisfy many other feature requests. It would
do this without great burden or bloat to the core of Vim! Most of the
work would be offloaded to Vimscript plugins that users could install
as they see fit.

I never understood the Vim stance against this particular feature!
* It's a feature that is very broad, generic, and "hackable".
* It's not a feature specific to a one specific application or problem.
* It's a feature that enables other features to be implemented in scripts.
* It's a feature that is not particularly difficult to implement.
* It's a feature that would not add greatly to the size of the Vim core.

Granted, that's all debatable as obviously Vim users debate this a lot,
but I still claim that implementing a PseudoTTY is not hard
and it doesn't have to turn into another Expect to be useful.
Now, after pulling all that out of my ass, I admit that I am totally
unfamiliar with the source code of Vim. Maybe there is some
fundamental design aspect of Vim that would make adding an
asynchronous pty interface difficult and nasty. I'll shut up now.

--
Noah Spurrier | email: no...@noah.org

[Hansen, Mike]

> BTW, does anyone actually use Emacs these days? (I tried it many
> times, and I think the main thing that always turned me off was the
> juvenile documentation which seems to have been written by Stallman in
> his youth and never brought up to any higher level of maturity.)

I suspect that Emacs is nearly as popular as VIM although this poll from 2007
shows otherwise:

http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/text-editor-of-the-year-610219/

or http://tinyurl.com/6rsm7n

Google trends shows Emacs dipping below VIM in 2007/2008.

http://www.google.com/trends?q=vim%2C+emacs

I guess we can prove whatever we want. =)

I tried Emacs 3...no...4 times. It never clicked with me. I ending up
tying my fingers up in knots. I think it's a powerful os...er..editor,
but just not for me.

[Edward Peschko]

The vim codebase is 250k..

Yes, it is extremely small.

Ed

[Charles Campbell]

Edward Peschko wrote:
> The vim codebase is 250k..
>
> Yes, it is extremely small.
>
> Ed
>
> On Mon, Sep 15, 2008 at 11:13 PM, bill lam <cbil...@gmail.com> wrote:
>
>> On Mon, 15 Sep 2008, Edward Peschko wrote:
>>
>>> The ironic things are that:
>>>
>>> - it has already been done in the most part (http://www.wana.at/vimshell)
>>> - it is an extremely small and clean patch (~3000 lines)
>>>
>> 3000 lines of patch is "extremely small" ?
>>

Continuing the about-to-be silly discussion...

Using the quantity of tags as a rough measure of the qty of vim's
features, and using the total qty of lines in *.[ch]:

374642/8265 = 45.3 lines/feature

So, this new feature requires 66 times as many lines as the average vim
feature. I'll go with "not small".

Regards,
Chip Campbell

[Edward Peschko]

And of those 3000 lines, ~2200 are in new files, and the rest are
#ifdef'd behind a tag named FEAT_VIMSHELL, so there is exactly zero
impact on the current build if you don't enable vimshell..

So, yes, it is 'extremely small' unless you are being incredibly
pedantic. It certainly doesn't add tons of code bloat to the core, and
certainly doesn't hack in 'just one feature' - it enables a whole
spectrum of features.

Ed

[Tony Mechelynck]

One box of Hollerith cards used to be 2000 lines. I wouldn't call a
single module one and a half boxes big a "small" program, not even in
COBOL which used to be somewhat verbose compared to, let's say, FORTRAN.
Twenty lines was certainly small. Five hundred, maybe. Three thousand,
no way.

Best regards,
Tony.
--
It would be nice if the Food and Drug Administration stopped issuing
warnings about toxic substances and just gave me the names of one or
two things still safe to eat.
-- Robert Fuoss

[Tony Mechelynck]

On 16/09/08 21:08, Edward Peschko wrote:
> And of those 3000 lines, ~2200 are in new files, and the rest are
> #ifdef'd behind a tag named FEAT_VIMSHELL, so there is exactly zero
> impact on the current build if you don't enable vimshell..
>
> So, yes, it is 'extremely small' unless you are being incredibly
> pedantic. It certainly doesn't add tons of code bloat to the core, and
> certainly doesn't hack in 'just one feature' - it enables a whole
> spectrum of features.
>
> Ed

By that criterion, there are no large features, because any feature is
zero bytes if you disable it at compile-time. There aren't even any
large programs (except the kernel, maybe), because any program is still
zero bytes if you don't install it. Sorry, but I prefer Dr. Chip's
"pedantry" to your sophistry.

Regards,
Tony.
--
An apple every eight hours will keep three doctors away.

[Edward Peschko]

Tony,

I'm sorry I fell for it. Don't like a patch/feature/whatever, you
label it as 'large' or 'unwieldly', any arguments for it are
'sophistry'. Like the patch/feature/whatever, you label it as 'small',
or 'elegant', any arguments against it are pedantic. I'm just as
guilty.

The only thing proper to do is to judge for yourself and actually look
at the code. I maintain that it is elegant because I've looked at it,
used it, and it solves a frequently felt need - I invite anyone who is
skeptical about it to look at the code themselves as well, and then
come back with criticisms.

Ed

[Tony Mechelynck]

On 17/09/08 02:49, Edward Peschko wrote:
> Tony,
>
> I'm sorry I fell for it. Don't like a patch/feature/whatever, you
> label it as 'large' or 'unwieldly', any arguments for it are
> 'sophistry'. Like the patch/feature/whatever, you label it as 'small',
> or 'elegant', any arguments against it are pedantic. I'm just as
> guilty.
>
> The only thing proper to do is to judge for yourself and actually look
> at the code. I maintain that it is elegant because I've looked at it,
> used it, and it solves a frequently felt need - I invite anyone who is
> skeptical about it to look at the code themselves as well, and then
> come back with criticisms.
>
> Ed

- What I call sophistry is saying that a patch is small "because it uses
zero bytes in the binary if you disable the feaure at compile-time".
Whether I like or dislike the patch doesn't enter the picture. It's just
that anything you don't install takes zero bytes, so calling it small
"because it takes no space if you don't install it" doesn't mean
anything. I'll call a patch "big" according to "how large is the source
(including both the true and false paths of #ifdef's, and all modules
regardless of whether their code ends up being linked into the binary or
not)?" and I'll call it "bloat" according to "how large a size
difference does it make in the binary when it _is_ included, and how
useful is it?" "Bloat" is subjective and pejorative, "big" by itself is
neither.

- I don't regard a three-thousand-line patch a small one regardless of
how useful it is or how big a program it is applied to. Maybe I'll apply
some other 3000-line unofficial patch for some other feature if I deem
it useful or interesting for my uses. But I won't call it a small patch.

- I could have said that you call an argument "pedantic" if it goes
against your likes or beliefs. I almost did, but if I did, I take it
back: let's not throw names at one another.

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
176. You lie, even to user-friends, about how long you were online
yesterday.

[vincent]

If you ask google about dvtm, it will tell you this:
http://www.brain-dump.org/projects/dvtm/ :)

Enjoy!

Vincent

> Thanks
> Penz

[Mikael Jansson]

> > Tony,
>
> > I'm sorry I fell for it. Don't like a patch/feature/whatever, you
> > label it as 'large' or 'unwieldly', any arguments for it are
> > 'sophistry'. Like the patch/feature/whatever, you label it as 'small',
> > or 'elegant', any arguments against it are pedantic. I'm just as
> > guilty.
>
> > The only thing proper to do is to judge for yourself and actually look
> > at the code. I maintain that it is elegant because I've looked at it,
> > used it, and it solves a frequently felt need - I invite anyone who is
> > skeptical about it to look at the code themselves as well, and then
> > come back with criticisms.
>
> > Ed
>
> - What I call sophistry is saying that a patch is small "because it uses
> zero bytes in the binary if you disable the feaure at compile-time".
> Whether I like or dislike the patch doesn't enter the picture. It's just
> that anything you don't install takes zero bytes, so calling it small
> "because it takes no space if you don't install it" doesn't mean
> anything. I'll call a patch "big" according to "how large is the source
> (including both the true and false paths of #ifdef's, and all modules
> regardless of whether their code ends up being linked into the binary or
> not)?" and I'll call it "bloat" according to "how large a size
> difference does it make in the binary when it _is_ included, and how
> useful is it?" "Bloat" is subjective and pejorative, "big" by itself is
> neither.
>

If there was a decent asynchronous communication framework in place in
Vim, we wouldn't need to argue about this at all, you know -- people
would be able to write plugins instead.

---
Mikael Jansson
http://mikael.jansson.be/hacking/limp

[Yongwei Wu]

2008/9/17 Mikael Jansson <mikael....@gmail.com>:

I second the plug-in idea. This is something I have wanted for some
time. It will make Vim more flexible and more extendible.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

[Claus Reinke]

> If there was a decent asynchronous communication framework in place in
> Vim, we wouldn't need to argue about this at all, you know -- people
> would be able to write plugins instead.

And the really interesting thing about that is that adding support
for asynchronous subprocesses could be a pre-cursor for
*removing* code from Vim (look at all those interfaces).

One general feature instead of many special cases - more
functionality, less code. More uniform feature set - easier
to understand. Standard support for a widely *needed*
feature - less configuration trouble (no need to require
Perl, and a specific version of the Perl library at that, just
to get at Perl's asynchronous subprocesses; no need to
install all of Perl/Python/.. just because different plugins
use different interpreters, just to get at their asynchronous
subprocesses; certainly no need to ask users to patch
their Vims;..).

<soapbox>

This is the only mis-feature of Vim that I have never found
an acceptable workaround for - and it bites me everytime
I want to edit programs or other meaningful text, where the
meaning can be extracted mechanically: most programming
languages have tools or APIs that make it possible to extract
semantic information for their source texts (I have worked on
a couple of such tools myself - and yes, I've had the mispleasure
of trying to find portable cludge-arounds to get them almost
working, most of the time, from within Vim).

Without Vim offering a standard way of plugging such tools
in, asynchronously, using them is error-prone and inefficient
at best. Why am I supposed to use another editor for
semantics-aware editing, when I prefer to use Vim for all
editing? Why are there special interfaces for some languages
and some tools, instead of a single general interface that
could be used by all?

Just have a look at the languages supported by syntax, or by
filetype, and compare to the list of languages supported by
interface/incrementally updated tags/..

Isn't it time to say good bye to the little jokes in design-not,
and instead look at the many other design-* ideals these
jokes and their consequence interfere with? Some examples:

Vim should make it easy for users to work in their preferred
styles rather than coercing its users into particular patterns of
work.

Vim is a component among other components. Don't turn it
into a massive application, but have it work well together with
other programs.

People switch from one platform to another, and from GUI to
terminal version. Features should be present in all versions, or
at least in as many as possible with a reasonable effort. Try to
avoid that users must switch between platforms to accomplish
their work efficiently.

</soapbox>

It would all be in the spirit of Vim/Unix - the only change would
be that it is no longer sufficient to have small tools called temporarily
by Vim, or Vim called temporarily by big tools: these days, Vim is
one of several tools of equal importance, and all these tools need to
be able to cooperate on an equal basis, with all the tools being able
to keep running and doing their jobs while communicating with each
other.

Since Vim does a very good job of providing an efficient editing
environment, it naturally has a major role in the user interface of such
a tool collection, wherever editing is concerned. That does not mean
that the other tools would become part of Vim (think toolbox instead
of kitchen sink), just that Vim no longer refuses to talk to other tools
to do a better job of semantics-aware editing.

Claus

[Richard Hartmann]

On Tue, Sep 23, 2008 at 16:14, Claus Reinke <claus....@talk21.com> wrote:

> [I want a generic API that splits engine from presenation]

I couldn't agree more, this is the one thing that Vim simply
can not do in a nice manner. It would solve several problems
at once, for example make it possible to re-introduce KVim
which died with KDE 2.

I did my tiny part in donating & voting on the feature. If
_many_ other people did the same, this might be done at
some point. As I understand Bram, there would be an insane
amount of work involved in this.

As long as we are in pony-land:
Bram, how many months of dedicated work would it take you
to do this?
If the community at large pledged money on this, for Uganda,
a sabbatical from google, or both, what amount would need
to be raised?

Of course, 'this can not reasonably be done' or 'I do not want
to do this in the next few years' are fully OK as answers, as
well.

Richard

[Bram Moolenaar]

Richard Hartmann wrote:

> On Tue, Sep 23, 2008 at 16:14, Claus Reinke <claus....@talk21.com> wrote:
>
> > [I want a generic API that splits engine from presenation]
>
> I couldn't agree more, this is the one thing that Vim simply
> can not do in a nice manner. It would solve several problems
> at once, for example make it possible to re-introduce KVim
> which died with KDE 2.

This is unrelated. The problem with kvim was that the people working on
it didn't like how Vim handles events, and instead of working around it
decided to start from scratch. It's common to think your design can do
things better, but only later find out all the little details that makes
a design fail.

> I did my tiny part in donating & voting on the feature. If
> _many_ other people did the same, this might be done at
> some point. As I understand Bram, there would be an insane
> amount of work involved in this.
>
> As long as we are in pony-land:
> Bram, how many months of dedicated work would it take you
> to do this?
> If the community at large pledged money on this, for Uganda,
> a sabbatical from google, or both, what amount would need
> to be raised?
>
> Of course, 'this can not reasonably be done' or 'I do not want
> to do this in the next few years' are fully OK as answers, as
> well.

I don't know what the actual request is. We already have plugins.
"API" is a word that can be used for many things. It's way too vague to
say anything about time or money.

Designing a good interface is difficult and often requires many
iterations. Implementing it can be an awful lot of work. A requirement
to be backwards compatible makes this about ten times more difficult.
Then you need to wonder how much end-users actually gain from this.

If there is one thing I would like to work on, given enough time, is to
compile Vim script into some kind of byte code. And clean up a lot of
the command line parsing along the way.

--
From "know your smileys":
% Bike accident. A bit far-fetched, I suppose; although...
o _ _ _
_o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Richard Hartmann]

On Wed, Sep 24, 2008 at 19:24, Bram Moolenaar <Br...@moolenaar.net> wrote:

> This is unrelated. The problem with kvim was that the people working on
> it didn't like how Vim handles events, and instead of working around it
> decided to start from scratch. It's common to think your design can do
> things better, but only later find out all the little details that makes
> a design fail.

I remembered something along those lines, yes.
I did not mean to imply it was the same. What I meant is that, as far as
I know, Vim and GVim do not have a clean seperation between the actual
data handling, command parsing and execution etc and the visual
front-end.
If Vim was able to act like a headless server with a single API to which
anything from the CLI interface over language interfaces to the GTK
front-end would connect, it should be relatively easy to write new
interfaces.

This would mean scrapping the current Vim and Gvim front-ends,
replacing them with stuff that interfaces against this generic API.

And yes, I am aware that this is probably insane ;)

> I don't know what the actual request is. We already have plugins.
> "API" is a word that can be used for many things. It's way too vague to
> say anything about time or money.

See above. A very ugly ASCII representation would be:

CLI GTK Perl ...
\ | /
\ | /
\ | /
API
|
Vim

> Designing a good interface is difficult and often requires many
> iterations. Implementing it can be an awful lot of work. A requirement
> to be backwards compatible makes this about ten times more difficult.

Indeed. This would be a huge change and devour most of the resources
that go into Vim for quite some time.

> Then you need to wonder how much end-users actually gain from this.

That is hard to gauge. I suspect that, in the long run, this would pay
off as implementing new KDE, Qt, Mac, X, whatever interfaces should
be pretty easy, same as support for new languages. It would even allow
Vim to be used from the command line, similar to perl -e.

I never took a very deep look at the existing netbeans API, but from the
regular requests & questions on this list, it does not seem to scratch the
itches of a lot of people trying to interface to Vim.

> If there is one thing I would like to work on, given enough time, is to
> compile Vim script into some kind of byte code. And clean up a lot of
> the command line parsing along the way.

Are you sure the improvements in execution speed would merrit this?
I suspect the overall benefit for all users would be less than said
all-powerful API.
Said API could even be used to interface with both the old Vimscript
parser and the new, shiny byte-code-generating one. The old one
could be used until such a time as the new one is ready and simply
be swapped for each other. First for the beta testers and then for
everyone else.

I would ask people on this list other than myself to chip in, as well.

Richard

[John Beckett]

Richard Hartmann wrote:
> I would ask people on this list other than myself to
> chip in, as well.

I'm going to be more of a cold-water person than you might have hoped for.

Bolting fundamental redesigns on a large system is one of those Great Ideas that
rarely works. Studying Vim's source proves the obvious: it is already sufficiently
complex!

I understand there is a 3000-line patch that achieves a working solution, and that a
lot of its complexity is compartmentalised. That's a great achievement, but imagine
the work involved in having Bram even READ the patch, let alone confirm its
reliability on a large number of systems under amazingly many situations ... all
those typeaheads, event handlers, and a heap of other stuff I haven't yet found.
There are more worthwhile things to do.

OTOH I'm a bit biased because I'm one of those who can't see the point of running
stuff in an editor.

John

[Claus Reinke]

> Bolting fundamental redesigns on a large system is one of those Great Ideas that
> rarely works. Studying Vim's source proves the obvious: it is already sufficiently
> complex!

There should be no need for fundamental redesigns? On Unixish systems,
the standard solution is to provide some form of popen2 (or to implement
the same using lower-level fork/exec/pipe/sockets/..); on Windows, there
seem to be different ways of providing essentially the same feature.

Such functionality is found in most scripting languages, and in many
general purpose languages as well, to protect programmers from
platform-specific ideosyncrasies, or to fit the low-level implementation
into the high-level framework. Looking into GPL-licensed implementations
for inspiration is not an option for Vim, but there are some BSD-licensed
implementations around as well. And I believe that some of the special-case
interfaces in Vim already use such code - they just don't expose the
generic functionality to VimScript.

The main difficulty would seem to be that Vim is not a multithreaded
application, so one would need to design and program carefully to
avoid blocking everything. But since several of Vim's scripting languages
provide such features, and several of Vim's interfaces use such features,
it should be possible to provide something similar in Vim itself.

> OTOH I'm a bit biased because I'm one of those who can't see the
> point of running stuff in an editor.

Then you are probably using the wrong editor. "running stuff" has
been part of Vim since Vi (:help ! or :help :!), the only difference
is that we'd like the stuff to stay alive in the background, instead
of restarting it all the time (mostly because extracting semantic
information from program sources is expensive, so you want to
let the external tool maintain it incrementally, as Vim edits files).

And Vim has lots of special case code for this already (:help
reference_toc | /Interfaces). Ideally, all of those special-case
interfaces would be replaced by a single generic interface in
Vim, moving the special case stuff into plugins that use the
generic interface.

Claus

[Ivan Tishchenko]

I'm not sure if this is relevant, but... I don't even need any API, I
already have python compiled into Vim. The ONLY thing I need is
possibility of running things asynchronously. Last time I tried, even
threads created in python got frozen when vim finished executing
vimscript (which particularly invoked the python command to create those
thread) and returned control to user. Thread gets frozen and un-frozes
only when you next time call something via :python.

So, basic problem for me is inability to run stuff asynchronously. And,
I don't even need vim engine processing commands asynchronously. It
would do if I could send keys/commands sequence, which would "block"
user input, break into Normal mode and do stuff, and then restore the
state as it was before this sequence, and return control back to user.

And I basically don't get why it's so hard to implement in general,
given that netbeans interface already does that.

WBR,
Ivan.

[Richard Hartmann]

On Thu, Sep 25, 2008 at 02:10, John Beckett <johnb....@gmail.com> wrote:

> I'm going to be more of a cold-water person than you might have hoped for.

Actually, no. All constructive feedback is good :)

> Bolting fundamental redesigns on a large system is one of those Great Ideas that
> rarely works. Studying Vim's source proves the obvious: it is already sufficiently
> complex!

True. Yet, removing all language- and UI-specific extra cases and wrapping
everything into one common API should help to reduce overall complexity.

> I understand there is a 3000-line patch that achieves a working solution, and that a
> lot of its complexity is compartmentalised. That's a great achievement, but imagine
> the work involved in having Bram even READ the patch, let alone confirm its
> reliability on a large number of systems under amazingly many situations ... all
> those typeaheads, event handlers, and a heap of other stuff I haven't yet found.

Which brings us back to the pros of a branch of Vim that has some stuff enabled
which did not, yet, make it into mainline. People interested in
feature X could use
that version and report any issue they might be having. After some grace period,
patches could be merged into mainline with a lot more confidence about their
stability.

> There are more worthwhile things to do.

Depends. If done right, this gives you a lot of stuff for free. No
more questions about
asynchronous execution, embedding of Vim into other programs or vice
versa or many
new native UI front-ends.
This would solve a huge number of requests which are made quite
regularly by various
different people.

> OTOH I'm a bit biased because I'm one of those who can't see the point of running
> stuff in an editor.

Running it within the editor is not a problem, anyway. The thing is to make Vim
play nice with all kinds of other applications instead of demanding
extra treatment.

Again, I am aware that this would be a huge amount of work. And I am far from
demanding anything. I just think it would be a worth-while medium-term goal.

Richard

[François Beaubert]

+1 for me

[Richard Hartmann]

On Thu, Sep 25, 2008 at 16:35, François Beaubert
<francois...@gmail.com> wrote:

> +1 for me

+1 for _what_?

The 'this would be useful', the 'this would not be useful' or any of
its sub-aspects?

RIchard

[François Beaubert]

2008/9/25 Richard Hartmann <richih.ma...@gmail.com>:

Sorry Richard

+1 for useful, very useful !

I agree with your "worth-while medium-term goal", in particular regarding:

asynchronous execution, embedding of Vim into other programs or vice
versa or many new native UI front-ends.

Regards

[Agathoklis D. Hatzimanikas]

On Thu, Sep 25, at 10:10 John Beckett wrote:
>
> OTOH I'm a bit biased because I'm one of those who can't see the point of running
> stuff in an editor.
>

Oh well, V(im) I(s) M(ore) than just an editor. :)
It's (firstly) a school of thought - (how should do (faster) more with less)
and (secondly) is an established (clever) productive environment with deep
roots in the history of computing.

- vi is a standard in any unix*
- vi mode is a choice in any shell (I use it in zsh and dash
(editline from netbsd http://www.thrysoee.dk/editline/))
- vi movements-motions are present or easy available in countless
applications (even in window managers like fvwm, dwm) or browsers
(elinks) ...
- and of course vi is in POSIX.

<Joking> around once I said that we could provide vi certificates, e.g.,
(the x application is vi compatible)... as (in my opinion) there is a
huge stream of users (poor, innocent and addictive geek brains) already
working in a full or mini (vi) environment. How and if they are willing
to follow a unification of the vi ecosystem under a common umbrella is
for another manifesto (ViOS).
</>

Little more seriously now (and yes I am running stuff in the editor and I
could also find a use for a shell (for instance)), the best feature
(for me) in vim is the expression register; because I tend to see (almost)
everything as a "value", so I find myself insert all the time the evaluation
of an expression (I wrote countless scripts for any matter that I need or
have an interest). And I wrote them in vimL, because it gives me: Dictionaries,
lists, loops, if statements, floating point support, system() ... and may
I say that vimL is simple and expressive (it's not scheme!), plus is native.
Wouldn't be a great extension to Vim, if there was a generic framework for
a two-way communication with other tools and languages (in an asynchronous
way), so the user can handle by himself the extend and the type of the
implementation?
Wouldn't that make Vim a viable long term solution?
(lying) I don't even dare to imagine the possibilities.

And before (you) try to accuse me as a dreamer, think for a sec: I am
just holding in my arms, a beautiful young girl 14 days old; besides that
I am training my 7 years old son in Vim! (and he is good :)).

> John

Regards,
Αg.

[bill lam]

On Thu, 25 Sep 2008, John Beckett wrote:
> Bolting fundamental redesigns on a large system is one of those Great Ideas that
> rarely works. Studying Vim's source proves the obvious: it is already sufficiently
> complex!

Actually I agree with you. IMO it is too late to re-factor vim into
model+view. It can't say that vim is bloated given its amazing
spectrum of features. However when intended as embedded editor using
only a small portion of vim will already very useful. In such scenario the
ancient ex-vi code is a possible candidate to start with.

[Ivan Tishchenko]

I vote for 'very-very-very useful'. :)

WBR,
Ivan.

[Raúl Núñez]

Saluton bill :)

On Thu, 25 Sep 2008 23:46:13 +0800, bill lam dixit:

> On Thu, 25 Sep 2008, John Beckett wrote:
> > Bolting fundamental redesigns on a large system is one of those
> > Great Ideas that rarely works. Studying Vim's source proves the
> > obvious: it is already sufficiently complex!
> Actually I agree with you. IMO it is too late to re-factor vim into
> model+view.

Unfortunately, yes. Vim is so full-featured that refactoring is no
longer possible (to be exact, it *is* possible, but would require a lot
of full-time volunteer work, so although possible, is not achievable
right now). But then again, Vim is so full-featured that any try to
start from scratch a new Vim incarnation, even half-featured, would be a
huge task too. Possible, yes. Not achievable, unfortunately yes too. And
I say unfortunate because a Vim rewrite separating presentation from
engine would be very good and very interesting IMHO. But, the fact is
that Vim works very good as-is.

> It can't say that vim is bloated given its amazing spectrum of
> features.

Neither can I. When I think about Vim I think about power and features,
but not bloat. There's no really anything I would be happy to see out of
Vim, although I don't use even the 10% of its power.

As for the 3k patch about async communication with subprocesses, I
haven't seen the code so I'm not going to judge. I think that having
such facility into Vim wouldn't be bad, but I cannot support the patch
without knowing the side effects (which BTW is something that probably
only Bram could know). So, I'm not going to tell anything about that
particular issue.

Raúl "DervishD" Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...

[Teemu Likonen]

Raúl Núñez de Arenas Coronado wrote (2008-09-25 18:29 +0200):

> Unfortunately, yes. Vim is so full-featured that refactoring is no
> longer possible (to be exact, it *is* possible, but would require
> a lot of full-time volunteer work, so although possible, is not
> achievable right now). But then again, Vim is so full-featured that
> any try to start from scratch a new Vim incarnation, even
> half-featured, would be a huge task too.

Hmm, Emacs already contains vi editor mode (viper-mode) so maybe someday
it will include the whole Vim too and thus all these requests are
answered :-) OK, I'm joking, but I have to admit that it's amazing how
Emacs's design seem to allow users to extend it do anything. I just
learned that it can display JPEG images.

[John Beckett]

Claus Reinke wrote:
>> OTOH I'm a bit biased because I'm one of those who can't
>> see the point of running stuff in an editor.
>
> Then you are probably using the wrong editor. "running stuff"
> has been part of Vim since Vi (:help ! or :help :!), the only
> difference is that we'd like the stuff to stay alive in the
> background, instead of restarting it all the time (mostly
> because extracting semantic information from program sources
> is expensive, so you want to let the external tool maintain
> it incrementally, as Vim edits files).

Sorry, I didn't realise I had to spell it out: Of course it's easy to suspend a
program, run something, extract results, and continue. Yes, of course I use those
facilities, which have been present from day one.

We're talking about taking 9MB source code *designed* for a single-thread model, and
"extending" it to cope with multiple threads in some form, at least async i/o.

I worry when tweaking one of my large programs, but the only thing that actually
frightens me is the async stuff (and that's when it was *designed* in from the
start). I have sometimes taken a week to change a couple of lines relating to the
async code (on a system that required special hardware to run, and couldn't be
properly tested except in public view).

John

[Claus Reinke]

> Of course it's easy to suspend a program, run something, extract results, and continue.
> Yes, of course I use those facilities, which have been present from day one.

That is a simple form of cooperative concurrency already: calling an
external tool while suspending Vim. The next step would be co-routines:
at any point, either the external tool or Vim is suspended, while the other
one runs for a while. Not killing the external tool after each use, but
suspending it instead and being able to resume it with the same
communication channels, would already allow for one common
usage pattern:

- start Vim on source code for language L
- start analysis tool T for language L
- edit source code in Vim, calling out to T whenever Vim needs to
know where to find the definition location or what the type of an
identifier is, or which names are in scope for insert-mode completion
- end Vim and T sessions

The difference is that the external tool does not have to be restarted,
loading all source code again, repeating expensive program analysis
again, every time Vim needs to ask for a little bit of information.

> We're talking about taking 9MB source code *designed* for a single-thread model, and
> "extending" it to cope with multiple threads in some form, at least async i/o.

Vim already has to have some support for asynchronous stuff to happen:
- autocommand events
- other Vim incarnations calling in via --remote

That is probably a cooperative form of concurrency: at certain well-defined
points, Vim suspends what it is doing, asks its scheduler whether it should
be doing something else, does that, then resumes what it was doing before.

So Vim has to deal with the difficulties already, but it doesn't get
the full benefits of those capabilities. So plugin authors are constrained
in what they can do. So program editing support in Vim isn't as good
as it could be (outside a small set of languages). So fewer people are
using Vim. I don't like to see so many people deprived of something
as good as Vim!-)

Claus

[Claus Reinke]

> I'm not sure if this is relevant, but... I don't even need any API, I
> already have python compiled into Vim.

The problem is portability: those plugin authors who need python anyway
can of course rely on their plugin users installing python; the same goes for
perl-related plugins, or tcl, or netbeans, or OLE, ..

But if you're writing a plugin supporting Vim editing of programs in a language
for which Vim does not have a built-in interface, you've got a problem: should
you ask your users to install python, or perl, or OLE, or what? Whatever you
choose, it won't work on some standard Vim installations (eg, Windows Vims
come with many interfaces enabled, but without the perl/python/tcl/.. libraries).

Moving the subprocess communication into Vim would allow such plugins
to be written for any language, without blowing up Vim binaries with whole
sets of interpreters for many languages, just in case one of them is used.

And since scripting languages have interpreters that Vim could call as an
asynchronous subprocess, support for this would also allow lots of the
interface code to be moved out of the Vim code base.

> The ONLY thing I need is
> possibility of running things asynchronously. Last time I tried, even
> threads created in python got frozen when vim finished executing
> vimscript (which particularly invoked the python command to create those
> thread) and returned control to user. Thread gets frozen and un-frozes
> only when you next time call something via :python.

Since you are willing to limit yourself to python: have you tried starting
a _separate process_ with a python interpreter to do your asynchronous
work, using the python binding in Vim only to communicate with that
other interpreter (using python's communication facilities)?

A similar approach has been used rather successfully for equipping emacs
with support for Erlang programming: a little emacslisp code to make
emacs look like just another Erlang node which can then communicate
with other, real Erlang nodes to get semantics information about Erlang
programs (they didn't want to write their support code in emacslisp,
preferring Erlang instead - programmers are strange, aren't they?-):

Luke Gorrie,
Distel: Distributed Emacs Lisp (for Erlang),
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.4770

Claus

[Yukihiro Nakadaira]

maybe a bit off topic...
This is my old attempt to provide IPC feature to VimScript by using
libcall().
http://yukihiro.nakadaira.googlepages.com/vimproc.zip

--
Yukihiro Nakadaira - yukihiro....@gmail.com

[Charles Campbell]

Using netrw, have you ever placed a cursor over somefile.jpg and pressed
"x"? Try it!

Chip Campbell

[Noah Spurrier]

On 2008-09-26 13:07+0100, Claus Reinke wrote:
>Since you are willing to limit yourself to python: have you tried starting
>a _separate process_ with a python interpreter to do your asynchronous
>work, using the python binding in Vim only to communicate with that
>other interpreter (using python's communication facilities)?

Has anyone tried using Pexpect from inside Vim?
I feel sort of silly asking since I wrote Pexpect.

--
Noah Spurrier | email: no...@noah.org | http://www.noah.org/wiki/engineering
-------------------------------------------------------------------------------

[Teemu Likonen]

> Teemu Likonen wrote:

> > I have to admit that it's amazing how Emacs's design seem to allow
> > users to extend it do anything. I just learned that it can display
> > JPEG images.

> Using netrw, have you ever placed a cursor over somefile.jpg and
> pressed "x"? Try it!

Yes I have, and it's nice that it can launch external viewer for
different types of files. Even though Emacs can display images and PDF
files inside an Emacs buffer I prefer to use my favorite KDE-based tools
for the job, for example, Gwenview and Kpdf. I don't even use netrw that
much because I think Konqueror is better. Anyway, thanks for the netrw
plugin.

But in this thread's context I could ask people to try running a shell
command from Vim and have this shell command open $EDITOR which is
a client for the same Vim session. I mean:

$ export EDITOR='/usr/bin/gvim --remote-tab-wait-silent'
$ gvim

Then from GVim run something that opens $EDITOR, for example:

:!crontab -e

The result is that GVim hangs. If EDITOR=/usr/bin/vim it also hangs
(sort of) because the "builtin_gui" terminal can't handle the terminal
Vim. A work-around is to redefine the EDITOR variable to something
external which does not depend on the current Vim's terminal, for
example:

let $EDITOR = '/usr/bin/gvim --nofork'

Emacs does better job here. From Emacs's shell or terminal buffer with
EDITOR=emacsclient the previous example just works. It opens emacsclient
session to the current Emacs server session.

[bill lam]

On Fri, 26 Sep 2008, Charles Campbell wrote:
> Using netrw, have you ever placed a cursor over somefile.jpg and pressed
> "x"? Try it!

I tried, it calls gimp unexpectedly. How does netrw determine mime
assoication?