Gökmen Görgen

Tag: emacs

  • Less Configuration for More Freedom

    I’m very conservative to avoid changing my routines, habits about my preferred software and hardware. But on the other hand, I always follow the new tools and try them as much as possible. It’s not easy to change habits, but if I think that the new alternative is better than my current one, and if I think that the new tool will increase my work quality, then I take a risk and replace it.

    Sometimes I’ve made the wrong decision, for example I was a KeePass user and switched to the Pass CLI application because I thought I didn’t need such features. But then I noticed that pass app doesn’t have a good client for desktop and it’s not easy to configure GPG, repository access for iOS. Then I decided to use Apple Passwords to get rid of installing extra password and two-factor authentication applications.

    Many developers have a repository that contains their public configuration files, and most of these are open to the public. I often look at these repositories, but unlike many people, I prefer to keep my config files as simple as possible, because it’s like adding a dependency to your project, every new dependency comes with a maintenance cost. The other main reason is that I want to keep flexibility. I don’t have specific requirements for any tools, but I always expect consistency between GUIs, keyboard shortcuts. And I also want to have all the features I need without adding a lot of plugins, or if that’s not possible, I expect the plugins to at least be officially supported.

    So when I discover a new tool, or want to replace my existing tool with another, I follow these steps:

    1. First, check your budget if the tool is not free. Some tools may come with a free subscription, but that does not mean the tool is always free. I don’t have a hard and fast rule here, but I definitely expect the paid tools to be better than the free alternatives.
    2. Prefer the one that is ready to use quickly. I could prepare a server to host my blog. I have to configure the virtual machine’s swap area, prepare some cron jobs to back it up, use some plugins to cache and optimise WordPress. Or I can host my site directly on WordPress.com. I preferred the second option, but considering the first rule, I had a budget for it.
    3. Look at all the features, but compare the options based on the features you really need. I used Evernote for a long time, then decided to investigate an alternative because of new expectations. Joplin was a good Evernote alternative, but I never used all of its features. So I even tried Apple Notes before making my final decision.
    4. Own fewer extensions, use all features efficiently. If I’m not sure about the benefit of a tool or a feature of a tool, I temporarily stop using it and make a note of what I’ve lost. Tools are like a knight’s sword and shield: the more effectively we use them, the better they help us do our job.
    5. Simplicity is fine to avoid distraction, but do not ignore helpful things. I don’t really need line numbers in my editor, but breadcrumbs are helpful to remember class name, module name, file path, etc.

    These rules also help with my hobbies and family time. The older you get, the more important it becomes to get things done on time.

  • Configuration Updates With Emacs 29

    As I mentioned in my last post, I started using VSCode to see what I’m missing and I thought that it’s a good time to take all the risks and break my Emacs configuration. In the last changes, I tried to use the built-in alternatives of the packages like eglot instead of lsp-mode. Now I’ve made the decision to update Emacs to version 29.

    When I first switched to Emacs 28, all my performance problems were solved thanks to native compilation support. Most of these problems were caused by LSP1 and it was very annoying to wait even half a second to see syntax errors in the code. Now I don’t close Emacs on the server for months. This was the most significant change to Emacs 28 that I can’t forget.

    Now, if you ask what the equivalent important update is on Emacs 29, I guess I can claim that Emacs has become quite useful even if you don’t install any extensions. Many extensions I used are now included in the project, for example:

    • Modus-Vivendi and Modus-Operandi, the themes I have been using for years and cannot give up, now come in.
    • The package configuration tool use-package is now included.
    • The internal LSP service eglot is now available. I’ve previously used the lsp-mode extension.
    • For tree-sitter support, nothing needs to be installed any longer.

    Furthermore, TRAMP2, which functions similarly to VSCode’s remote development extensions, has started to support Docker and Kubernetes; however, I have not yet verified whether LSP can be used in a remote development environment. I prefer to use MOSH3 to connect to the server and execute Emacs remotely, unless this occurs.

    As many extensions were included, I also reviewed the other extensions I used. Although it is possible to use Emacs without any installed extensions, it is very difficult for me to give up some extensions. For instance, magit is far superior to many competitors, both as an Emacs and a git client.

    Another extension that I can’t give up is doom-modeline. The default mode-line view in Emacs is also quite ineffective. It wastes space, uses the right half of the line very inefficiently, and shows minor modes needlessly. I began utilizing doom-modeline to address all of these issues. You can see the screenshot to see how it looks:

    With Emacs 29, I suppose the major modification I made was to cease using popups for text completion. I’m not sure if it’s a good idea yet, but I’ll keep trying. I use all of Emacs’ capabilities that make use of minibuffers considerably more effectively by using the following extensions:

    • consult: an extension for minibuffer completion.
    • vertico: a minibuffer completion UI. It’s necessary for consult.
    • orderless: completion style with various algorithms to find more search results.
    • marginalia: an extension to see more information about the search results.

    When I started using minibuffer instead of popup for completion, there was a lot of space left for a second text completion. so I thought why not use copilot or codium. Look at the screenshot to see how it works:

    I didn’t turn on a lot of UI components, like line numbers, tabs, fringe, and scroll bars, so it’s likely that my configuration isn’t optimal for a graphical user interface. And to be honest, I didn’t need it; perhaps I’ll keep the UI in zen mode and continue using Emacs in my preferred terminal program, WeztTerm. But for the time being, I intend to continue working with VSCode. You may find a new version of Emacs with my setup in my emacs.d repository if you want to try it out.

    1. LSP: Language Server Protocol ↩︎
    2. TRAMP: Transparent Remote Access, Multiple Protocol ↩︎
    3. MOSH: Mobile Shell ↩︎

  • Status Update on Emacs

    I’ve used Emacs for years, and it’s not easy to get rid of this archaic (what?) editor. Although it helped me do my job better, my setup was not as stable as in the editor. When I started working as a web developer, I was installing all the project requirements on the local machine, even though I was not using virtual environments. Emacs was good enough to make development possible.

    Then, I started using tools like vagrant, docker, and virtual environments that made it easy to install the project but difficult to use Emacs because I needed to configure the editor to find the right Python interpreter, Node version, etc. Having the language server protocols (LSP) was a great help, but I still had to create a virtual environment for each project.

    Then I switched to remote development; I had a remote server to access the same development environment from all my devices. I was using a good terminal emulator like WezTerm, connecting to the server using MOSH or Eternal Terminal, and running Emacs on the server remotely. This has never been as comfortable as working locally.

    In each case where my setup has changed, I have updated Emacs and reconfigured it for the new environment. If you take a look at my Emacs configuration, you will see that I’m using vanilla Emacs with the minimum configuration, and I try to use built-in packages as much as possible. But now I’m at a new crossroads because I started using AI tools actively and am getting bored waiting for the tools to support my editor. I’m looking at the GitHub Copilot, and even they don’t have a plan to support Emacs officially. You can say that it’s a tactic to force them to use their own editors or that they don’t have time to support all the editors. Maybe it’s better to help the community take initiative for preparing the extension. But anyway, that’s not fair or helpful for maintaining the diversity of the editors.

    Probably it’s not easy to change my habits quickly, but I plan to use VSCode for a while and see what I’m missing. I know that VSCode has good remote development tools and official GitHub Copilot support. During this period, I will update Emacs to have the same features as VSCode and try to use it again.

    For now, I want to compare the two editors for the extensions I’m using in Emacs. These extensions are mostly not needed on VSCode because they are built-in features:

    • company, company-prescient: autocomplete extension.
    • ctrlf: better search and replace.
    • deadgrep: ripgrep integration for Emacs. I’m using the built-in search and find commands on VSCode.
    • diff-hl: shows git diff in the fringe.
    • eglot: LSP client.
    • find-file-in-project: Helpful for finding a file in a project.
    • multiple-cursors: Another extension for editing multiple lines at once.
    • expand-region: Not easy to do this on VSCode (CTRL+CMD+SHIFT+Left what the hell?) but yes it’s a built-in feature.
    • magit: Git app for Emacs. I don’t think that I can find an equivalent in any editor. Don’t suggest me GitLens, please.
    • minions: Hides minor modes on Emacs mode line. Not necessary on VSCode.
    • modus-themes: My favorite theme for Emacs. I’m using the GitHub theme on VSCode.
    • puni: Structured editing tool for Emacs. Not sure if I can find an equivalent on VSCode.
    • vertico, vertico-prescient: Similar to CTRL|CMD+SHIFT+P or CTRL|CMD+P on VSCode.
    • tree-sitter, tree-sitter-langs: Not sure if VSCode needs this extension, but it’s a great synax parsing library for Emacs.
    • unfill: For unfilling paragraphs with a shortcut.

    My Emacs configuration is available on GitHub.

  • Emacs’e Nereden Başlamalı?

    Emacs’e Nereden Başlamalı?

    Yazılım dünyasının en eski editörlerinden Emacs, günümüzdeki diğer popüler editörlerden farklı bir kullanma ve öğrenme disiplini istiyor. Bazı temel özelliklerini öğrenmeden editörde bir dosya açmak bile zor. O nedenle Emacs’in kendi içinde gelen tutorial’ını en azından bir kez okumak, öğrendiklerini uygulamak ve birkaç hafta sabırla kullanmak gerekiyor.

    Emacs Linux, Windows ve macOS işletim sistemlerinde çalışıyor. Yükleyip editörü açtığınızda ilk hali muhtemelen arzu ettiğiniz gibi görünmeyecek. Bir yandan Emacs’i öğrenirken, bir yandan da kendi zevkinize göre özelleştirmeye başlamanızı öneriyorum. İnternette yüzlerce Emacs config dosyası bulabilirsiniz, bazı kullanıcılar işi bir adım daha ileriye götürüp Spacemacs, StarterKit gibi projelerle kullanıcıların ortalama ihtiyaçlarına göre hazır config dosyaları sunuyorlar. Deneyebilirsiniz; ama bana göre bu iyi bir başlangıç olmaz. Elinizde neredeyse her şeyi yapılandırabileceğiniz bir editör var ve bunu başkalarının zevklerine göre ayarlamak yerine, kendi ihtiyaçlarınızı tespit edip, bu ihtiyaçları başkalarının nasıl çözdüğüne bakarak kendi editörünüzü kendiniz yapılandırmanız daha doğru bir yaklaşım olur.

    Spacemacs’te Emacs’in görünümü bu şekilde.

    Emacs kendine özel bir Lisp yorumlayıcısıyla birlikte geliyor. Config dosyalarınızı bir Lisp script’i yazar gibi hazırlıyorsunuz. Daha önce hiç Lisp yazmadıysanız, buradan başlayabilirsiniz:

    https://learnxinyminutes.com/docs/elisp

    Config dosyası genellikle kullanıcı ev dizininizde ~/emacs.el veya ~/.emacs.d/init.el olarak saklanıyor. Yapılandırma dosyası hakkında daha fazla bilgi almak için okumaya buradan başlayabilirsiniz:

    https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html

    Belgeyi okuyup config dosyası hazırlamak gözünüzü korkutmasın, size açıklayarak küçük bir örnek göstereceğim. Benim config dosyam, önce paketleri kontrol etmek, eğer kurulmamış paket varsa da kurmakla başlıyor. Paketler, editöre ekstra özellik kazandıran kodlar içerir ve bunlar genellikle küçük dosyalardan oluşmazlar, örneğin HTML kodları, içinde CSS ve JavaScript kodu barındırdığında parse etmesi çok zordur, bunun için ek paket kurmak isteyebilirsiniz veya Emacs içinde bir git istemcisi kullanmak isteyebilirsiniz. Helm paketi ile Emacs komut satırını daha da güçlendirmek isteyebilirsiniz:

    (require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
(package-initialize)
(when (not package-archive-contents) (package-refresh-contents))
(defvar my-packages
  '(auto-complete
    flx-ido
    helm
    helm-ag
    helm-ls-git
    js2-mode
    magit
    markdown-mode
    scss-mode
    web-mode)
  "A list of packages to ensure are installed at launch.")
