Get the source-code

git clone git://git.sv.gnu.org/emacs

This step takes a long time, because the Emacs source repository is giant. But I recommend cloning the full repo:

• It's easy to stay updated with the latest changes with git fetch in the future.
• Telling Emacs where the C source code is let's us jump all the way down into primitive functions when exploring elisp functions.

      (setq source-directory (expand-file-name "/<path>/emacs/"))
      (setq find-function-C-source-directory (expand-file-name "/<path>/emacs/src/"))
      

Make sure you have the all the dependencies installed

The easiest way to install almost all the dependencies is to run the following command:

sudo apt build-dep emacs

This command uses the information in the Ubuntu package management system. In my experience today ([2025-01-01 Wed]), this command installed everything other than libgccjit and libtree-sitter. Let's install those now:

Installing libgccjit

1. Check your gcc version with gcc --version.
2. You need to install libgccjit-<x>-dev where <x> is your gcc version.

   sudo apt install libgccjit-11-dev
   

Installing libtree-sitter

sudo apt install libtree-sitter-dev

Compile Emacs!

# Generate Configure and Make scripts:
./autogen.sh
# Run the Configure command:
./configure --without-toolkit-scroll-bars --with-x-toolkit=gtk3 --with-xpm=ifavailable --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable --with-xml2 --with-rsvg --without-pop --with-png --with-mailutils --with-native-compilation --with-cairo --with-harfbuzz --with-tree-sitter --with-sqlite3
# If everything works:
make -j8 bootstrap
# If everything works:
make -j8
# Test the binary:
src/emacs -Q
# Install the binary:
sudo make install

Misc notes

• Running ./configure will output the default flags that Emacs plans to use.
  • If you look at the last section of what configure prints, you can check if there are new options which are not covered by my configure command above.
• To restart compilation from an absolutely clean slate, run make distclean
• To know the max number of cores you can run parallel compilation on, run nproc. This is the max value for the j parameter in the make command.

For reasons unrelated to this post, the phrase -*- lexical-binding: t -*- needs to exist as a comment in the first line of all my Emacs Lisp files.

This is what the first line of most of my elisp files looks like:

;;; init-isearch.el --- Configuring built-in isearch the way I like it

The line starts with ;;; (the comment syntax in Elisp), followed by the name of the file, and then a description of what the file contains.

This line needs to change to the following:

;;; init-isearch.el --- Configuring built-in isearch the way I like it -*- lexical-binding: t -*-

The caveats are as follows:

1. Some files already contain this directive, so they shouldn't be modified
2. Some files do not start with ;;;, these should be ignored.

With those caveats in place, here is the tiny shell puzzle:

1. Find all the files which need to be modified.
2. Modify all the files, writing the change back to disk

This is a great example of the kind of one-off tasks that shell scripting is great for!

Once you've given it a try, scroll down to see my answer.

Find all files which do not contain the phrase

I use ripgrep for all my searching, and it gives me a handy way of solving this part of the problem:

rg -t elisp --files-without-match "lexical-binding"

Add the directive to the first line of each file

My mind immediately jumped to using awk, which is my goto power tool for modifying file content. This problem is actually easier to solve with sed, but I've dropped sed entirely from my toolkit (in favour of awk).

gawk '
(NR==1 && /^;;;/){ print $0 " -*- lexical-binding: t -*-" };
(NR==1 && !/^;;;/){ print $0 };
(NR>1){ print $0 };
'

The final answer, with an explanation of what each line does

1  rg -t elisp --files-without-match "lexical-binding" | \
2  xargs -I {} \
3  gawk -i inplace '
4  (NR==1 && /^;;;/){ print $0 " -*- lexical-binding: t -*-" };
5  (NR==1 && !/^;;;/){ print $0 };
6  (NR>1){ print $0 };
7  ' {}

The meaning of each line is:

• Line 1: Use rg to find all fines which do not contain lexical-binding, and print only filenames.
• Line 2: Pipe the filenames to xargs for pushing one-by-one to awk.
• Line 3: Use the -i inplace switch to edit the file instead of printing to stdout.
• Line 4: If line number is 1 and the line starts with ;;;, add -*- lexical-binding: t -*- to the end of the line.
• Line 5: If line number is 1 but the line does not start with ;;;, just print the line as-is.
• Line 6: For all other lines, just print the line as-is.
• Line 7: This is where xargs will punch in the filename from our search (replacing {} with the filename)

