winrestview() after PageDown
I see a case in which winrestview() work incorrectly after PageDown
near end-of-file. (This is in the context of scrollfix plugin.)
To reproduce:
% vim -u NONE -c 'so x.vim'# x.vim is below
:help help" have some text
:set nu" see line numbers
press seevral ArrowDown to see how x.vim works, works OK, cursor is on 5th line
G OK, cursor is on 5th line
-- now this seems to be a bug, cursor is at top line instead of 5th line
:echo g:last " g:last shows how the last winrestview() was performed
{'lnum': 7336, 'leftcol': 0, 'col': 1, 'topfill': 0, 'topline': 7332,
'coladd': 0, 'skipc
ol': 0, 'curswant': 1}
NB: 'topline' is 7332 but winrestview() incorrectly ignored the 'topline'.
The same wrong behaviour can be observed even with small 3-line file.
Yakov
-- x.vim -
:let g:scroll_fix=5
:let so=0
aug scrollfix
au!
au CursorMoved * :call ScrollFix()
aug END
function! ScrollFix()
if g:scroll_fix==0 | return | endif
if &so!=0 | set so=0|endif
" keep cursor on fixed visual line of the window
let dict = winsaveview()
if dict['lnum'] <= g:scroll_fix | return | endif
if dict['lnum'] - dict['topline'] + 1 == g:scroll_fix | return | endif
let dict['topline'] = dict['lnum'] - g:scroll_fix + 1
let g:last = dict
call winrestview(dict)
endfunction
-
syntax with different language inside
Hi All,I'm trying to write a syntax file for a grammar called wpm, a simplified version is attached as test.apm in the attachment. And the syntax file is wpm.vim .There are one perl code and one _javascript_. If you opened test.wpm with wpm.vim, only the perl code will be highlighted (but not _javascript_ code). But if you exchanged the two "syn include" line in wpm.vim, the _javascript_ code will be hilighted instead of perl code. Is there any problem in my syntax definition?Help appreciated.Victor test.wpm Description: Binary data wpm.vim Description: Binary data
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: It is fairly easy to check for inconsistencies in Binary, Octal, and Hex because they have a fixed format. Decimal is not as easy due to there being integers, reals, and general format numbers (ie: #e+/-#) which are all grouped into the "Decimal" category. I'll think about it though. Maybe I can come up with something. :-) Actually, as I was sitting here typing this it popped into my head that such a test would actually fall under the Variable category rather than the Decimal category since variables can start with any character or an underscore; the opposite would be to start with something like a decimal number. A possibility maybe. :-) What /are/ you talking about? If you're discussing syntax highlighting, numbers usually fall under then Number group. Some syntax definitions highlight a leading zero as Special, as it does have special meaning, as it in some languages denotes an octal number. I have no idea of what you mean by "inconsistencies". This "stream of thought" mode you're using is more suited for IRC, see http://www.vim.org/community.php. nikolai
Re: Binary, Octal, Decimal, Hex!
Nikolai Weibull wrote: This "stream of thought" mode you're using is more suited for IRC, see http://www.vim.org/community.php. Yes. BTW, this is the list for development of Vim. Many of these Emails don't belong to the development list. General questions about Vim should be asked in the other list (vim@vim.org) if they aren't much more suited for IRC anyway. Best wishes, Georg Dahn ___ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: Possible addition to the c.vim and perl.vim syntax files
Mark Manning did utter on 10/09/2006 23:52: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W" Two issues - you most likely want to add underscore to the range since it should be \w less the valid hex digits (the difference between 0x88_65 and 0x88-65 will then highlight), and you need to be able to allow for the unsigned and long integer suffixes are part of the hex value, e.g. 0x88ul The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) TTFN Mike -- I am Homer of Borg! Prepare to be... Ooo! Donuts!
Re: Convert to HTML patch. Opinions / Testing.
On Sat, Sep 09, 2006 at 07:03:14PM +0100, Edd Barrett wrote: > > Here is the patch: http://arameus.net/users/edd/vim-test/2html.vim.diff > > Also in the same directory you will see the output of my tests, please > test them on other browsers. I viewed the output using the following systems and browsers: Linux, Mozilla 1.7.12 Windows XP, Mozilla 1.7.12 and IE 6.0.2900.2180.xpsp_sp2_gds.050301-1519 Mac OS X, Mozilla 1.7.12, IE 5.2.3, OmniWeb 4.5, and Safari 1.3.2 Note that two of the Mac browsers are a couple of years old. The pages all looked pretty much the same. On IE/Mac, the CSS versions seemed to use slightly smaller fonts than the non-CSS versions. In several browsers, the CSS versions had a little more "white" space at the top of the screen than the non-CSS versions. (Maybe because of the tags?) I do not see any problems in my browsers, so I vote in favor of improved compliance with the W3 standards. Minor point: in http://arameus.net/users/edd/vim-test/xhtml_no_css.html (XHTML without CSS) there are some "empty" tags such as . Isn't the standard advice to add a space before the slash, as in ? I think this still complies with the standard, and it is supposed to be easier for some older browsers to parse. > I am completely new to your development community (but I've been using > vim for many years), so I aplogize if I have broken any coding style > rules/other rules. =) I like to think that we are not too picky. Thanks for the contribution. HTH --Benji Fisher
Re: testing patchlevel from script
On Sun, Sep 10, 2006 at 01:05:11PM +, Yakov Lerner wrote:
> How can a script test for specific patchlevel ?
> For example, I have vim 7.0.86 and I need to check in the script that
> patchlevel is >= 7.0.86. But v:version is 700. How ? It would be
> nice if to have patchlist available through some v: variable.
I agree that a List of patch numbers would be convenient. You can
test for a specific patch with has("patch86").
:help has-patch
HTH --Benji Fisher
Re: Binary, Octal, Decimal, Hex!
Nikolai Weibull wrote: On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: It is fairly easy to check for inconsistencies in Binary, Octal, and Hex because they have a fixed format. Decimal is not as easy due to there being integers, reals, and general format numbers (ie: #e+/-#) which are all grouped into the "Decimal" category. I'll think about it though. Maybe I can come up with something. :-) Actually, as I was sitting here typing this it popped into my head that such a test would actually fall under the Variable category rather than the Decimal category since variables can start with any character or an underscore; the opposite would be to start with something like a decimal number. A possibility maybe. :-) What /are/ you talking about? If you're discussing syntax highlighting, numbers usually fall under then Number group. Some syntax definitions highlight a leading zero as Special, as it does have special meaning, as it in some languages denotes an octal number. I have no idea of what you mean by "inconsistencies". This "stream of thought" mode you're using is more suited for IRC, see http://www.vim.org/community.php. nikolai Ok, here goes: Binary numbers usually have a leading specifier and can only contain a zero or one. Octal numbers usually have a leading specifier and can only contain the numbers 0-7 Hex numbers usually have a leading specifier and can only contain 0-9 and A-F. Decimail usually do not have a leading specifier, can have 0-9, a period, an "E", plus or minus, and in pretty much whatever combination you would like for it to be. So it is easier to say what it is than what it is not. Because unlike Binary, Octal, or Hex - there is no standard way to represent a decimal number. That is why there are three entries in the syntax files for how a number can be declared. We were talking about doing the opposite though. Creating an error syntax that would highlight the problems rather than just identifying whether or not a number was a decimal number. So my thoughts are that it can not be done in one command or maybe not easily. Got it now? Mark
Re: Binary, Octal, Decimal, Hex!
Georg Dahn wrote: Nikolai Weibull wrote: This "stream of thought" mode you're using is more suited for IRC, see http://www.vim.org/community.php. Yes. BTW, this is the list for development of Vim. Many of these Emails don't belong to the development list. General questions about Vim should be asked in the other list (vim@vim.org) if they aren't much more suited for IRC anyway. Best wishes, Georg Dahn Sorry, new to the list and I was told not to just send replies privately but to post them publicly. (Damned if you do - damned if you don't!)
On the "Return Receipt" problem
David Brown wrote: Mark Manning wrote: Thanks for the info! :-) (Hit the reply button rather than "Compose Mail To".) Would you mind configuring your email client to not insert a Disposition-Notification-To: header when sending to the vim list. Although most clients do ignore this, some ask every time one of your messages is visited. Thanks, David Brown I have set up a second e-mail program that doesn't request a return receipt so the problem should be taken care of now. Mark
Re: Binary, Octal, Decimal, Hex!
On Mon 11-Sep-06 3:02am -0600, Nikolai Weibull wrote: > This "stream of thought" mode you're using is more suited for IRC, see > http://www.vim.org/community.php. Alternately, the vim list is a good choice. And never add return receipt requests in posts to a mailing list. -- Best regards, Bill
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: It is fairly easy to check for inconsistencies in Binary, Octal, and Hex I'm afraid C does not notion of binary numbers. Yakov
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: Creating an error syntax that would highlight the problems rather than just identifying whether or not a number was a decimal number. Sure. A thought, though. This is going to get rather complex and how often have you actually mistyped a hexadecimal, binary, or decimal number? An octal is one thing, as a leading zero is sometimes mistakenly added, e.g., for alignment purposes or when pasting from a zero-padded output, when you really want a decimal, i.e., with eights and nines, not an octal. nikolai
Re: Binary, Octal, Decimal, Hex!
Hi! Sorry, new to the list and I was told not to just send replies privately but to post them publicly. (Damned if you do - damned if you don't!) No, you are not damned, it is just confusing if each of your replies starts a new thread. I have realized very late - after my previous mail -, that most of your numerous mails, which look like IRC postings each having a return receipt request, seem to be only one thread or so. Best wishes, Georg Dahn ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Binary, Octal, Decimal, Hex!
Yakov Lerner wrote: On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: It is fairly easy to check for inconsistencies in Binary, Octal, and Hex I'm afraid C does not notion of binary numbers. Yakov On some systems that answer is correct. On others it is not. :-)
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > > It is fairly easy to check for inconsistencies in Binary, Octal, and Hex > I'm afraid C does not notion of binary numbers. On some systems that answer is correct. On others it is not. :-) On some systems, the C compiler is standards compliant. On others, it is not. nikolai
Re: Patch 7.0.096
Hari Krishna Dara wrote: > On Sun, 10 Sep 2006 at 1:56pm, Bram Moolenaar wrote: > > > > > Patch 7.0.096 > > Problem:taglist() returns the filename relative to the tags file, while > > the directory of the tags file is unknown. (Hari Krishna Dara) > > Solution: Expand the file name. (Yegappan Lakshmanan) > > Files: src/tag.c > > I applied the patch and tested that it works in my scenario, thank you. > However, I see that the name is expanded only when the tags file is not > in the current directory, which means the results can have a mixture of > both absolute and relative names (if they are coming from different tag > files in different directories). this could create some weird issues > with looking up tags in one window and opening the file in another > window and if they have differe lcd. This also means, the results can't > be cached and used later on, as the current directory could change. Is > this intentional? > > One observation I made is that (on windows) the expanded path doesn't > include the drive letter unless the current directory and the directory > of the tags files are on different drives. I don't know if this is how > Vim normally behaves, but this means, they are not really absolute > paths, but relative to the current drive. > > I could always explicitly do a fnamemodify() on each of the files, so it > is not a big deal, but I am wondering how efficient fnamemodify() is, if > it involves simple string manipulation or OS calls. Normally relative file names work just fine. If you need a full path you can use fnamemodify() in a map() to change it. > There was also a request from me some time back to allow a limit > argument to the taglist() function such that its response can be > improved in scenarios involving large number of matches. Is there a plan > to provide a 7.0 patch for this feature? Not soon. -- MESKIMEN'S LAW There's never time to do it right, but always time to do it over. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: winrestview() after PageDown
Yakov Lerner wrote:
> I see a case in which winrestview() work incorrectly after PageDown
> near end-of-file. (This is in the context of scrollfix plugin.)
>
> To reproduce:
>
> % vim -u NONE -c 'so x.vim'# x.vim is below
> :help help" have some text
> :set nu" see line numbers
> press seevral ArrowDown to see how x.vim works, works OK, cursor is on 5th
> line
> G OK, cursor is on 5th line
>
> -- now this seems to be a bug, cursor is at top line instead of 5th line
> :echo g:last " g:last shows how the last winrestview() was performed
> {'lnum': 7336, 'leftcol': 0, 'col': 1, 'topfill': 0, 'topline': 7332,
> 'coladd': 0, 'skipc
> ol': 0, 'curswant': 1}
> NB: 'topline' is 7332 but winrestview() incorrectly ignored the 'topline'.
>
> The same wrong behaviour can be observed even with small 3-line file.
It works just fine for me. Both with 7.0 and with all the latest patches.
--
CRONE: Who sent you?
ARTHUR: The Knights Who Say Ni!
CRONE: Aaaagh! (she looks around in rear) No! We have no shrubberies here.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Possible addition to the c.vim and perl.vim syntax files
Mark Manning wrote: > I saw in the c.vim that there was an error statement for octal numbers. > There isn't one for hex numbers so I made one really quickly. If you > want, just put it into the c.vim file. :-) > > The test: > > syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W" > > The highlight command: > > hi link cHexError cError > > Of course, this needs to be approved by Bram first though. :-) I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. -- There are 10 kinds of people: Those who understand binary and those who don't. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Possible addition to the c.vim and perl.vim syntax files
Bram Moolenaar wrote:
Mark Manning wrote:
I saw in the c.vim that there was an error statement for octal numbers.
There isn't one for hex numbers so I made one really quickly. If you
want, just put it into the c.vim file. :-)
The test:
syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W"
The highlight command:
hi link cHexError cError
Of course, this needs to be approved by Bram first though. :-)
I don't know what the rules are in all kinds of C, but at least things
like 0x0L, 0x0u, 0x0UL are valid.
Using a match instead of region would be simpler.
Actually, I looked through the c.vim file and someone asked me to put
the "ul" on the end. But then I noticed that the part that looked for
underscores was not in c.vim. Here:
"syn matchcNumberdisplay contained
"0x\x\+\(u\=l\{0,2}\|ll\=u\)\>"
syn matchcHexdisplay contained
"0x\x\+\(u\=l\{0,2}\|ll\=u\)\>\|0x\x\+\(_\x\x\)\+\(u\=l\{0,2}\|ll\=u\)\>"
The commented out line is what is in the c.vim file. I changed the
cNumber to cHex since there is a cOctal I figured "Why not?". However,
I'm still working on consolidating it down. I'm thinking that if I
change the "\+" to a "\*" after the "\(_\x\x\)" that I might be able to
combine the two parts down to just one Like I said though, I'm still
working on it. :-/ Gotta go right now though, going on a job
interview. :-)
PS: In my c.vim file I also made sure to insert the cHex and cHexError
into all of the same places where cOctal and cOctalError were located.
Again, hopefully a diff is coming soon. :-)
Re: Possible addition to the c.vim and perl.vim syntax files
Bram Moolenaar wrote: Mark Manning wrote: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W" The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. -- Matthew KATE: Awesome Text Editor
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > >> It is fairly easy to check for inconsistencies in Binary, Octal, and Hex > > > I'm afraid C does not notion of binary numbers. > > Yakov > On some systems that answer is correct. On others it is not. :-) I'm aware of binary numbers in perl (0b101010101). But in C ? What exactly is syntax of "binary numbers in C" ? How does it look ? On which systems ? I never heard of "binary numbers in C" ... I am very curious to hear from you all details that you can provide. What exactly are those systems and how exactly the syntax looks ? Yakov
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: Mark Manning wrote: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W" The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. Mike -- I made that part of the program bullet proof, but not 2x4 proof!
Re: Possible addition to the c.vim and perl.vim syntax files
Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke wrote: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. Microsoft's compiler, being the non-standard aberration it is, of course uses 'i64' for 64-bit integral constants. I don't think we need to worry about supporting _that_ :-). -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
On 9/11/06, mwoehlke <[EMAIL PROTECTED]> wrote: mwoehlke wrote: > Mike Williams wrote: >> mwoehlke did utter on 11/09/2006 17:44: >>> Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. >>> >>> If one takes KATE's c.xml as canonical, supported suffixes (but not >>> necessarily on all build configurations) are all combinations of 'U', >>> 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, >>> UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. >> >> Standard C only allows the following suffixes (in lower or uppercase): >> >> u, ul, ull, l, lu, and llu. > > D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so > all of the above are case-insensitive. But you are saying that > 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would > not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. For the literature, see /The C Programming Language/, Second Edition, Section A2.5.1, "Integer Constants", p. 193. nikolai
Re: Convert to HTML patch. Opinions / Testing.
Hi Benji, You are absolutely correct. This must have slipped past me. I have ammended my patch. New patch is here: http://arameus.net/users/edd/vim-test/2html.vim.diff Thankyou for your support. Best Regards Edd PS, Does anyone know how to disable HTML sending in gmail? Ezalm does not like it when gmail sends a multiple mime types in a message. I'm having to use mozilla to post to your lists. I dont have this problem with the openbsd lists.
Re: Possible addition to the c.vim and perl.vim syntax files
Nikolai Weibull wrote: On 9/11/06, mwoehlke <[EMAIL PROTECTED]> wrote: mwoehlke wrote: > Mike Williams wrote: >> mwoehlke did utter on 11/09/2006 17:44: >>> Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. >>> >>> If one takes KATE's c.xml as canonical, supported suffixes (but not >>> necessarily on all build configurations) are all combinations of 'U', >>> 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, >>> UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. >> >> Standard C only allows the following suffixes (in lower or uppercase): >> >> u, ul, ull, l, lu, and llu. > > D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so > all of the above are case-insensitive. But you are saying that > 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would > not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. For the literature, see /The C Programming Language/, Second Edition, Section A2.5.1, "Integer Constants", p. 193. Since none of the standards are freely available (not that I can see, anyway), all I can tell you is what is widely supported, and 'll' seems to qualify. -- Matthew KATE: Awesome Text Editor
Re: testing patchlevel from script
Benji Fisher wrote:
On Sun, Sep 10, 2006 at 01:05:11PM +, Yakov Lerner wrote:
How can a script test for specific patchlevel ?
For example, I have vim 7.0.86 and I need to check in the script that
patchlevel is >= 7.0.86. But v:version is 700. How ? It would be
nice if to have patchlist available through some v: variable.
I agree that a List of patch numbers would be convenient. You can
test for a specific patch with has("patch86").
:help has-patch
HTH --Benji Fisher
$VIM/plugin/patchlist.vim start
" Global plugin to make a List of included patches
" Maintainer: A.J.Mechelynck <[EMAIL PROTECTED]>
" Last change: 2006 Sep 11
" Version: 0.0
" run once only
if exists("g:patchList")
finish
endif
" Let's assume a single version of Vim cannot have
" more than 999 patches.
" If that maximum is irrealistic, it can be changed.
if ! exists("g:maxPatch")
let g:maxPatch = 1000
endif
" g:patchList : ordered List of all included patch numbers
" g:patchArray : string of (g:maxPatch) digits
" g:PatchArray()[n] is has("patch{n}") for all n (1 <= n < g:maxPatch)
" g:PatchArray()[0] is always 1 to represent the unpatched release
let s:i = 1
let g:patchList = []
let g:patchArray = "1"
while s:i < g:maxPatch
let g:patchArray .= has("patch" . s:i)
if g:patchArray[s:i]
let g:patchList += [s:i]
endif
endwhile
unlet s:i
let g:ver_patch = (version / 100) . "." . (version % 100) . "." .
\ g:patchList[-1]
$VIM/plugin/patchlist.vim end
Re: testing patchlevel from script
On 9/11/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
[a way to create a list of what patches has been applied]
Here's a simpler version of that script that doesn't allow for patches
to be skipped. I don't know if the Vim build scripts actually allow
for patches to be skipped, and considering that later patches will
often depend on earlier ones, I can't see any reason why someone
wouldn't have applied patch i when they have applied patch j, where i
< j.
" Vim plugin file
" Maintainer: Nikolai Weibull <[EMAIL PROTECTED]>
" Latest Revision: 2006-09-11
if exists("g:patches")
finish
endif
let s:i = 1
let g:patches = [0]
while has("patch" . s:i)
call add(g:patches, s:i)
let s:i += 1
endwhile
unlet s:i
let g:version_string = (version / 100) . '.' . (version % 100) . '.' .
g:patches[-1]
nikolai
Re: testing patchlevel from script
On 9/11/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 9/11/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
[a way to create a list of what patches has been applied]
Here's a simpler version of that script that doesn't allow for patches
to be skipped. I don't know if the Vim build scripts actually allow
for patches to be skipped,
Yes it is allowed.
... and considering that later patches will
often depend on earlier ones, I can't see any reason why someone
wouldn't have applied patch i when they have applied patch j, where i
< j.
" Vim plugin file
" Maintainer: Nikolai Weibull <[EMAIL PROTECTED]>
" Latest Revision: 2006-09-11
if exists("g:patches")
finish
endif
let s:i = 1
let g:patches = [0]
while has("patch" . s:i)
call add(g:patches, s:i)
let s:i += 1
endwhile
unlet s:i
let g:version_string = (version / 100) . '.' . (version % 100) . '.' .
g:patches[-1]
I'd prefer
let g:full_version = version . sprintf("%03d", g:patches[-1])
because such version string is comparable for (<,<=,>,>=)
whereas g:full_version is not.
I'd consider patchlevel to be max # of hole-free sequence
of patches starting from 1 (I think patch numbers are 1-starting),
*not* max # of patch applied. The extreme example would be
single patch#100 applied (without patches 1-99) which does
*not* make patchlevel 100.
Yakov
Re: testing patchlevel from script
On Mon, Sep 11, 2006 at 08:55:50PM +0200, Nikolai Weibull wrote: > On 9/11/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: > > [a way to create a list of what patches has been applied] > > Here's a simpler version of that script that doesn't allow for patches > to be skipped. I don't know if the Vim build scripts actually allow > for patches to be skipped, and considering that later patches will > often depend on earlier ones, I can't see any reason why someone > wouldn't have applied patch i when they have applied patch j, where i > < j. The Vim build scripts have no knowledge of which patches have or haven't been applied. One can skip patches and an example of a situation where that might be done is if the patch applies to the extra tarball. If I'm not using that, I have no need for the patch(es) that apply to it. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Patch 7.0.100
Patch 7.0.100
Problem:"zug" may report the wrong filename. (Lawrence Kesteloot)
Solution: Call home_replace() to fill NameBuff[].
Files: src/spell.c
*** ../vim-7.0.099/src/spell.c Tue Aug 29 17:28:56 2006
--- src/spell.c Mon Sep 11 20:45:35 2006
***
*** 1483,1489
else if ((mode == FIND_COMPOUND || mode == FIND_KEEPCOMPOUND
|| !word_ends))
{
! /* If there is no flag or the word is shorter than
* COMPOUNDMIN reject it quickly.
* Makes you wonder why someone puts a compound flag on a word
* that's too short... Myspell compatibility requires this
--- 1483,1489
else if ((mode == FIND_COMPOUND || mode == FIND_KEEPCOMPOUND
|| !word_ends))
{
! /* If there is no compound flag or the word is shorter than
* COMPOUNDMIN reject it quickly.
* Makes you wonder why someone puts a compound flag on a word
* that's too short... Myspell compatibility requires this
***
*** 9336,9342
--- 9336,9345
{
fputc('#', fd);
if (undo)
+ {
+ home_replace(NULL, fname, NameBuff, MAXPATHL, TRUE);
smsg((char_u *)_("Word removed from %s"), NameBuff);
+ }
}
fseek(fd, fpos_next, SEEK_SET);
}
*** ../vim-7.0.099/src/version.cSun Sep 10 21:38:48 2006
--- src/version.c Mon Sep 11 21:36:13 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 100,
/**/
--
Be nice to your kids... they'll be the ones choosing your nursing home.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Binary, Octal, Decimal, Hex!
Yakov Lerner wrote: On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > >> It is fairly easy to check for inconsistencies in Binary, Octal, and Hex > > > I'm afraid C does not notion of binary numbers. > > Yakov > On some systems that answer is correct. On others it is not. :-) I'm aware of binary numbers in perl (0b101010101). But in C ? What exactly is syntax of "binary numbers in C" ? How does it look ? On which systems ? I never heard of "binary numbers in C" ... I am very curious to hear from you all details that you can provide. What exactly are those systems and how exactly the syntax looks ? Yakov Since I've been working with computers since the early 1970s and since I used B (the predecessor of C which was [and possibly still is] used in Canada), it is more than most likely that I am mixing and matching my languages or remembering an outdated version of C. Also, since at NASA (I was at NASA JSC in ClearLake/Houston) we had to do a lot of our own coding for various items (like a control chair so simulations could be done with the astronauts, or the fixed and motion based simulators, etc...) it is also likely that I was using macros someone else wrote to allow for binary input of numbers. (This was necessary in some cases because the hardware would only accept binary information some times. In many cases we would do inline assembly language within the C programs too.) The 70's and even the 80's were a dark time in computer programming because there were very few standards and not a lot of company's used them. (This is one of the really few things that Microsoft and Apple Computer helped to change. They do try to enforce the standards - on everyone else of course. Even though it seems they both also break their own standards every chance they get.) Like SGI which had it's own special interface for their graphic computers until X-Windows came along and then SGI switched to Linux as their OS basis. There were some "special" items to SGI's C to help handle the graphics in the pre-X-Windows days. Things became more standardized with X-Windows and then the Linux OS helped out even more. So take your pick. Don't really care. But there probably are still systems out there that have binary capabilities in their C languages to help out with whatever. Check out Sony's PlayStation 3. People are having to write very low-level code to get it to work. Makes me wonder if people are using C and if those compilers have special additions to them that would allow someone to write binary information directly to a part of the hardware to help boost the speed of it. If so, they might extend the C language via macros or a direct change to the compiler in order for everyone to get the most out of the computer. Still, I'm not going to rack my brain for exactly which system and where just because you want to know. It is not worth the time or effort on my part. Have fun! :-) Mark
Re: testing patchlevel from script
Nikolai Weibull wrote: On 9/11/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: [a way to create a list of what patches has been applied] Here's a simpler version of that script that doesn't allow for patches to be skipped. I don't know if the Vim build scripts actually allow for patches to be skipped, and considering that later patches will often depend on earlier ones, I can't see any reason why someone wouldn't have applied patch i when they have applied patch j, where i < j. Yes, patches may be skipped, as mentioned under ":help has-patch". Linux versions commercially distributed often skip all "extra" patches which are for other OSes: the admin in charge of compilation would download only the "unix" and "lang" archives, and the "unix" patches, skipping the rest. To use your example, a Linux admin may skip patch i if it is for Windows or Mac, and apply patch j (j>i) if it is for Unix or for all-platforms. A later Unix patch will never depend on an earlier Windows-only patch. Best regards, Tony.
Re: testing patchlevel from script
Yakov Lerner wrote:
On 9/11/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 9/11/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
[a way to create a list of what patches has been applied]
Here's a simpler version of that script that doesn't allow for patches
to be skipped. I don't know if the Vim build scripts actually allow
for patches to be skipped,
Yes it is allowed.
... and considering that later patches will
often depend on earlier ones, I can't see any reason why someone
wouldn't have applied patch i when they have applied patch j, where i
< j.
" Vim plugin file
" Maintainer: Nikolai Weibull <[EMAIL PROTECTED]>
" Latest Revision: 2006-09-11
if exists("g:patches")
finish
endif
let s:i = 1
let g:patches = [0]
while has("patch" . s:i)
call add(g:patches, s:i)
let s:i += 1
endwhile
unlet s:i
let g:version_string = (version / 100) . '.' . (version % 100) . '.' .
g:patches[-1]
I'd prefer
let g:full_version = version . sprintf("%03d", g:patches[-1])
because such version string is comparable for (<,<=,>,>=)
whereas g:full_version is not.
I'd consider patchlevel to be max # of hole-free sequence
of patches starting from 1 (I think patch numbers are 1-starting),
*not* max # of patch applied. The extreme example would be
single patch#100 applied (without patches 1-99) which does
*not* make patchlevel 100.
Yakov
(imaginary example) A Unix version might display
Applied patches: 1-5,7-13,17-25,27-42,48-55,58-60,62-66,69-74,77,79-85
in the ":version" listing and it would still display "Version 6.4.85"
near the top of the splash screen; and properly so, since patches
6,14-16,26,43-47,56,57,61,67,68,75,76 and 78 would quite possibly be
Windows and Mac patches. I remember Unix versions from 6.x which had
that kind of "applied patches". In this example, no one in his right
mind should consider such a version as "6.4.5".
Best regards,
Tony.
Re: Binary, Octal, Decimal, Hex!
On 9/12/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > >> Yakov Lerner wrote: >> >> > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: >> > >> >> It is fairly easy to check for inconsistencies in Binary, Octal, >> and Hex >> > I'm afraid C does not notion of binary numbers. >> On some systems that answer is correct. On others it is not. :-) > > > I'm aware of binary numbers in perl (0b101010101). But in C ? > What exactly is syntax of "binary numbers in C" ? How does it look ? > On which systems ? > I never heard of "binary numbers in C" ... > I am very curious to hear from you all details that you can provide. > What exactly are those systems and how exactly the syntax looks ? > > Yakov > ... Still, I'm not going to rack my brain for exactly which system and where Don't bother. C standard does not have binary numbers. (I'm sorry to disappoint you but B, immediate predecessor of C, did not have binary numbers, too). Yakov
adding additional network stuff in RealWaitForChar?
Hello all vimmers! I would like to ask - how should I add additional stuff in RealWaitForChar? I have some network protocol, when another side periodically send me keepalive messages(every 10-15 secs). I would like to receive them and process. In GUI based vim it was pretty simple -- using gdk_input_add or similar thing. In other hand I would like to console users have same benefits - I've added handlers in RealWaitForChar, but ... it processes only first message on it's own. All latter messages are received, but does not processed -- until I press some key periodically, thus causing remote site timeouting and aborting the connection. I've implemented it in a quite similar way to FEAT_MOUSE_GPM and USE_XSMP implementations. What can I miss there? Any recommendations where to look? Thanks in advance, Gaspar -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e [EMAIL PROTECTED]
Re: Patch 7.0.096
On Mon, 11 Sep 2006 at 6:20pm, Bram Moolenaar wrote: > > Hari Krishna Dara wrote: > > > On Sun, 10 Sep 2006 at 1:56pm, Bram Moolenaar wrote: > > > > > > > > Patch 7.0.096 > > > Problem:taglist() returns the filename relative to the tags file, while > > > the directory of the tags file is unknown. (Hari Krishna Dara) > > > Solution: Expand the file name. (Yegappan Lakshmanan) > > > Files:src/tag.c > > > > I applied the patch and tested that it works in my scenario, thank you. > > However, I see that the name is expanded only when the tags file is not > > in the current directory, which means the results can have a mixture of > > both absolute and relative names (if they are coming from different tag > > files in different directories). this could create some weird issues > > with looking up tags in one window and opening the file in another > > window and if they have differe lcd. This also means, the results can't > > be cached and used later on, as the current directory could change. Is > > this intentional? > > > > One observation I made is that (on windows) the expanded path doesn't > > include the drive letter unless the current directory and the directory > > of the tags files are on different drives. I don't know if this is how > > Vim normally behaves, but this means, they are not really absolute > > paths, but relative to the current drive. > > > > I could always explicitly do a fnamemodify() on each of the files, so it > > is not a big deal, but I am wondering how efficient fnamemodify() is, if > > it involves simple string manipulation or OS calls. > > Normally relative file names work just fine. If you need a full path > you can use fnamemodify() in a map() to change it. Yes, that is what I am doing. Is fnamemodify() an expensive operation involving OS calls? -- Thanks, Hari > > > There was also a request from me some time back to allow a limit > > argument to the taglist() function such that its response can be > > improved in scenarios involving large number of matches. Is there a plan > > to provide a 7.0 patch for this feature? > > Not soon. > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Possible addition to the c.vim and perl.vim syntax files
Ok, please find attached my corrections to the c.vim file. (Diff
instructions.) Many thanks go to Tony for his invaluable help.
Especially with the diff command.
Synopsis:
Because hex values have the suffixes and the underscores it took a while
to come up with something which would handle all of the various aspects
of and combinations of items. My simplest effort would catch the errors
but would also catch the unwanted errors as well. (ie: It was catching
errors it should not have caught because they were not errors reallys.)
Even this solution is not perfect because in some of the test cases the
trailing "ul" would sometimes turn light blue (which is - I believe
standard text/instructions in my color scheme) instead of the entire
number being bold white (my set-up for errors). Still, the hex values
would completely show up as an error. Which was my main goal.
Changes:
The main changes are that there is now a cHex and a cHexError. These
have been inserted into the same locations as cOctal and cOctalError
respectively. Although cHex only takes one line, the cHexError required
four separate lines. I've left the old cNumber line for catching
hexidecimal numbers in the file. I've tested these changes on about ten
different lines of code. So feedback is welcome if, for some reason,
you find they do not work properly.
Mark
*** c.vim Mon Sep 11 23:56:51 2006
--- /home/Mark/ftp/vim70/runtime/syntax/c.vim Mon May 1 03:39:56 2006
***
*** 67,73
"catch errors caused by wrong parenthesis and brackets
" also accept <% for {, %> for }, <: for [ and :> for ] (C99)
" But avoid matching <::.
! syn cluster cParenGroup
contains=cParenError,cIncluded,cSpecial,cCommentSkip,cCommentString,cComment2String,@cCommentGroup,cCommentStartError,cUserCont,cUserLabel,cBitField,cCommentSkip,cOctalZero,cCppOut,cCppOut2,cCppSkip,cFormat,cNumber,cFloat,cHex,cOctal,cOctalError,cHexError,cNumbersCom
if exists("c_no_curly_error")
syn region cParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cCppString,@Spell
" cCppParen: same as cParen but ends at end-of-line; used in cDefine
--- 67,73
"catch errors caused by wrong parenthesis and brackets
" also accept <% for {, %> for }, <: for [ and :> for ] (C99)
" But avoid matching <::.
! syn cluster cParenGroup
contains=cParenError,cIncluded,cSpecial,cCommentSkip,cCommentString,cComment2String,@cCommentGroup,cCommentStartError,cUserCont,cUserLabel,cBitField,cCommentSkip,cOctalZero,cCppOut,cCppOut2,cCppSkip,cFormat,cNumber,cFloat,cOctal,cOctalError,cNumbersCom
if exists("c_no_curly_error")
syn region cParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cCppString,@Spell
" cCppParen: same as cParen but ends at end-of-line; used in cDefine
***
*** 94,106
"integer number, or floating point number without a dot and with "f".
syn case ignore
! syn match cNumbersdisplay transparent "\<\d\|\.\d"
contains=cNumber,cFloat,cOctalError,cHexError,cOctal,cHex
" Same, but without octal error (for comments)
! syn match cNumbersCom display contained transparent "\<\d\|\.\d"
contains=cNumber,cFloat,cOctal,cHex
syn match cNumber display contained "\d\+\(u\=l\{0,2}\|ll\=u\)\>"
"hex number
! "syn matchcNumber display contained
"0x\x\+\(u\=l\{0,2}\|ll\=u\)\>"
! syn match cHexdisplay contained
"0x\(\x\|_\x\)\+\(u\=l\{0,2}\|ll\=u\)\>"
" Flag the first zero of an octal number as something special
syn match cOctal display contained
"0\o\+\(u\=l\{0,2}\|ll\=u\)\>" contains=cOctalZero
syn match cOctalZero display contained "\<0"
--- 94,105
"integer number, or floating point number without a dot and with "f".
syn case ignore
! syn match cNumbersdisplay transparent "\<\d\|\.\d"
contains=cNumber,cFloat,cOctalError,cOctal
" Same, but without octal error (for comments)
! syn match cNumbersCom display contained transparent "\<\d\|\.\d"
contains=cNumber,cFloat,cOctal
syn match cNumber display contained "\d\+\(u\=l\{0,2}\|ll\=u\)\>"
"hex number
! syn match cNumber display contained
"0x\x\+\(u\=l\{0,2}\|ll\=u\)\>"
" Flag the first zero of an octal number as something special
syn match cOctal display contained
"0\o\+\(u\=l\{0,2}\|ll\=u\)\>" contains=cOctalZero
syn match cOctalZero display contained "\<0"
***
*** 119,130
endif
" flag an octal number with wrong digits
! syn match cOctalError display contained "0\o+[89a-zA-Z]\+\d*"
! "syn matchcHexError display contained
"0x!\(\x\+\(u\=l\{0,2}\|ll\=u\)\>\)\|0x!\(\x\+\(_\x\x\)\+\(u\=l\{0,2}\|ll\=u\)\>\)"
! syn match cHexError display contained
"0x\(\x\|_\x\)\+[g-km-tv-zG-KM-TV-Z]\+\(u\=l\{0,2}\|ll\=u\)\?"
! syn match cHexError display containe
Re: adding additional network stuff in RealWaitForChar?
On 11/09/06, Gaspar Chilingarov <[EMAIL PROTECTED]> wrote: Hello all vimmers! I would like to ask - how should I add additional stuff in RealWaitForChar? I have some network protocol, when another side periodically send me keepalive messages(every 10-15 secs). I would like to receive them and process. In GUI based vim it was pretty simple -- using gdk_input_add or similar thing. In other hand I would like to console users have same benefits - I've added handlers in RealWaitForChar, but ... it processes only first message on it's own. All latter messages are received, but does not processed -- until I press some key periodically, thus causing remote site timeouting and aborting the connection. I've implemented it in a quite similar way to FEAT_MOUSE_GPM and USE_XSMP implementations. What can I miss there? Any recommendations where to look? Thanks in advance, Gaspar There is a patched Vim7 here (http://theclapp.org/repos/vim70+async+ecl/) that contains code to handle network callbacks. However, beware! I think there are subtle bugs in way this works with Vim's code path. You cannot just randomly go calling functions from RealWaitForChar (for example, appending text), and expect everything to be OK. You probably want to look in network_io.c and os_unix.c. Cheers Brad
Re: adding additional network stuff in RealWaitForChar?
Brad Beveridge wrote: > On 11/09/06, Gaspar Chilingarov <[EMAIL PROTECTED]> wrote: >> Hello all vimmers! >> >> I would like to ask - how should I add additional stuff in >> RealWaitForChar? I have some network protocol, when another side >> periodically send me keepalive messages(every 10-15 secs). I would like >> to receive them and process. In GUI based vim it was pretty simple -- >> using gdk_input_add or similar thing. In other hand I would like to >> console users have same benefits - I've added handlers in >> RealWaitForChar, but ... it processes only first message on it's own. >> All latter messages are received, but does not processed -- until I >> press some key periodically, thus causing remote site timeouting and >> aborting the connection. >> >> I've implemented it in a quite similar way to FEAT_MOUSE_GPM and >> USE_XSMP implementations. >> >> What can I miss there? Any recommendations where to look? >> >> Thanks in advance, Gaspar > > There is a patched Vim7 here > (http://theclapp.org/repos/vim70+async+ecl/) that contains code to > handle network callbacks. However, beware! I think there are subtle > bugs in way this works with Vim's code path. You cannot just randomly > go calling functions from RealWaitForChar (for example, appending > text), and expect everything to be OK. You probably want to look in > network_io.c and os_unix.c. > > Cheers > Brad > Thanks for that link. Yes, I've looked into patched version of Vim. At this moment I don't want to force alpha-testers to patch Vim with network_io.patch -- while it's not stable and not found it's way into main Vim repository. About messing with Vim function calls from inside RealWaitForChar - I'm warned already. Currently I need only respond to keep-alive messages. /Gaspar -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e [EMAIL PROTECTED]
