Re: Floating point syntax

2008-06-06 Fir de Conversatie Tony Mechelynck

On 05/06/08 05:05, Bill McCarthy wrote:
 On Wed 4-Jun-08 3:42pm -0600, Bram Moolenaar wrote:

 Anyway, here is a patch to accept plain floating point numbers.  Goes on
 top of the previous floating point patch.  Give it a try and find out if
 any of your scripts break.

 My eval.c is the current release patched by both your latest
 and John Beckett's fix.  You new patch fails with:

 vim\vimfp  patch -b -p 0 -i Brams-may_not_work_with_jb.diff
 patching file src/eval.c
 Hunk #1 FAILED at 4799.
 1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

 I'm not great at reading patch files, but my eval.c does
 contain:

 ===
  case '7':
  case '8':
  case '9':
  vim_str2nr(*arg, NULL,len, TRUE, TRUE,n, NULL);
  *arg += len;
  if (evaluate)
  {
  rettv-v_type = VAR_NUMBER;
  rettv-vval.v_number = n;
  }
  break;

  /*
   * String constant: string.
 ===

 So it looks like - to me - that you patch should patch.


Works for me:

linux:~/.build/vim-test/vim71 # patch --dry-run -p0patches/Floating\ 
point\ noampersand.eml
(Stripping trailing CRs from patch.)
patching file src/eval.c
Hunk #1 succeeded at 4998 (offset 199 lines).
linux:~/.build/vim-test/vim71 #


Best regards,
Tony.
-- 
Getting an education at the University of California is like having
$50.00 shoved up your ass, a nickel at a time.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-06 Fir de Conversatie Bram Moolenaar


Tony Mechelynck wrote:

 On 04/06/08 21:40, Ilya Bobir wrote:
 [...]
  If there are no scripts that use two numbers with a dot in between
  without interleaving spaces then it follows that there are none that
  have these kind of numbers with an exponent appended.  And it means that
  if the float syntax will be smart enough to tell a float without an
  exponent from a concatenation then adding an exponent as a suffix will
  not introduce any ambiguity.  Am I missing something?
 
  Ilya Bobir
 
 What about 2.e32 ?

I think it's OK to not allow that and insist on using 2.0e32.
Just like you can't do .5 but need to use 0.5 instead.

Rationale:
let e32 =  times a day
echo 2.e32
   2 times a day
echo 3.e32
   3 times a day

This actually makes sense, so we should keep this backwards compatible.
The reasoning that 2.0 is currently not used is that it's not useful to
have this in a Vim script, you would write 20 instead.

I'm not saying I have accepted the backwards compatibility problem with
doing floating point this way, we still need to find that one script
that breaks.

-- 
A)bort, R)etry, D)o it right this time

 /// 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: Floating point syntax

2008-06-06 Fir de Conversatie Ben Schmidt

Bram Moolenaar wrote:
 Tony Mechelynck wrote:
 
 On 04/06/08 21:40, Ilya Bobir wrote:
 [...]
 If there are no scripts that use two numbers with a dot in between
 without interleaving spaces then it follows that there are none that
 have these kind of numbers with an exponent appended.  And it means that
 if the float syntax will be smart enough to tell a float without an
 exponent from a concatenation then adding an exponent as a suffix will
 not introduce any ambiguity.  Am I missing something?

 Ilya Bobir
 What about 2.e32 ?
 
 I think it's OK to not allow that and insist on using 2.0e32.
 Just like you can't do .5 but need to use 0.5 instead.
[...]
 This actually makes sense, so we should keep this backwards compatible.
 The reasoning that 2.0 is currently not used is that it's not useful to
 have this in a Vim script, you would write 20 instead.

Absolutely.

Another corner case that I believe wasn't searched for with the regex is
simply 2e32 which is presently valid and almost equivalent to the above
(I think it is two expressions side by side which :echo then
concatenates with a space between).

 I'm not saying I have accepted the backwards compatibility problem with
 doing floating point this way, we still need to find that one script
 that breaks.

Is it worth changing it for just one script? I would say no. If a
handful of scripts, perhaps, because that may indicate that there are
many more in the wild that aren't publicly accessible, but just one I'm
not sure is enough evidence to go on.

Ben.




--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-06 Fir de Conversatie ThoML

 Another corner case that I believe wasn't searched for with the regex is
 simply 2e32 which is presently valid and almost equivalent to the above

If it's supposed to be a float I think it should IMHO be 2.0e32. This
format currently isn't supported for integers it seems.

BTW I'm glad to see that float will look like a naive user would
expect it. Thanks.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-05 Fir de Conversatie Bram Moolenaar


Nico Weber wrote:

  Yes, but most people appear to be OK with the 123.456 syntax.  Thus  
  if you want something else, you need to come up with good arguments.
 
 I still haven't seen any good arguments why an editor needs floating  
 point numbers at all, other than hey, it can be done without breaking  
 old scripts with just slightly awkward syntax :-)

We don't really need :sort either.  It's just that it's very
convenient to have sorting and floating point numbers for writing
scripts that manipulate text.

For myself, I often add up columns with amounts.  Works easy for
integers, currently doesn't work for floating point (it's doable, but
a lot of work to implement and you get overflow/underflow problems).

-- 
I learned the customs and mannerisms of engineers by observing them, much the
way Jane Goodall learned about the great apes, but without the hassle of
grooming.
(Scott Adams - The Dilbert principle)

 /// 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: Floating point syntax

2008-06-05 Fir de Conversatie John Beckett

Bill McCarthy wrote:
 My eval.c is the current release patched by both your latest
 and John Beckett's fix.  You new patch fails with:

 vim\vimfp patch -b -p 0 -i Brams-may_not_work_with_jb.diff
 patching file src/eval.c Hunk #1 FAILED at 4799.
 1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

I can't reproduce this error. Any chance that you're using a version of 'patch' 
that
fails if the patch includes CR characters, and you have CR??

There does appear to be one minor glitch in patch 307, namely that it includes
FEAT_FLOAT. However, it doesn't do any harm. Here is a blow-by-blow summary of
some tests I just did.

I took a clean (no patches) copy of Vim 7.1 source, then applied patches 1 to 
311
(no float patches).

Everything applied cleanly, although there was one trivial warning:
patching file src/config.h.in
Hunk #1 succeeded at 155 (offset -1 lines).

I then applied Bram's float patch issued 2008-04-13. There were lots of Hunk...
succeeded at... warnings, and one error:
patching file src/if_python.c
Hunk #1 FAILED at 1130.

Manual inspection showed that if_python.c already had the patch that the float 
patch
was trying to apply, so the FAILED message can be ignored. This is due to patch 
307
(applying to src/if_python.c) already including some float code.

I then applied my float patch issued 2008-04-16. There were four Hunk... 
succeeded
at... warnings.

I then applied Bram's float patch issued 2008-06-05. There was one Hunk...
succeeded at... warnings.

I also tried (on another copy of the source), reversing the last two steps. 
Exactly
the same results (and identical source produced).

I haven't had a chance to compile yet. A very quick look at the source suggests 
that
there should be no conflict between my patch and any of Bram's, so I don't know 
why
you got the failure.

John


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-05 Fir de Conversatie Bill McCarthy

On Thu 5-Jun-08 7:35am -0600, John Beckett wrote:
 Bill McCarthy wrote:

 My eval.c is the current release patched by both your latest
 and John Beckett's fix.  You new patch fails with:

 vim\vimfp patch -b -p 0 -i Brams-may_not_work_with_jb.diff
 patching file src/eval.c Hunk #1 FAILED at 4799.
 1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

 I can't reproduce this error. Any chance that you're
 using a version of 'patch' that
 fails if the patch includes CR characters, and you have CR??
...
 I then applied Bram's float patch issued 2008-06-05. There was one Hunk...
 succeeded at... warnings.

Thanks, John.  You were close.  I had the proper
'fileformat' settings.  However I foolishly copy and pasted
the patch instead of using my mail macro to dump the mail
into Gvim (using Unix mailbox format).  When I did a vimdiff
of the two patches I could clearly see that the tabs were
spaces in last night's patch which had failed.  With the
proper patch:

vim\vimfp patch -b -p 0 -i Bram-dec_point_experiment.diff
patching file src/eval.c
Hunk #1 succeeded at 5001 (offset 202 lines).

I made both Vim and Gvim - thanks for verifying that it
worked!

Bram, this patch is very nice.  Hopefully is will not break
others' code.

-- 
Best regards,
Bill


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Floating point syntax

2008-06-04 Fir de Conversatie Ben Schmidt

Hi, folks,

The earlier thread where Bram asked for comments on floating point
syntax, after quite a few suggestions were made and rejected for
compatibility reasons, petered out. However, two proposals were made
that I think had merit, and I wonder if people have additional comment
on them, and perhaps may see them if part of a new thread!

The first proposal was mine:

- I pointed out that there is actually possibly ambiguity in the current
   syntax unless a float is required to have a decimal point or exponent,
   as 123.456 could mean float 123.456 or float 123 (123.0) concatenated
   with integer 456. If the requirement is added, the ambiguity is
   removed, but 123 is invalid, which is a bit of a shame.

- I proposed an alternative syntax that I prefer and I think is likely
   to be more robust in the long run: enclosing floats in curly braces.
   E.g. {123.456}. Specifically, a set of curly braces would be taken to
   represent a float if and only if it is (1) not preceded by a valid
   variable name character and (2) contains a valid float. Nobody came up
   with any reason this would not work.

The second was a proposal to represent floats as numbers with decimal
points but no additional punctuation which was implicit in this report
from Ilya Bobir:

- I did a search for vim scripts that use concatenation operation
   between two numbers without interleaving space.  It appears that
   Google Code Search was able to find only 39 matches and all were
   false positives.

Nobody gave any reply to the message.

I would like to note, though, that this doesn't solve the problem for
exponent notation. However, I suspect a search of vim scripts containing
numbers of that form would yield even less results, though I have not
tried it. The search also doesn't take into account expressions that may
be built dynamically in vim scripts rather than being hard coded, but
again, I doubt many if any of these exist.

I personally would prefer either of these syntaxes to the notation with
the ampersand.

Do people have further comments/thoughts on this? Is Bram still
interested in hearing them?

The earlier thread which contains more details can be read here:

http://groups.google.com/group/vim_dev/browse_thread/thread/1c8806e536ec12cd

The relevant posts are at the end. The last 7 or so, which happen to
nicely form the second page of posts at present.

Ben.





--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-04 Fir de Conversatie Bram Moolenaar


Ben Schmidt wrote:

 The earlier thread where Bram asked for comments on floating point
 syntax, after quite a few suggestions were made and rejected for
 compatibility reasons, petered out. However, two proposals were made
 that I think had merit, and I wonder if people have additional comment
 on them, and perhaps may see them if part of a new thread!
 
 The first proposal was mine:
 
 - I pointed out that there is actually possibly ambiguity in the current
syntax unless a float is required to have a decimal point or exponent,
as 123.456 could mean float 123.456 or float 123 (123.0) concatenated
with integer 456. If the requirement is added, the ambiguity is
removed, but 123 is invalid, which is a bit of a shame.

The . operator only works on strings.  There is no automatic
conversion of a float to a string, so a . after a float is invalid.
And with a single . it's part of the float, no matter what follows.

 - I proposed an alternative syntax that I prefer and I think is likely
to be more robust in the long run: enclosing floats in curly braces.
E.g. {123.456}. Specifically, a set of curly braces would be taken to
represent a float if and only if it is (1) not preceded by a valid
variable name character and (2) contains a valid float. Nobody came up
with any reason this would not work.

It would work, but I think 123.456 looks better than {123.456}.  And we
might want to use {} for something else (if possible, since it's already
used for curly-braces-names).

 The second was a proposal to represent floats as numbers with decimal
 points but no additional punctuation which was implicit in this report
 from Ilya Bobir:
 
 - I did a search for vim scripts that use concatenation operation
between two numbers without interleaving space.  It appears that
Google Code Search was able to find only 39 matches and all were
false positives.
 
 Nobody gave any reply to the message.

I wonder how you do that search.  And if you manage to come up with the
right pattern, what the number of matches actually means.

 I would like to note, though, that this doesn't solve the problem for
 exponent notation. However, I suspect a search of vim scripts containing
 numbers of that form would yield even less results, though I have not
 tried it. The search also doesn't take into account expressions that may
 be built dynamically in vim scripts rather than being hard coded, but
 again, I doubt many if any of these exist.
 
 I personally would prefer either of these syntaxes to the notation with
 the ampersand.
 
 Do people have further comments/thoughts on this? Is Bram still
 interested in hearing them?

Yes, but most people appear to be OK with the 123.456 syntax.  Thus if
you want something else, you need to come up with good arguments.

 The earlier thread which contains more details can be read here:
 
 http://groups.google.com/group/vim_dev/browse_thread/thread/1c8806e536ec12cd
 
 The relevant posts are at the end. The last 7 or so, which happen to
 nicely form the second page of posts at present.

-- 
It doesn't really matter what you are able to do if you don't do it.
(Bram Moolenaar)

 /// 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: Floating point syntax

2008-06-04 Fir de Conversatie Ilya Bobir

Bram Moolenaar wrote:
 [...]
 The second was a proposal to represent floats as numbers with decimal
 points but no additional punctuation which was implicit in this report
 from Ilya Bobir:

 - I did a search for vim scripts that use concatenation operation
between two numbers without interleaving space.  It appears that
Google Code Search was able to find only 39 matches and all were
false positives.

 Nobody gave any reply to the message.
 

 I wonder how you do that search.
I've explained how I did the search in my email on that thread.  
Probably you missed it, so I include this email here.  Here it goes:

Ilya Bobir wrote:
 Bram Moolenaar wrote:
   
 [...]

 I would still like feedback on the format of floating point numbers:

  123.456
  1.23e-3
   
 

 I did a search for vim scripts that use concatenation operation between two
 numbers without interleaving space.  It appears that Google Code Search was
 able to find only 39 matches and all where false positives.
 Here is the query:

 http://www.google.com/codesearch?hl=ruq=+lang:vim+%5E%5Cs*%5B%5E%22%5C+%5D(%22(%5C%5C.%7C%5B%5E%22%5D)*%22%7C%27%5B%5E%27%5D*%27%7C%5B%5E%22%5D)*%5Cs%5Cd%2B%5C.%5Cd%2B%5Cs+-menustart=30sa=N

 And here is a regex I've used (along with explanations). Maybe someone will
 double check to make sure I did not mistake.

 lang:vim   | Vim script language.
 ^\s*[^\ ] | In order to exclude comments the line should
|   start with anything but .
 (  | Catches different kind of strings.
  ( \\. | [^] )* | Double quoted strings along with escapes
|   inside the string.
 | ' [^']* '| Single quoted strings.
 | [^] | All the rest is OK.  And there maybe some
|   staff preceding the digits.
 )* |
 \s\d+\.\d+\s   | A pattern that I was looking for - two numbers
|   concatenated without an interleaving space
|   that are not part of a longer sequence.
 -menu  | menu command uses dot separated numbers to set
|   priority.  There are plenty of them and all
|   are false positives, so remove all lines with
|   menu string in them.
   

If something is hard to understand, please ask, I'll try to explain 
another way.  English is not my native language and sometimes I really 
have no clue whether what I write is understandable at all =)

   And if you manage to come up with the
 right pattern, what the number of matches actually means.
   

The number of matches is the number of lines that have two numbers 
concatenated without interleaving spaces.  A real match would mean that 
adding a common syntax for floats into Vim script would break a script 
with the match.
It appeared that all 39 matches was false positives meaning that all of 
them was really something else and was matched only because the pattern 
I've used it not perfect.  I checked all 39 matches by hand.  You can 
easily see them by following a link in my original e-mail that I've 
quoted above.
To sum it up, it appears that among all the vim scripts that are indexed 
by Google there are none that use the common float syntax to 
concatenate two numbers.  This means using the common syntax for 
floats will not break any of these scripts.
There still is a chance that some scripts use dynamically generated 
expressions that have two numbers concatenated without interleaving 
spaces but it is unlikely as one does not need a concatenation operation 
to concatenate numbers when building a dynamic expression - you can just 
put them in the result side by side.

 Ben Schmidt wrote:
 I would like to note, though, that this doesn't solve the problem for
 exponent notation. However, I suspect a search of vim scripts containing
 numbers of that form would yield even less results, though I have not
 tried it. The search also doesn't take into account expressions that may
 be built dynamically in vim scripts rather than being hard coded, but
 again, I doubt many if any of these exist.
 

If there are no scripts that use two numbers with a dot in between 
without interleaving spaces then it follows that there are none that 
have these kind of numbers with an exponent appended.  And it means that 
if the float syntax will be smart enough to tell a float without an 
exponent from a concatenation then adding an exponent as a suffix will 
not introduce any ambiguity.  Am I missing something?

Ilya Bobir

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-04 Fir de Conversatie Gary Johnson

On 2008-06-04, Bram Moolenaar [EMAIL PROTECTED] wrote:
 Ben Schmidt wrote:

  The second was a proposal to represent floats as numbers with decimal
  points but no additional punctuation which was implicit in this report
  from Ilya Bobir:
  
  - I did a search for vim scripts that use concatenation operation
 between two numbers without interleaving space.  It appears that
 Google Code Search was able to find only 39 matches and all were
 false positives.
  
  Nobody gave any reply to the message.

  I personally would prefer either of these syntaxes to the notation with
  the ampersand.
  
  Do people have further comments/thoughts on this? Is Bram still
  interested in hearing them?
 
 Yes, but most people appear to be OK with the 123.456 syntax.  Thus if
 you want something else, you need to come up with good arguments.

I've refrained from commenting so far because I haven't had anything 
to contribute other than that I really prefer to have floating-point 
numbers that look like floating point numbers.  Any other notation 
just looks silly.  In addition, when putting floating-point numbers 
in a script, or when copying and pasting them into a vim expression, 
I don't want to have to remember to adorn them with any special 
notation, or to have to think about whether the adornment is needed 
in that context.

The  prefix was thought to be needed to avoid breaking scripts that 
used . to concatenate two strings of digits.  Ilya has demonstrated 
that, at least for publicly accessible scripts, this is not a 
problem.

Using anything but the standard notation for floating-point 
numbers is going to lead to user confusion and errors.  If these 
numbers were a new thing that had to be learned by everyone, the 
notation wouldn't matter as much.  As it is, everyone knows how a 
floating-point number is represented in ASCII, so most people will 
use what they already know to write floating-point expressions in 
vim.  It won't occur to them that vim uses a unique notation.

For vim to depart from the conventional notation is aesthetically 
unpleasing, is going to cause problems, and at this point, seems to 
lack justification.

My $0.02.

Regards,
Gary


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-04 Fir de Conversatie Bram Moolenaar


Ilya Bobir wrote:

 Bram Moolenaar wrote:
  [...]
  The second was a proposal to represent floats as numbers with decimal
  points but no additional punctuation which was implicit in this report
  from Ilya Bobir:
 
  - I did a search for vim scripts that use concatenation operation
 between two numbers without interleaving space.  It appears that
 Google Code Search was able to find only 39 matches and all were
 false positives.
 
  Nobody gave any reply to the message.
  
 
  I wonder how you do that search.

 I've explained how I did the search in my email on that thread.  
 Probably you missed it, so I include this email here.  Here it goes:
 
 Ilya Bobir wrote:
  Bram Moolenaar wrote:

  [...]
 
  I would still like feedback on the format of floating point numbers:
 
 123.456
 1.23e-3

  
 
  I did a search for vim scripts that use concatenation operation between two
  numbers without interleaving space.  It appears that Google Code Search was
  able to find only 39 matches and all where false positives.
  Here is the query:
 
  http://www.google.com/codesearch?hl=ruq=+lang:vim+%5E%5Cs*%5B%5E%22%5C+%5D(%22(%5C%5C.%7C%5B%5E%22%5D)*%22%7C%27%5B%5E%27%5D*%27%7C%5B%5E%22%5D)*%5Cs%5Cd%2B%5C.%5Cd%2B%5Cs+-menustart=30sa=N
 
  And here is a regex I've used (along with explanations). Maybe someone will
  double check to make sure I did not mistake.
 
  lang:vim   | Vim script language.
  ^\s*[^\ ] | In order to exclude comments the line should
 |   start with anything but .
  (  | Catches different kind of strings.
   ( \\. | [^] )* | Double quoted strings along with escapes
 |   inside the string.
  | ' [^']* '| Single quoted strings.
  | [^] | All the rest is OK.  And there maybe some
 |   staff preceding the digits.
  )* |
  \s\d+\.\d+\s   | A pattern that I was looking for - two numbers
 |   concatenated without an interleaving space
 |   that are not part of a longer sequence.
  -menu  | menu command uses dot separated numbers to set
 |   priority.  There are plenty of them and all
 |   are false positives, so remove all lines with
 |   menu string in them.

 
 If something is hard to understand, please ask, I'll try to explain 
 another way.  English is not my native language and sometimes I really 
 have no clue whether what I write is understandable at all =)

It's not perfect and Google code search certainly doesn't contain every
Vim script, but it's an indication.

And if you manage to come up with the
  right pattern, what the number of matches actually means.
 
 The number of matches is the number of lines that have two numbers 
 concatenated without interleaving spaces.  A real match would mean that 
 adding a common syntax for floats into Vim script would break a script 
 with the match.

I meant: Since Google code search contains only a subset of all the Vim
scripts, what does it mean not to find a text string there that looks
like a floating point number?  There might be one very important Vim
script that breaks that isn't in Google code search.

[...]

Anyway, here is a patch to accept plain floating point numbers.  Goes on
top of the previous floating point patch.  Give it a try and find out if
any of your scripts break.


*** ../vim-7.1.311/src/eval.c   Thu May 29 21:46:10 2008
--- src/eval.c  Wed Jun  4 22:41:20 2008
***
*** 4600,4613 
  case '7':
  case '8':
  case '9':
!   vim_str2nr(*arg, NULL, len, TRUE, TRUE, n, NULL);
!   *arg += len;
!   if (evaluate)
{
!   rettv-v_type = VAR_NUMBER;
!   rettv-vval.v_number = n;
}
break;
  
  /*
   * String constant: string.
--- 4799,4847 
  case '7':
  case '8':
  case '9':
!   {
! #ifdef FEAT_FLOAT
!   char_u *p = skipdigits(*arg + 1);
!   intget_float = FALSE;
! 
!   /* We accept a float when the format matches
!* [0-9]\+\.[0-9]\+\([eE][+-]\?[0-9]\+\)\?.  This is very
!* strict to avoid backwards compatibility problems. */
!   if (p[0] == '.'  vim_isdigit(p[1]))
!   {
!   get_float = TRUE;
!   p = skipdigits(p + 2);
!   if (*p == 'e' || *p == 'E')
!   {
!   ++p;
!   if (*p == '-' || *p == '+')
!   ++p;
!   if (!vim_isdigit(*p))
!   get_float = FALSE;
!   else
!  

Re: Floating point syntax

2008-06-04 Fir de Conversatie Nico Weber

 Yes, but most people appear to be OK with the 123.456 syntax.  Thus  
 if
 you want something else, you need to come up with good arguments.

I still haven't seen any good arguments why an editor needs floating  
point numbers at all, other than hey, it can be done without breaking  
old scripts with just slightly awkward syntax :-)

Nico

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Floating point syntax

2008-06-04 Fir de Conversatie Bill McCarthy

On Wed 4-Jun-08 3:42pm -0600, Bram Moolenaar wrote:

 Anyway, here is a patch to accept plain floating point numbers.  Goes on
 top of the previous floating point patch.  Give it a try and find out if
 any of your scripts break.

My eval.c is the current release patched by both your latest
and John Beckett's fix.  You new patch fails with:

vim\vimfp patch -b -p 0 -i Brams-may_not_work_with_jb.diff
patching file src/eval.c
Hunk #1 FAILED at 4799.
1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

I'm not great at reading patch files, but my eval.c does
contain:

===
case '7':
case '8':
case '9':
vim_str2nr(*arg, NULL, len, TRUE, TRUE, n, NULL);
*arg += len;
if (evaluate)
{
rettv-v_type = VAR_NUMBER;
rettv-vval.v_number = n;
}
break;

/*
 * String constant: string.
===

So it looks like - to me - that you patch should patch.

-- 
Best regards,
Bill


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---