Getting It’s All Text to play with Cygwin

I love the FireFox plugin It’s All Text – it lets me edit wiki pages, webmail, etc. in my beloved editor of Emacs and automatically refreshes the text field in FF with my new text.  But I recently moved from using NTEmacs to Cygwin’s version, and things simply stopped working.  And it made sense — Cygwin is just a layer on top of Windows, but it uses Unix-like paths, while It’s All Text would, naturally, use Windows-style paths.

I put up with this for a few months, mostly because I didn’t want to spend the cycles on figuring this out.  I did spend a few, and they were all pretty much worthless. I’m not sure why — the idea wasn’t hard, but it seemed to be.

A while back I decided to put some dedicated cycles to this.  I found this comment from the It’s All Text developer on his blog — it didn’t work , but it was a start.   I took his work and built my own version.  I was trying to do it with a one-script solution but seeing his I knew I needed two: one batch file and then one shell script.  After some experimenting,

The following batch script should be left alone.  It sets up the Cygwin environment, and then uses Cygwin’s “run” command to start a bash shell, when then runs our shell script.  The “%~f1″ is actually the most important component here.  It is a batch file command that says to give the full path of the first argument. Of course, that assumes that the first argument is a file but considering we are using this with It’s All Text, we are safe with that assumption.

@echo off
SET DISPLAY=127.0.0.1:0.0
SET CYGWIN_ROOT=c:\cygwin
SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/X11R6/bin
SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH%
SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
SET XNLSPATH=/usr/X11R6/lib/X11/locale

rem the %~f1 is the full path name of the argument given to the script.
%CYGWIN_ROOT%/bin/run.exe c:/cygwin/bin/bash.exe  /cygdrive/h/bin/text.sh %~f1

The following is our shell script, which we referenced as “text.sh” above. It’s much simpler — it converts the Windows path it was given to a Unix path and then calls our editor (“emacsclient” in my case, which will load up the file in the current Emacs instance).  You maybe thinking that I could have just was well as done this in the batch file above — and, you are right, I could have ran the editor but I had to also convert the file’s path first.  That is really why we need two scripts — using a shell script is the only way I could find that would let me use the cygpath command in a reliable way.  Note that I used “$*” at the path name — that will give all the arguments, which I need because there are spaces in the full path name (“$~f1″ above).

#!/bin/sh

/usr/bin/emacsclient "`cygpath "$*"`"

So not easy, but it’s possible. Of course, I made it a lot easier now for everyone else!

Adding your custom fonts to Cygwin’s XWin

I decided to finally make the leap and install Cygwin’s XWindows and run Emacs out of that instead of NTEmacs.  There wasn’t one big thing, but a bunch of little things, including:

• I wanted to stop using Plink in TRAMP, because that was a mess.  I know that it works better with a command line SSH client, like what I was using for Cygwin.
• They took my Win32 grep away!  How else am I going to use grep-mode?
• Pasting a path/filename from my Cygwin prompt to NTEmacs always involved an extra step — calling cygpath and the copying the value.
• I wanted to mess around with BicycleRepairMan but my Python environment is in Cygwin and my Emacs environment wasn’t.

If you read between the lines, you see a common theme — control.  In my entire Windows workstation, I have very little control over the environment.  In my little Cygwin world,  I have almost complete control.

I had installed and used Emacs within Cygwin/X before, but found that it was slow and clusmey.  Now they’ve had a few years to work out the kinks and I have a much more powerful workstation. And so I tried it again. Yep, things are much better!  However, I like some of the functionality of Emacs 22 but Cygwin doesn’t have Emacs 22 — they still have Emacs 21 as “stable” and Emacs 23 as experimental!  So I jumped through the hoops to install the “unstable” Emacs 23 along with X-windows (XWin, the Cygwin/X world.)

And thus our story begins.  Since I now have complete control on one part of my GUI and one of the things I’m picky about is fonts.  I like to use ProggyClean and, now, heck I can install it. So I downloaded it, move it to the right file, did the magic “xset fp rehash” and  . . . nothing.  Nadda.  XWin couldn’t find it.

I won’t depress you with a play-by-play, but this is an overview:

