Posts

  • Jun 8, 2021

    Emacs as Your Calendar

    Even in the age of smartphones I still prefer to check the calendar on my computer and I’ve often been disappointed by the horrible default calendars that ship with some operating systems (e.g. macOS’s calendar accessible via its systray).

    Fortunately for us, Emacs users, we always have access to a proper calendar regardless of our OS and desktop environment (if any) - M-x calendar. By default it looks something like this:

    calendar_default.png

    Nothing fancy here, just a simple calendar that highlights the current date. You can easily jump to any date by pressing o (it stands for other) and go back to the current date by pressing .. You can also use < and > to move back and forward in chunks of 3 months (by default).

    You might have noticed that the calendar by default assumes that the week starts on Sunday, although in many countries (Bulgaria included) it actually starts on Monday. You can easily change this:

    (setq calendar-week-start-day 1)

    Sunday is 0, Monday is 1 and so on.

    You can go a step further and localize the calendar like this:

    ;; everything's better in Bulgarian
(setq calendar-day-name-array ["Неделя" "Понеделник" "Вторник" "Сряда" "Четвъртък" "Петък" "Събота"]
      calendar-day-abbrev-array ["Нд" "Пн" "Вт" "Ср" "Чт" "Пт" "Сб"]
      calendar-day-header-array ["Нд" "Пн" "Вт" "Ср" "Чт" "Пт" "Сб"]
      calendar-month-name-array ["Януари" "Февруари" "Март" "Април" "Май"
	                             "Юни" "Юли" "Август" "Септември"
				                 "Октомври" "Ноември" "Декември"])

    If you already have the calendar open you’ll have to do M-x calendar or M-x calender-redraw to reflect the new settings.

    Did you notice that the configuration uses Emacs Lisp arrays? They are so uncommon that I’m pretty sure most people don’t even know about their existence.

    And here’s the final result:

    calendar_bulgarian.png

    There are many more things that you can with the calendar (e.g. configure there national holidays, leverage integrations with org-mode and so on), but they are beyond the scope of this short intro. As usual I encourage all of you to share your favorite tips and tricks related to the calendar in the comments.

    I hope you learning something useful today. Keep hacking!

  • Apr 19, 2021

    Configuring Minibuffer Completion in Projectile

    Projectile, a popular project navigation and management package, has always supported multiple minibuffer completion frameworks (e.g. ido, ivy, selectrum, etc). A recent change of the default completion configuration caused a bit of confusion for Projectile’s users and inspired me to write this article.

    Projectile, like almost all Emacs packages, is extremely minibuffer-centric - you’d typically get a bunch of options in the minibuffer (e.g. a list of project files) and you have to select one of them. Projectile takes care of calculating the things to show, but it delegates the actual job of presenting the things and making it easy to filter them and select something to some generic minibuffer selection/completion framework.1 Historically, Projectile defaulted to ido-mode as its minibuffer completion framework for a couple of reasons:

    • back in the day ido didn’t have many alternatives
    • I somewhat foolishly assumed that everyone preferred ido over Emacs’s default minibuffer completion

    At first this was hardcoded and eventually it was made configurable via the configuration variable projectile-completion-system. The arrangement worked fine for a very long time, but there was always one big problem with it - the implicit assumption that you’d figure out that Projectile has such configuration and you’d tweak it to match whatever completion framework you’re using (e.g. ivy or selectrum). Of course, it didn’t have to be this way - it would have been much better if Projectile just auto-detected what framework (if any) you’re using by default and used it as well.

    That’s why we’ve added auto as one of the potential values for projectile-completion-system and made it the default in Projectile 2.3. This, however, showed an interested problem that we didn’t foresee. Many people complained after the change that the nice minibuffer completion, they were getting for things like finding files, had disappeared, and Projectile was broken for them. As some of you probably realize, it wasn’t that Projectile was broken - what was actually happening was that it had reverted to using Emacs’s default minibuffer completion for them (the one where you have to press TAB to get any results with). I had always assumed that everyone was using something like ido, ivy, helm or selectrum, but clearly this was not the case. Turned out that a lot of people didn’t configure anything at all and for them Projectile was the only package doing “fancy” minibuffer completion. So, if you were affected by the change you can easily revert it by adding something like this to your Emacs config:

    (setq projectile-completion-system 'ido)

    Still, I think you’d do better if you just enabled some completion framework globally. For ido you can add something like this:

    (use-package ido
  :config
  (setq ido-enable-flex-matching t)
  (ido-mode 1)
  (ido-ubiquitous-mode 1))

    I, however, favor selectrum these days (mostly because I prefer the candidates to listed vertically):

    (use-package selectrum
  :ensure t
  :config
  (selectrum-mode +1))

(use-package selectrum-prescient
  :ensure t
  :config
  (selectrum-prescient-mode +1)
  (prescient-persist-mode +1))

    Of course, there’s nothing preventing you from using a different minibuffer completion framework with Projectile and the rest of Emacs, but such a setup seems pretty weird to me. I wonder if any of my reasons are using it and why. Projectile’s completion options are documented here in more details.

    That’s all I have for you today. I do hope that the takeaways from this brief articles are clear - be careful with your assumptions, and there’s a configuration option for everything in Projectile. Keep hacking!

    1. I’ll refer to those as “completion frameworks” for short. ↩

  • Apr 7, 2021

    Run Shell Commands from the Minibuffer

    Today we’re going back to the basics.

    I assume most of you know that you can run a shell within Emacs using shell-mode or even a terminal (e.g. ansi-term or vterm). While those are super useful there’s a simpler and faster way to run the occasional shell command via the aptly named command shell-command.

    You can invoke shell-command by pressing M-! and you’ll get a minibuffer prompt asking you for the command to run. Type something like ls -l and you’ll the ls command’s output straight in your minibuffer. Simple and sweet!

    If the command you type ends in &, it will be executed asynchronously and the output will appear in a dedicated buffer (*Async Shell Command*). This is useful for commands that are going to take a while to complete. There’s also the command async-shell-command (bound to M-&) that always runs shell command asynchronously.

    A cool trick with shell-command is to run it with a prefix (C-u M-!) - when you do this the output from the shell command is going to be inserted at point.

    One important thing to keep in mind is that the shell command will be executed in the directory (default-directory) of the current buffer. If your current buffer has a remote directory (you’re using TRAMP), the shell command is executed on that remote host. Depending on your perspective that’s either a very useful feature or a somewhat undesirable one.

    I have to admit that I use these commands quite rarely, but they are still useful from time to time when I want to check something really quick without switching buffers.

    As a reminder - you can also evaluate Emacs Lisp code in the minibuffer.

    That’s all I have for you today. Keep hacking!

  • Mar 23, 2021

    Deleting Git Branches with Magit

    How do most people delete local or remote git branches? Well, it’s quite simple actually:

    1. Google for “how to delete (remote) git branch”
    2. Find the wildly popular StackOverflow topic on the subject
    3. Pick one of the options outlined there

    Some people would claim that they actually know how to delete git branches, but I’m convinced they are all liars! Anyways, most people end up doing one of the following:

    # delete a local branch
$ git branch -d branch_name
$ git branch -D branch_name
# delete a remote branch
$ git push -d origin <branch_name>

    This obviously gets the job done, but we’re Emacs users and we have more convenient options at our disposal. With Magit the process is as simple as:

    1. Open the Magit status buffer (C-x g)
    2. Press y to get a listing of all branches and tags in the git repo
    3. Navigate to the branch you want to delete and press k

    That’s it! As a bonus you can select multiple branches using a region (press C-SPC and start moving around to select several branches) and you can remove them all at once! You’ll get prompted to confirm the deletion, so there’s nothing to be afraid of if you want to try this out. Note, however, that Magit does not support marking non-consecutive branches (something that dired allows you to do for files and directories).

    Here’s how this functionality looks:

    magit

    Notice that I’ve selected 4 branches and I can delete them by pressing k at this point.

    With that newly acquired knowledge you’ve got no excuse to keep around obsolete branches, so get wild and clean up those messy git repos of yours! That’s all I have for you today! Keep hacking!

  • Dec 11, 2020

    Super Keybindings for Magit

    This short article will present one simple, but unconventional idea - super-powered keybindings for Magit.1

    I hope by now most of you know (and use) the 3 default global Magit keybindings:

    • C-x g (magit-status)
    • C-x M-g (magit-dispatch)
    • C-c M-g (magit-file-dispatch)

    Typically you’d add to them C-c g, as a more convenient alternative of C-c M-g.2

    So far, so good. Now you can invoke a lot of commands with keybindings like C-x g l l or C-c g b, which is not bad as far as Emacs keybindings go. Remembering when to use C-x g, C-x M-g and C-c g takes a bit of practice, but it’s not very hard.

    But what if you wanted to have a lot of Magit commands under a single two-key (super convenient) prefix? Such prefixes are tight in Emacs these days, but only if we’re talking about the commonly used prefixes based on Control (e.g. C-c and C-x). If you’re not a traditionalist you can try something different - use a prefix based on the rarely utilized in Emacs Super key.3 Here’s one such idea using the Super-m prefix (the m, of course, stands for Magit4):

    ;; essentials
(global-set-key (kbd "s-m m") 'magit-status)
(global-set-key (kbd "s-m j") 'magit-dispatch)
(global-set-key (kbd "s-m k") 'magit-file-dispatch)
;; a faster way to invoke very common commands
(global-set-key (kbd "s-m l") 'magit-log-buffer-file)
(global-set-key (kbd "s-m b") 'magit-blame)

;; or alternatively
(use-package magit
  :ensure t
  :bind (("s-m m" . magit-status)
         ("s-m j" . magit-dispatch)
         ("s-m k" . magit-file-dispatch)
         ("s-m l" . magit-log-buffer-file)
         ("s-m b" . magit-blame)))

    Not only are all essential Magit commands under a single mnemonic (s-m) right now, but you can also bind some “internal” commands that you’d normally invoke via magit-dispatch or magit-file-dispatch directly under this prefix. This makes it slightly more efficient to invoke frequently used commands.

    The suggested keys m, j and k are clustered together on a typical QWERTY keyboard which makes it super easy to press them in sequence. Of course, you can find many other comfortable options.

    One thing that you should keep in mind is that your mileage with Super keybindings will vary based on your operating system/desktop environment. Windows, for instance, uses Win + letter keybindings a lot, so s-m is not an option there (it minimizes the current window). Frankly, I’m not sure if any Win + letter keybindings are available there at all.5 On macOS and Linux, however, such keybindings work fairly well, unless you happen to be using a window manager that’s fond of them (e.g. exwm).

    I first adopted the use of Super several years ago, but I never promoted it enough, apart from including a few such keybindings in Emacs Prelude. While the examples I gave today are with Magit, you can leverage the super keybindings with any package - e.g. I’ve long favored the use of s-p for Projectile and bindings like s-. for avy.

    That’s all I have for you today. Super-X forever!

    1. In the sense of using the Super key. Although I guess one can argue that they are also super convenient. ↩

    2. This article discusses the topic of the essential Magit commands in a bit more detail. ↩

    3. Typically this is the Windows key on PC keyboards and the Command key on Mac keyboards. ↩

    4. I sometimes wonder how the default keybindings for Magit ended up the letter “g” instead of “m”. It’s either a reference to Git, or that “g” happens to be on the home row. Or both. ↩

    5. In theory it should be possible to tell Emacs to intercept the Win key before Windows for (at least) some commands, but the suggested solution never worked for me. ↩

Subscribe via RSS | View Older Posts