Critique of Gedit Syntax Highlighting + PHP Color Schemes

June 25th, 2014 by Jacob Barkdull

I've always liked PHP's default syntax highlighting, that is to say the color scheme used by highlight_file(). I've often found myself easily grokking code examples on when, say, looking up the parameter order for something like imageconvolution(), only to suffer some frustration once going back to Gedit.

Here's the thing, syntax highlighting is supposed to help prevent syntax errors (obviously) and aid programmers in finding what they're looking for in very large amounts of code. I didn't understand what was causing my frustrations with Gedit until recently when I realized its default color scheme is terrible.

Let's take a look at it...

Gedit's default syntax highlighting color scheme

Firstly, if the aim is to help prevent syntax errors, then errors must be clearly indicated as such by some means. Red text should, therefore, never be used in syntax highlighting schemes for anything other than errors, such as spelling errors and in advanced text editors -- of which Gedit is sadly not one, and most are not -- syntax errors such as calls to undefined variables, functions or uninstantiated classes should be indicated by red text or red underline. Red is the most useful and expected color to indicate errors, red should not be used to indicate function and class definitions, as is being done in the above screencap.

I also notice an unnecessary use of bold font for "class", "public", "function", and "for", which I have yet to find useful. However, Gedit does share this oddity with Wikipedia, GNU Nano, GNU Emacs, and even GitHub, so perhaps this kind of syntax highlighting is simply common among text editors.

Gedit's default syntax highlighting color scheme also poorly aids programmers in finding what they're looking for. For example, function and class names as well as constants are colored black, and therefore hard to find. If a programmer is defining or looking for a specific variable they should be able to simply skim over the source code tree looking for text of a certain color, allowing them to focus on or ignore the defining of functions, classes, constants and likewise calls to functions, classes, constants and variables. Gedit's default color scheme fails to do this well, for every language. However, GNU Nano is by far the worst offender.

Admittedly, the default PHP color scheme is only marginally better than Gedit's default, as variables, integers, floats, functions, and classes all use the same color. However, that isn't a deal breaker as the idea behind it -- as far as I can tell -- is that things the programmer defines like variables, functions, classes, and constants are of one color, the defining method ($, function ..., class ..., define) are of another color and the values of things like variable strings, echoes, and arrays are of yet another color... sadly red.

I personally think Gedit should conform to the standard or default syntax highlighting color scheme of each language. Gedit's default may feel very comfortable to C/C++ and JavaScript programmers, but it's rather foreign to PHP programmers. Therefore C/C++ and JavaScript should use one color scheme, PHP should use another, and HTML/CSS/XML should use a different scheme as well. This would be particularly useful for PHP projects where HTML, JavaScript and PHP code is often mixed together, having each language conform to specific color schemes would allow programmers to easily differentiate between the different languages.

With that said, here are three Gedit color schemes that mimic PHP's default.

All three color schemes
Default PHP color scheme
PHP Default
Default PHP color scheme (with grey comments)
PHP Default
(grey comments)
Default PHP color scheme 'User Contributed Notes' section
(User Contributed Notes) section
Installation Instructions

Step 1.

Download .tar Archive

Step 2.

Extract the files to the hidden directory ~/.local/share/gedit/styles

Step 3.

Start or restart Gedit.

Step 4.

Select "PHP Default" from the "Color Scheme" list in the "Font & Colors" tab under Preferences.

Step 5.

Enjoy! Happy hacking!

Known Issues
* Curly braces aren't colored, there doesn't appear to be an option to define a color for curly braces.

On the Blog RSS

May 9th, 2021

GNOME 40 is finally out and I'm happy to say a small contribution of mine made it into the release. My contribution adds a new feature to GNOME System Monitor version 40. Few articles about GNOME 40 mention it, but some power users might find my contribution useful.

November 15th, 2019
If you leave this option checked when you export your image, any pixels you erased will be saved in the exported image. They will not be truly erased, just made fully transparent. In other words, the data that describes the color of each pixel will be preserved, they will just be made invisible. This option has privacy implications. With it enabled, what you erase from an image may still be present in transparent pixels.
May 2nd, 2015

Over the past few days I've been in talks with a nice fellow named Kamil Jablonski, a concept artist, graphic designer, and web developer who recently contributed a Polish locale for HashOver. He shared with me a logo design for HashOver, that after some back and forth became, in my opinion, a very cool design.

Subscribe to Newsletter

Want to get the latest news and updates about my software, blog posts and behind the scenes information? Than subscribe to my newsletter to stay up-to-date!