There is a bug in the first line – our search query. Can you spot it? See if you can, and then scroll on to see the answer

Searching only in the first line of the file

The bug is that we are looking for the phrase lexical-binding anywhere in the file. What we want is for it to exist in the first line of the file, and if it does not exist, we want to add it.

This bug meant I missed updating 3 files in my initial run.

I couldn't fix it using just ripgrep, so this was what I replaced the first line with. If you know a better solution, please get in touch!

fd -e .el --exec sh -c 'head -n 1 {} | rg -qv lexical-binding && echo {}'

Here, I use fd to find all emacs-lisp files, and then execute a small script on them. This script checks the first lines, and if the first line does not contain lexical-binding, it outputs the filename!

Features I want (have no issue trying to add manually, but would like to see it there) -

• Project Management
• LSP with Linting
• Popup/Toggle-based Terminals

My Answer:

I'd be happy to explain / work with you on these requirements. What you are looking for:

1. project.el : Understanding what a project is (actions like searching in projects, switching projects, opening files in projects etc). IF you mean the other project management (task management) then org-mode which is a beast of it's own. Both are built-ins.
2. eglot for LSP. Invoke with M-x eglot from inside whichever project.
3. I did not understand what this means.

A long time back, I wrote some documents that you might find useful:

1. What Your Programming Editor Should Be Able To Do : a list of table-stakes operations, and key-bindings for my setup of Emacs.
2. An Opinionated Emacs Tutorial: Getting started fast. : A presentation I used to give in my previous work-place for getting started with Emacs: https://github.com/vedang/emacs-up/blob/master/docs/01_opinionated_emacs_tutorial.org (This is more philosophy than quick-tips, but might be useful to you)

As I was reading through the TabFS page (linked above), I thought to myself: "this is so much RC energy!". So I checked, and lo and behold, Omar Rizwan is an RC Alum :D

Why I wanted something like TabFS

The internet is full of interesting stuff that hijacks my attention. I end up getting completely distracted from my planned tasks. My solution to this is: I open all the links I want, but I don't read anything immediately. Instead, I capture the link in Org-Mode and schedule it for later (generally tomorrow). This way, when I am planning the day, I have a bunch of links in my Agenda. I choose which ones I want to read on any given day and defer / delete the rest. I use the excellent Bulk Scatter tool built into Org Agenda for this.

I thought: Why do this manually? Enter TabFS

A small Babashka script

With TabFS installed, it was a small step to go from there to org-mode. My go-to scripting tool is Babashka. Here is the meat of the code:

