Yann Hodique blog:2011

fixing greek characters display

Yann Hodique — 2011-12-11T16:35:13+01:00

I generally like the Monaco font, that I use for both Emacs and my rxvt-unicode terminals in GNU/Linux. In order to achieve this, I had the following in my ~/.Xdefaults:

emacs*font: Monaco:pixelsize=13

urxvt*font: xft:Monaco:pixelsize=13

Although it works perfectly fine for “normal text”, it does a disastrous job for fancier characters such as greek symbols. I don't know much about fonts lookup, but I guess there's a fallback mechanism to elect another font when the selected one does not contain the required symbols.

Anyway, as you can see in the following capture of my rxvt-unicode setup, it's not exactly pretty (bottom left for the display before fixing). It gets mucc better after modifying my ~/.Xdefaults to contain:

urxvt*font: xft:Monaco:pixelsize=13,xft:Monospace

Similarly for Emacs, the default display was not great (although at least readable). Putting something like the following in my ~/.emacs solved the issue for me.

(set-fontset-font "fontset-default" 'greek '("dejavu sans mono". "unicode-bmp"))

And now my Lisp lambdas can finally look good :)

emacs, urxvt,, config

Read or add comments to this article

A mocking framework for Emacs

Yann Hodique — 2011-11-04T12:32:47+01:00

As I'm currently trying to introduce some unit tests for Magit (see the unit-test branch) I realize I really need some mocking capabilities. For some reason, even though we now have a testing framework released with Emacs (ERT), no mocking library found its way to the core (yet?).

In its manual, ERT refers to the 3rd party el-mock.el, but I don't like the DSL approach too much (feels un-lispy to me) and it has definitions I strongly disagree with (“Mocks are temporary functions which accept specified arguments and return constant value.”) that make my life harder as a test writer. In my opinion, mocks are supposed to work in a record/replay way, which implies to be able to record different outputs for different (or even same) inputs. Returning a constant value is more of a stub thing. Actually I don't care too much about the naming, but I need the feature anyway :p

So, even though it is really nice for basic mocking (and achieves very low verbosity), el-mock.el is just not flexible enough for my purpose.

Here comes mocker.el, my attempt at achieving greater mocking flexibility. Admittedly, this is much more verbose, but for some twisted reason I like it better this way :) Note that the architecture is meant to be flexible, so in theory it would even be possible to define a way to express mocking expressions in a DSL similar to el-mock.el's.

2 quick examples taken from the documentation:

(mocker-let ((foo (x y z)
                  ((:input '(1 2 3) :output 4)
                   (:input '(4 5 6) :output 10)))
             (bar (x)
                  ((:input '(42) :output 4))))
  (+ (foo 1 2 3)
     (foo 4 5 6)
     (bar 42)))
 
;;; make `foo' generate the fibonacci suite, no matter how it's called
(mocker-let ((foo (x)
                  ((:input-matcher (lambda (x) t)
                    :output-generator (lexical-let ((x 0) (y 1))
                                        (lambda (any)
                                          (let ((z (+ x y)))
                                            (setq x y y z))))
                    :max-occur nil))))
  (* (foo 1) (foo 0) (foo 42)))

For more details, please refer to the page of the project. Bottom line, mocker-let is just a macro around flet that specializes in recording expected behaviors, then consuming them.

For what matters, I'd like it a lot if a proper mocking solution (whatever it may be) made its way to Emacs (as part of ERT or not). Maybe if there are enough people interested in this we can come up with something together :)

emacs, code, testing

Read or add comments to this article

Org-mode links for Magit

Yann Hodique — 2011-08-12T09:29:25+01:00

Since some people seem to find it useful, let's advertise it a bit :) I've wrote a very small extension to Org-Mode and Magit, that allows me to put links to magit items in my org files. See https://github.com/sigma/org-magit

Currently 3 types of links are supported:

magit:/path/to/repo::commit@<hash>
magit:/path/to/repo::status
magit:/path/to/repo::log

But you probably don't want to bother, and use org-store-link from the target buffer.

See the header of org-magit.el for more information.

Within emacs, opening those links will just invoke magit with the proper environment. When exporting to HTML, this extension tries to convert the links to something meaningful, using a list of web frontend and their URL schemes. Only GitHub is provided out of the box, but nothing prevents from adding more. Actually I'm doing exactly that to point to an internal cgit instance I have at work.

I'm using this as a set of bookmarks, and also to link actual commits to my development tasks.

(once I'm done with a couple of improvements, I'll definitely push into magit contrib)

emacs, code, magit, org

Read or add comments to this article

Tweaking zsh completion for git checkout

Yann Hodique — 2011-08-05T19:19:57+01:00

By default, zsh completion allows you to complete according to “git checkout” semantics. So git checkout path/to/<TAB> will actually work for updating files from the index (and some other similar cases).

There's nothing to say about it, it's obviously correct. Now, there are 2 things that make it inconvenient for me:

first of all, I happen to work regularly with huge repositories, with huge working directories (approximately 35GB). Since the completion code ends up calling git ls-files, even caching doesn't help that much reducing the time spent building the completion table. And I wouldn't want to pay the price even the first time.
second, my branches generally use a directory-like layout (like t/bugfix/<id>, so that it makes the whole completion list rather confusing.

Due to the second point, I happen to always use -- to make it clear I'm refering to filenames in the above scenario. So instead of git checkout path/to/<TAB>, I would actually always write git checkout -- path/to/<TAB>.

From there, the solution to my problem is obvious, I just have to disable filename completion until -- is seen.

Here's the code (put it as a _git-checkout function in your $fpath):

_git-checkout

#compdef git-checkout
local curcontext=$curcontext state line
declare -A opt_args
 
local new_branch_reflog_arg
 
if (( words[(I)-b] > 0 )); then
    new_branch_reflog_arg='-l[create the new branch'\''s reflog]'
else
    new_branch_reflog_arg='-l[create the branch'\''s reflog]'
fi
 
if compset -N '--'; then
    __git_cached_files
else
    _arguments -C -S \
        '-q[suppress feedback messages]' \
                                                                                  \
        - switch-branch \
        '-f[force a complete re-read]' \
        '-b[create a new branch based at given branch]: :__git_guard_branch-name' \
        {-t,--track}'[set up configuration so pull merges from the start point]' \
        '--no-track[override the branch.autosetupmerge configuration variable]' \
        $new_branch_reflog_arg \
        '-m[3way merge current branch, working tree and new branch]' \
        '::branch:__git_revisions' \
                                                                                  \
        - update-files \
        '::tree-ish:__git_tree_ishs' && ret=0
fi

You can compare to the original version in /usr/share/zsh/functions/Completion/Unix/_git

Edit: thanks to Friedrich for pointing out the need for a #compdef cookie to ensure proper behavior

zsh, code, git

Read or add comments to this article