• I made ~/.fonts a font directory
• fonconfig ignores any addition to the /etc/fonts/local.conf file even though it says I loaded it.
• I decided to kick up old school and edit the ~/.xinitrc file — only to find out that if XWin starts in Rootless most it doesn’t even look at the ~/.xinitirc.

What ended up working was that I added the following to the /usr/bin/startxwin.bat file just before the last command (an xterm, I believe):

%RUN% /usr/bin/xset +fp /cygdrive/h/.fonts &

Then the font is loaded! Then I just make sure my ~/.emacs says:

(set-default-font
"-windows-proggyclean-medium-r-normal--13-80-96-96-c-70-iso8859-1"
)

And then you see such beautiful things as:

Emacs using Proggy Clean

Using Jython as a Terracotta Command Line

My new position at work was best described to me from my AVP: “Figure out how to make it work.”  The first thing that I need to see if it will work is Terracotta.  Terracotta is cool stuff — more to follow on it later.  Probably.

If you know me well enough, or have been reading this blog for a while, you know that I’m a big fan of Python.  Well, if I need to figure out how to “make it work” it generally involves Jython.  That way, I can open a prompt up and noodle around at the object and see what makes them tick.  To me, this could be especially important in Terracotta since you have objects floating around everywhere.

Getting Jython as a command-line interface into a Terracotta cluster is trivial — almost not worth blogging about.  And the result is oh-so cool.

Here is my Jython script. It just imports some common things and a Spring application context, and then get an object from the context. That object contains my Terracotta root object, which means that it stays in sync across my client and server JVM’s.

import sys,os

from org.springframework.context.support  import ClassPathXmlApplicationContext

if __name__ == '__main__':

    ctx = ClassPathXmlApplicationContext("applicationContext.xml")

    worker=ctx.getBean("worker")

Not that there isn’t anything specific to Terracotta in there — just like it should be.

I then wrote a shell script to setup my environment and run my Jython script in a Terracotta-instrumented environment. I actually run everything in Windows (unfortunately) so I have some Cygwin magic in there to change the classpath and to run the dso-java.bat in a cmd window:

#!/bin/sh

cp="dowork.jar:/c/Projects/jython2.5.1rc2/jython.jar"
cygstart bin/dso-java.bat -classpath `cygpath -mp $cp` org.python.util.jython -i $1 $2 $3 $4 $5

This allows me to run any script in a Terracotta cluster and then keep a command line open to I can muck around with stuff. Thejython.jar I use is a stand-alone install. I’ve just found that easier than worrying about where all modules are.

So now I just enter the shell script name with my Jython script as an argument and away I go!

And this works exactly as I expected. I can see the state of the root in the worker object, update that state in another clustered JVM, and then see that state immediately in my Jython prompt.

I’m sure you can do the same with Groovy, JRUby and their ilk. But I use Jython. It’s just how I roll

Getting Cygwin and Java to play together

I hate it when Open Source projects can’t handle the fact that I run everything in Cygwin.  Yes, I still want to use your run.sh file and have it understand my Java interpreter. Yes, classpath and everything!  It’s not hard people!

Luckily, I keep this script handy, which I stole from ANT years ago:

case "`uname`" in
  CYGWIN*) cygwin=true ;;

esac

# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
  JAVA_HOME=`cygpath --windows "$JAVA_HOME"`
  CLASSPATH=`cygpath --windows --path "$CLASSPATH"`
fi

How to stop zshell from dumping

I fixed this once couple years ago, with more than a little guidance from the ZSH-Users list.  But it started happening to me again a few weeks ago and I couldn’t remember how I fixed it. After searching through my GMail this morning, I found it.  Maybe if I put it here I will remember how to fix it next time.  And maybe help someone else.

This only happens to me when I use zsh  via Cygwin (I also use zsh on OSX and Linux).  What happens is that when zsh hits compinit in my ~/.zshrc, it prints a ton of the built-in functions to standard error and that’s it.  No error, no complaints . . . and no completion.  None at all!  See this article for a decent idea on how wonderful zsh does completion.

The fix is easy — manually remove ~/.zcompdump and manually run compinit. That instance of compinit will complete fine.  Then start a new shell and you are good to go!  Note that you have to manually run compinit – just starting a new shell won’t fix it.

I’m not sure why my ~/.zcompdump keeps getting corrupted . . . maybe because my home directory is on a shared drive?