This note is in reply to an old message (http://osdir.com/ml/gis.grass.user/2003-01/msg00039.html) seeking advice on using GRASS within EMACS. While not perfect (it would be nice to have a proper grass mode for emacs) I have a solution that works fairly well and is easy to implement.
I use R and GRASS together and frequently switch back and forth to accomplish tasks (this is the main reason I’ve stopped using Arc products - it’s difficult to interface with a powerful statistics program), so I wanted to find a way to use GRASS easily within the EMACS - ESS environment (where I do my R work). I found that this is as simple as starting an R process (see http://ess.r-project.org/index.php?Section=home), then switching to GRASS with a system() command and specifying the mapset. The send line function still works the same as in R, so the functionality is very similar.
run: system(“grass63 /media/Data/Work/grassdata/spearfish/PERMANENT”) # or whatever grass version and location/mapset you want to open. This can be the first line of your script.
That’s it, you now have an interactive GRASS session that you can send lines of code using the ess interface.
if you want to start a R process within GRASS, you can run “R” at the grass prompt and you start a new nested R process, where you can load library(spgrass6) and use all those powerful R functions
This results in a R process running within a grass process running within the original R process, but I don’t notice any performance loss or bad repercussions of this. Ctrl-L sends the current line to the grass prompt (emacs-ess still thinks it’s running R). This makes it quite simple to have a single script that bounces back and forth between GRASS and R. You can even exit from GRASS (which puts you back at the original R process) and then start a new GRASS process in a new mapset with another system() call. I like to keep an instance of QGis open at the same time for viewing the data I’m playing with, just hit ctrl-R there to refresh the map so it reflects any recent changes you made in the emacs-grass terminal. This results in a much better workflow than I have experienced with any arc products. While GRASS is chugging away on some big job, I am free to explore the same data in QGis. Emacs-ESS even allows multiple process to be running at the same time, so you if have some big jobs that you’d like to run in the background (but keep all the commands together in one script), you can do that too (though you cannot easily open the same mapset twice).
A few things about the Emacs-ESS interface that don’t work (the first two are probably easily fixable, but I don’t know how to do it):
Send-region (ctrl-r) sends the first line then freezes the interface. Hit ctrl-g to unfreeze it. You have to send GRASS commands one line at a time. A little annoying but not horrible.
When the cursor is at the shell in GRASS - alt-p does not bring back the previously executed command. You have to re-type or copy-paste from above.
And, according to the previous post, “a few programs (primarily v.digit and many of the imagery programs) can only be used through a curses-based interface,
which won’t work with shell-mode. term-mode should work, but that “eats” most of Emacs’ common keystrokes, which substantially reduces its usefulness, IMHO. - Glenn”
For someone that understands lisp and how to set up modes in Emacs-ESS, it would probably not be too hard to add a GRASS mode by just making a few small changes to the R mode.
I hope someone finds this helpful. Thanks to all who have contributed to GRASS, it’s great!
I use R and GRASS together and frequently switch back and forth to
accomplish tasks (this is the main reason I've stopped using Arc products -
it's difficult to interface with a powerful statistics program), so I wanted
to find a way to use GRASS easily within the EMACS - ESS environment (where
I do my R work). I found that this is as simple as starting an R process
(see http://ess.r-project.org/index.php?Section=home), then switching to
GRASS with a system() command and specifying the mapset. The send line
function still works the same as in R, so the functionality is very
similar.
For example:
1. Open emacs and start R as described in the ess documentation http://ess.r-project.org/index.php?Section=home
2. run: system("grass63
/media/Data/Work/grassdata/spearfish/PERMANENT") # or whatever grass
version and location/mapset you want to open. This can be the first line of
your script.
3. That's it, you now have an interactive GRASS session that you can send
lines of code using the ess interface.
4. if you want to start a R process within GRASS, you can run "R" at the
grass prompt and you start a new nested R process, where you can load
library(spgrass6) and use all those powerful R functions
FWIW, I would suggest skipping the "grass63" startup altogether.
I source the following script from my ~/.bash_profile (which is
sourced by my ~/.xsession file, so the settings also apply to X
programs):
This means that I can run GRASS commands anywhere, e.g. using M-! from
within XEmacs. You can use g.mapset to change database/location/mapset.
It should also allow you to use other packages which normally only work
"within GRASS".
Starting a login shell ("bash --login", which sources ~/.bash_profile)
will create a separate session with its own $GISRC file.
Many of the environment variables are optional. The ones which really
matter are GISBASE, GISRC, PATH and LD_LIBRARY_PATH. g.mapset requires
GIS_LOCK to be set, but it doesn't matter to what. The others are only
used by specific modules; see variables.html in the GRASS
documentation for an extensive list.
This means that I can run GRASS commands anywhere, e.g. using M-! from
within XEmacs. You can use g.mapset to change
database/location/mapset. It should also allow you to use other
packages which normally only work "within GRASS".
Starting a login shell ("bash --login", which sources ~/.bash_profile)
will create a separate session with its own $GISRC file.
Many of the environment variables are optional. The ones which really
matter are GISBASE, GISRC, PATH and LD_LIBRARY_PATH. g.mapset requires
GIS_LOCK to be set, but it doesn't matter to what. The others are only
used by specific modules; see variables.html in the GRASS
documentation for an extensive list.
I like this way of working. In Emacs, I've found one needs to set PATH
variable so that completion works in shell modes, etc.
Then TAB completes GRASS modules as usual in shell modes. Sh-script
mode offers a subset of the facilities that ESS gives when working with
R, including executing regions, buffer, etc.