udevrules filetype detection

[Tony Mechelynck]

On my system, udev rules files are detected as filetype=hog rather than 
filetype=udevrules. I suggest the following patch:

*** ../vim71/runtime/filetype.vim   Wed Jun  4 13:50:01 2008
--- runtime/filetype.vimThu Jun  5 05:06:49 2008
***
*** 1783,1788 
--- 1783,1791 
   " SNMP MIB files
   au BufNewFile,BufRead *.mib,*.my setf mib

+ " Udev rules (must be before Snort *.rules)
+ au BufNewFile,BufRead /etc/udev/rules.d/*.rules setf udevrules
+
   " Snort Configuration
   au BufNewFile,BufRead *.hog,snort.conf,vision.conf   setf hog
   au BufNewFile,BufRead *.rulescall s:FTRules()
***
*** 2009,2017 
   " Udev conf
   au BufNewFile,BufRead /etc/udev/udev.confsetf udevconf

- " Udev rules
- au BufNewFile,BufRead /etc/udev/rules.d/*.rules setf udevrules
-
   " Udev permissions
   au BufNewFile,BufRead /etc/udev/permissions.d/*.permissions setf udevperm
   "
--- 2012,2017 



Best regards,
Tony.
-- 
Very few profundities can be expressed in less than 80 characters.

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

Re: Floating point syntax

[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
-~--~~~~--~~--~--~---

Re: Patch 7.1.306

[Bill McCarthy]

On Wed 4-Jun-08 3:59am -0600, Bram Moolenaar wrote:

> Patch 7.1.306

I also found 307-311 on the ftp site.  After deleting from
the patches those portions applicable to runtime files (such
as optwin.vim), they built fine.

I then turned to floating point (which I last updated at
305).  Only if_python.c and version.c needed to be updated
(or so I thought).

After the patch to if_python.c failed completely, version.c
patched fine.

On further inspection I see that the standard if_python.c is
already patched for floating point.  So I just copied it and
my floating point versions of vim and gvim are at 311.

Since eval.c didn't change, I didn't need to apply John
Beckett's fp patch - will that be included?

I didn't have any of Tony's problems.  I agree that it would
be great to have fp in the main distribution.

-- 
Best regards,
Bill


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

Re: How to start for newbie

[Andrei Aiordachioaie]

Hello,

I have recently started to work on the regular expression code ... In
short, last summer two students have implemented a new version of the
regular expression engine. However, it is not yet included in the main
source code of Vim. As part of Google Summer of Code, my project deals
with including the new version of the regexp engine into vim, testing
it and making sure it does not break anything.

If you're still interested, I have a couple of notes on the
implementation of regexps at  
http://code.google.com/p/vim-soc2008-regexp/wiki/Regexp_Interface_Both_Engines
. You are more than welcome to also browse through the sources in the
project (just go to the "Source" tab).

Also, a very good article about regular expressions and their
efficient implementation is by Russ Cox, at 
http://swtch.com/~rsc/regexp/regexp1.html
. I really recommend reading this article, it is very clear and
concise. It describes the non-deterministic finite automata (NFA)
method of dealing with regexps.

Cheers,
Andrei

On May 28, 6:33 pm, Guang Yang <[EMAIL PROTECTED]> wrote:
> I want to start read vim source code from regular expression, but I found it 
> really hard for a newbie. Do you have any suggestion about how to start? I 
> think it is better we make this post a guideline for all the people who want 
> to contribute this gread project.
> _
> Discover the new Windows 
> Vistahttp://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Floating point syntax

[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

[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=ru&q=+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+-menu&start=30&sa=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 == '+')
!

Re: Floating point syntax

[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

[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=ru&q=+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+-menu&start=30&sa=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
-~--~

Including a new language (ECL) in Vim?

[Mikael Jansson]

Hi,

I've picked up the work by the SlimVim project 
 and applied it onto the latest version of 
Vim, but removed the controversial (and supposedly still buggy) 
asynchronous network IO functionality.

There is still some work to do, but when that is fixed, I hope to be 
able to contribute a patch I suitable for inclusion in the official Vim 
distribution.

Work-in-progress, based on [EMAIL PROTECTED]

svn diff \
https://svn.jansson.be/public/limp/vim-ecl/r1024 \
https://svn.jansson.be/public/limp/vim-ecl/vim

So, given a patch I'm happy with, how would I go about packaging it for 
review and what else that needs to be done?


--
Mikael Jansson
http://mikael.jansson.be

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

Re: Floating point syntax

[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: Patch to allow ctermfg or bg values as #rrggbb

[Richard Musil]

On Dec 21 2007, 6:44 am, "Matt Wozniski" <[EMAIL PROTECTED]> wrote:
> So, I'd appreciate comments.  The reworked patch can be found:
http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff
(source, against SVN)
http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff
(runtime, against latest AAP)

I have tried your patches on recent vim71 ([EMAIL PROTECTED]). They applied
with few small corrections. I would post the fix, but googlegroups
does not allow me include file :(. When trying to figure out, how
properly "publish" hexhex2nr I got lost, since originally it seemed
like FEAT_SYN_HL is needed, but later on it seemed that in fact
FEAT_EVAL might be sufficient to trigger scheme file loading, even
though help clearly says that +syntax is required.

Then I used the regex script posted here:
http://www.cs.drexel.edu/~mjw452/ctermrgbify-scheme.vim

to convert my favorite scheme (darkblue). With small tweak of
background color (which was too light on xterm-256color compared to
gVim running on Windows) I got almost the same coloring. So far so
good.

Then I found out that it is possible to use RGBified scheme with this
script:
http://www.vim.org/scripts/script.php?script_id=1809

and it works the same way as your patch (well, on the first look).

So now I wonder, if it is worthy the hassle of patching, when in fact,
the same thing could be done just by script. Also it seems that the
point raised here about different colors for 16 and 256 is valid. For
example on darkblue-rgb I had to make blue background slightly darker,
so it will match black on 256 approximation rather than blue (which
was too blue to my likings.).

Richard

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

Floating point syntax

[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: Patch 7.1.306

[Tony Mechelynck]

On 04/06/08 17:24, Bram Moolenaar wrote:
> Tony Mechelynck wrote:
>
>> On 04/06/08 10:59, Bram Moolenaar wrote:
>>> Patch 7.1.306
>>> Problem:Some Unicode characters are handled like word characters while
>>> they are symbols.
>>> Solution:   Adjust the table for Unicode classification.
>>> Files:  src/mbyte.c
>> After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
>> received the latter two by email)
>>
>> if_python.c: In function ‘VimToPython’:
>> if_python.c:1157: warning: format ‘%f’ expects type ‘double’, but
>> argument 3 has type ‘long int’
>
> Are you sure you patched OK?  I see:
>
>   sprintf(buf, "%f", our_tv->vval.v_float);

sprintf(buf, "%f", (long)our_tv->vval.v_float);

That's part of that hulk which didn't apply, see below. I'll remove the 
typecast by hand.

Here's the exact text I have there, from #ifdef to #endif plus three 
lines of context either side, before removing that typecast:

result = Py_BuildValue("s", buf);
PyDict_SetItemString(lookupDict, ptrBuf, result);
 }
#ifdef FEAT_FLOAT
 else if (our_tv->v_type == VAR_FLOAT)
 {
char buf[NUMBUFLEN];

/* For backwards compatibility numbers are stored as strings. */
sprintf(buf, "%f", (long)our_tv->vval.v_float);
result = Py_BuildValue("s", buf);
PyDict_SetItemString(lookupDict, ptrBuf, result);
 }
