102 lines
18 KiB
Plaintext
102 lines
18 KiB
Plaintext
<p>There are a few things I think would be good to see implemented in and around Emacs, but I don’t know if I will find any time soon to do so properly. There is no pride in hiding ideas one thinks might be worthwhile, so I’d like to share them here:</p>
|
||
<hr />
|
||
<h1 id="more-deriving-from-prog-mode">More deriving from <code>prog-mode</code></h1>
|
||
<p>Major modes can “derive” functionality from other modes, similar to how classes can inherit from one another in OOP.</p>
|
||
<p>For example: Customizing <code>prog-mode-hook</code> should affect all programming languages. I think this is a good thing, that makes maintaining Emacs easier: I want <code>flyspell-prog-mode</code>, <code>abbrev-mode</code>, <code>display-line-numbers-mode</code>, etc. to be enabled in every programming mode by default, but I don’t have to add it to every mode I might end up using manually.</p>
|
||
<p>The issue is this: The concept of deriving could go a lot further, and defining new major modes for programming languages could be a lot less repetitive.</p>
|
||
<p><em>So how about this:</em> Instead of just deriving-prog-mode directly, further “abstract” modes are defined for different types of programming languages: <code>interpreted-prog-mode</code>, <code>compiled-prog-mode</code>, <code>interactive-prog-mode</code>. These define their own commands, such as <code>complied-prog-mode-compile</code>, <code>interactive-prog-mode-eval</code>, etc. that are used instead of custom commands for each actual mode. Their behaviour is generic, and depends on the actual mode deriving these intermediate modes.</p>
|
||
<p>The immediate advantage is that the user has less to learn. All interactive modes open a REPL the same way via <code>C-z</code>, all compiled modes compile a project using <code>C-c C-k</code>. Every programming mode has <code>C-c C-f</code> bound to a formatting command. Of course, if a functionality is not available for a certain language, a warning is issued.</p>
|
||
<p>It might even be possible to provide a macro that makes defining these modes even easier:</p>
|
||
<div class="sourceCode" id="cb1"><pre class="sourceCode lisp"><code class="sourceCode commonlisp"><span id="cb1-1"><a href="https://ruzkuku.com/emacs.atom#cb1-1"></a>(define-interpreted-prog-mode python-mode</span>
|
||
<span id="cb1-2"><a href="https://ruzkuku.com/emacs.atom#cb1-2"></a> :eval #'python-mode-eval</span>
|
||
<span id="cb1-3"><a href="https://ruzkuku.com/emacs.atom#cb1-3"></a> :format #'python-mode-format</span>
|
||
<span id="cb1-4"><a href="https://ruzkuku.com/emacs.atom#cb1-4"></a> ...)</span></code></pre></div>
|
||
<p>that then expands to a <code>define-derived-mode</code> and finally a regular major mode definition.</p>
|
||
<p>Of course such a change might be very intrusive, especially when changing the keybindings, as no compromise can be found. I can imagine two mitigation strategies, assuming such a feature should even be included into the core:</p>
|
||
<ol type="1">
|
||
<li>Generic major modes are enabled manually, either all at once or one-by-one. They will not interfere with existing definitions, unless the user expressly permits this.</li>
|
||
<li>Different maps are provided, emulating exiting conventions in popular major modes. By default these might emulate the old mode, but this should be easily reconfigurable.</li>
|
||
</ol>
|
||
<p>Something along these lines could also be done for markup languages.</p>
|
||
<p>(<a href="https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg01389.html">See also</a>)</p>
|
||
<h1 id="a-forwards-compatibility-library">A forwards-compatibility library</h1>
|
||
<p><a href="https://ruzkuku.com/emacs-style.html">Previously</a>, I have expressed my <em>lack of enthusiasm</em> towards libraries such as <a href="https://github.com/magnars/dash.el">dash</a>, <a href="https://github.com/magnars/s.el">s</a>, <a href="https://github.com/rejeep/f.el">f</a>, <a href="https://github.com/Wilfred/ht.el">ht</a>, …</p>
|
||
<p>Despite stylistic and other disagreements, one has to admit that even just a few years ago these libraries met a real need to simplify programming with Elisp. However, for a while now code Emacs has improved, and provides many functionalities it previously lacked.</p>
|
||
<p>The issue is that these have been added in successive versions of Emacs, and it is understandable that a package maintainer might not want to depend on the newest version, especially when older versions are still in circulation, e.g. by being packaged by Debian and CentOS.</p>
|
||
<p><em>So how about this:</em> A library that provides at least strict subsets of functions and variables that have been defined in a more recent version of Emacs.</p>
|
||
<p>So while <code>subr-x</code> defines <code>string-clean-whitespace</code> in version 28.1, and the same version provides <code>length<</code> is written in C the motivation to use this code in a package is limited by the fact that it is not worth excluding most Emacs users for a little convenience.</p>
|
||
<p>Instead, one could depend on <code>compat.el</code>, the compatibility library. This would provide a copy of <code>string-clean-whitespace</code> and a reimplementation of <code>length<</code> that would only be loaded for versions older than 28.1.</p>
|
||
<p>The effect would hopefully be that packages can turn around: Instead of looking backwards at what was supported in version 24.1, they can look ahead and use what is new, without fragmenting the language.</p>
|
||
<p>(<a href="https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg01052.html">See also</a>)</p>
|
||
<h1 id="local-packages-with-package.el">Local packages with <code>package.el</code></h1>
|
||
<p>An issue with <code>package.el</code> is that it is not easy to safely modify packages installed from an package archive. With each update, all your local changes can be overridden, and there is no way to store these changes in a VCS.</p>
|
||
<p>Most packages on the other hand are managed by some VCS (git, hg, CVS, …), but it requires some work OOTB to make that work. My workaround is a mix of <a href="https://www.emacswiki.org/emacs/UpdateAutoloads">this</a> and the thread linked to below.</p>
|
||
<p><em>So how about this:</em> <code>package.el</code> is added support for managing and initializing local packages. Maybe this means new packages can be installed by giving <code>M-x package-install</code> a URL, maybe this means packages can be installed by cloning them into <code>~/.emacs.d/elpa/</code>. Either way, a local package should be automatically byte-compiled and autoloaded.</p>
|
||
<p><code>M-x list-packages</code> might also be able to update these packages, by fetching new commits, and if possible merging them with local customizations.</p>
|
||
<p>The intention is to provide a low-maintenance method of managing packages the user might want to work on, and perhaps contribute their improvement upstream.</p>
|
||
<p>(<a href="https://mail.gnu.org/archive/html/emacs-devel/2021-08/msg00295.html">See also</a>; as far as I know a library called straight.el is comparable to what I am describing, but it rejects <code>package.el</code> instead of extending it. I have not tried it for this reason, so I cannot say.)</p>
|
||
<h1 id="semantic-faces">Semantic faces</h1>
|
||
<p>Someone in my local Emacs user-group suggested this once, and I think it would be nice to see. The issue is this: Do <code>M-x list-faces-display</code>, and a buffer will appear. This buffer documents all the faces Emacs knows of, and shows you how they look like.</p>
|
||
<p>On closer inspection, especially the more packages a user might have installed, one might notice duplication. A lot of faces that indicate “good” things are green, a lot of faces that indicate “bad” things are red. Most markup modes also define similar faces, for similar concepts, that go beyond the basic <code>bold</code>, <code>italic</code>, <code>bold-italic</code>, …</p>
|
||
<p><em>So how about this:</em> A package consisting mainly of face declarations, and uncontroversial/uncreative defaults. That’s it.</p>
|
||
<p>The effect would be that packages do not have to define as many faces, and instead can reuse the ones defined in such a package. My hope would be to see two effects:</p>
|
||
<ol type="1">
|
||
<li>More consistent visual hints and design</li>
|
||
<li>Less effort in defining new themes: Instead of adding support for every package, a theme just has to modify the semantic faces.</li>
|
||
</ol>
|
||
<p>It could be discussed whether or not these faces should be used as they are, or if they should be derived. If I had to decide, I think the former would be preferable from a performance and consistency standpoint.</p>
|
||
<h1 id="package-installation-hints">Package installation hints</h1>
|
||
<p>I think it is good for packages to minimize their UI. Provide as little as possible, let something else do as much work as possible: Be lazy! For example: If implementing a syntax checker for some language Blub, don’t implement a minor mode that generates overlays, defines commands for introspection, etc. Instead, implement a Flymake backend. That way you have less to deal with, while users have less to configure.</p>
|
||
<p>But there might still be something to configure. <code>add-hook</code>, <code>add-to-list</code>, <code>global-set-key</code>, etc. might have to be used.</p>
|
||
<p><em>So how about this:</em> A package can provide machine-readable hints, on how a package can be configured. It might for example want to express that all you need is to add</p>
|
||
<p>My idea (see below) was to use a list <code>pacakge-configuration-suggestions</code> like this</p>
|
||
<div class="sourceCode" id="cb2"><pre class="sourceCode lisp"><code class="sourceCode commonlisp"><span id="cb2-1"><a href="https://ruzkuku.com/emacs.atom#cb2-1"></a>(add-to-list</span>
|
||
<span id="cb2-2"><a href="https://ruzkuku.com/emacs.atom#cb2-2"></a> 'pacakge-configuration-suggestions</span>
|
||
<span id="cb2-3"><a href="https://ruzkuku.com/emacs.atom#cb2-3"></a> `(avy</span>
|
||
<span id="cb2-4"><a href="https://ruzkuku.com/emacs.atom#cb2-4"></a> (key <span class="co">; type of suggestion</span></span>
|
||
<span id="cb2-5"><a href="https://ruzkuku.com/emacs.atom#cb2-5"></a> <span class="st">"Jump to a specific character"</span> <span class="co">; explanation</span></span>
|
||
<span id="cb2-6"><a href="https://ruzkuku.com/emacs.atom#cb2-6"></a> ,(kbd <span class="st">"C-:"</span>) <span class="co">; key to bind</span></span>
|
||
<span id="cb2-7"><a href="https://ruzkuku.com/emacs.atom#cb2-7"></a> avy-goto-char) <span class="co">; command to bind</span></span>
|
||
<span id="cb2-8"><a href="https://ruzkuku.com/emacs.atom#cb2-8"></a> (key <span class="co">; etc.</span></span>
|
||
<span id="cb2-9"><a href="https://ruzkuku.com/emacs.atom#cb2-9"></a> <span class="st">"Jump to a specific word"</span></span>
|
||
<span id="cb2-10"><a href="https://ruzkuku.com/emacs.atom#cb2-10"></a> ,(kbd <span class="st">"C-'"</span>)</span>
|
||
<span id="cb2-11"><a href="https://ruzkuku.com/emacs.atom#cb2-11"></a> avy-goto-word)))</span></code></pre></div>
|
||
<p>but it might also make sense to reuse the customize interface, and add an attribute to user options with hints. <code>package.el</code> could find these and inform the user about possible options when installing a package (or later when requested manually).</p>
|
||
<p>The question then remains if this should just set an option and hide what is being done, or if actual code should be generated? The first way is easier, The latter is preferable if you want to teach users how to configure Emacs. It might even be able to generate <code>use-package</code> and <code>setup.el</code> code from these hints all together.</p>
|
||
<p>(<a href="https://mail.gnu.org/archive/html/emacs-devel/2021-02/msg01183.html">See also</a>)</p>
|
||
<h1 id="persistent-and-caducous-selection-interface">(Persistent and caducous) selection interface</h1>
|
||
<p>I remember being charmed by <code>completing-read</code> and related functions. It was the missing abstraction that distinguished Emacs as a “shell” from the classical Unix shells. And it is true: completing-read provides an interface from both a programmer and user perspective, that can be used for a wide variety of cases. The popularity of “completion frameworks” such as Ivy, Helm, Vertico, … prove this point.</p>
|
||
<p>But the abstraction might have turned out to be leaky. Consider the “type” of <code>completing-read</code>: It maps a set (list, alist, hash table, …) of strings to a single string. OOTB this is clear, as pressing <code>TAB</code> just completes the user input as bash might do in a terminal session. The “completion frameworks” take the liberty of interpreting the interface differently. The focus is placed on narrowing and selecting elements of the set. Technically, both are interpretations are acceptable.</p>
|
||
<p>Issues emerge when developers assume more than the interface provides, and rely on specific front-ends. For example: “selection” makes it easier to choose in non-ascii text, “completion” handles multiple selections well.</p>
|
||
<p>From a developer perspective, the issue of being returned a string can be inconvenient. Especially when the intention is to select an item from a set, the text representation has to be mapped back on to the actual object. This is cumbersome, but also restrictive, because multiple objects might share a common representation (e.g. two buffer might have the same name).</p>
|
||
<p><em>So how about this:</em> If we want selection, we do selection. A function, <code>selecting-read</code>, <code>choose-selection</code>, <code>select-ephemeraly</code> or whatever is created that maps a list to an element of the list. Each element has to be able to generate a text representation, that is used by the selecting function to represent it to the user.</p>
|
||
<p>I have tried implementing this, and it looked something like this</p>
|
||
<figure>
|
||
<img alt="" src="https://ruzkuku.com/images/selecting-read.png" />Selecting a city
|
||
</figure>
|
||
<p>As I was designing a new interface, I decided to add the ability to define hierarchies and attributes to items via cl-generic. The idea was that you could filter items by attributes, fold and show children, etc. In this example is also displays a buffer on the side, instead of the bottom of a frame as most completion frameworks do.</p>
|
||
<p>This might also be extended to a <code>select-persistently</code> function that doesn’t return an object, but attaches actions to objects that are executed on selection. Maybe <code>select-consistently</code> could be updated based on what the user is doing, and provide context sensitive options to suggest (In that case M-<em>number key</em> could be bound to easily select an option).</p>
|
||
<p>An older version of the code can be found <a href="https://paste.sr.ht/~pkal/c926a37e4270e8c67ab20ff1e75f117d5107a8a5">here</a>. I continued working on it, but my implementation was too slow and unstable.</p>
|
||
<p>(<a href="https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00202.html">See also</a>)</p>
|
||
<h1 id="a-cleaner-gnus-a-more-powerful-rmail">A cleaner Gnus, a more powerful Rmail</h1>
|
||
<p>Gnus can be… <a href="https://www.emacswiki.org/emacs/GnusMnemonics">unintuitive</a>. But after <a href="https://ruzkuku.com/rmail.html">using Rmail</a> for a while, I still prefer it when it comes to functionality</p>
|
||
<p>Gnus it is not a mail client, it is a very extensible news reader. Rmail felt nicer when handling mail, not only because it is more light weight. But it lacks too many features I enjoy using, and the code is difficult to work on.</p>
|
||
<p><em>So how about this:</em> A Emacs MUA that explicitly is written for Mail, yet extensible to handle multiple backends, while keeping configurations simple.</p>
|
||
<p>Again, I have sketched out a rough design based on cl-lib. Ideally the configuration should just consist of giving a list of mail sources:</p>
|
||
<div class="sourceCode" id="cb3"><pre class="sourceCode lisp"><code class="sourceCode commonlisp"><span id="cb3-1"><a href="https://ruzkuku.com/emacs.atom#cb3-1"></a>(<span class="kw">setq</span> nmail-sources '((maildir <span class="st">"~/Mail/Personal"</span>)</span>
|
||
<span id="cb3-2"><a href="https://ruzkuku.com/emacs.atom#cb3-2"></a> (maildir <span class="st">"~/Mail/Professional"</span></span>
|
||
<span id="cb3-3"><a href="https://ruzkuku.com/emacs.atom#cb3-3"></a> :address <span class="st">"john@job.com"</span>)</span>
|
||
<span id="cb3-4"><a href="https://ruzkuku.com/emacs.atom#cb3-4"></a> (news <span class="st">"emacs.devel"</span> :server <span class="st">"news.gmane.io"</span>)))</span></code></pre></div>
|
||
<p>Where “Nmail” is a reference to “Rmail”, as I would like it to have a similar UI (message first, list second).</p>
|
||
<p>The user would then enter <code>M-x nmail</code>, select a inbox, and just do what they want to do.</p>
|
||
<p>Admittedly, this is not that creative of an idea. “What we have now, just better and a new name” is standard industry practice. Not only that, but there are a lot of <a href="https://www.emacswiki.org/emacs/CategoryMail">MUAs</a> in Emacs, and I haven’t tried them all. It might be that what I want already exists, at least to a close enough approximation.</p>
|
||
<h1 id="regular-expression-objects">Regular expression objects</h1>
|
||
<p>(Note: This is the idea I am least sure about, because it involves the C-part of Emacs, and my experience with that part of the code is limited.)</p>
|
||
<p>I am not even sure if this is an issue, but I always wondered why regular expressions are always handled as strings. Couldn’t they be compiled to increase performance? Especially considering that they currently are used for a lot of highlighting.</p>
|
||
<p><em>So how about this:</em> A new reader syntax for regular expressions.</p>
|
||
<pre><code>#r<GNU \([eE]macs?\)*\'></code></pre>
|
||
<p>On the one hand, this should make quoting easier, and improve the highlighting of the syntax. But a the same time, they represent a compiled and perhaps optimised matcher object. All the functions that accept regular expressions (<code>search-forward-regexp</code>, <code>string-match</code>, <code>looking-at</code>, …) would have to support this addition, and handle these matcher objects properly.</p>
|
||
<p>Maybe this is premature optimisation, maybe might speed things up. I don’t really know.</p>
|
||
<hr />
|
||
<p>This turned out to be longer than I initially though. I’m just glad I don’t have to keep remembering these ideas, and noticing that I still haven’t done anything.</p>
|
||
<p>My hope is that someone might pick up on these ideas up before I do, in which case I would be glad to discuss, collaborate and contribute. Just <a href="https://ruzkuku.com/#email">send me a message</a>!</p> |