(dolist (p my-packages)
  (when (not (package-installed-p p)) (package-install p)))
    Lisp

    Editörü kullandıkça bazı ihtiyaçlar ortaya çıkmaya başlıyor. Örneğin bir projede çok uzun süre çalışıp daha sonra başka bir projeye geçmek istediğimde arka planda açık olan tüm dosya yedeklerini silmek istiyorum. Bunun için `kill-other-buffers` adında bir fonksiyon yazdım ve bu fonksiyonu bir klavye kısayoluna atadım (Ctrl c, k):

    (defun kill-other-buffers ()
 “Kill all other buffers.”
 (interactive)
 (mapc ‘kill-buffer (delq (current-buffer) (buffer-list)))
 (message “All other buffers are killed..”))(global-set-key (kbd “C-c k”) ‘kill-other-buffers)
    Lisp

    Emacs’i olabildiğince sade kullanmaya çalışıyorum. O nedenle menüyü, açılış ekranını kaldırdım, imleç pozisyonunu satır uzunluğunu anlayabilecek şekilde yapılandırdım, fontumu değiştirdim, dosya kaydederken beyaz boşlukların otomatik silinmesini sağladım, parantezlerin otomatik kapatılması gibi birçok ayarı etkinleştirdim:

    (setq-default truncate-lines t)