#endif
 else if (our_tv->v_type == VAR_LIST)
 {
list_T  *list = our_tv->vval.v_list;


>
> That is clearly a double argument.
>
>> also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
>> version but on eyeball inspection it was already included, though with
>> an additional comment in the middle (hunk #10 at 1130, bracketed between
>> #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
>> feature could now be made a part of the "standard" sources? Of course,
>> if anyone gets cold feet, it can still be disabled at compile-time by
>> commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
>> similar)
>
> The FEAT_FLOAT parts in if_python shouldn't hurt, since FEAT_FLOAT isn't
> yet defined anywhere.  Unless you are using the experimental floating
> point patch, but then it should work (if you avoid patching the same
> thing twice).

I am, and the patch program didn't reapply that hulk. I didn't check the 
other hulks (the ones which succeeded, sometimes with fuzz); I hope 
they're OK -- normally your diffs should have enough context for that. I 
still have (in a parallel directory structure) the version without the 
float patch but that's not the one I "install".

>
> I still have a few fixes in the pipeline for the floating point patch.
>

Aha! I can hardly wait.


Best regards,
Tony.
-- 
BLACK KNIGHT: None shall pass.
ARTHUR:   I have no quarrel with you, brave Sir knight, but I must cross
   this bridge.
BLACK KNIGHT: Then you shall die.
  "Monty Python and the Holy Grail" PYTHON (MONTY) 
PICTURES LTD

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

Re: Patch 7.1.306

[Bram Moolenaar]

Tony Mechelynck wrote:

> On 04/06/08 10:59, Bram Moolenaar wrote:
> >
> > Patch 7.1.306
> > Problem:Some Unicode characters are handled like word characters while
> > they are symbols.
> > Solution:   Adjust the table for Unicode classification.
> > Files:  src/mbyte.c
> 
> After applying patches 7.1.306 to 7.1.308 (of which I haven't yet 
> received the latter two by email)
> 
> if_python.c: In function 'VimToPython':
> if_python.c:1157: warning: format '%f' expects type 'double', but 
> argument 3 has type 'long int'

Are you sure you patched OK?  I see:

sprintf(buf, "%f", our_tv->vval.v_float);

That is clearly a double argument.

> also, one of 37 hunks of 7.1.307 failed to patch in the "floating point" 
> version but on eyeball inspection it was already included, though with 
> an additional comment in the middle (hunk #10 at 1130, bracketed between 
> #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point 
> feature could now be made a part of the "standard" sources? Of course, 
> if anyone gets cold feet, it can still be disabled at compile-time by 
> commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or 
> similar)

The FEAT_FLOAT parts in if_python shouldn't hurt, since FEAT_FLOAT isn't
yet defined anywhere.  Unless you are using the experimental floating
point patch, but then it should work (if you avoid patching the same
thing twice).

I still have a few fixes in the pipeline for the floating point patch.

-- 
Imagine a world without hypothetical situations.

 /// 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: Patch 7.1.306

[Tony Mechelynck]

On 04/06/08 10:59, Bram Moolenaar wrote:
>
> Patch 7.1.306
> Problem:Some Unicode characters are handled like word characters while
>   they are symbols.
> Solution:   Adjust the table for Unicode classification.
> Files:src/mbyte.c

After applying patches 7.1.306 to 7.1.308 (of which I haven't yet 
received the latter two by email)

if_python.c: In function ‘VimToPython’:
if_python.c:1157: warning: format ‘%f’ expects type ‘double’, but 
argument 3 has type ‘long int’

also, one of 37 hunks of 7.1.307 failed to patch in the "floating point" 
version but on eyeball inspection it was already included, though with 
an additional comment in the middle (hunk #10 at 1130, bracketed between 
#ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point 
feature could now be made a part of the "standard" sources? Of course, 
if anyone gets cold feet, it can still be disabled at compile-time by 
commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or 
similar)


Best regards,
Tony.
-- 
... so long as the people do not care to exercise their freedom, those
who wish to tyrranize will do so; for tyrants are active and ardent,
and will devote themselves in the name of any number of gods, religious
and otherwise, to put shackles upon sleeping men.
-- Voltarine de Cleyre

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

Patch 7.1.306

[Bram Moolenaar]

Patch 7.1.306
Problem:Some Unicode characters are handled like word characters while
they are symbols.
Solution:   Adjust the table for Unicode classification.
Files:  src/mbyte.c


*** ../vim-7.1.305/src/mbyte.c  Wed Feb 20 11:27:59 2008
--- src/mbyte.c Wed May 21 20:49:34 2008
***
*** 1973,1980 
{0x205f, 0x205f, 0},
{0x2060, 0x27ff, 1},/* punctuation and symbols */
{0x2070, 0x207f, 0x2070},   /* superscript */
!   {0x2080, 0x208f, 0x2080},   /* subscript */
!   {0x2983, 0x2998, 1},
{0x29d8, 0x29db, 1},
{0x29fc, 0x29fd, 1},
{0x3000, 0x3000, 0},/* ideographic space */
--- 1973,1982 
{0x205f, 0x205f, 0},
{0x2060, 0x27ff, 1},/* punctuation and symbols */
{0x2070, 0x207f, 0x2070},   /* superscript */
!   {0x2080, 0x2094, 0x2080},   /* subscript */
!   {0x20a0, 0x27ff, 1},/* all kinds of symbols */
!   {0x2800, 0x28ff, 0x2800},   /* braille */
!   {0x2900, 0x2998, 1},/* arrows, brackets, etc. */
{0x29d8, 0x29db, 1},
{0x29fc, 0x29fd, 1},
{0x3000, 0x3000, 0},/* ideographic space */
*** ../vim-7.1.305/src/version.cThu May 29 22:41:19 2008
--- src/version.c   Wed Jun  4 10:54:36 2008
***
*** 668,669 
--- 673,676 
  {   /* Add new patch number below this line */
+ /**/
+ 306,
  /**/

-- 
Engineers are always delighted to share wisdom, even in areas in which they
have no experience whatsoever.  Their logic provides them with inherent
insight into any field of expertise.  This can be a problem when dealing with
the illogical people who believe that knowledge can only be derived through
experience.
(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
-~--~~~~--~~--~--~---