Re: [Announcement] Subversion repository location changed
On Wed, May 09, 2007 at 10:27:24AM +0800, Edward L. Fox wrote: On 5/9/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Edward L. Fox announced: Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Shouldn't there be vim7.1a (the a'th candidate for 7.1) today, and eventually, when Bram releases version 7.1, vim7.1? So is the last argument to svn co correct? And isn't today's branch/trunk/whatever 7.1a rather than 7.1? 7.1, not 7.1a. Because as the alphabetical version changes so fast, personally I don't want to create too many branches for that. --Suresh That's what tags are for. Let's say you want to release 7.1b from the current 7.1 branch: svn copy -m Tagging 7.1b release https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 https://vim.svn.sourceforge.net/svnroot/vim/tags/vim7.1b Copies are very space-efficient in svn, which is why they are the mechanism for both branching and tagging. --Greg
Re: wish: collaboration of N vim instances editing same file
On Sun, Apr 29, 2007 at 10:43:14PM +0200, Bram Moolenaar wrote: Yakov Lerner wrote: Is it possible to add this item to the vim voting list ?: collaboration of N vim instances editing same file -- Ability of N instances of vim to absorb, merge and show changes to the same file made by other running vim instances [ either by reading other vim's swapfiles, or somehow else ] ? It's an interesting idea. Won't be easy to implement in such a way that it works on most platforms. I think the hard part will mostly have to do with design/policy choices. How is a session instigated? Does a single instance own the file and other instances join? Or maybe there should be some server that fronts a repository (e.g. svn, plain filesystem, WebDAV, etc.)? Or does it use svn (or WebDAV, or other network fileshare) for everything, including discovery, authentication, and inter-vim communication? What kind of protocol should be used? It will be at least partially homegrown, but is there a standard on which it should be based (perhaps there is a standard for recording document edits beyond just diffs, I don't know)? Should communication be over a star network of reliable (i.e. TCP) connections? A mesh? A hypercube? A minimum spanning tree? Should it be, instead, unreliable (i.e. UDP) multicast (which makes discovery easy and authentication a separate protocol)? None of these questions involve platform-specific issues, since they all assume that communication will be over TCP/IP, but I don't think they have easy answers. It mostly comes down to what problem you are trying to solve. Some sample scenarios: - allow a few (5) open source developers work on the same source file, which has its primary existence in a subversion repository to which they all have write access, collaboratively across the net - allow developers (5) in the same company work collaboratively on a source file over their company LAN - allow massive numbers of people collaborate on some literary art project (e.g. a collaborative novel, something Wikipedia-like) - provide a teleconferencing system for a few writers and a large number of readers across the net (e.g. teaching aid, watch Bram code Vim promotion) - two, and only two, developers working together over a fast network - allow a small group (10) collaborators develop the Next Big Thing for their startup, despite each developer living in a different city Each one implies different choices. If it's over the open net, authentication and security are concerns, at least for writers. If non-writers are allowed to spectate, you need some sort of permissions system. Over the open net there needs to be some handling of timeouts and lag. Smaller numbers of participants lets you cut corners in ways that larger numbers of participants do not. Editing sensitive data (e.g. the next Harry Potter, if J.K. Rowling used Vim and collaborated directly with another author or with her editor) requires encryption over the network, not to mention strong authentication. Making something that serves all these needs is a massive undertaking, but since Vim gets used in all sorts of environments, which scenario(s) do you choose? It will probably require a server to make it possible for various Vim instances to find each other. And to take care of authentication. Perhaps such a server already exists? [...] As far as I know, the first implementation of this sort of idea to gain real traction among users of text editors (i.e. largely developers) is SubEthaEdit http://www.codingmonkeys.de/subethaedit/collaborate.html. It uses MacOS X's Bonjour (which is an implementation of ZeroConf, see http://developer.apple.com/opensource/internet/bonjour.html for Apple's BSD-licensed implementation) for discovery. I'd be inclined to go with the single instance owning the file and announcing itself via ZeroConf, but I think even that requires either requiring a particular ZeroConf implementation on the system or juggling carefully which vim instance is responding to DNS requests. It also plays no part in authentication. Another alternative is to skip discovery and require some out-of-band communication (e.g. IM, phone call, etc.) to communicate the host and port to connect to. Of course, that makes authentication easy since the same out-of-band communication can be used to give a password. No, that isn't what you'd call strong authentication or good security, but it's probably good enough for most people. Of course, your communication protocol should be encrypted... Authentication is prickly and I'm not sure how you'd choose what authentication methods should be allowed (and implemented). Again, it falls under the question of which scenario(s) we intend to serve. I'll point out that this sort of thing is what first-person shooter network play has been about since Doom first came out way back when. At the time, the solution was to broadcast every keystroke (over IPX, yet) and have each
Re: replace VimScript (was: wish: allow a: in the function def)
On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] Actually, I like the proposal for two entirely different reasons: 1) the language specification comes from an international standards body 2) there are lots of people working on efficient implementations, at least two of which are open source (SpiderMonkey and Adobe's Tamarin, though there seem to be some plans to convert SpiderMonkey to use Tamarin) It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. There's a lot to be said for following a path that leads to interoperability and code reuse. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. --Greg
Re: replace VimScript (was: wish: allow a: in the function def)
On Tue, Apr 24, 2007 at 05:57:45PM +0200, Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
Robert Lee wrote:
[snip]
Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?
Aw, come on. Everyone knows ECMAScript. It's like with HTML:
everyone knows HTML. It's like on the web and stuff.
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', )
than
:set fo-=t
It's all about domain specific languages. It's said so on the internet.
Hey, congratulations! You designed a crappy API! Of course, you can
design a crappy API in any language. Take a look at this:
:let fo = substitute(fo, t, , )
That looks terrible! Oh, hang on, you say there's a better way?
I'm not impressed with your strawman argument.
nikolai
--Greg
Re: replace VimScript (was: wish: allow a: in the function def)
On Tue, Apr 24, 2007 at 05:49:19PM +0200, Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] Actually, I like the proposal for two entirely different reasons: 1) the language specification comes from an international standards body So? In what way does this make it a good language? In what way does this make it a good language to extend Vim with? Anyone can write a standard. It doesn't mean that it's good or what is being standardized will be, either. Where did anyone say that standardization made it a better language than any other? Most of what makes it a good language has been there since the earliest JavaScript implementations. Many of the issues that have made it difficult to work with in the past have been hammered out during standardization or were API issues rather than language issues. But even that isn't what standardization buys you. The main advantage is interoperability. If someone writes some excellent library for use in some Flash app, but is of use in some other environment that provides ECMAScript extension, you can just copy it over and use it. I'm capable of porting an algorithm in one language I know to another language I know, but that's a bit more work than copy and paste. 2) there are lots of people working on efficient implementations, at least two of which are open source (SpiderMonkey and Adobe's Tamarin, though there seem to be some plans to convert SpiderMonkey to use Tamarin) SpiderMonkey is a terribly inefficient implementation, which is why Tamarin will be used in future versions of Gecko. And I wouldn't say that efficiency is the primary concern of a language/runtime engine to use for Vim. I strongly disagree with that statement. Efficiency is certainly important for an editor. I don't want to sit and twiddle my thumbs while vim starts up or executes hooks on file read, nor do I want it to suck up a big chunk of memory while it's going about its business. In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. Efficiency is definitely important. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? As for following the leader, you are on shaky ground. Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? nikolai --Greg
