Intesting blog posts of 10 year vim user switching to emacs
Xulxer
perhaps someone is interested in the good features of the other great
editor:
http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/
http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/
Kind regards
Chris
Charles Campbell
mentioned. Just complaints about vim.
Chip Campbell
Gene Kwiecinski
>mentioned. Just complaints about vim.
And most of the items mentioned (spellcheck, IDEs, etc.) I don't even
use, nor would particularly want. Hey, if I see an error on line 35 of
file 'fooey.c', I'll edit 'fooey.c' and '35G'. Big deal. Never much
bothered with spellcheckers anyway, as the dictionary sizes are immense.
I'd just like to see him use emacs on a smartphone...
Tom Link
> mentioned.
etc. I especially liked this sentence: "I think that nowadays Emacs is
ready to be switching to". Finally. :-)
One thing he mentions is management of async processes which would be
handy. (Not for the spellchecker though. I personally love vim's
spellchecker.)
Regards,
Thomas.
Joseph Sullivan
alias emacs="echo haha, no emacs for you\!; sleep 2; vi $@"
703designs
Tony Mechelynck
> Hi,
>
> perhaps someone is interested in the good features of the other great
> editor:
What good features?
I tried Emacs a couple of times, among other things because there's so
much hype about it in the help for the "info" program. Never could make
head or tail of it. Then I found Vim. That's an editor I could relate
to. At first I used it in Console mode to edit my lilo.conf (nowadays I
don't use LILO anymore, and I rarely use Vim in Console mode even on
Linux). The bright colours surprised me at first, but I ran the
vimtutor, installed Vim on Windows (I still used double-boot then),
subscribed to the list... Here I am now, and never would use any other
editor if I could.
If you want to leave Vim and fly Emacs, go ahead, I'm all for freedom.
But if you want _me_ to believe just one instant that Emacs is better
than Vim for _my_ purposes, I'll tell you: No way! I tried it, more than
once, and I had to come to the conclusion that that program and I are
totally foreign to each other.
Best regards,
Tony.
--
press CTRL-ALT-DEL for more information
StarWing
that's true. i just want a debuger with Vim.....
On 11月18日, 上午10时35分, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
Joseph Sullivan
> > alias emacs="echo haha, no emacs for you\!; sleep 2; vi $@"
>
Sorry to clog up the list with silliness, but it's possible my solution
to this problem will be of help to people ;)
-----------------------
alias which="~/which"
cat ~/which
#!/bin/sh
if [ "$1" = "emacs" ]; then
rm -fv `/usr/bin/which emacs`
echo 'Way to go!'
else
/usr/bin/which $@
fi
-----------------------
You must be clever to combat religious zealots.
A. S. Budden
>
>> because a firm choice in Vim is to ... (OK, I confess, I'm starting to beat a dead horse) ... not have support for interaction with external processes.
>
> that's true. i just want a debuger with Vim.....
Me too... I don't see me changing to emacs any time soon (my hands
aren't dextrous enough to cope with alt-ctrl-shift-etc), but I do wish
there was more capability to have interaction with external processes
/ debugging support etc.
Ah well...
Al
Efraim Yawitz
The main thing I think this blog post missed is the fact that we
vi/vim fans think that modality is the whole point (not a drawback, as
he seems to imply)! I could see using Emacs with viper mode if I
really needed the connection with external processes (and somehow was
unable to use vim at the same time), but who wants to use the
non-modal regular mode of Emacs? And yes, Elisp (or any kind of LISP)
is cool and maybe cooler than Vim's pseudo-Perl sort of scripting
language, but how much really complex scripting do most users do on a
regular basis?
Ephraim
Thomas Koch
> > because a firm choice in Vim is to ... (OK, I confess, I'm starting to
> > beat a dead horse) ... not have support for interaction with external
> > processes.
>
> that's true. i just want a debuger with Vim.....
one. It seems so un-unix and bad that VIM implements it's own
spellchecker instead of giving me the freedom to use what spellcheck I
like.
What's the reasoning for not using external processes. Couldn't it just
be added as a feature to get everyone happy?
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
A. S. Budden
Elisp is another of the reasons I wouldn't change to emacs: I think it
is a horrible language (ditto for other LISPs), but I realise that a
lot of people really like it, to each their own I guess. Vim script
is nasty compared to python/perl/ruby etc, but I'd take it over Elisp
any day!
Al
Teemu Likonen
> 2008/11/18 StarWing <weasl...@sina.com>:
>> that's true. i just want a debuger with Vim.....
>
> Me too... I don't see me changing to emacs any time soon (my hands
> aren't dextrous enough to cope with alt-ctrl-shift-etc), but I do wish
> there was more capability to have interaction with external processes
> / debugging support etc.
Somewhat ironically, in Vim manual section |design-speed-size| it says:
- Vim is a component among other components. Don't turn it into a
massive application, but have it work well together with other
programs.
But as the blog post says[1] Vim would play much better with other
programs if it didn't try to "re-implement the wheel inside the editor"
but had a support for asynchronous interaction with external processes.
Because of this feature Emacs plays much better with other programs.
Interesting blog post. After using Vim 4-5 years I have also eventually
switched to Emacs; it happened gradually during several months. My
reasons are partially the same as the blog writer's. Other reasons are
that Emacs just has many really cool features.
----------
[1] http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/
Teemu Likonen
>> http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/
> The main thing I think this blog post missed is the fact that we
> vi/vim fans think that modality is the whole point (not a drawback, as
> he seems to imply)!
You are wrong about the writer missing that point. The blog writer likes
the modality of Vim:
[...] [Vi/Vim] has got right a good deal of design choices. One is
the often debated modality. [...] In the case of Vim, modality is
good because it let you use powerful yet simple motions in command
mode, which can be easily combined with operator-pending commands.
I read his point being that modality has been _debated_ and argued as a
bad thing but it really isn't because after user has mastered it it
becomes really powerful - as we all know. The blog writer has used Vi or
Vim about ten years.
Raúl Núñez
On Tue, 18 Nov 2008 13:30:30 +0200, Teemu Likonen dixit:
> A. S. Budden (2008-11-18 07:58 +0000) wrote:
>
> > 2008/11/18 StarWing <weasl...@sina.com>:
> >> that's true. i just want a debuger with Vim.....
> >
> > Me too... I don't see me changing to emacs any time soon (my hands
> > aren't dextrous enough to cope with alt-ctrl-shift-etc), but I do
> > wish there was more capability to have interaction with external
> > processes / debugging support etc.
>
> Somewhat ironically, in Vim manual section |design-speed-size| it
> says:
>
> - Vim is a component among other components. Don't turn it into
> a massive application, but have it work well together with other
> programs.
>
> But as the blog post says[1] Vim would play much better with other
> programs if it didn't try to "re-implement the wheel inside the
> editor" but had a support for asynchronous interaction with external
> processes. Because of this feature Emacs plays much better with other
> programs.
I don't have a definite opinion about this issue of async interaction
with external processes (although this feature looks attractive to me),
but regarding spellchecking, it would be great to use one of the
available spell checkers instead of using Vim's own. Not a great
disadvantage, though, but...
> Interesting blog post. After using Vim 4-5 years I have also
> eventually switched to Emacs; it happened gradually during several
> months. My reasons are partially the same as the blog writer's. Other
> reasons are that Emacs just has many really cool features.
I have yet to discover an edition feature in Emacs that I would miss in
Vim (I must confess that I don't use the full power of Vim, anyway, so I
don't think I would ever use the full power of Emacs...), and some
Emacs things look weird to me (e.g. the major/minor modes vs. filetype
plugins in Vim), probably because I'm so used to Vim and so stranged to
Emacs. In addition to this, my brain now thinks in "modal", and I'm used
to use one key commands to perform most of my editing tasks, so starting
to use Ctrl-whatever for simple commands would be hard. And I hate LISP.
I simply don't see me using Emacs full time in the near future.
This said, I miss some things in GVim: antialiased fonts, faster
redrawing and better integration with GTK+. I've stopped using GVim for
those reasons: Vim on xfce4-terminal looks much better and it's more
readable and fast than GVim. Emacs, in its latest versions, has
antialiased fonts support and it's much faster redrawing the screen (on
the other hand, it is MUCH slower when starting up...).
So to say, I would like to have the look of "gedit" and the feel of
"Vim" ;)))
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 ...
James Kanze
> On Mon, Nov 17, 2008 at 11:16 AM, Xulxer <xul...@gmail.com> wrote:
> I could see using Emacs with viper mode
carpal tunnel syndrome in me, so it is out of the question.) In
practice, it doesn't work out that well, because some modes
(dired comes to mind) remap the keyboard, and they remap it with
standard emacs functionality in mind. So while you use j and k
for down and up in most windows, in a few, you'll need n and p.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
François Beaubert
> "Vim" ;)))
So have a look at Pida you won't be disappointed:
It's in heavy devlopment and soon a 0.6 release will be available
Most of the developers are on irc: #pida
Raúl Núñez
On Tue, 18 Nov 2008 15:30:46 +0100, François Beaubert dixit:
> > So to say, I would like to have the look of "gedit" and the feel of
> > "Vim" ;)))
>
> So have a look at Pida you won't be disappointed:
>
> http://pida.co.uk/
Usually I don't like IDE's (I prefer to do things my way), but I'll keep
an eye on PIDA. Thanks for pointing :)
A. S. Budden
Certainly looks very good: as soon as it works (and is easy to
install) on both Linux & Windows, I may well start using this more
actively. I use 50% Windows and 50% Linux, so I avoid anything that
isn't cross platform. It doesn't help that, even with cygwin (which I
prefer to avoid for GUI stuff), compiling stuff on Windows is a right
royal pain in the a**e.
Al
François Beaubert
Pida is lightweight, fast, easy to use and highly configurable with plugins
You use what you want to use, point.
Try it ...
And if you want to be on the bleeding edge have a look at the dev
version which will be the 0.6:
hg clone http://pida.co.uk/hg/ pida
cd pida
./tools/update_externals.sh
python setup.py build_ext -i
./run-pida.py
Best
Francois
2008/11/18 Raúl Núñez de Arenas Coronado <ra...@dervishd.net>:
François Beaubert
> Certainly looks very good: as soon as it works (and is easy to
> install) on both Linux & Windows, I may well start using this more
> actively.
A windows version is on the way ...
Best is to ask the developers on the mailing list or on irc
Sergey Khorev
>
> Pida is lightweight, fast, easy to use and highly configurable with plugins
> You use what you want to use, point.
François Beaubert
indeed, it's the same spirit but IMHO not as slick
Francois
Gene Kwiecinski
>one. It seems so un-unix and bad that VIM implements it's own
>spellchecker instead of giving me the freedom to use what spellcheck I
>like.
>What's the reasoning for not using external processes. Couldn't it just
>be added as a feature to get everyone happy?
Because it'd have to be done for the 27 incarnations of Windows, the 426
incarnations of *nix, for VMS, for Mac, for...
Anyone left out would no doubt complain, and adding something like this
might be a major rewrite of vim's "kernel" code, not just a fix or
add-on of a few lines of code.
How long would you be willing to wait for the next release, and put all
other bug-fixes and feature add-ons on hold until then?
For me, ':%!sort' is fine for my usage of "external processes", as I
don't try to shoehorn an editor into an IDE and whatever else, but
others' opinions may differ.
Charles Campbell
is based on syntax keywords and a dictionary.
Regards,
Chip Campbell
A. S. Budden
>
>>I believe that the issue of external processes interaction is a valid
>>one. It seems so un-unix and bad that VIM implements it's own
>>spellchecker instead of giving me the freedom to use what spellcheck I
>>like.
>
>>What's the reasoning for not using external processes. Couldn't it just
>>be added as a feature to get everyone happy?
>
> Because it'd have to be done for the 27 incarnations of Windows, the 426
> incarnations of *nix, for VMS, for Mac, for...
Certainly a problem...
>
> Anyone left out would no doubt complain, and adding something like this
> might be a major rewrite of vim's "kernel" code, not just a fix or
> add-on of a few lines of code.
>
> How long would you be willing to wait for the next release, and put all
> other bug-fixes and feature add-ons on hold until then?
I for one would be willing to wait as long as it takes if I knew that
this feature were coming.
Al
François Ingelrest
>
> Am Tuesday 18 November 2008 04:57:07 schrieb StarWing:
>> > because a firm choice in Vim is to ... (OK, I confess, I'm starting to
>> > beat a dead horse) ... not have support for interaction with external
>> > processes.
>>
>> that's true. i just want a debuger with Vim.....
> I believe that the issue of external processes interaction is a valid
> one. It seems so un-unix and bad that VIM implements it's own
> spellchecker instead of giving me the freedom to use what spellcheck I
> like.
>
> What's the reasoning for not using external processes. Couldn't it just
> be added as a feature to get everyone happy?
What would be the "killer application" if that kind of support was added?
I'm not against it, but I just don't see what I could do with it that
could change my life. I always see debugging as a possible
application, but personally I rarely use a debugger. The internal
spell checker is good enough for me, as long as it uses a good
dictionary. And for the rest, I always use a second shell.
Teemu Likonen
> For me, ':%!sort' is fine for my usage of "external processes", as I
> don't try to shoehorn an editor into an IDE and whatever else, but
> others' opinions may differ.
I don't want to argue against your preferences but I'd like to point out
that supporting asynchronous interaction with external processes is not
about being an IDE in itself. It's about being better player in the
"component among other components" game. This is the game that has been
claimed one of the traditional strengths of Vi and Vim, and is also one
of the design goals of Vim. Unfortunately this is supported only on very
simple level:
let output = system(program, input)
As a *side effect* asynchronous process interaction allows developing
IDE features like compiling in the background (with real-time "quickfix"
output in editor buffer), on-the-fly syntax checking for programming
languages, debugger integration etc. Whatever tools are out there can be
turned into an editor feature - by any user. Good thing is that it's
still about "the best tool for the job" ideology. Editor is just a
control panel for any given best tool.
Dominique Pelle
>
> Am Tuesday 18 November 2008 04:57:07 schrieb StarWing:
>> > because a firm choice in Vim is to ... (OK, I confess, I'm starting to
>> > beat a dead horse) ... not have support for interaction with external
>> > processes.
>>
>> that's true. i just want a debuger with Vim.....
> I believe that the issue of external processes interaction is a valid
> one. It seems so un-unix and bad that VIM implements it's own
> spellchecker instead of giving me the freedom to use what spellcheck I
> like.
>
> What's the reasoning for not using external processes. Couldn't it just
> be added as a feature to get everyone happy?
Regarding spell checking, the reasons for vim's implementation
are well explained in :help develop-spell
-- Dominique
Matthew Winn
<antoine.m...@gmail.com> wrote:
> I tried Emacs a couple of times, among other things because there's so
> much hype about it in the help for the "info" program. Never could make
> head or tail of it.
I tried Emacs and gave up on it because it required the use of ^S and
^Q, which on the hardware I was using were reserved for flow control.
The "help" Emacs offered was "get different hardware". I decided I
wanted nothing to do with software that was so arrogant it refused to
conform to what was at the time the dominant method of flow control.
Also, I have a certain amount of distaste for anything associated with
Richard Stallman.
--
Matthew Winn
703designs
> Also, I have a certain amount of distaste for anything associated with
> Richard Stallman.
Thomas
Bram Moolenaar
Thomas Koch wrote:
> Am Tuesday 18 November 2008 04:57:07 schrieb StarWing:
> > > because a firm choice in Vim is to ... (OK, I confess, I'm starting to
> > > beat a dead horse) ... not have support for interaction with external
> > > processes.
> >
> > that's true. i just want a debuger with Vim.....
> I believe that the issue of external processes interaction is a valid
> one. It seems so un-unix and bad that VIM implements it's own
> spellchecker instead of giving me the freedom to use what spellcheck I
> like.
>
> What's the reasoning for not using external processes. Couldn't it just
> be added as a feature to get everyone happy?
In the case of the spell checker: There is no spell checker available
that is fast enough to be used with Vim.
I've been thinking of making the Vim spellcheck code available as a
library, but simply don't have the time for it. It's superior to all
other spell checkers I know, especially when it comes to giving
suggestions. Only aspell comes close and it doesn't work for Unicode
(it converts the text to an 8-bit encoding before doing the actual
spellcheck).
--
There is a fine line between courage and foolishness.
Unfortunately, it's not a fence.
/// 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 ///
Teemu Likonen
> I tried Emacs and gave up on it because it required the use of ^S and
> ^Q, which on the hardware I was using were reserved for flow control.
> The "help" Emacs offered was "get different hardware". I decided I
> wanted nothing to do with software that was so arrogant it refused to
> conform to what was at the time the dominant method of flow control.
>
> Also, I have a certain amount of distaste for anything associated with
> Richard Stallman.
Sounds like quite long ago. I don't know about the documentation at that
time but Emacs' version control system says that the flow control issue
was addressed in 1992-02-07. The code has changed a bit after that and
the current code is mostly from 1994 - 1995 (by Richard Stallman).
Description of the function (M-x enable-flow-control):
enable-flow-control is an interactive autoloaded Lisp function in
`flow-ctrl'. (enable-flow-control &optional ARGUMENT)
Toggle flow control handling.
When handling is enabled, user can type C-s as C-\, and C-q as C-^.
With arg, enable flow control mode if arg is positive, otherwise
disable.
Luc Hermitte
"Bram Moolenaar" <Br...@moolenaar.net> wrote :
> I've been thinking of making the Vim spellcheck code available as a
> library, but simply don't have the time for it.
It could be really nice. As a matter of fact, today
I was wondering how I could replace firefox suggestions
engine with a better one (being better is not that uncommon)
like the one from aspell.
> It's superior to all
> other spell checkers I know, especially when it comes to giving
> suggestions. Only aspell comes close
I remember that aspell does quite interesting
things like considering the keyboard layout. Does
it means that vim suggestions engine also considers
this aspect ?
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
Tony Mechelynck
Any kind of LISP is cool? Not for me. Refrigerating maybe. If you want
Polish notation, give me FORTH. But in most cases a structured language
like Vimscript is just what I need.
Best regards,
Tony.
--
An Army travels on her stomach.
Tony Mechelynck
> Am Tuesday 18 November 2008 04:57:07 schrieb StarWing:
>>> because a firm choice in Vim is to ... (OK, I confess, I'm starting to
>>> beat a dead horse) ... not have support for interaction with external
>>> processes.
>> that's true. i just want a debuger with Vim.....
> I believe that the issue of external processes interaction is a valid
> one. It seems so un-unix and bad that VIM implements it's own
> spellchecker instead of giving me the freedom to use what spellcheck I
> like.
>
> What's the reasoning for not using external processes. Couldn't it just
> be added as a feature to get everyone happy?
>
> Best regards,
AFAIK, every application (Firefox, Thunderbird, SeaMonkey, but also
Konqueror, etc.) includes its own spell-checker (if it includes one at
all, of course). _Dictionaries_, OTOH, are installed as separate files,
which means that the user's choice applies to them.
Best regards,
Tony.
--
Graduate life: It's not just a job. It's an indenture.
bill lam
V
Just for the record, mutt can use external spell-checker such as
ispell. However I've never used that, instead spell checking is done
with vim when composing message that can give instant feedback on
typo.
That said, I can see vim 7.2 still flag all chinese characters as
typo.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩037 王昌齡 塞下曲
飲馬渡秋水 水寒風似刀 平沙日未沒 黯黯見臨洮
昔日長城戰 咸言意氣高 黃塵足今古 白骨亂蓬蒿
Tony Mechelynck
Each Chinese character is a "word" by itself, isn't it, so no spell
check is needed when typing Chinese text? Or do you have a Chinese spell
dictionary which rejects characters which cannot be used alone (e.g.
counting words maybe), unless thay are used in an acceptable context
(e.g. in the case of counting words: after a numeric hanzi and before a
noun of the proper category)?
Anyway, when spell-checking English text, I would expect hanzi glyphs to
be flagged as "non-English" regardless of which English dictionary you
are using. (Similarly for text in any non-CJK language.)
Best regards,
Tony.
--
Real programmers don't write in FORTRAN. FORTRAN is for pipe stress
freaks and crystallography weenies. FORTRAN is for wimp engineers who
wear white socks.
bill lam
> Each Chinese character is a "word" by itself, isn't it, so no spell
> check is needed when typing Chinese text? Or do you have a Chinese spell
> dictionary which rejects characters which cannot be used alone (e.g.
> counting words maybe), unless thay are used in an acceptable context
> (e.g. in the case of counting words: after a numeric hanzi and before a
> noun of the proper category)?
>
> Anyway, when spell-checking English text, I would expect hanzi glyphs to
> be flagged as "non-English" regardless of which English dictionary you
> are using. (Similarly for text in any non-CJK language.)
I'll be happy if it can distinguish between "non-english/french/...."
and "real typo".
There are characters which cannot be used alone, but they are very
rare so that they are be ignored altogether. An example that I know
is "pi pa", a music string instrument imported from north western
tribes.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩129 孟浩然 秦中感秋寄遠上人
一丘嘗欲臥 三徑苦無資 北土非吾願 東林懷我師
黃金燃桂盡 壯志逐年衰 日夕涼風至 聞蟬但益悲
Tony Mechelynck
[...]
> I'll be happy if it can distinguish between "non-english/french/...."
> and "real typo".
Isn't that where the suggested alternate spellings come into play? If
you type an English (or French or...) word with one letter replaced by
another, you ought to be able to find the correct spelling among the
"suggestions". If you type a hanzi (or a word in Cyrillic or devanagari
for that matter) in English (or French) text, there's of course no way
Vim can guess the "correct" English or French word by which to replace it.
See
:help z=
:help :spellr
Best regards,
Tony.
--
With a gentleman I try to be a gentleman and a half, and with a fraud I
try to be a fraud and a half.
-- Otto von Bismark
Efraim Yawitz
<antoine.m...@gmail.com> wrote:
>
>
> Any kind of LISP is cool? Not for me. Refrigerating maybe. If you want
> Polish notation, give me FORTH. But in most cases a structured language
> like Vimscript is just what I need.
>
Hansen, Mike
> Any kind of LISP is cool? Not for me. Refrigerating maybe. If
> you want
> Polish notation, give me FORTH. But in most cases a
> structured language
> like Vimscript is just what I need.
(LISP(Lost (In) (Stupid) (Parentheses)) =)
Tom Link
undergone any major changes for years. Nevertheless it's suitable to
do all sorts of things and it is quite stable.
elisp's weak spot is its dynamic binding. Otherwise it's cool and
practical (as proven for many years).
parentheses rock.
Noah
On Nov 18, 7:48 am, "Gene Kwiecinski" <gkwiecin...@dclab.com> wrote:
> >What's the reasoning for not using external processes. Couldn't it just
> >be added as a feature to get everyone happy?
>
> Because it'd have to be done for the 27 incarnations of Windows, the 426
> incarnations of *nix, for VMS, for Mac, for...
> Anyone left out would no doubt complain, and adding something like this
> might be a major rewrite of vim's "kernel" code, not just a fix or
> add-on of a few lines of code.
pseduo tty or async external process interface in Vim
is more of a stubborn attitude. "Expect" is pretty portable.
It runs on plenty of UNIX platforms and even on Windows.
Nobody is asking for all the feature of Expect in Vim.
I've worked with the C source code to the 'pty' module in Python.
It's not very complicated at all.
And like MANY other optional feature in Vim, it could be
enabled or disabled in the Configure script at build time.
Here are a few of the OPTIONAL features in Vim:
multibyte unicode support, scope, netbeans interface,
mouse support, Sun Visual Workshop, Sniff interface,
GUI (gvim), python, perl, tcl, ruby
run `./configure --help` for the full list.
--
Noah
Bram Moolenaar
Luc Hermitte wrote:
> "Bram Moolenaar" <Br...@moolenaar.net> wrote :
> > I've been thinking of making the Vim spellcheck code available as a
> > library, but simply don't have the time for it.
>
> It could be really nice. As a matter of fact, today
> I was wondering how I could replace firefox suggestions
> engine with a better one (being better is not that uncommon)
> like the one from aspell.
>
> > It's superior to all
> > other spell checkers I know, especially when it comes to giving
> > suggestions. Only aspell comes close
>
> I remember that aspell does quite interesting
> things like considering the keyboard layout. Does
> it means that vim suggestions engine also considers
> this aspect ?
It sounds nice, but I have no clue that this actually helps giving
better suggestions. One would need a large set of mistyped words and
what they should have been, for all supported languages, to find out.
I only have a short list for English.
Vim does keep a usage count, this helps to avoid suggesting words that
are rarely used. And uses sound folding, for languages where this is
implemented.
--
Bravely bold Sir Robin, rode forth from Camelot,
He was not afraid to die, Oh Brave Sir Robin,
He was not at all afraid to be killed in nasty ways
Brave, brave, brave, brave Sir Robin.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Tony Mechelynck
Ever had a look at FORTH? If, like me, you had, you'd know that
parentheses suck.
Don't
multiply(add(a, b), subtract(c, d))
but rather do
a b + c d - *
Much more elegant.
Or if you find it too terse, not understandable enough for someone
allergic to math (not that LISP be any better than Sanskrit either, if
you're allergic to math), then use good old COBOL:
ADD A B GIVING TEMP-1.
SUBTRACT D FROM C GIVING TEMP-2.
MULTIPLY TEMP-1 TEMP-2 GIVING RESULT.
No need to have learnt the language to understand what _this_ means.
Best regards,
Tony.
--
He was not in the least bit scared to be mashed into a pulp
Or to have his eyes gouged out and his elbows broken;
To have his kneecaps split and his body burned away
And his limbs all hacked and mangled, brave Sir Robin.
Teemu Likonen
> On 19/11/08 18:11, Tom Link wrote:
>> parentheses rock.
> parentheses suck.
Parentheses make it easy to see code in hierarchically structured units,
even the smallest parts. It's also easy to evaluate any such unit
interactively.
(function1 (function2 parameter))
In Emacs user just moves the cursor after any closing parentheses and
presses "C-x C-e". That unit is evaluated immediately and becomes part
of the current Emacs session. More concrete example:
(* 2 (+ 1 4))
Pressing "C-x C-e" when the cursor is after "(+ 1 4)" will print "5",
and after the last parentheses will print "10".
No matter what someone thinks about Lisp in general this suits extremely
well to programmable environments like Emacs where user can
interactively evaluate (and debug) code and it becomes part of the
environment right away.
Pento
I tried a lof of editors. No one of them have such feautres like have
vim.
May be in the future it will be geany [0], but at this moment geany is
lacks vs vim.
About emacs. I don't like lisp syntax and emacs keybindings.
[0] http://www.geany.org/
On Nov 17, 12:16 pm, Xulxer <xul...@gmail.com> wrote:
> Hi,
>
> perhaps someone is interested in the good features of the other great
> editor:
>
> http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/
>
> http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/
>
>
> Chris
Marc Weber
>
> As I thinks there is no full alternative to vim.
linux..
I guess there are three issues:
a) vim is not an ide (such as eclipse). So if you have to do Java
programming the best thing to do is get Eclipse and the vi-Plugin
(IMHO).. Why? Because some features can't be implemented in vim such
as a tree view and show which files contain errors.. Aeh.. ok it could
be done, like the file tree view. But you can no longer work with that
if you have thausands of files..
So I don't think vim should even try to achieve the same goals here.
Vim shines anyway if you want to make your php scripts write a stack
trace and ask vim to jump to the file containing the error..
Vim is prefect, reliable and fast here.
So here is nothing which can be improved. Eg I'm using vim to edit
.php files and i use Eclipse to debug them. You can't tell Eclipse use
tabs for the one project but spaces for the other! In vim that's
easy.
b) IDE-Features I've been missing:
Eclipse has some really nice features which I'm missing in vim.
Those are:
- outline
- opening resources
I've tried reemplementing both in vim the way I can, but they are not
as interactive as the features provided by Eclipse (filtering the list
while typing etc..)
The result is some regex like outline and glob open.
Eg the first one shows these lines when using the regex outline on
this email. You can then use enter to jump to one. That's much faster
then searching and jumping to the next because you see all occurences
at one glance.
34 - outline
39 The result is some regex like outline and glob open.
The same for glob open. You can use <m-g><m-o>pat* to get a list of
files within the current directory and choose one file. That's much
faster than :e **/*pat. On the other hand I'm really missing
g; text objects and such things in IDE's..
I wouldn't have had the time to implement them properly..
c) interfacing with external programs..
Having had a look at the vim-dev mailinglist today I've seen there is
a patch providing debugger integration. (I haven't tried it)..
But vim will never be able to show vars the way Eclipse debugger does.
(I've used the .php python debugger extension for some time.. but
Eclipse wins)
Anyway: What is really missing to start interfacing with external
programs? You can always use python and start some threads there.
That's what I've done in the run-task-in-background script. It works
nicely but it requires the vim client-server feature to run vim
commands in a synchronized manner which is only availible in gvim..
*Question*: How much effort would it be to make the pyhton vim.eval
command be synchronized so that it can be used within shell within a
python thread savely? What else is missing?
Using gvim I already restart the web server after background
compilation has finished automatically this way..
(Of course it doesn't have to by python, but its the language I do
know best after haskel, php, JavaScript and vimscript)
If someone has the perfect proposal I'd be willing to spend $200
so that someone can also implement it.
d) The *one* way to search
- for scripts or libraries
- update them
- distribute them
- customize them
- document them
- evaluate them (not only +1 / 0 / -1, but you should be able to give feedback easily!) [1]
- reusing code this way
that thing that vim is lacking but PHP, ruby etc all have (?)
Does this *one* way exist? I mean vim runs on linux, windows (maybe
cygwin).. so at least there must be some boilerplate code to handle
file pathes correctly in all cases (can this be done at all?)..
I'm using cygwin for that reason because it just works the way I'm
used to unless you want to parse compiler messages with C:\ in it..
If someone is interested in building up a "vim-framework" providing some
of the functions (background compilation, outline features, easy script
configuration setup, ..etc) let me know. I've already written an
alternative vim script distribution system figuring out dependencies
automatically so that autoloading can be exploitet fully.
To create an installer all you have to do is add a small comment and provide a list of
functions/ files which must be present. The dependencies are added
automatically based on occurences of foo#bar of functions beeing automatically loaded..
call vl#lib#vimscript_installer#create_installer#CreateInstaller( "vimlib_glob_open_installer_sourceme.vim"
\ , ["\" approximately something like ctrl-shift-r (open resource) of eclipse). I call it glob open." ]
\ , [ autoload_files['vl#ui#openFileFromList'] ]
\ )
Looking at my comments below you see one sentence a way to often "never got any feedback"..
So I'd like to improve that. Is there any way to make www.vim.org accept
comments from other users ?
I guess its time to join "Vim Online". I'll contact Scott about that.
I've uploaded some scripts to vim.org. I have to agree that some have not been too useful to others..
vl_sql : alias sensitive SQL completion (MySQL implemented):
http://www.vim.org/scripts/script.php?script_id=2376 (Rating 2/2, downloaded by 50)
never got any feedback
vimscript coding aids : some coding aids for writing vim scripts
http://www.vim.org/scripts/script.php?script_id=1963 (Rating -1/1, Downloaded by 142)
comment: It does two useful things: It can complete vim script functions and
it can automatically fix the autoload foo#bar# prefix after moving files.
It got that rating from the beginning. I never received any feedback on it.
I find it really useful (?)
QuickFixFilterUtil : filter matched files in the quickfix window manually/ drop .svn .hg _darcs
http://www.vim.org/scripts/script.php?script_id=1946 (Rating 0/0, Downloaded by 145 )
never got any feedback
runtaskinbackground : keep on working while compiling your project (I've talked about that above)
http://www.vim.org/scripts/script.php?script_id=1582 (Rating 0/0, Downloaded by 316)
never got any feedback
You can get the glob open script here, I haven't uploaded it yet
http://mawercer.de/~marc/vimlib_glob_open_installer_sourceme.zip
Have a look at
call vl#ui#openFileFromList#UI()
to see the default mappings
I'd like to remove these two
switch files : switch between .c and .h files or different path and same filename easily
http://www.vim.org/scripts/script.php?script_id=2072 (Rating -3/3, downloads: 126)
comment: it seems that it has been useful for me only..
yet another svn script : makes svn add /commit much easier from vim
http://www.vim.org/scripts/script.php?script_id=2071 (Rating -2/2, Downloaded by 130)
comment: has been useful for me only..
which is the way to do that?
Thanks for listening, happy vimming. Help improving things!
Sincerly
Marc weber
Luc Hermitte
> d) The *one* way to search
> - for scripts or libraries
> - update them
> - distribute them
> - customize them
> - document them
> - evaluate them (not only +1 / 0 / -1, but you should be able to
> give feedback easily!) [1]
> - reusing code this way
>
> that thing that vim is lacking but PHP, ruby etc all have (?)
>
> Does this *one* way exist? I mean vim runs on linux, windows (maybe
> cygwin).. so at least there must be some boilerplate code to handle
> file paths correctly in all cases (can this be done at all?)..
I have some old functions for that issue.
> I'm using cygwin for that reason because it just works the way I'm
> used to unless you want to parse compiler messages with C:\ in it..
>
> If someone is interested in building up a "vim-framework" providing
> some of the functions (background compilation, outline features, easy
> script configuration setup, ..etc) let me know.
I remember you had your framework online. Did you remove it?
Otherwise, yes. I'm quite interested by the library/framework
side of things ; even if there are a lot of redundant code
between our two frameworks. :)
Actually, I'm already maintaining a few more or less dependant
frameworks. See http://code.google.com/p/lh-vim/wiki/lhVimLib
for the more general one.
[I'm currently adding boost.bind-like functions that I'm planning
to use in order to simplify my refactoring plugin.]
> I've already written an
> alternative vim script distribution system figuring out dependencies
> automatically so that autoloading can be exploited fully.
That sounds interesting. Having to say "to use this plugin, you have
to install the following 4 vimballs", as I'm currently doing, does not
seem to be the right way. I'll have a look at your solution.
[...]
> Looking at my comments below you see one sentence a way to often
> "never got any feedback"..
Sometimes, I have some feedback. But that's quite rare. Unless our scripts
are exceptionally visible, we won't get much. Library oriented script seem
to me to be the worse kind: most of us prefer to reinvent the wheel instead
of relying on external library-plugins.
> So I'd like to improve that. Is there any way to make www.vim.org
> accept comments from other users ?
I did move my scripts to googlecode to track their evolutions, bugs and RfC.
May be, I'll move them back to vim.org if it eventually offer what has been
discussed in the other thread about vim.org and scripts hosting.
703designs
notation, but I think that what you've shown there is very confusing
because, like many others, I read left to right, not right to left.
Thomas
> never got any feedback
>
> vimscript coding aids : some coding aids for writing vim scriptshttp://www.vim.org/scripts/script.php?script_id=1963(Rating -1/1, Downloaded by 142)
> it can automatically fix the autoload foo#bar# prefix after moving files.
> It got that rating from the beginning. I never received any feedback on it.
> I find it really useful (?)
>
> never got any feedback
>
> runtaskinbackground : keep on working while compiling your project (I've talked about that above)http://www.vim.org/scripts/script.php?script_id=1582 (Rating 0/0, Downloaded by 316)
> never got any feedback
>
> You can get the glob open script here, I haven't uploaded it yethttp://mawercer.de/~marc/vimlib_glob_open_installer_sourceme.zip
> call vl#ui#openFileFromList#UI()
> to see the default mappings
>
> I'd like to remove these two
> switch files : switch between .c and .h files or different path and same filename easily
>
> yet another svn script : makes svn add /commit much easier from vim
Marc Weber
You can get it from git://mawercer.de/vl_repo.
(You all may also push your own branches there (even if they contain your scripts).. Just don't put big binaries up!)
I'm using this .sh function to recreate all installers. You have to replace
*/vl_repo by the location of the repository.
createVimInstallers ()
{
rm -fr /tmp/installer;
mkdir /tmp/installer;
cd /tmp/installer;
gvim -v --noplugin -c "set runtimepath+=~/vl_repo" -c "silent! source /home/marc/mwr/vl_repo/autoload/vl/lib/vimscript_installer/create_installer_examples.vim" -c "silent! call vl#dev#vimscript#vl_create_docs#CreateDocumentationFromDir('/home/marc/mwr/vl_repo/', '/tmp/htmldocs')" -c "echo 'ready'";
for i in *;
do
zip ${i/.vim/.zip} $i;
done
}
Be aware that half of the code is rubbish.
(We can talk about wether , should be the beginning of a line as well
It just happens that I look more often at the beginnings than at the end.
That's why I like it :-)
Eg I've written my own abstraction over quickfix:
let formats = {
\ 'js' : [
\ '%E%f:%l: %m'
\ , '%-C:%l: %s'
\ , '%Z%s:%p^'
\ ],
[..]
which does automatically qoute the "," etc.. Because I never can
remember them.
It can be used like this: (this will do syntax checking of php files when writing it.. terrible useful)
augroup PHP
autocmd bufread,bufnewfile *.php* setlocal ft=php
autocmd bufwritepost *.php* silent! call vl#lib#quickfix#runtaskinbackground#RunInBGQF(['php','-l', expand('%')],{ 'efm' : 'php', 'onFinish' : 'cw', 'loadErrorCmd' : 'cfile' })
augroup end
Of course the documentation thing is higly experimental and we can
change that. Ping me on irc (MarcWeber) if you have some free minutes so
that I can help you getting started. I'm also willing to remove all the rubbish..
The German encyclopedia Brockhaus doesn't mention vim at all. It only knows
about the 30 year old vi! But it lists emacs as "the linux editor" *lol*..
It doesn't know that vim has been awarded serveral times..
> Sometimes, I have some feedback. But that's quite rare. Unless our scripts
> are exceptionally visible, we won't get much. Library oriented script seem
> to me to be the worse kind:
But it will be the only thing which will let us grow and enhance.
Because reading a library which is already well written and documented
can teach you very much.
> I did move my scripts to googlecode to track their evolutions, bugs and RfC.
> May be, I'll move them back to vim.org if it eventually offer what has been
> discussed in the other thread about vim.org and scripts hosting.
I've missed that thread. We don't need much. *One* git repository would be
enough. I can host it for free or we can use github..
Sincerly
Marc Weber
Marc Weber
>
> About that Forth snippet: I only program in languages with infix
> notation, but I think that what you've shown there is very confusing
> because, like many others, I read left to right, not right to left.
Marc Weber
bill lam
>
> On 19/11/08 18:11, Tom Link wrote:
> >> (LISP(Lost (In) (Stupid) (Parentheses)) =)
> >
> > Come on folks. The elisp dialect is a pretty old one that AFAIK hasn't
> > undergone any major changes for years. Nevertheless it's suitable to
> > do all sorts of things and it is quite stable.
> >
> > elisp's weak spot is its dynamic binding. Otherwise it's cool and
> > practical (as proven for many years).
> >
> > parentheses rock.
>
> Ever had a look at FORTH? If, like me, you had, you'd know that
> parentheses suck.
>
> Don't
>
> multiply(add(a, b), subtract(c, d))
>
> but rather do
>
> a b + c d - *
>
> Much more elegant.
>
Actually it is personal preference. I would write it as
(a+b)*c-d
in an APL-ish style that evaluate from right to left. No! APL is not
dead or used only by dinosaurs. Same myth as vi.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩272 韋應物 滁州西澗
獨憐幽草澗邊生 上有黃鸝深樹鳴 春潮帶雨晚來急 野渡無人舟自橫
Tony Mechelynck
> About that Forth snippet: I only program in languages with infix
> notation, but I think that what you've shown there is very confusing
> because, like many others, I read left to right, not right to left.
>
> Thomas
Forth is actually left-to-right, it describes the actions to be executed:
a b + c d - *
means:
a Push the value of variable a onto the stack.
b Push the value of variable b onto the stack.
+ Pop the top two stack values, and push their sum.
c Push the value of variable c onto the stack.
d Push the value of variable d onto the stack.
- Pop the top two stack values, subtract the former stack-top from the
former second-from-top, and push the result.
* Pop the top two stack values, and push their product.
Mathematicians call that reversed-Polish notation or RPN. After running
that, you are left with, on top of the stack, what is usually
represented as (a+b) * (c-d) in "algebraic" notation.
Best regards,
Tony.
--
"We don't care. We don't have to. We're the Phone Company."
Tom Link
> to install the following 4 vimballs", as I'm currently doing, does not
> seem to be the right way.
Does your installer provide some sort of version management? To me
this sounds a little bit like Windows installers vs. linux/bsd-type of
package management.
I guess I'd much rather prefer dependency handling (ie automatic
downloading & installation of dependencies) in vimball.
> Library oriented script seem
> to me to be the worse kind: most of us prefer to reinvent the wheel instead
> of relying on external library-plugins.
prior to vim7. A second reason probably is the lack of automatic
dependency handling.
Tom Link
>
> a b + c d - *
programming embedded devices etc.
I guess you also like factor[1].
[1] http://factorcode.org
Orestis Markou
>
> As a *side effect* asynchronous process interaction allows developing
> IDE features like compiling in the background (with real-time "quickfix"
> output in editor buffer), on-the-fly syntax checking for programming
> languages, debugger integration etc. Whatever tools are out there can be
> turned into an editor feature - by any user. Good thing is that it's
> still about "the best tool for the job" ideology. Editor is just a
> control panel for any given best tool.
>
I second this. Having developed PySmell (a python auto-completion
library that works with many editors), I would really like to be able
to better integrate it into vim. Right now I have to do a lot of work
just-in-time, which prevents me from doing potentially expensive
operations.
If this was implemented, and if it meshed nicely with Python, I could do these:
* On the fly syntax and style checking for Python (with PyFlakes and friends)
* Awesomely fast auto-complete, continuously updated as you edit your project
* Run tests, fix failures as they happen.
I'm sure other people have ideas like these, and implementing a
background process integration would enable them to realize them.
Orestis Markou
Marc Weber
>
> > That sounds interesting. Having to say "to use this plugin, you have
> > to install the following 4 vimballs", as I'm currently doing, does not
> > seem to be the right way.
>
> @Marc Weber:
> Does your installer provide some sort of version management? To me
> this sounds a little bit like Windows installers vs. linux/bsd-type of
> package management.
Are you talking about changing
call a#b#foo()
to
a#b#version0_1#foo() ?
So that you'll end up having
a#b#version0_1.vim
a#b#version0_2.vim
a#b#version0_3.vim
a#b#version0_4.vim
> I guess I'd much rather prefer dependency handling (ie automatic
> downloading & installation of dependencies) in vimball.
Is this because you've used vimball a lot of times before?
Of course I'd like to use "my tools" I've been using for years as well.
Have you actually tried installing one of those installers?
If you don't trust me run strace -o /tmp/trace -f vim, then soucre the
file. This way you can lookup all files which have been modified.
(I'm not sure wether it works on windows yet..)
Tom, if you really want to help make me understand the features of
vimball you like and you need which are lacking in my installer.
You can install each "package" to another directory so that you can
remove that easily if you don't like the script. What else do you really
need? You'll be notified for updates *before* files are overridden.
So you can't loose data. So give it a try and give some feedback so that
we can choose the best tool to enhance. But I'd like to see more than
just "I'd prefer vimball for no obvious reasons because I feel so"..
I'm willing to clean up my library and adopt it to community needs..
But I'll only start to do so if there is valuable feedback because
I don't have time to waste either. If I've missed the point retell me.
I"ll try to improve to get it the first time in the future.
> I think one reason for this is that there was no autoload facility
> prior to vim7. A second reason probably is the lack of automatic
> dependency handling.
It's there you just have to try it once. I even have implemented a proof
of concept to download missing files if you just tell vim to get all
dependencies of file X based on autoload functions..
Of course if you have
function foo()
if false
call a#b#c()
else
call d#e#f()
endif
endfun
a/b.vim and d/e.vim will be downloaded.. There is no way for the script
to know..
By the way if we manage to separate the user interface from the
implementation we can also implement kind of garbage collector removing
no longer referenced files. That's what nixos is doing with packages and
its the only way to go (IMHO)..
Sincerly
Marc Weber
Tom Link
I was just wondering what would happen if you installed package A
consisting of
foo.vim (version 2)
bar.vim
and then installed package B containing the files
foo.vim (version 1)
boo.vim
Then I remember that questions older windows installers used to ask:
"Do you really want to overwrite shdkishd.dll with shdkishd.dll".
The vimball approach would be to have three separate packages A, B,
and foo. If you wanted to update foo, you wouldn't have to touch
packages A and B. With your approach, you'd have to update the
installers for A and B. But maybe I got it all wrong and maybe there
is an obvious solution for that. And maybe such questions would become
obsolete anyway with the use of git.
One thing though. You use start and end markers. How do you protect
against end markers accidentally showing up in the file? Vimball uses
line counts for this. One solution would be to insert a finish
statement after the loader and to not comment out the markers, I
guess. IMHO line counts could help to simplify the loader though
because you could then simply use getline(from, from + count) to
extract the file contents.
I'll check your libraries out.
BTW I took the liberty to re-implement your outline.vim in ttoc[1],
which does some dynamic filtering.
[1] http://www.vim.org/scripts/script.php?script_id=2014
Jack Donohue
Yes, back in the day when people used hand held calculators, there were
great religious wars about RPN used by HP and the other way used by
everybody else. But like anything else, if you had an HP calculator, you
got used to it pretty quick and actually grew to like it.
Jack
Charles Campbell
>> a#b#version0_1#foo() ?
>>
>
> I was just wondering what would happen if you installed package A
> consisting of
>
> foo.vim (version 2)
> bar.vim
>
> and then installed package B containing the files
>
> foo.vim (version 1)
> boo.vim
>
> Then I remember that questions older windows installers used to ask:
> "Do you really want to overwrite shdkishd.dll with shdkishd.dll".
>
> The vimball approach would be to have three separate packages A, B,
> and foo. If you wanted to update foo, you wouldn't have to touch
> packages A and B. With your approach, you'd have to update the
> installers for A and B. But maybe I got it all wrong and maybe there
> is an obvious solution for that. And maybe such questions would become
> obsolete anyway with the use of git.
>
" GetLatestVimScripts: ...
lines, one for each package their plugin needs. The next
:GLVS
will then go and acquire all of them (assuming they're out-of-date).
Regards,
Chip Campbell
Marc Weber
>
> Tom Link wrote:
> >> a#b#version0_1#foo() ?
> >>
location to save the files (like g:vimball_home ?).
However it's not a question about vimball, but a question about how to
identify a function Foo of lib version 1 or 2.
So I don't see how vimball can protect against that?
Example:
bundle 1:
fun a#Foo()
" version1
enfun
bundle 2:
fun a#Foo()
" version2
enfun
So which function is used when running call a#Foo()?
That depends on your runtimepath settings.
The only way to protect against that is using
bundle 1:
fun a#V1#Foo()
" version1
enfun
bundle 2:
fun a#V2#Foo()
" version2
enfun
and call a#V1#Foo() or a#V2#Foo()
But that is totally independant of the installer system.
So this is the only way to go. But even then the meaning of global vars
might change. So We must add verion information as well..
I agree that the way vimball does add the files is better by adding line
counts. You're right. It shouldn't be much work to ask my dependency
analysis system create .vba files.
> > and foo. If you wanted to update foo, you wouldn't have to touch
> > packages A and B.
Then you still don't have any guarantee that it works, see above.
>Tom wrote
>BTW I took the liberty to re-implement your outline.vim in ttoc[1],
>which does some dynamic filtering.
> [1] http://www.vim.org/scripts/script.php?script_id=2014
Tom! Awesome! Thanks for pointing me to it..
Would you like to join our effort by adding this script in the near
future after figuring out which is the best way mantain a global vim
library ?
Also see my next post
Marc