Possible bug in vb.vim or html.vim
I have run across a rather strange error in the syntax highlighting for either vb.vim or html.vim. I'm unsure which is causing the problem. Here are the circumstances under which this error occurs: I am developing an HTA program. An HTA program (for those who do not use Windows) is an HTML executable program. I'm using vbscript inside of the HTML via the script tag to write a small program. What happens is that if multiple lines of comments in a vbscript are placed together with several single character comments sparced between the longer comments, then for some reason all of the code is marked as Normal in the syntax coloring. Once this happens, various things such as the in IF statements turn red (I haven't figured out which syntax coloration this is) and other statements turn green (again, I am still tracking down which of the syntax commands this represents in my color scheme). I was wondering if anyone else has run across this problem? Here is (off the top of my head) an example of what seems to cause this problem: Example: html head titleTest Program/title script language=vbscript dim i dim a ' 'BEGIN DOC ' '-Calling Sequence: ' ' myFunc() ' '-Description: ' ' This function does nothing. ' '-Inputs: ' ' None. ' '-Outputs: ' ' None. ' 'END DOC ' set objFSO = CreateObject( whatever.FileSystem.Object ) set objFile = CreateTextFile( myfile.dat ) set anotherObj = About this time the lines should turn all one color. objFSO.stdout.Write I know this isn't good vbscript - it's just for show /script /head body Test program /body /html Usually, as the above line says, all of the lines turn one color. If this doesn't do it for you, then I'll see about sending some code from work that this happens on. But it will look a lot like the above. :-)
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!
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!
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: 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 contained
0x[g-zG-Z]\+\(\x\|_\x\)\+\(u\=l\{0,2}\|ll\=u\)\?
! syn match cHexError
Q: I'm working on the basic.vim file
I started using FreeBasic which uses the *.bas ending and was wondering if: 1. Anyone is interested in me sending in the updated basic.vim file. 2. If this is the right mailing group to send it to. Thanks! Mark
The c.vim file
In the syntax stuff, the c.vim file should be changed to have the following: Old: syn regioncStringstart=++ skip=+\|\\+ end=++ contains=cSpecial New syn regioncStringstart=++ skip=+\||'+ end=++ contains=cSpecial syn regioncStringstart=+'+ skip=+\|\\\'\|+ end=+'+ contains=cSpecial This would take care of the ..'. problem and the '' problem where strings run off the end of the line because of the embedded single quote and double quote. (Hopefully this goes through as text, Mozilla still has the HTML stuff at the top of the message.)
Hmmmmmm....
I get: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mail server after RCPT TO:[EMAIL PROTECTED]: host uk2mxarray3.uk2.net [83.170.64.215]: 550 address [EMAIL PROTECTED] disabled by user or upstream So I take it that Mr. Kelly is no longer reachable. Let me contact Bram and talk to him. :-)
Sorry
I'm working in FreeBasic and some C and some Perl. This is one of the fixes in the basic.vim thing I'm doing and I saw the same thing in the c.vim file and thought they would give the same incorrect highlighting. I ran into this (for C) while working at NASA and thought I'd fix it, but as you say - it already works in version 7.0.17. :-/ However, it does not work in the basic.vim or the perl.vim. If you try: test.pl print This's a test; exit( 0 ); The single quote makes the perl.vim rules think it is still in the single quoted area. The same if you do it the other way as well. Sorry for not checking the c.vim stuff before. It didn't work in the other two and I was going I'll fix it in all three! When I should have been going Let me check this out first! :-/ Oh well, what can I say but DOH! :-P Mark
Well....
That is very strange. In 7.0.17 the exit command is still highlighted as a string. If I put in an additional single quote then it re-highlights as a function. test.pl print This's a test'; exit( 0 ); Look correct but the test.pl print This's a test; exit( 0 ); Does not. Also the: test.pl a =END_TEXT; This's a test END_TEXT exit( 0 ); Also makes the exit command show up as a string versus function call. Which version do you have? Mark
New question
Hey, I hate to keep barging in here asking questions and such but here is a new one. :-) In the new basic.vim file I am having a problem. In FreeBasic you can use both single as well as double quotes to enclose a string. Unfortunately, you can also have comments which start with a single quote. So far I can capture and highlight correctly these three conditions: 1. REM Comment 2. Spaces'Comment 3. :SpacesComment What I can not get is the: 1. 'Comment Like so: test.bas rem This is a comment ' This is a comment : ' This is a comment ' This is a comment too but it doesn't properly highlight. Instead, it thinks it is a string. end Here are my commands: Comments syn matchbSpecialcontained \\. syn region bCommentstart=^rem end=$ contains=bSpecial,bTodo syn regionbCommentstart=:\s*' end=$ contains=bSpecial,bTodo syn regionbCommentstart=^\s*' end=$ contains=bSpecial,bTodo String and Character contstants syn regionbStringstart='' end='' contains=bSpecial,bTodo syn regionbStringstart=' end=' contains=bSpecial,bTodo Suggestions?
Possible addition to the c.vim and perl.vim syntax files
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. :-) Mark
Thanks!
Thanks for the info! :-) (Hit the reply button rather than Compose Mail To.) Mark
Binary, Octal, Decimal, Hex!
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. :-) Mark
Re: Update on the update
A.J.Mechelynck wrote: Mark Manning wrote: Ok, after downloading the current items on the web page at vim.org both C and Perl are working ok (in both Windows and Cygwin/Linux). Basic still has the problems from before. Thanks to everyone for speaking up. :-) To Tony: Thanks for the diff command. I'll see about posting it but not until after Bram has said it is ok. :-) I also see that the web page version of 7.0 is very out-of-date (If I put in echo version it comes back as 700. Even the 7.0.17 version comes back as 700 (which turns out to have been installed into /usr/bin instead of /usr/local/bin)). Ok. Now all I have to do is to rsync the Cygwin version and CVS the Windows one so they are both up-to-date. A few more minutes work. :-) 1. Next time, please use a more explicit Subject: line, and, if you continue a single conversation, use Reply to all rather than Write new mail. It makes a difference on mail clients which, like mine, can group posts by thread. 2. version will be 700 on all patchlevels of 7.0. To see the highest patch number included, see :intro, and to see them all, look at the first four lines of the output of :version. If the latter doesn't say Included patches: then you have an unpatched version. The latest patchlevel of 7.0 is currently 99; any new patches will be published by Bram in the vim-dev list. To test (in a script) whether such-and-such a patch was included, see :help has-patch. 3. Programs which come bundled with a Linux distribution will usually be installed in /usr/bin unless there's a reason to put them some other place (such as /usr/X11R6/bin or /opt/kde3/bin). /usr/local/bin intentionally comes ahead of all those places in the $PATH, so additional software added by the user will take precedence if the program name is the same. To see all the places in your $PATH where an executable named (e.g.) vim has been installed, and also all aliases (if any) for vim, use (in bash or similar shell) type -a vim If there is more than one, the first one listed is the one which will be invoked when you type just vim at the shell prompt. Best regards, Tony. 1. Well, I didn't want to get an additional reply like you pointed out in the previous message that might have been the reason for the duplicate messages from everyone. So I guess you get one or the other. (ie: Duplicate messages or different subject line.) 2. Already knew this because someone else had already posted it. Sorry if #1 caused you to reply to an already replied to message. 3. Yeah, I know. :-) Thanks though for replying. Not trying to be rude or anything like that. I really DO like to get a reply and there is always a chance that something I had no idea about would be said. Like the rsync'ing. I usually just ftp everything down when I'm updating. Never thought about using rsync before. :-) So thanks for that again. :-) Mark
Hello! Well Met! And a possible bug. :-)
I believe I may have found an obscure bug. It is not a harmful bug. It
does not make VIM crash or do weird things. (Well, sort-of.) :-)
Here is how to reproduce it:
First you have to have a lot of open and close braces (}). They
do not have to be on the same line and in fact, this bug shows up better
if they are on separate lines. For example: This happened while I was
writing some Perl code and I had a lot of IF statements with their
trailing braces. These were inside of a subroutine so the last line of
the subroutine is, of course a brace. There were lots of subroutines
and I was cleaning up code by separating out the subroutines into
separate files. So my code originally looked like this:
main
.
.
.
sub a
{
if(){
if(){
}
}
}
sub b
{
more stuff
if(){
if(){
}
}
}
and so on...
Ok. So the problem happens when you delete sub b and then hit the
dd key to delete the blank line between sub a's ending close brace
and where sub b's starting line was. When you do this VIM pops up
onto the end of the brace for sub a. The thing is, is that the cursor
isn't _on_ the close brace - it is next to the close brace. So if you
then do a % VIM pops to the middle of the file rather than to the open
brace like it should do. (ie: Match braces.)
Like I said - it's not a terrible problem, it doesn't crash VIM, it's
just a what the heck!? kind of thing and it took me a while to realize
that I was not doing something myself wrong and that it had more to do
with how VIM treated the deletion of the other line and where it put the
cursor afterwards.
However, this also brings up the next thing. If, after deleting the
blank line you type the $ key, the curse will pop to the correct
location (ie:on the close brace). Does this mean that the cursor is
actually beyond the end of the line at that point? Could this cause
other problems with VIM?
Anyway, just a short note. Other than this, VIM works fine. Here is my
system information:
Two separate versions of VIM are doing this.
Version #1 of VIM:
VIM v6.1
Windows XP Pro
512MB of memory
250GB hard drive (lots of space)
Editing standard text files.
Version #2 of VIM:
Vim v7.0.1
Cygwin via Windows XP Pro
Same system so same everything else.
