Re: GSOC: that compiler/yacc book I mentioned...
Thanks a lot, it seems to be a valuable resource. Regards, Birgi --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
GSOC: that compiler/yacc book I mentioned...
Its Allen I. Holub's "Compiler Design in C", ISBN 0-13-155045-4 Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated FP Patch - Not Setting $VIM Correctly
On Mon 14-Apr-08 3:12am -0600, Tony Mechelynck wrote:
> It's not a bug, see ":help $VIM" item 3. Vim 7.1 will try removing
> "vim71" from the directory from which it was started. That's what
> vim{version} means. "vim75" would be the vim{version} of vim 7.5 but
> it's vim 7.1 that you're using.
That certainly isn't clear from that paragaph - which, of
course, I read before posting. The 7.1 doc clearly states
that you can use other numbers. The example given is vim54.
I had tried several directory names under \vim and vim75
worked, so I thought, with the first FP patch. I must have
been mistaken.
> I recommend installing your executables into a single vim71 directory
> but with different names such as gvim.exe and gvim-fp.exe (see the
> paragraph below the list of executable names at ":help gvim" etc.).
I just replace gvim - Bram's test patches are usually more
solid than Microsoft's final releases :-) Each time I build
a new version of the release, I copy it to \vim\vim71 as
gvim.exe and as, say, gvim-7.1.293 so I always have a
fallback.
Thanks for your comments, Tony.
--
Best regards,
Bill
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Updated floating point patch
Dnia Monday 14 of April 2008, Charles E Campbell Jr napisał: > Bram Moolenaar wrote: > > Here is an update for the floating point patch. The 'g' argument for > > printf() was implemented and a few bug fixes. > > > > This is to be applied to the original source code, without the older > > floating point patch. > > > > I would still like feedback on the format of floating point numbers: > > > > &123.456 > > &1.23e-3 > > Hello! > > I have an alternative format: > >123;456 > > ie. use semicolons instead of the ".". If the printing of them also > uses semi-colons, they'll be a bit less likely to cause problems: > > let a=12;34 > echo a >12;34 > let b=string(a) > "12;34" > let c=eval(b) > 12;34 > > I admit that I'm not sure if I like semi-colons better than the leading > & myself -- although a semi-colon does have a "." of sorts embedded in > it. > > Regards, > Chip Campbell I suggested it few days ago :) But it they are possible conflicts with list unpacking. :help let-unpack :let [a, b; rest] = ["aval", "bval", 3, 4] m. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Lin wrote: > On Apr 15, 12:28 am, Marc Haisenko <[EMAIL PROTECTED]> wrote: > >> IMHO not a good idea. You will waste most of the time writing/debugging the >> parser instead of the Vim part (plus all the time you need to solve problems >> related to the parser and the grammar). Don't reinvent the wheel when there's >> one that might suit your need sufficiently well. >> >> Writing a parser seems not that hard at first, but how many have you written >> so far ? It really is not an easy task and that's why yacc/bison is still so >> popular despite it having some limitations. >> >> Plus writing a grammar for C sounds as joyful as driving a glowing steel rod >> through your private parts, considering all its ambiguities. >> Marc >> > > I agree. In fact I'm not for a new parser either. I wrote an LALR > compiler as a course project some years ago. Debugging the grammar is > really painful, even for a very limited subset of C. Ambiguity is > quite hard to figure out and solve. > That book I mentioned that I have on writing a LALR, yacc-like parser is at home; I'll try to remember to find its ISBN (and title). It does happen to be written in C; if the authors would be amenable, perhaps it could be imported and perhaps modified to support incremental grammar checking (and lexical analysis and type checking and symbol table and ...). The advantage of it is that there is, in fact, an entire book on it, so its well documented. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch: FreeBSD console mouse support
On Apr 12, 6:55 am, Tony Mechelynck <[EMAIL PROTECTED]> wrote: > On 11/04/08 14:12, Paul B. Mahol wrote: > [...] > > > Should gpm and sysmouse have its entries in 'ttymouse' ? > > I don't know about sysmouse, but a few experiments on my Linux text > terminal (on /dev/tty3) show that Vim recognises the gpm mouse if > installed (and running), even with 'ttymouse' left empty (which, on that > terminal, is the default). Thanks, I already know that, but could you tell me is it possible to select and paste text when in cmdline mode with gpm. > > Best regards, > Tony. > -- > "You and I as individuals can, by borrowing, live beyond our means, but > only for a limited period of time. Why should we think that collectively, > as a nation, we are not bound by that same limitation?" > -- Ronald Reagan --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
On Apr 15, 12:28 am, Marc Haisenko <[EMAIL PROTECTED]> wrote: > IMHO not a good idea. You will waste most of the time writing/debugging the > parser instead of the Vim part (plus all the time you need to solve problems > related to the parser and the grammar). Don't reinvent the wheel when there's > one that might suit your need sufficiently well. > > Writing a parser seems not that hard at first, but how many have you written > so far ? It really is not an easy task and that's why yacc/bison is still so > popular despite it having some limitations. > > Plus writing a grammar for C sounds as joyful as driving a glowing steel rod > through your private parts, considering all its ambiguities. > Marc I agree. In fact I'm not for a new parser either. I wrote an LALR compiler as a course project some years ago. Debugging the grammar is really painful, even for a very limited subset of C. Ambiguity is quite hard to figure out and solve. Regards, Lin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
On Monday 14 April 2008, Lin wrote: > On Apr 14, 11:18 pm, Charles E Campbell Jr <[EMAIL PROTECTED]> > > wrote: > > The primary disadvantage is that effectively writing a new yacc/bison is > > not a small task. I have a real thick book about writing a yacc-like > > parser somewhere; if anyone's interested, I could look up its ISBN. > > The biggest advantage for writing a brand new LALR parser I think is > that we can make it incremental. I know something about parsing LALR > grammars. They would produce some intermediate table from the grammar > definition (called status table?) to guide the parser, so that it > operates like a finite automata with a stack equipped. If we have that > table we can just store the stack and the parser's state to avoid > looking back to previous codes. > Then we also need a scanner recognizing different types of words. For > this we can seek help from tools like Lex. > > Is C++ an LALR language? Not sure... > > Regards, > Lin IMHO not a good idea. You will waste most of the time writing/debugging the parser instead of the Vim part (plus all the time you need to solve problems related to the parser and the grammar). Don't reinvent the wheel when there's one that might suit your need sufficiently well. Writing a parser seems not that hard at first, but how many have you written so far ? It really is not an easy task and that's why yacc/bison is still so popular despite it having some limitations. Plus writing a grammar for C sounds as joyful as driving a glowing steel rod through your private parts, considering all its ambiguities. Marc -- Marc Haisenko Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
On Apr 14, 11:18 pm, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: > The primary disadvantage is that effectively writing a new yacc/bison is > not a small task. I have a real thick book about writing a yacc-like > parser somewhere; if anyone's interested, I could look up its ISBN. The biggest advantage for writing a brand new LALR parser I think is that we can make it incremental. I know something about parsing LALR grammars. They would produce some intermediate table from the grammar definition (called status table?) to guide the parser, so that it operates like a finite automata with a stack equipped. If we have that table we can just store the stack and the parser's state to avoid looking back to previous codes. Then we also need a scanner recognizing different types of words. For this we can seek help from tools like Lex. Is C++ an LALR language? Not sure... Regards, Lin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Hi all, I too support a built in parser for VIM.But according to Bram,it is too hard.It would take a human life to complete the project alone in a decent way...he said. So I would prefer a compiler link in VIM which can de - parse error messages..than some thing you all suggest. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
> There are yacc grammars available for several languages, including C, > Matlab, and Lisp. The advantage of this approach is similar to the > advantage of the syntax highlighting engine; its not particularly tied > to any language. I mostly program in C/Matlab myself, but I know > there's plenty of other languages and users out there (python, perl, > sh/csh/ksh/zsh/tcsh/..., java, lisp, scheme, ada, matlab, ... > apologies > to those folks for whom I've missed mentioning their favorites) and > tying a major feature of vim to one or two languages is probably not > going to be universally appreciated. What I was advocating was the > ability to use LALR grammars (read: yacc/bison) so that vim isn't tied > to a particular language and, in fact, can be extended to cover future > languages. A language checker has to do more than just grammar checking, you also need type checking, checks if a variable is defined before use, etc. > Nico --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Lin <[EMAIL PROTECTED]> wrote: > This is another student who is applying for the on-the-fly code > checker project in GSoC. > > On Apr 14, 2:59 am, [EMAIL PROTECTED] wrote: > > However, I do am interested in something able to understand C++ > > constructs in order to built even more powerful code > > transformations and generations. > > As such, this GSOC project may initiate the development of the API > > I'm missing. > > Hence I'm looking forward to it. > > Would it be useful to have a mechanism for Vim to do some "background" > job? By using threads etc. It all depends on the job I guess. > Another feature becoming possible with this API would be an on-the-fly > tags generator. When SOME threshold is reached, we can call a > background thread to refresh the tags, which can be in turn reflected > in the tags window (which is supplied in the Taglist plugin). > But fine tunes should be given for the threshold. The same problem > exists for syntax checker. > > Would anyone find this useful? IMHO, there is no need to run ctags in the background. [I already have a plugin (one of the rare I've never published) that updates my tags file every time a buffer is saved. By "update" I mean that only the updated file is parsed, and that the tags previously associated to this file are replaced by the new ones. At most, I loose 1/10 s every time I hit (mapped to :update). I won't be surprised to learn that there already are several other plugins that do that on vim.org.] My main concern is more that ctags itself is not a very good solution -- for parsing C++ files. A good solution will need to see the current buffer (we are back to your "thread" proposal), and do a lot of work to really understand the code. -- Luc Hermitte http://lh-vim.googlecode.com/ http://hermitte.free.fr/vim/ --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Bram Moolenaar wrote: > Birgi Tamersoy wrote: > > >> Hey everybody, >> >> Apparently many students (like me) are interested in this project. So, >> I decided to start a new thread where we can talk about the challenges >> in the project and how to solve them. I went over previous posts to >> include all the related ideas in this new thread. >> > > Thanks for starting this discussion. > > >> Here are a few initial thoughts about the project: >> >> I think *speed* is one of the major concerns. Basically, editing speed >> should not be affected at all by the code checker. >> >> Running a compiler in the background with a temporary copy of the >> code, parsing the error messages and highlighting the related parts is >> one of the intuitive solutions (which is also implemented in Emacs >> Flymake). Although this is a to-the-point solution it will be quite >> slow according to your project size. >> >> *Incremental compiling* can be used to enhance this method. Rather >> than compiling the whole code every time, the checker can compile only >> the necessary parts. Right now, I don't know if this is supported by >> the majority of the compilers or the interpreters. >> >> Using a *built-in parser* is solution emphasized by Charles E. >> Campbell Jr in a related post. A parser would be perfect for syntax- >> checking, but I think the code checker should also detect errors like >> a misspelled library name. >> > > In my opinion the errors and warnings that are highlighted must be 99% > correct. It's very annoying if you get an error for something that is > not wrong, or compiling fails with an error but the error was not > highlighted. I don't think that a built-in parser will be able to reach > this accuracy, except perhaps for some simple languages. > There are yacc grammars available for several languages, including C, Matlab, and Lisp. The advantage of this approach is similar to the advantage of the syntax highlighting engine; its not particularly tied to any language. I mostly program in C/Matlab myself, but I know there's plenty of other languages and users out there (python, perl, sh/csh/ksh/zsh/tcsh/..., java, lisp, scheme, ada, matlab, ... apologies to those folks for whom I've missed mentioning their favorites) and tying a major feature of vim to one or two languages is probably not going to be universally appreciated. What I was advocating was the ability to use LALR grammars (read: yacc/bison) so that vim isn't tied to a particular language and, in fact, can be extended to cover future languages. The primary disadvantage is that effectively writing a new yacc/bison is not a small task. I have a real thick book about writing a yacc-like parser somewhere; if anyone's interested, I could look up its ISBN. Probably one could set up pipes to an external yacc or bison and avoid that problem, but that introduces the "external sort" type of problems people have had until vimgrep. If, in fact, a LALR parser is embedded a future GSOC would involve using it to do more accurate syntax highlighting. To support C++ and other object oriented languages would also involve symbol table handling. Sounds like a huge project to me to make it truly generic. I'm not sure I would like it; especially if I got yammered at for incomplete code. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Hello everyone, This is another student who is applying for the on-the-fly code checker project in GSoC. On Apr 14, 2:59 am, [EMAIL PROTECTED] wrote: > However, I do am interested in something able to understand C++ constructs in > order to built even more powerful code transformations and generations. > As such, this GSOC project may initiate the development of the API I'm > missing. > Hence I'm looking forward to it. Would it be useful to have a mechanism for Vim to do some "background" job? By using threads etc. Another feature becoming possible with this API would be an on-the-fly tags generator. When SOME threshold is reached, we can call a background thread to refresh the tags, which can be in turn reflected in the tags window (which is supplied in the Taglist plugin). But fine tunes should be given for the threshold. The same problem exists for syntax checker. Would anyone find this useful? Lin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Hello everyone, This is another student who is applying for the on-the-fly code checker project in GSoC. On Apr 14, 2:59 am, [EMAIL PROTECTED] wrote: > However, I do am interested in something able to understand C++ constructs in > order to built even more powerful code transformations and generations. > As such, this GSOC project may initiate the development of the API I'm > missing. > Hence I'm looking forward to it. Would it be useful to have a mechanism for Vim to do some "background" job? By using threads etc. Another feature becoming possible with this API would be an on-the-fly tags generator. When SOME threshold is reached, we can call a background thread to refresh the tags, which can be in turn reflected in the tags window (which is supplied in the Taglist plugin). But fine tunes should be given for the threshold. The same problem exists for syntax checker. Would anyone find this useful? Lin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Bram Moolenaar wrote: > Here is an update for the floating point patch. The 'g' argument for > printf() was implemented and a few bug fixes. > > This is to be applied to the original source code, without the older > floating point patch. > > I would still like feedback on the format of floating point numbers: > > &123.456 > &1.23e-3 > Hello! I have an alternative format: 123;456 ie. use semicolons instead of the ".". If the printing of them also uses semi-colons, they'll be a bit less likely to cause problems: let a=12;34 echo a 12;34 let b=string(a) "12;34" let c=eval(b) 12;34 I admit that I'm not sure if I like semi-colons better than the leading & myself -- although a semi-colon does have a "." of sorts embedded in it. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC Application
> Using eclipse, I believe it has a compilation system so that it > compiles while you write the code, while compiling it checks for > errors in the syntax, if there are any syntactical errors it will > underline them and make it known to the user and won't let the user > run the application until all of the errors are fixed. eclipse also does type-checking, method lookup and all the other stuff a compiler frontend does. > Implementing a similar system in vim, I believe the hardest problems > to deal with would be getting the compiler to compile often enough > so that the user could see the errors and correct them quickly, but > not so often as to affect the performance of the system. So updating > of the compilation would need to occur asynchronously, depenedant on > how much code is being written by the programmer and such. I believe > this to be the crucial part of the project, because if the plugin is > to be a feasible part of Vim, it needs to be so fast that the > programmer doesn't want to turn it off. http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascript-mode-for-emacs.html has some (lengthy, rambling ;-) ) discussion on asynchronous parsing. > I believe this could be accomplished with help from other projects > such as GCC, G++, who would know good ways to rapidly update the > compilation without affecting performance too greatly. A nice > feature would be to have a gradual compilation, where the project is > compiled as the programmer writes it, and so there is no big > compilation at the end. Such a system is evident in eclipse, and VS > has this as well. > > Any feedback on this is appreciated. As mentioned before, the clang project ( clang.llvm.org ) is an open- source frontend for C, C++ and ObjC. As far as I understand, Apple wants to use it in future XCode releases to do syntax highlighting, eclipse-like error highlighting, and refactoring. It is under active development by Apple employees and other contributors. It uses a library-based design, so you could run only the parser and not the type analysis for example. Writing your own frontend is madness :-) The real challenge is to come up with a general interface between vim and the language checking modules; writing a module for C with clang should be doable. Nico --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC Application
Hi Bram, Sorry for the delay in replying, been sick the past few days. I've applied to three other GSOC organizations, GNOME, Kate and Audacity. My Kate application is to create a vi-like modal system for Kate, along with improvements to the command-line konsolepart. Using eclipse, I believe it has a compilation system so that it compiles while you write the code, while compiling it checks for errors in the syntax, if there are any syntactical errors it will underline them and make it known to the user and won't let the user run the application until all of the errors are fixed. Implementing a similar system in vim, I believe the hardest problems to deal with would be getting the compiler to compile often enough so that the user could see the errors and correct them quickly, but not so often as to affect the performance of the system. So updating of the compilation would need to occur asynchronously, depenedant on how much code is being written by the programmer and such. I believe this to be the crucial part of the project, because if the plugin is to be a feasible part of Vim, it needs to be so fast that the programmer doesn't want to turn it off. I believe this could be accomplished with help from other projects such as GCC, G++, who would know good ways to rapidly update the compilation without affecting performance too greatly. A nice feature would be to have a gradual compilation, where the project is compiled as the programmer writes it, and so there is no big compilation at the end. Such a system is evident in eclipse, and VS has this as well. Any feedback on this is appreciated. Regards, Jonathan. On 12/04/2008, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > Jonathan - > > I'm still looking at the applications. > > You mention you have used Eclipse. So you know how it highlights errors > and warnings in Java code. If we want to do something similar in Vim, > can you think of the most difficult issues to be dealt with? > > You might want to respond to the vim-dev list and trigger a discussion > there. I'm also asking other students, we'll see what happens :-). > > - Bram > > > -- > A successful man is one who makes more money than his wife can spend. > A successful woman is one who can find such a man. > > > /// 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 > /// > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Updated floating point patch
John Beckett wrote:
> Bram Moolenaar wrote:
> > Here is an update for the floating point patch.
>
> I've done a bit more testing with the latest floating point patch.
> Vim's floating point doesn't need to cover all extremes, but the
> following shows some bad results.
>
> :help floating-point-format (in eval.txt)
> It says you can have negative number: &-0.123
> :let a = &-0.123
> Result: E112: Option name missing: &-0.123
> :let a = -&0.123
> This works but is inelegant.
I'll fix that.
> str2float('1.75') works by converting '1' to 1 and '75' to 75, then
> combining them (1 + 75/10^2). That gives a couple of problems. First,
> should probably document that a 32-bit machine won't keep 15 digits of
> precision in something like str2float('0.123456789012345').
>
> Second, the lhs and rhs of the '.' can each overflow an integer, giving chaos.
> :let a=str2float('0.3111222333')
> :echo a
> Result: -0.118374
How do you suggest to fix this?
> In the next example, Vim calculates (-1 + 0.75).
> :let a=str2float('-1.75')
> :echo a
> Result: -0.25
I'll fix that.
> Typo in eval.c ("sting" --> "string"):
> Convert the sting "text" to a floating point number.
I'll fix that.
--
You were lucky to have a LAKE! There were a hundred and sixty of
us living in a small shoebox in the middle of the road.
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Updated FP Patch - Not Setting $VIM Correctly
On 14/04/08 02:25, Bill McCarthy wrote:
> Hello Vim,
>
> Sorry if this shows up a second time - I didn't see it post.
>
> As with the first patch I installed the FP package to
> C:\vim\vim75.
>
> In the prior patch, this worked fine. In the new patch,
> although FP is working fine, my _vimrc is not being found.
>
> Started from C:\vim\vim75 or from C:\vim\vim75\src, an echo
> $vim reports C:\vim\vim75. This appears to be a bug.
>
> If I copy gvim.exe to my normal C:\vim\vim71, echo $vim
> correctly reports C:\vim.
>
> What's happening here?
>
It's not a bug, see ":help $VIM" item 3. Vim 7.1 will try removing
"vim71" from the directory from which it was started. That's what
vim{version} means. "vim75" would be the vim{version} of vim 7.5 but
it's vim 7.1 that you're using.
I recommend installing your executables into a single vim71 directory
but with different names such as gvim.exe and gvim-fp.exe (see the
paragraph below the list of executable names at ":help gvim" etc.).
Best regards,
Tony.
--
Canada Bill Jone's Motto:
It's morally wrong to allow suckers to keep their money.
Supplement:
A .44 magnum beats four aces.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
RE: Updated floating point patch
> -Original Message- > From: vim_dev@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Jürgen Krämer > Sent: 14 April 2008 10:09 > To: vim_dev@googlegroups.com > Subject: Re: Updated floating point patch > > > > Hi, > > Zdenek Sekera schrieb: > > > > But I am very uneasy with that leading ampersand. That's so different > > from any usual writing so it's looks somehow bizarre to me. > > I don't like the leading ampersand, either. > > > There are human languages where a floating is not necessarily > > written with a dot but with a comma, like this '1,71'. Not very > > transparent to those not used to it but it can be done. I had > > to learn the dot notation coming from the comma, took me short > > while before becoming natural, so I supposed it shouldn't be > > a big problem going the other way around. > > > > So 'let a=1,72+1,98' (no apostrophes of course) may not look so > obscene > > after a while to anybody. Even Windows and Linux OS/applications > > > > How would this change complicate the vim parser? Have I overlooked > > some obvious reason why this couldn't be considered? > > Yes; commas are used as argument separators in function calls. With a > comma as decimal separator you wouldn't know, if > > :call MyFunc(123,456) > > call MyFunc() with two integer or one floating-point arguments. Right, obvious, forgot about that! ---Zdenek --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
Hi, Zdenek Sekera schrieb: > > But I am very uneasy with that leading ampersand. That’s so different > from any usual writing so it’s looks somehow bizarre to me. I don't like the leading ampersand, either. > There are human languages where a floating is not necessarily > written with a dot but with a comma, like this ‘1,71’. Not very > transparent to those not used to it but it can be done. I had > to learn the dot notation coming from the comma, took me short > while before becoming natural, so I supposed it shouldn’t be > a big problem going the other way around. > > So ‘let a=1,72+1,98’ (no apostrophes of course) may not look so obscene > after a while to anybody. Even Windows and Linux OS/applications > > How would this change complicate the vim parser? Have I overlooked > some obvious reason why this couldn’t be considered? Yes; commas are used as argument separators in function calls. With a comma as decimal separator you wouldn't know, if :call MyFunc(123,456) call MyFunc() with two integer or one floating-point arguments. jkr -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin) --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Updated floating point patch
Sorry for pre-posting but it is difficult to post-reply to an HTML text. (Do we need HTML for emails???) Anyway, somehow it seems to me this feature is a solution looking for a problem. For a long time the good (not necessarily liked) principle was to add a feature (and I like features!) when it is demanded/useful, not simply nice-to-have. Well I don't think this has ever been seriously requested in any vim polls-for-features. Well, it's here, hallelujah. But I am very uneasy with that leading ampersand. That's so different from any usual writing so it's looks somehow bizarre to me. There are human languages where a floating is not necessarily written with a dot but with a comma, like this '1,71'. Not very transparent to those not used to it but it can be done. I had to learn the dot notation coming from the comma, took me short while before becoming natural, so I supposed it shouldn't be a big problem going the other way around. So 'let a=1,72+1,98' (no apostrophes of course) may not look so obscene after a while to anybody. Even Windows and Linux OS/applications can be configured to print floating with commas by default, can't they? How would this change complicate the vim parser? Have I overlooked some obvious reason why this couldn't be considered? Cheers, ---Zdenek From: vim_dev@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Yakov Lerner Sent: 14 April 2008 07:15 To: vim_dev@googlegroups.com; Bram Moolenaar Subject: Re: Updated floating point patch On Sat, Apr 12, 2008 at 4:58 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Here is an update for the floating point patch. The 'g' argument for printf() was implemented and a few bug fixes. This is to be applied to the original source code, without the older floating point patch. I would still like feedback on the format of floating point numbers: &123.456 &1.23e-3 When left operand is number, can you require space around '.' concatenation operator, otherwise '.' is floating point ? Who needs concatenation of two constants anyway ? 123.456 " floating number 123 . 456 " concatenation of "123" and "456" 123. 456 " floating number 123. concatenated with "456" 123 .456 " integer 123, space, floating .456 123.e2 " floating number 123 . e2 "concatenation of number and variable 123. e2 "floating number, space, variable e2 123 .e2 "concatenation ? Maybe backward-compatibility option for that ? (treat 123.456 as concat vs floating ?) Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
Re: Updated floating point patch
On Mon, Apr 14, 2008 at 7:14 AM, Yakov Lerner <[EMAIL PROTECTED]> wrote: >123. 456 " floating number 123. concatenated with "456" Correction: 123. 456 " floating number 123. , space, integer 456 --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
