5 ms·

This is really impressive, I'm starting to try Racket coding with Emacs + Geiser Mode. And I really need some sort of Guides to rely on once in a while. The fo

by pimgeek 12y ago

This is really impressive, I'm starting to try Racket coding with Emacs + Geiser Mode. And I really need some sort of Guides to rely on once in a while. The following words also sounds convincing: "If you are a programmer, you should try to automate thing as much as possible. One way of doing this is using a good editor that automates many menial and tedious tasks. For example, one of the thing that annoys me is using the command cd to change into a deep directory path like this: [/path/to/a/very/long/long/long/long/long/long/..../directory/ ]"

tuhdo 12y ago
Great. Keep up using Emacs and you won't regret, especially using it for writing Lisp code.
cmpitg 12y ago
You might want to combine Geiser with Quack[1] for best result with Scheme. Also, I think it's worth a shot to have a look at the fairly new Racket-mode[2] written by Greg[3]. Geiser + Quack are rather old and for Scheme in general, Racket-mode focuses on and is tightly integrated with Racket. [1] http://www.neilvandyke.org/quack/ http://www.neilvandyke.org/quack/ [2] https://github.com/greghendershott/racket-mode https://github.com/greghendershott/racket-mode [3] http://www.greghendershott.com/ http://www.greghendershott.com/
- klibertp 12y ago
  racket-mode is good in that it at least indents Racket code properly. It implements it's own integration with the REPL, IIRC, which makes working with Geiser at the same time not ideal. But still manageable, just a bit of tweaking needed. Disclaimer: I may remember wrong or it may have changed since I was last configuring Racket support in Emacs, so don't get discouraged and just go check racket-mode anyway :)
look_lookatme 12y ago
Related to that last part... after 10 or so years of using Emacs off and on (mostly when editing files remotely), I went full time with it a couple of months ago. In the beginning I used projectile the way the OP illustrates it works, but then I began streamlining and customizing that workflow even more. An example of this is that as part of my job I have to maintain a handful of wordpress sites. We keep these sites in one git repo, but they are different sites altogether so the layout would be: /sites/www/site1 /sites/www/site2 (and so on) ... with each site(N) being distinct Wordpress installations. One of the annoying aspects of maintaining a bunch of Wordpress sites like this is that they all contain the WP framework code (which I never edit) and all of the code that is edited frequently tends to be in each sites respective theme, all of which also tend to have the same filenames. So if you wanted to visit the header template for site1 you would fire up projectile, type in "site1/wp-content/themes/header.php" or some such and you'd probably get a hit. If you just typed in "header.php" you'd end up with a bunch of different hits, including Wordpress framework files, multiplied by the number of sites. Projectile has a mechanism for ignoring files[1], which is nice for omitting framework code, but I wanted a workflow that was "On keystroke, prompt me for sitename and open a projectile prompt that autocompletes files for that site only". Turns out this is really easy. While Projectile will normally use git to determine its project root, you can actually add a .projectile file to any directory and that directory then becomes a project root. From there it's easy to write an interactive elisp function that will ask you which projectile project to load, then fire up the autocomplete. Bind that to a global key and it becomes really easy to break down your large-ish codebase into logical sub-projects and get to business quickly. (Haha, I just realized how emacs-y that tip was.) Lastly, if you find your .emacs configuration becoming unwieldy, or if you are like me and originally broke out mode specific configuration into distinct files (php.el, ruby.el, web.el) I can't recommend enough switching your config to one big org-mode + babel[2] file. Doing so was my first foray into org-mode and literate programming and I can't recommend it enough, if only for keeping your Emacs configuration sanely documented. I used this config as an example for getting started: https://github.com/larstvei/dot-emacs/blob/master/init.org https://github.com/larstvei/dot-emacs/blob/master/init.org [1] https://github.com/bbatsov/projectile#ignoring-files https://github.com/bbatsov/projectile#ignoring-files [2] http://orgmode.org/worg/org-contrib/babel/intro.html http://orgmode.org/worg/org-contrib/babel/intro.html
davexunit 12y ago
I use Emacs + Geiser + Guile on a regular basis and it's the best programming environment I've ever used, hands down.

by pimgeek 12y ago

tuhdo 12y ago

Great. Keep up using Emacs and you won't regret, especially using it for writing Lisp code.

cmpitg 12y ago

You might want to combine Geiser with Quack[1] for best result with Scheme. Also, I think it's worth a shot to have a look at the fairly new Racket-mode[2] written by Greg[3]. Geiser + Quack are rather old and for Scheme in general, Racket-mode focuses on and is tightly integrated with Racket. [1] http://www.neilvandyke.org/quack/ http://www.neilvandyke.org/quack/ [2] https://github.com/greghendershott/racket-mode https://github.com/greghendershott/racket-mode [3] http://www.greghendershott.com/ http://www.greghendershott.com/

klibertp 12y ago
racket-mode is good in that it at least indents Racket code properly. It implements it's own integration with the REPL, IIRC, which makes working with Geiser at the same time not ideal. But still manageable, just a bit of tweaking needed. Disclaimer: I may remember wrong or it may have changed since I was last configuring Racket support in Emacs, so don't get discouraged and just go check racket-mode anyway :)

look_lookatme 12y ago

Related to that last part... after 10 or so years of using Emacs off and on (mostly when editing files remotely), I went full time with it a couple of months ago. In the beginning I used projectile the way the OP illustrates it works, but then I began streamlining and customizing that workflow even more. An example of this is that as part of my job I have to maintain a handful of wordpress sites. We keep these sites in one git repo, but they are different sites altogether so the layout would be: /sites/www/site1 /sites/www/site2 (and so on) ... with each site(N) being distinct Wordpress installations. One of the annoying aspects of maintaining a bunch of Wordpress sites like this is that they all contain the WP framework code (which I never edit) and all of the code that is edited frequently tends to be in each sites respective theme, all of which also tend to have the same filenames. So if you wanted to visit the header template for site1 you would fire up projectile, type in "site1/wp-content/themes/header.php" or some such and you'd probably get a hit. If you just typed in "header.php" you'd end up with a bunch of different hits, including Wordpress framework files, multiplied by the number of sites. Projectile has a mechanism for ignoring files[1], which is nice for omitting framework code, but I wanted a workflow that was "On keystroke, prompt me for sitename and open a projectile prompt that autocompletes files for that site only". Turns out this is really easy. While Projectile will normally use git to determine its project root, you can actually add a .projectile file to any directory and that directory then becomes a project root. From there it's easy to write an interactive elisp function that will ask you which projectile project to load, then fire up the autocomplete. Bind that to a global key and it becomes really easy to break down your large-ish codebase into logical sub-projects and get to business quickly. (Haha, I just realized how emacs-y that tip was.) Lastly, if you find your .emacs configuration becoming unwieldy, or if you are like me and originally broke out mode specific configuration into distinct files (php.el, ruby.el, web.el) I can't recommend enough switching your config to one big org-mode + babel[2] file. Doing so was my first foray into org-mode and literate programming and I can't recommend it enough, if only for keeping your Emacs configuration sanely documented. I used this config as an example for getting started: https://github.com/larstvei/dot-emacs/blob/master/init.org https://github.com/larstvei/dot-emacs/blob/master/init.org [1] https://github.com/bbatsov/projectile#ignoring-files https://github.com/bbatsov/projectile#ignoring-files [2] http://orgmode.org/worg/org-contrib/babel/intro.html http://orgmode.org/worg/org-contrib/babel/intro.html

davexunit 12y ago

I use Emacs + Geiser + Guile on a regular basis and it's the best programming environment I've ever used, hands down.