Seeing me freak out at solving maths equations, my mom used to say that solving maths problems is fun once you get the hang of it. I thought that she’s just telling me that to finish up my homework, but I now understand because its not that solving maths has become fun for me but I’ve found coding & solving problems in there to be fun, which apparently some people don’t. So logically speaking, when you get going in something, it starts looking fun to you, whatever it maybe, be it solving maths problems or logical equations while coding or cooking!!
But then since I’m into coding & this blog is about that, so lets stick to that, and while we are at it, I would like to announce the v3.5 of iG:Syntax Hiliter. This version is an update to the v3.1.1 and has bugfixes and new features and the new GeSHi engine(v1.0.7.6) and two new languages, Ruby and MySQL. While the Ruby language file was created by me, I’ve included the MySQL language file from the GeSHi package to allow for hiliting of MySQL specific SQL. But then, as you should know, since v3.0 you are no longer bound to the language files included with the plugin, you can use any language file supported by the GeSHi version bundled with the plugin. So what’s new in this release, some of you might ask & here’s what I’ve to say:
- Tested for compatability with both WP1.5.2 and WP2.0.1
- You can use any other BB tag based plugin with iG:Syntax Hiliter now. A check is done for the existence of the language file in the appropriate directory and if the language file is not present there, the code is returned as it is with the tags, no parsing done on it.
- Code posted in the comments can be hilited using the appropriate code tags. However this feature can be enabled/disabled from the admin interface of iG:Syntax Hiliter.
- A colour picker is now available for you to pick colours of the line numbers displayed with your code.
- A new type of “Plain Text” view of code is available that gives you the plain text code within the code box itself.
That’s apparently not all. There was a bug reported where the “C” language’s code was not being hilited & its been squashed. For full details, please refer to the Manual, its not very much but it has some details. π
So without any further ado, download iG:Syntax Hiliter v3.5. Any bugs etc. that you may find or have anything to say about the plugin, please leave a comment here or on the official thread at the WordPress support forums at http://wordpress.org/support/topic/10533.
Colourful Coding to you all!! π
UPDATE:- The new “Plain Text” view of displaying plain text code in the codebox itself is kinda experimental. It has one known problem of the codebox getting resized to a small height making it impossible to view the code if it contains 1-2 lines of code. This is being looked into, so if you have a problem with this, please don’t report it as a bug. Patience is a virtue. You can report anything else that’s not already reported!! π
UPDATE:- The thread at WordPress forums seems to have been closed by the moderators there!! I don’t know why since I’m quite infrequent at the forums there now, so all questions etc. regarding the plugin go here. π
Sweet!
I’ll install it when I get home later. Thanks for your hard work Amit!
Just installed it. I really like the new option to show the plaintext code right in the codebox as well as the ability to have code in the comments.
I am experiencing the following issues however.
1. Settings reset when changing plugins. This has been mentioned in previous posts. If I go to the Syntax Highlighter plugin options and set Show Language name and Show Line Numbers to false, then go to my WP plugins page and active a plugin that is not currently on, Syntax Highlighter will forget my settings.
2. language=”javascript” is not needed on the javascript links, in fact it can cause pages to not validate. I have already removed them from my own files, I suggest you remove them from the release.
3. Look at this URL:
http://www.projectarcanum.com/archive/2006/02/16/popular-posts-with-mint/#comment-114
The equal sign (=) in the code gets whited out. I have narrowed this down to when I turn off “Show Line Numbers”. If I leave that as on, the equal appears. This also only seems to effect equals in the comments.
5. With this same URL, if you click Plain Text the box collapses, changing in size so that only the first line is visible.
4. If you try to validate the above URL:
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.projectarcanum.com%2Farchive%2F2006%2F02%2F16%2Fpopular-posts-with-mint%2F
You will see that the syntax highlighter is inserting an end paragraph tag where this is no one open. Again, this problem only appears when “Show Line Numbers” is set to false.
Aside from these bugs the new version is great. I can answer any questions you have about my setup, hopefully we can get these bugs licked.
Silly me, I put 5 before 4.
Anyway, on number 5 (the one numbered 5), the problem also only occurs in comments.
Yes that’s been mentioned before but when I tested it on my WP2.0.1 test install, I wasn’t able to recreate this issue. I tried activating & deactivating a lot of plugins & never did the settings of iG:Syntax Hiliter change to default. Perhaps you can email me your WP admin username & password and I can look into what’s going on.
Again, this problem seems to be related to your styles. As you can see in this screenshot, switching off line numbers doesnot affect the code in anyway. π
That is a problem, seems like its there only with codeboxes having a line or two of code. I can’t brew a fix for this, except that we can use “min-height” CSS property but then that applies to only Opera & FireFox, not IE. Other way I can think of about it is to use a fixed height which again wouldn’t be cool!! If you’ve any suggestions, feel free to convey them!!
Well, the plugin doesn’t add any paragraph tags nor does it close them. That might be WordPress doing it!! Its because of you not using proper indentation of your code, because if you did then in the blank line you’ll have atleast 1 tab(every code editor I’ve used does this by default) which wouldn’t make WordPress think that its an end of a paragraph & so it won’t try to close it & start a new paragraph in the next code line. However when you have the Line Numbers enabled, then all your code is put in an ordered list which would prevent WordPress from putting in paragraphs at the end of a line as each line in that case is put in as a list item. Nothing I can do about it!! π
I will email you my login information so you can try and diagnose the settings reset problem. (note: its not like I expect you to fix it, its just that if looking at my site can help i would be happy to help).
Did you notice what I said about your javacsript?
Anyway, first to the paragraph thing. You were right about it being wordpress and about putting an indent on blanklines fixing it up! Thanks!
About the plain text collapse, its happening because sPlainCodeHTML in the javascript is not calculating the height value properly. I’m not good at javascript, so I dont know why. But I know its generating values too small, like 8px height for 3 lines of code. Even in a long box of code, it doesnt generate a high enough number to encompass the entire block of plain code.
A css way to deal with it would be to use min-height and height for IE. IE (6 and below) incorrectly treat height as min-height anyway. So if you did somethink like:
.syntax_hilite textarea {
min-height: x !important;
}
* html .syntax_hilite textarea {
height: x !important;
}
It would work as wanted in all browsers. I think the important is necessary as linked stylesheets are less priority then inline styles.
But what would you set the min-height too? I think the best solution is to figure out how to make the javascript work well.
Actually I just played around with min-height and it only helps so much. Another wierd thing about this is that the browser isn’t creting a vertical scroll bar within the text area. Its like it thinks its the correct size.
Would using the correct dom methods rather then innerHTML help perhaps? I would love to find a solution to this because I prefer the inplace plain text option very much.
About the dissapearing equal sign, it was indeed a style problem. I apologize, I am usually good about catching those.
OK, I emailed you my information. If you don’t get it feel free to contact me directly. Hopefully it will be of use to you figuring out the settings problem. If you need anymore information from me, feel free to ask.
Thanks for listening to my problems! I always feel bad when I point out problems that aren’t really the fault of whoever I am pointing them out too!
Yes, I did note that, but its a trival thing. It’ll be taken care of in the next update.
Yeah, that’s right!! I’ll look into it.
If you can point me to a link with some reference on what that will be, then I might look into it, since when I was doing this “Plain Text” feature, I did read up a bit on what to use and went with innerHTML since its supported by almost all browsers. First I tried a hand at using innerText but then not many support it, so I went with innerHTML & stripped out HTML tags from it.
I prefer it as well, the reason it being a default option & also on my blog!! π
No problem, we all make mistakes!! π
Got it & I’ve checked your blog, its not resetting all options, just 2-3 of them. I’ll look into it!!
No problem, the less bugs the better it is. Saves others a lot of trouble!! π
About the settings reset, I was poking around in syntax_hilite.php and I think the problem has to be with igSynHilite_Install(), as all the values that reset are all the ones that are set to ‘true’ in the $igSHOptionsArr array. So somewhere in there its not respecting if the options have been changed to false. I can poke around more, but being familiar with the code you would probably have more success.
About the javascript issue, like I said I suck with javascript, but one time I was having an issue with a clients site at work as it had to be served application/xhtml+xml which forces compatable browsers into a strict mode where innerHTML doesnt work (actually, in the new firefox, it would). So I had to look at alternatives to innerHTML. I can’t seem to find the page right now, but I believe you have to use createElement(), createElementNS(), createTextNode(), appendChild(). You can try searching Google for “xhtml innerhtml”. Sorry I can’t be more help on this. Javascript is my weakest language.
Hmmm…about the Javascript problem, perhaps it relates to the usage of a textarea. I just replaced the textarea with a div and now the sizing problem doesnt exist! There is a new problem of all the lines being dropped onto one line, but that could be solved by converting the ‘n’ newlines into linebreaks.
Would that work? What was your reason for using a textarea, to avoid having to encode any html?
I have something else you could look at if you want. Its only loosely related to Syntax Highliter, so feel free to ignore it. I use wp-print to produce print pages of my posts, like here:
http://www.projectarcanum.com/archive/2006/02/16/popular-posts-with-mint/print/
The syntax highlighted code looks pretty ugly in there, so I wanted to show plain text. What I did is modify wp-print so that before anything like wptexturize() or wpautop() can fire on the content, I use a preg_match borrowed from Syntax Highlighter to find any code blocks. I then do two things. First, I strip the code block of the starting and ending tags (
, for example) so that Syntax Highlighter doesnt fire. Then I run htmlentities() on the content between the blocks and insert it back into the main content
It works well as you can see in the linked post, with the only exception that it removes indents. Can you think of a way to make the indents work?
Actually, this could potentially help Syntax Highlighter. If we can create a plain text that works within a div and not a text area, then we can ditch the textarea that seems to be the source of the sizing glitch.
If I am annoying you with all my posts we can switch to email π
yeah you are right about that. I’ll look into it later today when I get some free time. π
As for Javascript issue, well, the createElement() etc. is not gonna help here. And that textarea disappearing, well, that seems to be a style dependent thing as well. If you see here on my test blog, there’s a single line codebox at the bottom & if you view it as plain text, it displays alright, doesn’t collapse like it does on your blog!! π Still I’ll see what can be done in this as well. π
No, you are not annoying. Discussing here will also be of help to any others & I’ll also be able to refer back later(I usually delete all emails except some important ones). π
when i remove the tags for image files aka xhtml
when i enter
i get
with a xsrc
what do you mean by that Jamie?
PS: remember, you can’t post any code here, it’ll be stripped out, so better show it in a text file hosted on your server!! π
it seems to adjust my code a bit. for example if i type in
img src=”” it would show up as
img xsrc=””
is there a way to turn the xhtml formatting off? thank you very much π
Jamie, as I’ve said repeatedly, your code isn’t modified by iG:Syntax Hiliter, so whether you write “src” or “xsrc” it doesn’t matter to the plugin!! And I don’t understand how come that’s happening, since I’ve never come across “xsrc” for “img” tag. You can however try turning off WordPress’ xHTML formatting by going to the Writing Options(in wp-admin) and unchecking the “WordPress should correct invalidly nested XHTML automatically” checkbox.
Thank you so much for your advice. I wonder if it could be something with my server. Since when I checked into the option you specified, it was already off. I will do some more checking and let you know if I find something. Thank you for your help so far. I love the look of this program and will get it working with my install π
You are welcome, & wait for it, an update will be released shortly that’ll fix some bugs in v3.5. π
Found a bug. If you don’t have WordPress installed in the same directory as your blog, then the JS and stuff doesn’t work.
This is the correct code to be using:
oh damn, I thought I had that fixed!! π ok, thanks for pointing out, I was preparing for an update anyway, so its been fixed & will be available soon!! π
I would like to inform that the tag can not be outputed with php code when I use it in [php-] [-/php]
Sorry the html tag has been filtered. It is tag br
what do you mean pcdinh? you mean you are trying to display <br /> in your PHP code and its not displaying? See here, its displaying alright!!
Hey,
Quoting:
“You will see that the syntax highlighter is inserting an end paragraph tag where this is no one open. Again, this problem only appears when Γ’β¬ΕShow Line NumbersΓ’β¬Β is set to false.”
Well, no this ahppens even with show line numbers on.
However, luckly its a simple fix. π
Simply after [ /code ] add a blank line then two breaks, that is then another blank line. Problem solved. π
Perhaps the plugin can auotmaticly do that?
Take Care,
Will