New features to vote on and sponsoring
Bram Moolenaar
Hello Vim users,
I have added two items to vote on:
- add collaborative editing: changes made to a file show up in another
Vim in a second
- add flexible tab stops, can be used for tables
Registered users and sponsors can change their votes. See this page for
info: http://www.vim.org/sponsor/index.php
Note that I'm very busy, I have little time for new features at the
moment. I can't make promises about when a new feature will be added.
I'm glad to report that in 2007 I have received a total of 9000 euro.
All this money has been sent to Uganda, to help the children in Kibaale.
Thanks to all the Vim supporters!
The project is doing well. We expect to have 766 children in nursery,
primary and secondary school when the it starts again in a couple of
weeks. More children are studying in other schools.
One of the big projects for 2008 is building a new clinic. The number
of patients has been increasing steadily, the current building is worn
out and too small. The plans have been approved, the builders are
expected to start next month.
More information about the project on the ICCF website:
http://iccf-holland.org
Happy Vimming!
--
It is illegal for anyone to give lighted cigars to dogs, cats, and other
domesticated animal kept as pets.
[real standing law in Illinois, United States of America]
/// 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 ///
Nico Weber
> Vim in a second
Do you mean "changes to a file" (ie. contents are only synced on file
write) or do you mean "changes to a buffer" (ie collaborative real-
time editing over the web)?
Thanks,
Nico
Bram Moolenaar
Nico Weber wrote:
You are right, it should be "buffer". I'll change it.
Not sure about the "over the web" part. This won't be easy to implement
locally anyway.
--
Biting someone with your natural teeth is "simple assault," while biting
someone with your false teeth is "aggravated assault."
[real standing law in Louisana, United States of America]
George V. Reilly
> Nico Weber wrote:
>
> > > - add collaborative editing: changes made to a file show up in another
> > > Vim in a second
> >
> > Do you mean "changes to a file" (ie. contents are only synced on file
> > write) or do you mean "changes to a buffer" (ie collaborative real-
> > time editing over the web)?
>
> You are right, it should be "buffer". I'll change it.
>
> Not sure about the "over the web" part. This won't be easy to implement
> locally anyway.
Wow, this seems like an enormous can of worms. Do you have a
centralized server or a peer-to-peer architecture? Discovery.
Authentication. Security. Session management. Server farms.
Distributed transactions. Failover. Recovery. Cross-platform. Buzzword
bingo.
I'm not saying that it can't be done, but it moves the Vim codebase in
a direction that it's never gone before.
Is there some existing open source project that can be leveraged to
solve a lot of these problems? Or some Google project?
--
/George V. Reilly
http://www.georgevreilly.com/blog
Nico Weber
>>> file
>>> write) or do you mean "changes to a buffer" (ie collaborative real-
>>> time editing over the web)?
>>
>> You are right, it should be "buffer". I'll change it.
>>
>> Not sure about the "over the web" part. This won't be easy to
>> implement
>> locally anyway.
What would this be good for if it works only locally then?
> Wow, this seems like an enormous can of worms. Do you have a
> centralized server or a peer-to-peer architecture? Discovery.
> Authentication. Security. Session management. Server farms.
> Distributed transactions. Failover. Recovery. Cross-platform. Buzzword
> bingo.
Distributed transactions, failover, recovery, cross-platform and
within limits even discovery, authenticaion and security are problems
you have to deal with locally as well. (I'm not saying doing this over
the web doesn't make it quite a bit harder, but I don't see any value
in this feature without web support.)
>
Nico
Ben Schmidt
>>> implement
>>> locally anyway.
>
> What would this be good for if it works only locally then?
I'm sure locally includes ssh sessions which can provide across-the-web
functionality. Just have to have two people logged into the same machine, quite
possibly both via ssh. That's how I'd expect to use it; log into someone else's
machine and somehow attach to their Vim process to help them edit a file.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Gary Johnson
> >>> Not sure about the "over the web" part. This won't be easy to
> >>> implement
> >>> locally anyway.
> >
> > What would this be good for if it works only locally then?
>
> I'm sure locally includes ssh sessions which can provide
> across-the-web functionality. Just have to have two people logged
> into the same machine, quite possibly both via ssh. That's how I'd
> expect to use it; log into someone else's machine and somehow
> attach to their Vim process to help them edit a file.
That makes sense, especially since you can then let ssh take care of
all the security and authentication issues. If that's the usage
model, though, then I think 'screen' could be used to provide the
multiuser, simultaneous editing capability, and vim would not have
to be modified at all.
Regards,
Gary
Charles E. Campbell, Jr.
I'd like Decho (from my debugging plugin) to be able to report what
line/file/function it was called from so I can relate Decho output to
where it was generated. Something like the following would do the trick:
v:call_line -- would hold the line number (either the absolute line
number or like echoerr reports, function-relative) of what called the
current function
v:call_file -- would hold the name of the file (if absolute line number
is used for v:call_line)
v:call_function -- would hold the name of the calling function (if
function-relative line number is used for v:call_line)
I'm afraid that I didn't see anything quite like that available. Its
like echoerr, but echoerr only need report where *it* was called. The
stuff above would probably necessitate recording what echoerr knows but
at the point of the call. I suppose these variable values would need to
be placed on a stack to maintain validity when function calls a function
calls a function, and then the deepest one returns.
What'ch'all think? (my famous line before getting shot down)
Chip Campbell
Zdenek Sekera
Excellent suggestion IMHO, very useful, immediately usable.
And it may not be all that hard to implement.
---Zdenek
Diwaker Gupta
> solve a lot of these problems? Or some Google project?
IMHO Gobby is one of the best out there: free, open source, real time
collaboration: http://gobby.0x539.de
Diwaker
--
http://floatingsun.net/
krischik
> Hello Vim users,
>
> I have added two items to vote on:
>
> - add collaborative editing: changes made to a file show up in another
> Vim in a second
> - add flexible tab stops, can be used for tables
plugin in Eclipse"? Do you enjoy torturing us poor eclipse users?
Just to clarify: we don't use Eclipse because we love to - we have to
use Eclipse because it is a company strategic tool (At least I expect
it is the case with quite a few of us + voters). And there you go
ahead and destroy our last hope: a fully working Vim-Eclipse-Plugin!
Please don't be cruel - rethink you vote. And it won't be taking that
much time of Bram either - most of the work needed is done in the
VimPlugin [1] and Eclim [2] project.
Martin
[1] http://vimplugin.sourceforge.net/wiki/pmwiki.php
[2] http://eclim.sourceforge.net/index.html
Milan Vancura
Bram, do you mean Matthew Winn's patch? It would be super! I hope that as it
works, the amount of work to push it to production state will be small and this
feature will be be included in vim even without any extra votes ;-)
> - add collaborative editing: changes made to a file show up in another
> Vim in a second
for me, just the ability to make a diff between current buffer and the
corresponding file on the disk would be suficient. (and add it as a next item
to a dialog "File was modified externaly: [O]K, [L]oad the file...[S]how diff")
Milan Vancura
Ingo Karkat
> for me, just the ability to make a diff between current buffer and the
> corresponding file on the disk would be suficient. (and add it as a next item
> to a dialog "File was modified externaly: [O]K, [L]oad the file...[S]how
> diff")
>
> Milan Vancura
That's possible with a VIM script, see http://vim.wikia.com/wiki/VimTip1030
Having this built-in and added to the mentioned dialog would be nice, though.
-- regards, ingo
/^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
krischik
> corresponding file on the disk would be suficient. (and add it as a next item
> to a dialog "File was modified externaly: [O]K, [L]oad the file...[S]how diff")
Martin
Matthew Winn
wrote:
> > - add flexible tab stops, can be used for tables
>
> Bram, do you mean Matthew Winn's patch? It would be super! I hope that as it
> works, the amount of work to push it to production state will be small and this
> feature will be be included in vim even without any extra votes ;-)
It's slightly buggy at the moment, in that it doesn't correctly update
the global values. I need to bring my Linux machine up and have a look
at it.
Also, it uses the same tabstops over an entire file. An extended idea
is to find some way of specifying different tab widths at different
parts of the same file, but that means a heap of empty cans and worms
all over the place.
--
Matthew Winn
Zdenek@gmail
> -----Original Message-----
> From: vim...@googlegroups.com [mailto:vim...@googlegroups.com] On
> Behalf Of Matthew Winn
> Sent: 16 January 2008 13:55
> To: vim...@vim.org
> Subject: Re: New features to vote on and sponsoring
>
>
> On Wed, 16 Jan 2008 11:46:46 +0100, Milan Vancura <mi...@ucw.cz>
> wrote:
>
> > > - add flexible tab stops, can be used for tables
> >
> > Bram, do you mean Matthew Winn's patch? It would be super! I hope
> that as it
> > works, the amount of work to push it to production state will be
> small and this
> > feature will be be included in vim even without any extra votes ;-)
>
Very much so.
> It's slightly buggy at the moment, in that it doesn't correctly update
> the global values. I need to bring my Linux machine up and have a look
> at it.
>
Have a go at it, this is an excellent feature of yours!
> Also, it uses the same tabstops over an entire file. An extended idea
> is to find some way of specifying different tab widths at different
> parts of the same file, but that means a heap of empty cans and worms
> all over the place.
Very true :-)!
But it would so nice.
---Zdenek
Richard Hartmann
> - add collaborative editing: changes made to a file show up in another
> Vim in a second
Unless this is done in full, screen -x is probably better suited. I have to
agree that this would be great for mentoring people, though. And yes, I
know about the downsides of screen -x, i.e. only one cursor, no
parallel editing.
> - add flexible tab stops, can be used for tables
> > Also, it uses the same tabstops over an entire file. An extended idea
> > is to find some way of specifying different tab widths at different
> > parts of the same file, but that means a heap of empty cans and worms
> > all over the place.
Yes, yes, yes and yes. I will move my votes accordingly when I get
home.
Richard
Ben Schmidt
> I think it'd be a small thing -- but only Bram knows for sure.
>
> I'd like Decho (from my debugging plugin) to be able to report what
> line/file/function it was called from so I can relate Decho output to
> where it was generated. Something like the following would do the trick:
I personally would think that having a function that returns the call stack as a
list would be a better interface for this, but agree it could be handy info to
have for plugin writers and for debugging vimscript generally.
This should probably have been a new thread.
Ben Schmidt
+1 (not registered).
Ben Schmidt
>> Bram, do you mean Matthew Winn's patch? It would be super! I hope that as it
>> works, the amount of work to push it to production state will be small and this
>> feature will be be included in vim even without any extra votes ;-)
>
> It's slightly buggy at the moment, in that it doesn't correctly update
> the global values. I need to bring my Linux machine up and have a look
> at it.
>
> Also, it uses the same tabstops over an entire file. An extended idea
> is to find some way of specifying different tab widths at different
> parts of the same file, but that means a heap of empty cans and worms
> all over the place.
I think this is a much bigger problem than tabstops, and not worth addressing
until a true and general solution can be found. The problem is basically that of
having 'context-local' option settings, i.e. options that aren't global, nor local
to a buffer or window, but local to a part of a file. Vim has no way of doing this
though there are a number of occasions where it would be useful, and as you say
there are many cans of worms if this is pursued.
And, to be honest, the need for this is small. If a file uses different width tab
stops for different parts of the file it would either be (1) Vim-specific and
reliant on the Vim variable tabs feature or (2) some mish mash of files that
should be in separate files anyway (i.e. somebody probably catted two different
datafiles together) or (3) use spaces not tabs anyway.
In those rare cases, it's no big deal to change the tabstop settings to work on
the part of the file you're interested in, IMHO, especially if the AutoTabs
command (I forget who provided this) is updated to accept a range (I have been
meaning to do this as it does annoy me that it doesn't at present; often I have a
small amount of paragraph text/comments with no tabs at all followed by a table
and at present the comments push the first tab to the right side of the screen all
the time, and so I delete the comments, run AutoTabs and replace them; would be
much better to select the table and run AutoTabs on just that part).
Mark Waggoner
if has("vartabs")
function! AutoVariableTabstop(line1,line2,...)
let extra = 0
if a:0 > 0
let extra = a:1
endif
let i = a:line1
let tabs = []
while i <= a:line2
let fields = split(getline(i),"\t",1)
let i = i + 1
let f = 0
while f < len(fields)
let l = strlen(fields[f])+1+extra
if (len(tabs) <= f)
call add(tabs,l)
else
if (l > tabs[f])
let tabs[f] = l
endif
endif
let f = f + 1
endwhile
endwhile
execute "set vts=" . join(tabs,",")
endfunction
command! -nargs=? -range=% AutoTabs call AutoVariableTabstop(<line1>,<line2>,<args>)
endif
Charles E Campbell Jr
>(snip)
>Also, it uses the same tabstops over an entire file. An extended idea
>is to find some way of specifying different tab widths at different
>parts of the same file, but that means a heap of empty cans and worms
>all over the place.
>
>
>
You'd probably need to use something like folding's markers (ie. {{{1,
etc). Perhaps ( <<<1,3,10,20 ). Can't say I'd use it, though, myself,
but you never know. That marker suggestion above may conflict with cvs
conflict marks, so it may not be the best choice.
Regards,
Chip Campbell
Matt Wozniski
>
> Charles E. Campbell, Jr. wrote:
> > I think it'd be a small thing -- but only Bram knows for sure.
> >
> > I'd like Decho (from my debugging plugin) to be able to report what
> > line/file/function it was called from so I can relate Decho output to
> > where it was generated. Something like the following would do the trick:
>
> I personally would think that having a function that returns the call stack as a
> list would be a better interface for this, but agree it could be handy info to
> have for plugin writers and for debugging vimscript generally.
>
> This should probably have been a new thread.
>
> Ben.
function C()
echo expand("<sfile>")
endfunction
function B()
echo expand("<sfile>")
call C()
endfunction
function A()
echo expand("<sfile>")
call B()
endfunction
call A()
results in this being printed:
function A
function A..B
function A..B..C
So, you can easily make a function yourself returning the callstack,
something like:
function! CallStack()
return split(substitute(expand("<sfile>"), '^\S\+\s', '', ''), '\.\.')
endfunction
HTH,
~Matt
Charles E Campbell Jr
If this is intended to address the topic for debugging ... just what
line in the functions are A, B, and C called from?
Regards,
Chip Campbell
Ben Schmidt
>
> function A
> function A..B
> function A..B..C
>
> So, you can easily make a function yourself returning the callstack,
> something like:
>
> function! CallStack()
> return split(substitute(expand("<sfile>"), '^\S\+\s', '', ''), '\.\.')
> endfunction
That's cool; I didn't realise <sfile> behaved like that.
But what I was envisaging was something richer, i.e. with line numbers and source
file as Chip had suggested.
Dasn
>
>> - add collaborative editing: changes made to a file show up in another
>> Vim in a second
>
>Unless this is done in full, screen -x is probably better suited. I have to
>agree that this would be great for mentoring people, though. And yes, I
>know about the downsides of screen -x, i.e. only one cursor, no
>parallel editing.
>
>
Multi-cursor parallel editing does make sense, which reminds me the Hex
editing in the hex workshop and ultra edit :).
--
Dasn
Mikolaj Machowski
> Hello Vim users,
>
> I have added two items to vote on:
>
> Vim in a second
>
I'd like to see something simpler(?): better command line completion of
built-in commands. You can script user defined commands as you wish to
perform all magic but completion of many built-in commands is really
dumb.
For example I am working lately with "Tab Separated Values". When I try
to insert Tab into regular expression of vimgrep Vim constantly tries to
resolve it to file name. I have to resort to <C-V><C-I>.
m.
Tony Mechelynck
To search for a hard tab, use \t in the pattern.
Currently, :command can have at most one -complete= parameter. I suspect this
unicity also applies to builtin commands.
Best regards,
Tony.
Matthew Winn
<v...@mwinn.powernet.co.uk> wrote:
> On Wed, 16 Jan 2008 11:46:46 +0100, Milan Vancura <mi...@ucw.cz>
> wrote:
>
> > > - add flexible tab stops, can be used for tables
> >
> > Bram, do you mean Matthew Winn's patch? It would be super! I hope that as it
> > works, the amount of work to push it to production state will be small and this
> > feature will be be included in vim even without any extra votes ;-)
>
> It's slightly buggy at the moment, in that it doesn't correctly update
> the global values. I need to bring my Linux machine up and have a look
> at it.
Here's a new version of my patch, against 7.1.230.
It's no longer the case that setting ts sets vts and vice versa.
It wasn't intuitive and dealing with setglobal and setlocal was too
much of a pain. Now the new options work in a similar way to the
relationship between wrapmargin and textwidth: if a new option (vts
or vsts) is set it hides the effect of the older option (ts or sts).
Setting a new option to an empty string unhides the basic option.
The new code is compiled in for big versions of Vim and above, or
if FEAT_VARTABS is defined.
This has been quite a large internal change so don't be tempted to
patch a global system Vim used by many people unless you have a quick
way to get back to an older version.
tabstop.src.patch is the patch for the source and tabstop.doc.patch
is the patch for the help files. Also included are tests, named as
"test99" so they don't conflict with any normal tests. (To run the
tests do "make test99.out" in the testdir.)
--
Matthew Winn
Ben Schmidt
And maybe I'm just dumb, but isn't auto-complete on a regular expression a bit of
a silly idea?! If it's so obvious from what you've already typed what it should be
completed to, you probably already have enough typed there to do the search...
Inserting <Tab> as ^I isn't auto-complete, but lack thereof, and \t, as Tony
points out, is a better way of doing that anyway, even though it involves pressing
an extra key. Another way of getting around it would be to use a different key to
<Tab> for your autocomplete (if there's a key you need to enter less often)!
Mikolaj Machowski
> Tony Mechelynck wrote:
> > Mikolaj Machowski wrote:
> >> Dnia Thursday 17 of January 2008, Bram Moolenaar napisał:
> >>> Hello Vim users,
> >>>
> >>> I have added two items to vote on:
> >>>
> >>> - add collaborative editing: changes made to a file show up in
> >>> another Vim in a second
> >>> - add flexible tab stops, can be used for tables
> >>
> >> I'd like to see something simpler(?): better command line completion
> >> of built-in commands. You can script user defined commands as you
> >> wish to perform all magic but completion of many built-in commands is
> >> really dumb.
> >>
> >> For example I am working lately with "Tab Separated Values". When I
> >> try to insert Tab into regular expression of vimgrep Vim constantly
> >> tries to resolve it to file name. I have to resort to <C-V><C-I>.
> >>
> >> m.
> >
> > To search for a hard tab, use \t in the pattern.
> >
> > Currently, :command can have at most one -complete= parameter. I
> > suspect this unicity also applies to builtin commands.
>
> And maybe I'm just dumb, but isn't auto-complete on a regular expression
> a bit of a silly idea?!
That is the point. I don't want completion at this moment.
> If it's so obvious from what you've already
> typed what it should be completed to, you probably already have enough
> typed there to do the search...
No.
m.
ap
Completing
with '^J' is useless in 99% of my standard use-cases. I believe,
ultimately
the completion should be configurable like for custom-commands. That
way everybody can have it the way he wants.
Is this becoming a wishlist ?
:b[dw][np] -- Delete/Wipe buffer and open next/previous one w/o
closing any
tabs/windows
Scanning the votelist, it appears that it is a bit inhomogeneous.
The topics range from 1-week to in-the-lifetime-achievement-class.
For some it is arguable, whether it's understood by "most people"
in the same way. Take this topic : Maybe "most people" assume,
that it would "naturally" include connections via the web and wouldn't
vote for it this wouldn't be the case.
Well, that's just a sidenote.
-ap
>
> m.
sc
that's something i've wished for too -- i always figured it
was my ignorance preventing me from deleting buffers without
closing the split window that's holding it
sc
Tony Mechelynck
>> I'd like to see something simpler(?): better command line completion of
>> built-in commands. You can script user defined commands as you wish to
>> perform all magic but completion of many built-in commands is really
>> dumb.
>>
>> For example I am working lately with "Tab Separated Values". When I try
>> to insert Tab into regular expression of vimgrep Vim constantly tries to
>> resolve it to file name. I have to resort to <C-V><C-I>.
>
> I tend to agree, but would have argued the other way around.
> Completing
> with '^J' is useless in 99% of my standard use-cases. I believe,
> ultimately
> the completion should be configurable like for custom-commands. That
> way everybody can have it the way he wants.
Do you mean ^J (newline or maybe null) or ^I (tab)?
Even in a user command, the -complete= parameter (or its absence) is defined
when the command is defined and cannot be altered later (other than by
redefining the command). Now builtin ex-commands are defined in the C source
and cannot be redefined.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
245. You use Real Audio to listen to a radio station from a distant
city rather than turn on your stereo system.
ap
not be implemented by scripts.
-ap
ap
On Jan 20, 12:02 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> > On Jan 17, 10:07 pm, Mikolaj Machowski <mikm...@wp.pl> wrote:
> [...]
> >> I'd like to see something simpler(?): better command line completion of
> >> built-in commands. You can script user defined commands as you wish to
> >> perform all magic but completion of many built-in commands is really
> >> dumb.
>
> >> For example I am working lately with "Tab Separated Values". When I try
> >> to insert Tab into regular expression of vimgrep Vim constantly tries to
> >> resolve it to file name. I have to resort to <C-V><C-I>.
>
> > I tend to agree, but would have argued the other way around.
> > Completing
> > with '^J' is useless in 99% of my standard use-cases. I believe,
> > ultimately
> > the completion should be configurable like for custom-commands. That
> > way everybody can have it the way he wants.
>
> [...]
>
> Do you mean ^J (newline or maybe null) or ^I (tab)?
>
> Even in a user command, the -complete= parameter (or its absence) is defined
> when the command is defined and cannot be altered later (other than by
> redefining the command). Now builtin ex-commands are defined in the C source
> and cannot be redefined.
>
for it.
What I have in mind, is the ability to use a wrapper function around
the
builtin command completion. 2 internal functions. First one returns
which kinds
vim would complete, second the (mostly) static wordlists with
typeinfo.
Then one could complete caseinsensitive filenames or add words from
the buffer in a :s command or be happy without '^I' popping up.
Note: Some custom cline completion is already possible via 'CTRL-\e'.
It's just an idea, i wouldn't die for it.
-ap
Nico Weber
>>
>> :b[dw][np] -- Delete/Wipe buffer and open next/previous one
>> : w/o
>>
>> closing any
>> tabs/windows
>
> that's something i've wished for too -- i always figured it
> was my ignorance preventing me from deleting buffers without
> closing the split window that's holding it
I'd like to have that too.
Nico
Matt Wozniski
Is this close enough?
:command BDP bp | bd #
:command BDN bn | bd #
~Matt
sc
works for me -- thanx!
sc
Nico Weber
> :command BDP bp | bd #
> :command BDN bn | bd #
Yes. Thanks :-)
Nico