(setq inhibit-splash-screen t)
(menu-bar-mode -1)
(scroll-bar-mode -1)
(tool-bar-mode -1)
(setq visible-bell 1)
(column-number-mode t)
(set-face-attribute ‘default nil :font “Fira Code” :height 105 :weight ‘normal :width ‘normal)
(ido-mode 1)
(ido-everywhere 1)
(flx-ido-mode 1)
(setq ido-enable-flex-matching t)
(setq ido-use-faces nil)
(setq-default indent-tabs-mode nil)
(electric-pair-mode 1)
(add-hook ‘before-save-hook ‘delete-trailing-whitespace)
(ac-config-default)
    Lisp

    Editörde dosya açarken, aynı dizinde geçici bir dosya oluşturulduğunu göreceksiniz. Bu dosyaların ortalıkta değil de, başka bir yerde tek bir dizin içinde saklanmasını sağlıyorum:

    (setq backup-directory-alist `((“.*” . ,temporary-file-directory)))
(setq auto-save-file-name-transforms `((“.*” ,temporary-file-directory t)))
    Lisp

    Son olarak, normalde uzun satırları kırmayı sevmiyorum, tek satırda göstermesi benim için daha iyi; ama metin dosyaları hariç, onlarda uzun satırları kırıp satırbaşıymış gibi göstermesini sağlıyorum:

    (add-hook ‘markdown-mode-hook ‘visual-line-mode)
(add-hook ‘text-mode-hook ‘visual-line-mode)
    Lisp

    40 yıllık editör için yapılandırmam bundan ibaret. Yapılandırmanızı ne kadar basit tutarsanız o kadar iyi. Eğer Emacs ile ilgileniyorsanız, aşağıdaki linklere de göz atın, istediğiniz zaman yorum yazıp bana soru iletebilirsiniz.

    Kaynaklar

    1. Bilgem Çakır, “Kullandığım Araçlar: Emacs”, https://youtu.be/qXw0ocR_XBI
    2. Üstün Özgür, “Emacs: Özgür Yazılım Devriminin Editörü”, https://youtu.be/FsN3Yp05_aQ
    3. Örnek config dosyası: https://github.com/gkmngrgn/emacs-config/blob/master/init.el
    4. Spacemacs projesi: http://spacemacs.org/
    5. Awesome Emacs: https://github.com/emacs-tw/awesome-emacs