Re: improving encryption in vim
The main problem that I see is that adding a strong encryption function can have regulation issues. That was the only reason that I thought about using the external library is to get around this. How secure does the encryption need to be? -- Josh
patch 7.0.219
Patch 7.0.219
Problem:When using the 'editexisting.vim' script and a file is being
edited in another tab page the window is split. The "+123"
argument is not used.
Solution: Make the tab page with the file the current tab page. Set
v:swapcommand when starting up to the first "+123" or "-c" command
line argument.
Files: runtime/macros/editexisting.vim, src/main.c
*** ../vim-7.0.218/runtime/macros/editexisting.vim Sun Apr 30 20:33:40 2006
--- runtime/macros/editexisting.vim Sat Mar 17 22:21:30 2007
***
*** 1,6
" Vim Plugin: Edit the file with an existing Vim if possible
" Maintainer: Bram Moolenaar
! " Last Change:2006 Apr 30
" This is a plugin, drop it in your (Unix) ~/.vim/plugin or (Win32)
" $VIM/vimfiles/plugin directory. Or make a symbolic link, so that you
--- 1,6
" Vim Plugin: Edit the file with an existing Vim if possible
" Maintainer: Bram Moolenaar
! " Last Change:2007 Mar 17
" This is a plugin, drop it in your (Unix) ~/.vim/plugin or (Win32)
" $VIM/vimfiles/plugin directory. Or make a symbolic link, so that you
***
*** 85,93
" Function used on the server to make the file visible and possibly execute a
" command.
func! EditExisting(fname, command)
! let n = bufwinnr(a:fname)
! if n > 0
! exe n . "wincmd w"
else
exe "split " . escape(a:fname, ' #%"|')
endif
--- 85,107
" Function used on the server to make the file visible and possibly execute a
" command.
func! EditExisting(fname, command)
! " Get the window number of the file in the current tab page.
! let winnr = bufwinnr(a:fname)
! if winnr <= 0
! " Not found, look in other tab pages.
! let bufnr = bufnr(a:fname)
! for i in range(tabpagenr('$'))
! if index(tabpagebuflist(i + 1), bufnr) >= 0
! " Make this tab page the current one and find the window number.
! exe 'tabnext ' . (i + 1)
! let winnr = bufwinnr(a:fname)
! break;
! endif
! endfor
! endif
!
! if winnr > 0
! exe winnr . "wincmd w"
else
exe "split " . escape(a:fname, ' #%"|')
endif
*** ../vim-7.0.218/src/main.c Tue Feb 27 16:51:07 2007
--- src/main.c Sun Mar 18 21:51:48 2007
***
*** 798,803
--- 798,808
create_windows(¶ms);
TIME_MSG("opening buffers");
+ #ifdef FEAT_EVAL
+ /* clear v:swapcommand */
+ set_vim_var_string(VV_SWAPCOMMAND, NULL, -1);
+ #endif
+
/* Ex starts at last line of the file */
if (exmode_active)
curwin->w_cursor.lnum = curbuf->b_ml.ml_line_count;
***
*** 2202,2207
--- 2207,2227
argv_idx = 1;
}
}
+
+ #ifdef FEAT_EVAL
+ /* If there is a "+123" or "-c" command, set v:swapcommand to the first
+ * one. */
+ if (parmp->n_commands > 0)
+ {
+ p = alloc((unsigned)STRLEN(parmp->commands[0]) + 3);
+ if (p != NULL)
+ {
+ sprintf((char *)p, ":%s\r", parmp->commands[0]);
+ set_vim_var_string(VV_SWAPCOMMAND, p, -1);
+ vim_free(p);
+ }
+ }
+ #endif
}
/*
*** ../vim-7.0.218/src/version.cThu Mar 15 22:54:51 2007
--- src/version.c Sun Mar 18 21:49:11 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 219,
/**/
--
FATHER:You only killed the bride's father - that's all -
LAUNCELOT: Oh dear, I didn't really mean to...
FATHER:Didn't mean to? You put your sword right through his head!
LAUNCELOT: Gosh - Is he all right?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: improving encryption in vim
Josh wrote: > Another idea that I saw on the list was improving the encryption in > vim and encrypting the swap file. The ideas that I have for this range > from replacing the encryption function in vim with one that is more > secure to adding support for an external library library to adding > functions to modify the encryption support in the various scripting > languages that vim has. Am i missing any details? Main issue is that the current encryption is breakable. We need a stronger encryption, which is free to distribute. We only need one new method. Using an external library creates an extra dependency. It would be easier to select an algorithm which we can include directly. That also means the code for it must be relatively short. Encrypting the swap file is actually another item, although it's related. Goal is that the harddisk doesn't contain plain text. Although virtual memory page swapping may still write something to disk (most systems don't allow disabling this). -- The early bird gets the worm. If you want something else for breakfast, get up later. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: creating eclipse plugin for vim
Hi,
One more thing we need to verify from bram what he thinks.
On 3/18/07, Asim Imdad <[EMAIL PROTECTED]> wrote:
yup, I was talking about the same thing and sure we can combine
effort
to do this. It will be my pleasure.
> Eclipse has an option of using Vim as an external editor.
> So the only missing part of the puzzle is to open Vim window in
Eclipse
> workspace.
> That can be done using Eclipse Plugin Arch and not from Vim side.
> Are you looking for this kind of integration?
one problem you'll likely run into is that vim can only have one
window ('gui window', what emacs calls a frame) open. So if you're
opening several embedded vim editors in eclipse, you have three options:
1.) Each embedded editor contains its own complete vim. This way
completion doesn't work across across the editors and it takes more
memory.
2.) Each embedded editor is a vim buffer. This way all of the eclipse
editor windows need to have the same size.
3.) Add support for several windows to vim. This is probably the most
work, but also the most flexible solution (and would improve the mac
version a lot too ;-) ).
I'm no vim expert, so take this with a grain of salt...
Bye,
Nico
improving encryption in vim
Another idea that I saw on the list was improving the encryption in vim and encrypting the swap file. The ideas that I have for this range from replacing the encryption function in vim with one that is more secure to adding support for an external library library to adding functions to modify the encryption support in the various scripting languages that vim has. Am i missing any details? -- Josh
Re: Improving regexp performance
On Sun, 2007-03-18 at 17:32 +0100, Nikolai Weibull wrote: > On 3/18/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > > > On Sun, 2007-03-18 at 14:07 +0100, Nikolai Weibull wrote: > > > > Then there's the parallel one that keeps track of all the states that > > > we're currently in that accepts as soon as an accepting/final state is > > > reached. > > > I think by parallel you are referring to the usual mechanism for > > simulating the NFA ( on the fly subset construction ? ). Simply, we have > > a set of states ( initially S0 ) and the we keep eating a symbol at a > > time, calculate the next possible set of states ( including E-closure ) > > and whenever the current set of states contain an accepting state of the > > original NFA, Voila! > > Yes. Quite elegant, wouldn't you say? ;-) > > > > And then there's the cached DFA implementation that builds the DFA > > > representation of the NFA as needed while traversing the input. This > > > is the most difficult one to implement, but also the fastest for most > > > inputs. > > > Sorry, but I'm in confusion here. Are you telling me that the current > > regxp engine has a cached DFA implementation ? ( I thought such an > > implementation was the aim of this project :( ) > > No. The current implementation is purely backtracking, with a bunch > of tricks to speed it up. > > > > Russ Cox's article is good, but doesn't show anyting new, even though > > > it has been received like as it would. And he really skims over some > > > of the important issues that one has to consider when using regular > > > expressions for doing anything other than just accepting or rejecting > > > input as being part of a regular language. Perhaps most important is > > > submatch reporting, which causes all kinds of difficulties that he > > > simply doesn't mention. > > > > I agree. Just out of curiosity, I referred to the book "Compilers - > > Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey > > D. Ullman". It has a very nice explanation of NFA, NFA->DFA, Regxp->NFA > > and even Regxp->DFA ( I'm still trying to understand the last one ). > > I used the article by Russ Cox to verify what I have learnt from the > > above book. But I believe that above article is a good starter. > > Yes, it's a very good and short (which is a good thing!) summary. The > book you mention above is also very good, and covers a bit more > theory. I can highly recommend the following books and articles: > > John E. Hopcroft and Jeffrey D. Ullman, Introduction to Automata Theo- > ry, Languages, and Computation. (Addison–Wesley, Reading, Massachusetts, > 1979). > > This is really the reference work if you care about the theory. > Contains a lot of information on formal languages, of which only the > regular ones are really of interest for this project. > > Gonzalo Navarro, NR-grep: A fast and flexible pattern matching tool , > Software—Practice and Experience 31(13), pp. 1265–1312 (2001). > > A very fast grep implementation. The algorithm used uses bitfields to > keep track of the finite automatons state, making it very fast for > many common patterns. > > Alfred V. Aho, Algorithms for Finding Patterns in Strings. In Algorithms > and Complexiy, vol. A of Handbook of Theoretical Computer Science, chapter > 5, pp. 255–300 (Elsevier Science Publishers B.V., Cambridge, Massachusetts, > 1990). > > This last one covers the theory especially well for this project, I'd > say, and contains a very complete bibliography. > > I hope you won't drown in information ;-). More pointers can be found > in my thesis, but those are probably the most interesting ones. > > > Thank you so much for the feed back. :) > > No problem. I'm very interested to see where this project will go and > I hope I can be of help, should you need it. I definitely need your help! :) - Asiri > nikolai
Re: Improving regexp performance
On 3/18/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: On Sun, 2007-03-18 at 14:07 +0100, Nikolai Weibull wrote: > Then there's the parallel one that keeps track of all the states that > we're currently in that accepts as soon as an accepting/final state is > reached. I think by parallel you are referring to the usual mechanism for simulating the NFA ( on the fly subset construction ? ). Simply, we have a set of states ( initially S0 ) and the we keep eating a symbol at a time, calculate the next possible set of states ( including E-closure ) and whenever the current set of states contain an accepting state of the original NFA, Voila! Yes. Quite elegant, wouldn't you say? ;-) > And then there's the cached DFA implementation that builds the DFA > representation of the NFA as needed while traversing the input. This > is the most difficult one to implement, but also the fastest for most > inputs. Sorry, but I'm in confusion here. Are you telling me that the current regxp engine has a cached DFA implementation ? ( I thought such an implementation was the aim of this project :( ) No. The current implementation is purely backtracking, with a bunch of tricks to speed it up. > Russ Cox's article is good, but doesn't show anyting new, even though > it has been received like as it would. And he really skims over some > of the important issues that one has to consider when using regular > expressions for doing anything other than just accepting or rejecting > input as being part of a regular language. Perhaps most important is > submatch reporting, which causes all kinds of difficulties that he > simply doesn't mention. I agree. Just out of curiosity, I referred to the book "Compilers - Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman". It has a very nice explanation of NFA, NFA->DFA, Regxp->NFA and even Regxp->DFA ( I'm still trying to understand the last one ). I used the article by Russ Cox to verify what I have learnt from the above book. But I believe that above article is a good starter. Yes, it's a very good and short (which is a good thing!) summary. The book you mention above is also very good, and covers a bit more theory. I can highly recommend the following books and articles: John E. Hopcroft and Jeffrey D. Ullman, Introduction to Automata Theo- ry, Languages, and Computation. (Addison–Wesley, Reading, Massachusetts, 1979). This is really the reference work if you care about the theory. Contains a lot of information on formal languages, of which only the regular ones are really of interest for this project. Gonzalo Navarro, NR-grep: A fast and flexible pattern matching tool , Software—Practice and Experience 31(13), pp. 1265–1312 (2001). A very fast grep implementation. The algorithm used uses bitfields to keep track of the finite automatons state, making it very fast for many common patterns. Alfred V. Aho, Algorithms for Finding Patterns in Strings. In Algorithms and Complexiy, vol. A of Handbook of Theoretical Computer Science, chapter 5, pp. 255–300 (Elsevier Science Publishers B.V., Cambridge, Massachusetts, 1990). This last one covers the theory especially well for this project, I'd say, and contains a very complete bibliography. I hope you won't drown in information ;-). More pointers can be found in my thesis, but those are probably the most interesting ones. Thank you so much for the feed back. :) No problem. I'm very interested to see where this project will go and I hope I can be of help, should you need it. nikolai
Re: creating eclipse plugin for vim
One more thing we need to verify from bram what he thinks. On 3/18/07, Asim Imdad <[EMAIL PROTECTED]> wrote: yup, I was talking about the same thing and sure we can combine effort to do this. It will be my pleasure. On 3/18/07, Manu Anand <[EMAIL PROTECTED]> wrote: > > > On 3/18/07, Asim Imdad <[EMAIL PROTECTED]> wrote: > > Yes but it emulates vim but it is not the VIM. I think lot of features > > might be missing from it because it emulates the vim. Nicolas is right > > in saying that if somebody starts writing the vim in java it will take > > lot of time. So only method is to embed it via some terminal emulation > > or create a console interface to embed vim into eclipse. > > Asim IMDAD > > > Hi Asim: > > Eclipse has an option of using Vim as an external editor. > So the only missing part of the puzzle is to open Vim window in Eclipse > workspace. > That can be done using Eclipse Plugin Arch and not from Vim side. > Are you looking for this kind of integration? > > Manu > > > On 3/18/07, Doug Kearns <[EMAIL PROTECTED] > wrote: > > > On Sun, Mar 18, 2007 at 08:28:19AM +0100, Asim Imdad wrote: > > > > Hi, > > > > I was think of rewriting code base of vim in java. What kind of > > > > problems do you people think I can face? Already there is another > > > > project known as jvi. How much faithful it is to true vim design? > > > > > > There's also a 'vim' plugin for IDEA's IntelliJ: > > > http://ideavim.sourceforge.net/ > > > > > > Regards, > > > Doug > > > > > > >
Re: creating eclipse plugin for vim
yup, I was talking about the same thing and sure we can combine effort to do this. It will be my pleasure. On 3/18/07, Manu Anand <[EMAIL PROTECTED]> wrote: On 3/18/07, Asim Imdad <[EMAIL PROTECTED]> wrote: > Yes but it emulates vim but it is not the VIM. I think lot of features > might be missing from it because it emulates the vim. Nicolas is right > in saying that if somebody starts writing the vim in java it will take > lot of time. So only method is to embed it via some terminal emulation > or create a console interface to embed vim into eclipse. > Asim IMDAD Hi Asim: Eclipse has an option of using Vim as an external editor. So the only missing part of the puzzle is to open Vim window in Eclipse workspace. That can be done using Eclipse Plugin Arch and not from Vim side. Are you looking for this kind of integration? Manu > On 3/18/07, Doug Kearns <[EMAIL PROTECTED] > wrote: > > On Sun, Mar 18, 2007 at 08:28:19AM +0100, Asim Imdad wrote: > > > Hi, > > > I was think of rewriting code base of vim in java. What kind of > > > problems do you people think I can face? Already there is another > > > project known as jvi. How much faithful it is to true vim design? > > > > There's also a 'vim' plugin for IDEA's IntelliJ: > > http://ideavim.sourceforge.net/ > > > > Regards, > > Doug > > >
Re: creating eclipse plugin for vim
Yes but it emulates vim but it is not the VIM. I think lot of features might be missing from it because it emulates the vim. Nicolas is right in saying that if somebody starts writing the vim in java it will take lot of time. So only method is to embed it via some terminal emulation or create a console interface to embed vim into eclipse. Asim IMDAD On 3/18/07, Doug Kearns <[EMAIL PROTECTED]> wrote: On Sun, Mar 18, 2007 at 08:28:19AM +0100, Asim Imdad wrote: > Hi, > I was think of rewriting code base of vim in java. What kind of > problems do you people think I can face? Already there is another > project known as jvi. How much faithful it is to true vim design? There's also a 'vim' plugin for IDEA's IntelliJ: http://ideavim.sourceforge.net/ Regards, Doug
vim via console in eclipse
Hi, There is one idea to use eclipse console class and extend to incorporate vim into it. It is defined in org.eclipse.ui.console. I am currently looking into details related to this. There will be no rewriting of code for eclipse and original can be used. Asim Imdad
Re: Improving regexp performance
On Sun, 2007-03-18 at 15:07 +0100, Bram Moolenaar wrote: > Asiri Rathanayake wrote: > > > I read several articles on possible NFA implementations ( took some time > > to understand ). But I think implementing an NFA based approach is quite > > possible ( Russ Cox has provided a sample implementation in his > > article ). But I'm having a hard time understanding the existing > > approach taken :'( . > > > > The current implementation also seem to have a bypass mechanism, the > > vim_regcomp() method is setting variables Regstart and reganch so that > > obvious non matching cases can be avoided. I was thinking if this > > approach can be used to switch between old implementation and the new > > one. Is this possible ? > > Everything is possible... > > The existing code is hard to understand, since it has been extended a > lot and quite a few bits are optimized for space and speed. On top of > that I changed it from a recursive to an iterative mechanism (avoids > running out of stack space and crashing). Thanks, that eased a lot of pain, I thought my brain was lagging behind. :) > > It would be good if the rest of the Vim code doesn't need to know how > vim_regcomp() and vim_regexec() work. Adding a flag to regprog_T should > work. > - Asiri
Re: Improving regexp performance
On Sun, 2007-03-18 at 14:07 +0100, Nikolai Weibull wrote: > On 3/18/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > > > I read several articles on possible NFA implementations ( took some time > > to understand ). But I think implementing an NFA based approach is quite > > possible ( Russ Cox has provided a sample implementation in his > > article ). But I'm having a hard time understanding the existing > > approach taken :'( . > > The current implementation is also an NFA-based one. What's more > interesting is how the NFA is simulated. The current implementation > uses backtracking, that is, it tries a solution and checks if it > works. If so, then accept. Otherwise, try the next one. > > Then there's the parallel one that keeps track of all the states that > we're currently in that accepts as soon as an accepting/final state is > reached. I think by parallel you are referring to the usual mechanism for simulating the NFA ( on the fly subset construction ? ). Simply, we have a set of states ( initially S0 ) and the we keep eating a symbol at a time, calculate the next possible set of states ( including E-closure ) and whenever the current set of states contain an accepting state of the original NFA, Voila! > And then there's the cached DFA implementation that builds the DFA > representation of the NFA as needed while traversing the input. This > is the most difficult one to implement, but also the fastest for most > inputs. Sorry, but I'm in confusion here. Are you telling me that the current regxp engine has a cached DFA implementation ? ( I thought such an implementation was the aim of this project :( ) > Russ Cox's article is good, but doesn't show anyting new, even though > it has been received like as it would. And he really skims over some > of the important issues that one has to consider when using regular > expressions for doing anything other than just accepting or rejecting > input as being part of a regular language. Perhaps most important is > submatch reporting, which causes all kinds of difficulties that he > simply doesn't mention. I agree. Just out of curiosity, I referred to the book "Compilers - Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman". It has a very nice explanation of NFA, NFA->DFA, Regxp->NFA and even Regxp->DFA ( I'm still trying to understand the last one ). I used the article by Russ Cox to verify what I have learnt from the above book. But I believe that above article is a good starter. > > nikolai Thank you so much for the feed back. :) - Asiri
Re: creating eclipse plugin for vim
On Sun, Mar 18, 2007 at 08:28:19AM +0100, Asim Imdad wrote: > Hi, > I was think of rewriting code base of vim in java. What kind of > problems do you people think I can face? Already there is another > project known as jvi. How much faithful it is to true vim design? There's also a 'vim' plugin for IDEA's IntelliJ: http://ideavim.sourceforge.net/ Regards, Doug
Re: Improving regexp performance
Asiri Rathanayake wrote: > I read several articles on possible NFA implementations ( took some time > to understand ). But I think implementing an NFA based approach is quite > possible ( Russ Cox has provided a sample implementation in his > article ). But I'm having a hard time understanding the existing > approach taken :'( . > > The current implementation also seem to have a bypass mechanism, the > vim_regcomp() method is setting variables Regstart and reganch so that > obvious non matching cases can be avoided. I was thinking if this > approach can be used to switch between old implementation and the new > one. Is this possible ? Everything is possible... The existing code is hard to understand, since it has been extended a lot and quite a few bits are optimized for space and speed. On top of that I changed it from a recursive to an iterative mechanism (avoids running out of stack space and crashing). It would be good if the rest of the Vim code doesn't need to know how vim_regcomp() and vim_regexec() work. Adding a flag to regprog_T should work. -- "It's so simple to be wise. Just think of something stupid to say and then don't say it."-- Sam Levenson /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: Improving regexp performance
On 3/18/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: I read several articles on possible NFA implementations ( took some time to understand ). But I think implementing an NFA based approach is quite possible ( Russ Cox has provided a sample implementation in his article ). But I'm having a hard time understanding the existing approach taken :'( . The current implementation is also an NFA-based one. What's more interesting is how the NFA is simulated. The current implementation uses backtracking, that is, it tries a solution and checks if it works. If so, then accept. Otherwise, try the next one. Then there's the parallel one that keeps track of all the states that we're currently in that accepts as soon as an accepting/final state is reached. And then there's the cached DFA implementation that builds the DFA representation of the NFA as needed while traversing the input. This is the most difficult one to implement, but also the fastest for most inputs. Russ Cox's article is good, but doesn't show anyting new, even though it has been received like as it would. And he really skims over some of the important issues that one has to consider when using regular expressions for doing anything other than just accepting or rejecting input as being part of a regular language. Perhaps most important is submatch reporting, which causes all kinds of difficulties that he simply doesn't mention. nikolai
Re: creating eclipse plugin for vim
Hi, I was think of rewriting code base of vim in java. The whole code base? What kind of problems do you people think I can face? As sloccount vim7-svn/src shows, there are about 281000 thousand lines of vim code. The average programmer writes 10 lines of functional, tested code. Say that the java version would take only half as much code for some reason (only one gui version needed, ...), and that you're an above average programmer that writes 50 lines of code per day. Then you'll need 7.7 years to rewrite vim in java. Furthermore, the GUI would suck (due to being written in Java) and the code would probably be slower (yes, I do have my gripes with java ;-) ). Bye, Nico
Improving regexp performance
Bram, I read several articles on possible NFA implementations ( took some time to understand ). But I think implementing an NFA based approach is quite possible ( Russ Cox has provided a sample implementation in his article ). But I'm having a hard time understanding the existing approach taken :'( . The current implementation also seem to have a bypass mechanism, the vim_regcomp() method is setting variables Regstart and reganch so that obvious non matching cases can be avoided. I was thinking if this approach can be used to switch between old implementation and the new one. Is this possible ? - Asiri
Re: creating eclipse plugin for vim
On Sun, 2007-03-18 at 08:28 +0100, Asim Imdad wrote: > Hi, > I was think of rewriting code base of vim in java. What kind of > problems do you people think I can face? Already there is another > project known as jvi. How much faithful it is to true vim design? > AI I have seen gedit integrated to eclipse but in a rather different manner. Say, when you double click on a file that is not associated with any of the files eclipse recognizes, it will open up a separate gedit window. I don't know whether this is what suits the project, wait for bram to reply. - Asiri
