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. 🙂
I don’t see how I can help Manuel, there’s nothing broken in iG:Syntax Hiliter! The problem is with SmartyPants that it doesn’t gives the option to specify custom tags which it can skip while beautifying the rest of the quotes. 🙂
If you mean to suggest that I use the <code> tag for the hilighting purposes then that would mean making a big mess as a lot of people(including me) are already using the BB Code style tags for this plugin!
You can however modify the plugin for your own purposes, have it use <code> tag(like <code lang=”php”>) instead of BB Codes so that way you won’t have to put in <code> tag everytime manually. Or you can modify the quicktags for this plugin & put in <code> tag there so that you just click the quicktag button & the <code> tag will appear without you having to write it! 🙂
option no.1 would be splendid, mate! shall we continue to discuss this via email? your contact.php seems to be borked though, so I’ll wait for an email by you 🙂
manuel
I just figured out the problem many users have with this and other code highlighting plugins while writing code in visual/WYSIWYG mode (e.g. see comment by alexis above about the “>” problem). I made a simple hack for the same(link). Take a look
Manuel, you can do it yourself by editing the line #203 which is this:
Its a plain RegEx call, you can edit it so that it takes the code from between your desired tags instead of the BB Code tags that it takes currently. 🙂
Shantanu, its been said over & over again that if code is to be posted while using this plugin then the WYSIWYG editor is not be used, its also mentioned in the Plugin Manual. It becomes a sad story when people don’t read it at all & start filing reports for problems when there are none! 🙂
Yeah, I feel you man about the issue of people not reading things and posting the same question again and again, even if you post it in a size 20 font 🙂
But still I made the hack cuz I found it a bit problematic to maintain my posts with the WYSIWYG limitation.
Yeah, it’ll be good for those who just use WYSIWYG only! 🙂
Cheers Amit, but i decided to not use smartypants/typogrify any longer. I usually pay attention while typing (i used the plugin more like a safety net) and add non breaking spaces between the last three (instead of two) words, so i bet smartypants/typogrify was bored already anyways 🙂
One thing i can not nail down though, is that sometimes my IG:Syntax settings seem to be re-setted, but i can not tell yet what is causing this. Got a clue?
Hey, just got an idea. You can provide this as an option in the plugin. I mean whether the user wants to use WYSIWYG or not. The hack can then be wrapped around in an if() that checks for the option.
@Manuel:
Some people have reported this issue that when they activate other plugins then this one’s settings are reset while others have reported that its working fine for them. I tried it out on 3 versions of WordPress in my sandbox & wasn’t able to re-generate this problem. So really can’t help there at the moment! 🙁
@Shantanu:
Yeah but like I said, its a one-way street. Once you’ve used it then you will have to use it always. Like if I write code in WYSIWYG in 2 posts & then later I decide not to use WYSIWYG(or vice versa) then my earlier code will be screwed!! Then for that a seperate value per post will have to be saved to mark if that post was done in WYSIWYG or not.
The reasoning behind not using WYSIWYG was that anyone who uses this plugin is a programmer(don’t think any non-programmer has any use for this plugin) & hence they shouldn’t have problems using non-WYSIWYG interface since the quicktags toolbar that’s there in non-WYSIWYG interface is pretty cool too & makes up for the WYSIWYG interface & besides, the WYSIWYG interface produces ugly HTML!! 😉
@Amit:
1. Its not necessarily a one-way street. Depends on how we implement it. If you don’t want to update it, can I distribute a modified version? All other aspects of it will remain intact like its name, its author’s name etc. Might include a one line of “modified by me” though. But all this only if you don’t plan to include this feature, and you approve of modification. If you don’t then also I understand.
2. About the reasoning of only programmers using this plugin, I agree but:
a. It might also be used by people who have never coded in html, etc but code in other languages.
b. Now, html is not so hard and even if one knows it, it might be a bit of pain and waste of time to do everything by hand always.
c. People might be using offline clients to post (like me), where using the WYSIWYG mode also means that you don’t need to upload any files, images etc separately, the client takes care of that. moreover, writing the same piece of custom inline css etc can also be taken care of in this mode.
@Amit: I just installed a new plugin and the setting were gone again. Does that help?
btw, text-transform:uppercase is really killing me, dude 😉
Is there a way to set the different options uniquely for each code-elemnt? This would be similar to specifying the starting line number, but for the other options such (Show Language Name, etc.).
This would be very nice to have.
And thank you for a very nice plugin!
It’s so easy to add other language files… just fantastic.
The PHP chr() function breaks this plugin.
I just spent 30 minutes trying to figure out what was going on until I discovered that I cannot post any code that contains chr().
If someone could post a fix, that would be awesome.
I also suffer from the resetting of options every time the plugin is disabled/re-activated (during WP upgrades for example). Otherwise, this is a great plugin! Thanks Amit!
I guess I posted too soon! It doesn’t appear to be a problem with this plugin, but rather with WordPress 2.3.3! I just tried upgrading another blog to 2.5 and the problem doesn’t occur.
@Michael:
No, I’m afraid there’s no way to do that right now! Might look into this for next version! 🙂 Thanks for liking the plugin! 🙂
@Raam:
Its ok, mistakes can happen with anyone! 🙂
WP 2.5: Settings still get re-setted if you de- or install another plugin. Major Bummer Amit!
Hi,
this is a great plugin. Tnx for all the hard work. I’ve got one problem though.
The HTML code which is produced when you use
is not html valid. It adds closing a href html element unnecessary at every line. Can you please take a look. Thank you.
Example page: http://trsplet.com/blog/2008/04/03/uporabni-html-meta-tagi/
Hi.
How can i reduce the width of the code box of iG:Syntax Hiliter ???
I try to modify value of css but it don’t have efect.
I think it will may be a option in control panel.
Thanks
@David:
You can do that in “syntax_hilite_css.css” file. Thats the only place where styles for the code box are defined! 🙂
Hi! Could you make in the next version of the opportunity to change the inscription “PLAIN TEXT” and “HILITED HTML” in your plugin’s settings?
@Yuriy: Can sure consider that! 🙂
Thank you. It’s very important for plugin’s users who spoken on diferent from English languages.
Is posible exclude some words?
there is a plugin that i need, that use the same kind of symbols
[name] …. [/name]
So, because of that, while i’m using hiliter, i can’t use the other plugin.
Thanks….
@patricia:
If you are using v3.5 of the plugin, you don’t have to worry about this issue. Except the tag names for the included language files, if you use any other tag name then the plugin will check if that particular language file is available or not. If its not available then the plugin won’t parse that text as you can see yourself here that the plugin has not parsed the [name] tag that you put in the comments! 🙂