Re: New features to vote on and sponsoring
Is this close enough? :command BDP bp | bd # :command BDN bn | bd # Yes. Thanks :-) Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Dnia Saturday 19 of January 2008, Ben Schmidt napisał: 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-VC-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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Jan 17, 10:07 pm, Mikolaj Machowski [EMAIL PROTECTED] 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-VC-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. 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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Saturday 19 January 2008 16:07, ap wrote: On Jan 17, 10:07 pm, Mikolaj Machowski [EMAIL PROTECTED] 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-VC-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. Is this becoming a wishlist ? :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 sc 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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Jan 19, 11:32 pm, sc [EMAIL PROTECTED] wrote: On Saturday 19 January 2008 16:07, ap wrote: On Jan 17, 10:07 pm, Mikolaj Machowski [EMAIL PROTECTED] 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-VC-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. Is this becoming a wishlist ? :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 sc On a 2nd thought, there are more important features, which can not be implemented by scripts. -ap --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
ap wrote: On Jan 17, 10:07 pm, Mikolaj Machowski [EMAIL PROTECTED] 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-VC-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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Jan 20, 12:02 am, Tony Mechelynck [EMAIL PROTECTED] wrote: ap wrote: On Jan 17, 10:07 pm, Mikolaj Machowski [EMAIL PROTECTED] 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-VC-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. That sounds like you don't like it, but is actually the best reason 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 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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Saturday 19 January 2008 22:30, Matt Wozniski wrote: On Jan 19, 2008 7:36 PM, Nico Weber wrote: Is this becoming a wishlist ? :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 Is this close enough? :command BDP bp | bd # :command BDN bn | bd # ~Matt works for me -- thanx! sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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-VC-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. Best regards, Tony. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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-VC-I. m. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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-VC-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?! 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)! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Is there some existing open source project that can be leveraged to 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/ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On 15 Jan., 21:55, Bram Moolenaar [EMAIL PROTECTED] wrote: 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 Now I wonder why so may of you vote make it possible to use Vim as a 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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) Yes! that would be a great enhancement! Martin --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Wed, 16 Jan 2008 11:46:46 +0100, Milan Vancura [EMAIL PROTECTED] 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Jan 15, 2008 9:55 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: - 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: New features to vote on and sponsoring
-Original Message- From: vim_dev@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Winn Sent: 16 January 2008 13:55 To: [EMAIL PROTECTED] Subject: Re: New features to vote on and sponsoring On Wed, 16 Jan 2008 11:46:46 +0100, Milan Vancura [EMAIL PROTECTED] 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
- 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. 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). Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Matthew Winn wrote:
(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
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Jan 16, 2008 1:15 PM, Ben Schmidt [EMAIL PROTECTED] 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. 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). Ben. I did update it - I don't remember if I posted the updated version or not. 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
- 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)? Thanks, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On 15/01/2008, Bram Moolenaar [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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. 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On 2008-01-16, Ben Schmidt [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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: 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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