(require '[babashka.fs :as fs]
         '[clojure.string :as cs])

(defn build-tab-info
  "Collects the title and URL for all open tabs using TabFS."
  [opts]
  (map (fn [t]
         {:title (first (fs/read-all-lines (str t "/title.txt")))
          :url (first (fs/read-all-lines (str t "/url.txt")))})
       (fs/list-dir (:tab-dir opts))))

(def plain-text-template
  "The template for creating the org-mode plain-text entry. Placeholders
are for the following items (in order):
  1. Org-Mode Heading level: default value is 1.
  2. URL of the link to the stored.
  3. Title of the link to be stored.
  4. Date when the Tab is scheduled for reading: default is tomorrow.
  5. Date when the Tab was captured."
  "%s TODO [[%s][%s]]\nSCHEDULED: %s\n%s")

(defn tabs->text
  "Convert the list of open tabs to a wall of text that can be stored in
  Plain-Text."
  [opts]
  (->> (build-tab-info opts)
       (map (fn [t]
              (format plain-text-template
                      (apply str (repeat (:org-mode-heading-level opts) "*"))
                      (:url t)
                      (:title t)
                      (:scheduled-on opts)
                      (:captured-on opts))))
       (cs/join \newline)))

I wrote a CLI script for the code, here is what the help command looks like:

✦ ➜ bb-plain-text-tabs --help
Convert all open tabs to plain text Org Mode format. Optionally, close the open tabs.

Usage: bb-plain-text-tabs [options]

Options:
  -fs,  --tabfs-mnt-path                *REQUIRED* TabFS mount path. The path on the filesystem where TabFS is mounted.
  -hl,  --org-mode-heading-level        1                            The heading level at which link headings will be stored in Org Mode.
  -s,   --scheduled-on           <date> tomorrow                     Date on which to schedule reading this batch of links, in yyyy-MM-dd format.
  -del, --delete-tabs            <del>  false                        Boolean value to indicate if browser tabs should be closed

Examples:
   bb-plain-text-tabs -fs <TabFS Mount Path> # Convert Open Tabs to Plain Text
   bb-plain-text-tabs -fs <TabFS Mount Path> --delete-tabs # Delete tabs and print plain text
   bb-plain-text-tabs -fs <TabFS Mount Path> | tee tabs.org # Capture Plain Text output to file

What it looks like

Finally, this is the output, in Org Mode:

I hope all the Emacs/Org-mode folks reading this find it useful! Thank you to Omar for the excellent TabFS tool!

Did you know that Gitlab Pages supports private / auth-based static sites? Basically, you add people you want to share your site with as Project Members to the repository. Gitlab then enforces Gitlab Login on the website, so you can only see the content if you are logged into Gitlab (and have been given access to the repository).

This is a very cool way to host private static sites freely (vs, for example, self-hosting + HTTP Basic Auth).

Moving from Github Actions to Gitlab CI/CD Pipelines (+ running Docker containers in CI/CD scripts)

It's ridiculously hard to Google for the right way to run a dockerized tool in CI/CD environments.

Github Actions makes this a nobrainer because their images (example: ubuntu-latest) have docker clients and servers baked in already. So you just write your command (say docker run hello-world) directly into your YAML file and you are done.

Gitlab CI/CD does not have this. They expect you to search + use images from Dockerhub / Gitlab Container Registry. To make matters worse, it isn't enough to use the official Docker in Docker image (which is docker:latest btw). Using this image only gives you the docker client. You still need to run the docker server separately. If you don't, your pipeline will fail with the following error:

docker: error during connect: Post "http://docker:2375/v1.24/containers/create": dial tcp: lookup docker on 169.254.169.254:53: no such host.

To run the server, you need to understand the Services concept of Gitlab CI/CD. In short, this is a way to run services that your main job might need to access when it runs. You can use it, for example, to run database instances that your test job would connect to. In our case, we need a docker daemon service, which is provided by the docker:dind image.

Once you have this, then your entire pipeline will finally run. It took me a frustratingly long time to figure it all out. Here is what my final .gitlab-ci.yml file looks like:

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

before_script:
  - mkdir -p .neuron/output && touch .neuron/output/.nojekyll

pages:
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker run -v $PWD/content:/notes sridca/neuron neuron gen --pretty-urls
    - cp -R content/.neuron/output public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == "master"

The pages job-name is special. Gitlab understands that it is meant for hosting, and expects HTML / assets in a top-level directory called public.

I hope this helps someone else waste less time.

I didn't find a handy reference to getting started with REBL if your primary workflow is Leiningen/nrepl, so here is the series of things I had to do to get the REBL up and running for myself.

1. Download the REBL jar from Cognitect.
2. Use lein-localrepo to install the REBL jar to your m2.

       lein localrepo install rebl-0.9.242/rebl-0.9.242.jar com.cognitect/rebl 0.9.242
       

3. Add the following code to your profiles.clj file (code below). This is based on the REBL installation guide and Rick Moynihan's nrepl middleware:

       {
        ;; ....
        ;; You other profiles stuff
        ;; ....
        :rebl {:plugins [[cider/cider-nrepl "0.25.3"]
                         [refactor-nrepl "2.5.0"]
                         [nrepl "0.8.2"]]
               :repl-options {:nrepl-middleware [nrebl.middleware/wrap-nrebl]}
               :dependencies [[org.clojure/tools.deps.alpha "0.7.511"]
                              [com.cognitect/rebl "0.9.242"]
                              [org.clojure/core.async "1.3.610"]
                              [cljfmt  "0.6.4"]
                              [rickmoynihan/nrebl.middleware "0.3.1"]
                              [org.openjfx/javafx-fxml "15-ea+6"]
                              [org.openjfx/javafx-controls "15-ea+6"]
                              [org.openjfx/javafx-swing "15-ea+6"]
                              [org.openjfx/javafx-base "15-ea+6"]
                              [org.openjfx/javafx-web "15-ea+6"]]}
        ;; ....
        ;; If you don't have anything in your profiles.clj right now, just
        ;; remove the comments and copy the whole map over.
        }
       

4. Start the REPL with the new profile

       lein with-profile +rebl repl :headless
       

5. Connect to the REPL from Emacs. Do this by opening up any Clojure file in your project and executing M-x cider-connect in the file.
6. Run the following commands in the REPL to spin up the REBL.

       (require '[cognitect.rebl :as rebl])
       (rebl/ui)
       

7. At this point, anything that you evaluate when programming will be sent to your REPL as well as to your REBL and can be inspected from there. Anything you evaluate into the REPL will be sent over to the REBL as well.
8. Work on the REPL as you normally would. Your work is also being sent into the REBL for fancy viewing when you need it.

Important Note

I'm enjoying using a Linux laptop after years of development on the Macbook, and this post is more a list of issues I personally faced on moving to Linux after 7 years of development on the Macbook. I'd written a similar thing when I'd moved to the Macbook for the first time. Hopefully, this will help someone else moving to this particular laptop. This is not a "look, linux sux" post. The Oryx Pro is a great machine, and is a far better experience than the overall Linux experience I remember from 2012.

Emacs is unusable due to constant movement of the cursor.

• The cursor constantly moves to the end of the first line on screen for no apparent reason.
  • I'm convinced the reason that the cursor moves to the end of the first line on screen has to do with the position of the mouse-pointer. I confirmed this by changing ‘mouse-avoidance-mode' to ‘animate' (from ‘banish'). This stops the pointer from being moved to the top right corner on key press in Emacs. Now, the cursor does not move to the end of the first line like it used to, but to some other random place (wherever the mouse pointer happened to be last)
• Repeatedly performing certain key-bindings (like C-n) causes a buffer menu to pop up. I have no idea why this happens and how to reproduce it / stop it.
  • Once the menu shows up, repeatedly pressing the same key-binding causes it to go away after some time. (This may be true only of C-n, which is what triggers this for me the most.)
• Update : Both problems above are due to the awkward placing of the touchpad on the System 76 laptops. This touchpad is sensitive and registers "ghost clicks" during typing. I confirmed this by disabling my touchpad. The problem went away. This is an acceptable workaround for me as I don't need the mouse when I'm in Emacs (and disabling/enabling the touchpad is straightforward using xinput)
  • xinput list will list all the available input devices. Look for your touchpad and note the id of the device.
  • xinput disable <id> will disable the device.
  • xinput enable <id> will enable the device.

The space key is weird.

• More than any other key on the laptop, the space key needs a solid thump for it to register. This is especially irritating when typing out passphrases, since there is no visible feedback.
• Update : Over time, I've gotten used to this and no longer need to worry about whether my keypress has registered or not.

Power management and suspend.

No "just works" for Suspend.

• Years of using the Mac have trained me to just shut the laptop lid when I'm done working. However, with Oryx, there is no predictable way to tell whether the battery will continue to be drained or not once the lid is down. I've left a fully charged laptop, come back to it 4 hours later to find that it was completely drained (to the point that it does not start unless you plug it into a power source). I have no clue why this happens.
  • Update : Apparently this is famous in the world of System76 as the 'suspend black screen of death' bug. :( These are the kind of things due to which 'year of the Linux desktop' is a broken promise.
• Update 2 : Suspend works okayish, it just drains the battery faster than I would have expected. I guess I'll have to learn to live with this (but it seriously hampers the use of this laptop as a carry-around device, which is something I'm grumpy about).
• Update 3 : Prolonged use of this laptop really makes me appreciate the incredible power management of the Macbook. I love Oryx as a development environment, but the Macbook's power management is in a whole different class.

The Power button is weird.

I've gotten into the habit of shutting down my laptop when I'm unsure about battery and want to definitely conserve it (example when I'm traveling). There is no immediate feedback on pressing the power button. Due to this, it's hard to know if the keypress has registered or not. This is a small gripe in the big picture, but it gets annoying fast.

This is an incomplete list of the things your editor should be able to do for you. Please help me make it better by suggesting functionality that you find indispensable in your editor.

I have tried to arrange it in decreasing order of importance. I consider all this functionality table stakes, but if you must prioritise then start from the top.

Complete Anything (In Emacs: company, capf, eldoc)

Your editor should be able to show you completions for anything you are currently typing. This list includes, but is not restricted to:

• Completion of functions, variables, types, namespaces, classes, plain-text.
• Completion of arguments, with doc-strings

Note: eldoc is an Emacs built-in

Jump to source and back (In Emacs: xref, via dumb-jump or eglot)

Your editor should be able to jump to the definition of something on demand. This can be symbol at point (meaning word under the cursor) or can be anything I choose to enter.

• M-. : Jump to the source of something
• M-, : Jump back from the source of something

Note: xref is the built-in Emacs jump mechanism, eglot is the built-in Emacs LSP client

Check your syntax as you type (In Emacs: flycheck, flymake)

Your editor must be able to integrate with a linter program. As you are typing code, it should be able to point out all the problems in your code without getting in your way or slowing you down.

Note: flymake is the built-in Emacs mechanism for integrating checkers and linters

flycheck key-bindings:

• C-c ! l : List all errors
• C-c ! n : Go to the next error
• C-c ! p : Go to the previous error
• M-g M-n : Go to the next error
• M-g M-p : Go to the previous error

Understand and manipulate your project structure (In Emacs: project.el)

Your editor should have an understanding of the current project you are working in, as a whole. You should be able to quickly search for occurrences of certain words / phrases / symbols across the project. You should be able to pull up any file you wish in the project quickly, without needing to know exactly how the project is structured on disk

Note: project.el is the built-in Emacs project manager

project.el key-bindings:

• C-x p p : Switch to a project on disk
• C-x p f : Find a file in the current project
• C-x p G : Search for something in the current project

Use Git from the editor (In Emacs: magit)

Your editor should be able to give you the full power of your version control system in your editor. This includes, but is not limited to: creating new commits, listing changes made in a certain file(s), jumping to different versions of the code in the VCS.

magit key-bindings:

• M-x magit-status : Access the magit-status buffer for your project.
• C-c C-c : Access the full set of possible actions in your buffer
• M-x magit-blame-addition : For each line of the current buffer, show the revision which it was added in

Edit code as a structured entity (In Emacs: paredit)

Your editor should be able to understand the semantics of your programming language. It should be able to recognise and move quickly between functions and expressions. It should be able to manipulate entire expressions in one go.

• C-a : beginning-of-line
• C-e : end-of-line
• M-a : backward-sentence
• M-e : forward-sentence
• C-M-f : forward-sexp
• C-M-b : backward-sexp
• C-M-a : beginning-of-defun
• C-M-e : end-of-defun
• M-m : back-to-indentation
• C-) : paredit-forward-slurp-sexp
• C-( : paredit-backward-slurp-sexp
• C-} : paredit-forward-barf-sexp
• C-{ : paredit-backward-barf-sexp

Jump to important points in your code quickly (In Emacs: imenu and avy, helm)

Your editor should be able to jump to all the important points of your code in the least number of keystrokes (i.e. quickly). You should be able to quickly see all function names, type declarations, variable declarations in a given file and ideally in a given project as well. You should be able to jump to any word on the screen quickly.

Note: imenu is a built-in Emacs feature.

My helm and avy key-bindings:

• C-x c i : Show all the function, type, variable declaration names and be able to jump to any of them with a few keystrokes
• C-x c b, C-c n : Cycle through all the "sessions" and resume any you wish. A session here is a search of any kind that you have done before: for a file name, symbol name, variable listing, bookmarks etc
• M-g SPC : Jump to a word on screen by typing the starting character

Understand and refactor your programming language (In Emacs: eglot, cider, clj-refactor, clojure-lsp)

Your editor should have a clear understanding of the code you are writing, and should be able to help you change it faster. This includes, but is not limited to:

Note: eglot is the built-in LSP client for Emacs. cider, clj-refactor and clojure-lsp are Emacs packages specific to the Clojure programming language.

• Refactoring support:
  • Being able to rename symbols across the project
  • Being able to suggest code clean up
  • Being able to quickly import / clean-up dependencies
• Finding usages of code:
  • Being able to find all the places where a certain function is being used

Run your tests on-demand, and show you the results (In Emacs: cider-test)

Your editor should be able to run the tests of your project, integrating with your test-runner. It should be able to run these tests on-demand, and show the results of running the tests. You should be able to re-run all the tests, or only the failed tests. This depends on the test-runner and not the editor, so check whether your test-runner is powerful enough.

cider-test is provided by the cider Emacs package for running Clojure project tests. Other languages have similar modes provided for their projects.

Debug your code using a powerful debugger (In Emacs: gud, cider-debug, dap-mode)

Your editor should integrate with and start a debugger on demand. At least the basics of debugging (set breakpoints, step-in, step-out, see local variables) should be supported.

Note: In Emacs, gud is built-in and integrates with a variety of debuggers.

Support templates and expansion (In Emacs: yasnippet, org-capture)

Your editor should support creation and fast usage of templates (snippets) for common boiler-plate functionality. This speeds up development and documentation tremendously.

Support automating fast edits (In Emacs: kmacro-start-macro, multiple-cursors)

Your editor should be able to help you with one-off weird edits, eg: automatically numbering every new line with an incrementing counter.

Upcoming Experimental features

I am currently working on fine-tuning my editor experience to work best with LLMs and Code Assistants. The current state-of-the-art for this is the VSCode fork Cursor, and there is excellent work happening in this area.

Stay tuned!

After using StumpWM for nearly a year, I'm finally quitting and moving back to Gnome. I came to love StumpWM's minimalistic approach, and this isn't an easy decision. So why am I doing it?

Pinky Hell

I am (was) a heavy user of Emacs, Tmux and StumpWM. These programs rely heavily on the Ctrl key. This means that the Ctrl key and my left pinky finger are pretty much destroyed at this point. With the spectre of RSI looming over my head, StumpWM is the easiest tool to get rid off. I might have less screen-space now, but my fingers will thank me for it.

What you gain in Functionality, you lose in Integration

StumpWM is infinitely configurable. If you have the patience, you can get it to do things that are simply impossible with other Windows Managers. For example, there is a mpd.lisp module inside the contrib directory which converts StumpWM into a MPD client. A full-fledged client. This means that all music operations are entirely unobtrusive and always at your beck and call. MPD with StumpWM has without a doubt been the best music setup I've ever used.

However, I missed Gnome's integration with Ubuntu - Ubuntu One, Gwibber, Pidgin, event notifications. Even if I could configure StumpWM for these things, there was too much effort involved.

Dead processes, High temperatures

Disclaimer : Everything I'm about to say now is conjecture. There is no proof that StumpWM is responsible for any of this.

At 5 days uptime, my system load was touching 2, and my system temperature was at 65 degrees C. KK had a similar number of programs running on his system - this is a guy who uses full-blown compiz effects - his system temperature was 36 degrees and load average was around 1.15. Furthermore, he had a 48 day uptime. KK gleefully told me that it had to be StumpWM that was the problem! He was kidding, but some inquiry around the office showed that my laptop was much worse than the other guys on Ubuntu.

I also found that Chrome was leaving behind loads of defunct processes on my machine. There were 41 defunct chromium-browser processes when I decided to reboot the laptop and do some monitoring. Within an hour of the reboot, I had 7 defunct processes, CPU temperature was at 45 degrees and the load average was hovering around 1.8. That was the proverbial straw that broke the camel's back. I switched back to Gnome. Later in the day, I thought about actually investigating the behavior of my laptop, but it's been behaving well on Gnome. As I write, I have a day's uptime, a load average of 1.03 and CPU temperature at 37.5 degrees C. Unscientific, but fine by me.

How I got over the Withdrawal Symptoms:

Of all the StumpWM features, there was just one that I simply could not do without - 'run-or-raise'. On StumpWM, you can define hot-keys to behave as follows:

1. Launch the program if it is not running
2. Move focus to the program if it is already running.

I use one Emacs instance, one terminal instance (tmux'ed) and one Chrome instance. I need to be able to access them with minimal friction. Turns out, a little hackery on compiz is all we need - compiz-send.py is a nifty little script that sends messages to DBus and interacts with compiz. I can use it along with xdtool to implement my run-or-raise behavior. Here is a look at my run-or-raise-emacs.sh script:

https://gist.github.com/vedang/1130303

You can download compiz-send from here

So there you have it. At the moment, life is back to Gnome+Compiz. If you know any nifty hacks for Gnome+Compiz, please let me know in the comments.

References:

wiki.compiz.org