Today I want to share with you some tips. I discover them myself during my efforts to get the best out of VoraX.
I was asked once about the possibility to offer support for multiple connections within VoraX. Despite this would be quite nice, it is not easy to implement at all. I mean, think about it: you have to link every Vim buffer to a particular oracle connection and have to maintain this relation. When you open a new sql file you have to decide to which connection it belongs. Every connection must have its own output buffer, right? The DbExplorer has to be also aware of multiple connections.
At the beginning of VoraX I thought of this and one idea was to use Vim tabbing support to map one tab to an oracle connection. If you open a new sql file, you open it to the current tab which is supposed to have a connection attached. That sql buffer will inherit the connection from its parent tab. I switch the tab and I'm connected to another session. It sounds pretty good, doesn't it? Well, during my first attempts to implement this I encountered a lot of problems:
- vim support for tab events is quite poor. For example, it doesn't provide a tabClose event (aka autocommand). This event is critical in order to force a disconnect when the user simply closes a vim tab. However, I succeeded to manage this with a lot of CursorHold trickery but the final result was not very nice.
- the vim tabbing model is not the same as in the most known IDEs/editors. In vim, a tab acts more like a viewport or a layout. This means a particular buffer doesn't stick to its tab. It can be migrated to another tab if you want. This may lead to confusion, because a buffer which was belonging to a connection can suddenly become part of another tab and, as a consequence, mapped to a new unexpected connection.
- in addition there's no good support for vim unit testing. There are a few plugins (including this) but I didn't have a pleasant experience with them. So, I didn't want to implement a complex connection management feature without a strong testing/regression support.
But, how about VoraX on Windows? Well, here things are not very promising yet. The only multiplexer I know in Windows is GNU Screen on top of Cygwin. This means you'd also need a cygwin version of vim (console mode, not gvim) with ruby support. Most likely you'd have to compile it yourself. Maybe this is not a big deal but the major problem right now is that VoraX doesn't provide a cygwin interface yet. Nevertheless, I'm going to create one in the next future. Till then, all of you guys on Windows, sorry... you'll have to wait!
If you were to ask me, I use GNU Screen for years. I like it a lot and I think it is a great tool. It is a productivity booster and it's worthing to learn some of its key shortcuts. However, one problem I had was with my vim colors. I like the earendel colorscheme. It's light and friendly with my eyes. However, you may notice a big difference between the colors in the GUI version of vim and the colors displayed within the plain console vim. Of course, using gvim and GNU screen doesn't have much sense, so you have to focus on the console version of vim.
First of all, you must have a decent terminal with the ability to display 256 colors. I use gnome-terminal with a "Linux console" built-in schema palette and it's working pretty well. I expect XTerm to be also a good choice. Then, I recommend CSAprox plugin which tries to map vim colors to your terminal as close as possible. This plugin comes with good documentation therefore I'll just skip the details. So after installing this plugin, your vim colors should look fine in your terminal too.
There's one more catch. I noticed that the colors were not displayed correctly when vim is opened into a GNU screen session. They were okey in a plain terminal but not under GNU Screen. I google for this topic and I found a solution. Add this to your .screenrc file:
# terminfo and termcap for nice 256 color terminalRestart your GNU Screen and Voila! You have beautiful colors in your screen console:
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on"
Above is a screenshot with two of my multiplexed VoraX sessions. Both of them are shown in a split which is not very common but is good for demonstration purposes. In practice is more likely to have one "full VoraX window" session at a time, with the possibility to switch to another one running in background. Isn't it great? In this light I must say: Who needs VoraX multi-connection support anyway?
No comments:
Post a Comment