Not only that he’s included the SQL*Plus keywords as well. Evert Verhellen, the author, has not only included all of the ANSI standard SQL commands but has added keywords for specific vendor implementations such as DB2 and, fortunately for us, Oracle. The sql.lang file is pretty comprehensive out of the box. Save the changes, open a file with the appropriate extension in gedit and it should now be highlighted in the same way as a. Once in the file, we need to define these extensions in the sources section ( that’s the first section in the file) : We will now have a copy of the original file in sql.bak whilst we’re playing with it. It’s worth noting that at this point, I got a bit careful and made a backup of the file before I started messing about with it…just in case.Ĭd /usr/share/gtksourceview-2.0/language-specs The definition file we’re interested in is sql.lang. You can find these files in /usr/share/gtksourceview-2.0/language-specs. Like Textpad, gedit implements syntax highlighting by means of language definition files…and it has them in spades. While we’re at it, we may as well specify all of the following file extensions as being PL/SQL files :
So, the next step is to get gedit to recognise files with these extensions as being SQL or PL/SQL files. Obviously, the package header and package body have the same name, so I need to distinguish between the files by means of the extension. Like many people, if I’m writing a package, I’ll save the script in a file with the format of package_name.extension. Not all PL/SQL ( or even SQL ) scripts I write are in files with. Come on Mike, focus ! Adding file extensions for PL/SQL files Getting a bit misty-eyed and geeky there.
#No package gedit plugins available code#
The other is the Code Comment plugin which enables you to comment out or uncomment lines or blocks of code just by using a keyboard shortcut ( CTRL + M to comment out, SHIFT CTRL M to uncomment). This allows you to run your code, see any errors, then edit, save and re-run without having to switch applications. One is the Embedded Terminal, which makes a terminal session available in the pane below the main editing area. I’m not going to go into detail about what each plugin does ( that’s covered by the Tuxcoder article) but I do have to mention two of them. To enable the plugin, just click the checkbox next to it. Once the package is installed, open gedit and go to Edit/ Preferences and click the Plug-Ins tab where you can view the resulting selection of goodies… gedit Plugins dialog So, if like me, you don’t already have this package, you can get it in the usual way – i.e. Whilst gedit comes with some plugins as part of the standard Ubuntu distro, there are even more goodies available in the gedit-plugins package.
#No package gedit plugins available how to#
There’s a really good article on how to customise gedit on tuxcoder.īut before you go running off to read the musings of a proper Linux expert, it’s probably worth me mentioning what I’m covering here : This means getting to play with another of those unobtrusive Linux gems – gedit. Text editors tend to do this stuff really well.Īt work, being stuck on Windows, I have to rely on the trusty Textpad, which is perfectly adequate.įortunately, when I get home, it’s Ubuntu all the way. If the compiler reports an error at line 100, I want to be able to go to line 100 in my code directly, no messing. Yes, SQLDeveloper ( and Toad for that matter) are great for looking at stored program units, running ad-hoc queries etc, but I find there’s no substitute for being “close to the metal” when it comes to in-depth or complex programming in PL/SQL.Īpart from anything else, the feedback you get at the prompt is the actual error, and not masked by something the IDE is objecting to. As I’ve said before, when it comes to doing serious Database programming, I prefer to work in SQL*Plus.
0 kommentar(er)
