Skip to content

Latest commit

 

History

History
1270 lines (970 loc) · 56.2 KB

TODO.org

File metadata and controls

1270 lines (970 loc) · 56.2 KB
Raw

Learn from other people’s Emacs configurations

Fix Emacs’ selection after window quit/close

So very annoying. Apparently switching window focus after creating window splits somehow causes a window kill to not select the window’s parent anymore, but instead selects a different window.

Repro: C-x 3 C-x o C-x o C-x 2 C-x 0

Result: Switches focus to the other split side instead of the parent window.

Very likely to be something within delete-window-internal.

Fix Emacs’ window quitting behaviour

This seems to pose a significant issue for implementing interfaces that pop up buffers and need quitting to just work. It would be obvious to implement a FIFO-like structure (see http://sprunge.us/aGHM), but that’s not how it works. (info "(elisp) Window Parameters") should have the relevant information on influencing this behaviour.

Investigate in recentf truncation behaviour

Something about it feels off. It’s supposed to remove duplicate entries first, then truncate if it’s still too long, but it feels like despite a fairly high history length it truncates too many recent files. In other words, I want a behaviour comparable to zsh and its history pruning. In case that’s not the reason for it, I’ll probably just increase the history limit to a ridiculously large number.

If the situation should turn out to be hopeless, I better investigate into Fuco’s autobookmarks instead.

Join forces with Fuco and think up better names for the projects to hack on

The plan is to do a Github organization and to learn useful stuff along the way, such as advanced dash usage, EIEIO (an undebuggable partial implementation of the infamous CLOS) and more abstractions. The general plan is to reimplement sane subsets of popular packages since those are assumed to be unfixable with a few pull requests, such as helm, ace-jump and many more.

As for the name of this organization, I plead for tetracat and either http://brause.cc/tetracat.jpg or a derived work. Should be only a matter of time with a graphics tablet and either Inkscape or Krita.

Rewrite a sane subset of helm

I should really just contribute to sallet by either fixing bugs, implementing features or just writing interfaces with it that replace the helm ones I’m currently using (see the respective section of my init.org). Here’s a list of helm-like interfaces I’d like to have additionally to currently existing ones:

  • Arch Linux Package and AUR search
  • Search of Emacs C internals, zipped system parts, personal config
  • helm-do-grep with a history
  • org document outline
  • dict.cc interface
  • mpd
  • a better cmd-T interface which doesn’t truncate the paths or locate with path truncation from the current directory on
  • full-text search of info manuals

Rewrite a sane subset of dired

Let’s call it rind (for rind Is Not dired or ranger-INspired dired). The reason why should be obvious, dired’s method of getting file information by parsing ls output is brittle and it’s surprisingly hard to extend. I really like ranger, but it does neither live within Emacs nor is it able to be extended with elisp. Fuco’s etable looks like a good starting place for writing the UI. Alternatively, ctable might be it, weren’t it for all these strange diagrams…

Rewrite a sane subset of tramp

I’m not even sure whether that’s a good idea at all, let alone how to test such a thing considering I don’t have many remote boxes to try it on (or to be more precise, just a single one). It could very well be that my issues with it arise from its implicit integration into Emacs.

Here’s a Sublime Text package going for the explicit way:

https://wbond.net/sublime_packages/sftp

Rewrite calfw

It is pretty much impossible to understand and has bizarre bugs (like, quitting fucks up position of the window point in the last buffer). Also, writing your own calendar seems to be good tradition to experience the many falsehoods programmers believe in about time and dates yourself.

Rewrite AUCTEX

It behaves differently from every other newer mode, is hard to understand and customize and I don’t need most of its features anyways. So, maybe take a look at the following and do better (then call it nique?):

Write a more interactive LaTeX preview

Something à la LyX or https://www.overleaf.com/. This will be pretty tricky. One possible approach is writing something along the lines of KaTeX for fast visualization, then some heuristics to figure out when to rerender and logic for turning interaction into updates. Either it will be about putting a pseudo-cursor into a rendered image which you can interact with in a limited way or incrementally updating already typed TeX code. Probably not worth the effort.

Make a list of (REPL) modes to enable company for

Stuff like ielm would qualify. Perhaps some textual modes, too.

Improve elisp completion in company

There are a few corner cases (with company-elisp, check whether they are still present in company-capf), fix those. The one annoying me most is when I’m in a quoted or let-binding list and the completion assumes that it’s first item must be a function which is just wrong. Additionally to that it would be very cool to have contextual completion inside macros, like loop to get the loop keywords as candidates.

Learn how company-capf works

The elisp backend was replaced by it in 24.4, its code should tell me enough about the effort involved in getting other backends to use it. Porting the other ones over (like, the nxml, jedi and CSS backend) will give me completion styles for them.

Integrate yasnippet into company

company-yasnippet looks pretty snazzy, the only thing preventing me from using it is that the official documentation suggests making company-backends buffer-local and change its value in every mode making use of snippets.

Write own snippets

I’ve installed yasnippet because at that time I had to write Java code in a course and didn’t feel like using Eclipse. The default snippets are a bit problematic though, especially the ones used for elisp code because they’re very short and get triggered even if I hadn’t inserted the text beforehand, so hitting TAB in an already written line at an arbitrary position where the text before point makes up a valid snippet abbreviation triggers it. That’s definitely not ok, part of the solution would be writing my own, the other would be giving them longer names suitable for tab-completion via company.

I should add my whimsy snippets to my Emacs configuration, too.

Learn the yasnippet syntax

http://capitaomorte.github.io/yasnippet/snippet-development.html

Write a flx-like completion style

While there’s already flx code, I need to find out how completion styles are implemented and check how slow they’d be with flx as is. If it’s not fast enough, write a binary component in CHICKEN and make it flexible enough for more than just that.

Reuse binary component from above for helm / ido matching

This would solve the problem of not having nice and fast flex matching à la Sublime Text. The key to this is the combination of fast submatching (heatmap + optimization that makes use of the reuse of the string since you usually append a glyph at a time and therefore don’t need to start all over again) as described in this blog post and sorting of the candidates by criteria that make matches for word boundaries appear at the top. I’m afraid the hard part would be rather integrating it in these tools than writing it judging by the fact that some ready-made solutions do exist (like ycmd, fzf, selecta, pick, etc.), yet nobody did wire them up to Emacs yet.

Write a pure elisp torrent client

Sounds like a pretty hefty exercise considering a network process that errors out can cause Emacs to hang up and it doesn’t have the facilities required for writing sparse files exposed (yet, I’ve found internal C functions for advancing to arbitrary positions in files, see fileio.c when searching for lseek). It would probably be more useful to write a proper frontend to an existing torrent client.

edit: write-region supports seeking with the APPEND argument, insert-file-contents takes a start byte and seeks to it if possible. That leaves allocating a sparse file, but maybe you can leave that to an external utility like dd or fallocate?

Help out holomorph with his transmission UI

Unlike the previous entry this sounds very doable and profitable. Here’s some somewhat related resources:

Investigate in database fun

The standard advice for applications relying on state serialization beyond serializing something lispy (with pretty-printing deactivated please) is to speak to SQlite3, but that’s a poor match for Emacs as it’s not embedded into it and speaking to the CLI utility can deal with the CSV format at best. Yuck. See also emacsql for a package doing exactly that, it could use a lower-level API for more utility (as described here).

The other problem is that Emacs can only read in a file completely. No arbitrary seeking and reading allowed. See Elfeed’s database for a workaround. Maybe using lseek or modules will be viable at some point, dunno.

edit: That’s wrong! You can actually read and write after seeking to an offset, it’s just not very obvious that this kind of thing is possible. See write-region and insert-file-contents for details.

An alternative is just using some sort of in-memory store that behaves either relational or key-value-like, I’ve started writing pdata.el for that purpose because I’ve seen datascript and liked the idea of worrying less about storing state while being able to query it in a more structured manner, but it will be more like sql-de-lite (very bare-bones, yet high-level enough) and Active Record (see the convenience methods, not the design).

Fix long lines bug

Oh boy. My main idea how to fix this properly relies on section 6.3 of the ECO document. In other words, keeping track of visual line breaks, using them to speed up rendering and keeping them up to date. This will obviously require hacking on the buffer data structure and display code to make use of it.

Update: Apparently there is such a thing as a cache for newlines in the buffer. So maybe I’m not totally screwed and it’s merely a matter of working with font-lock. Whether that’s actually simpler is a different question of course.

Fix overlay slowness

See the following thread for the reasons, possible remedies and facepalms about RMS being silly for no damn reason.

https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00616.html

Bring pixel-level smooth scrolling to Emacs

This is part of the railwaycat OS X Emacs port. To my surprise the code enabling it is 99% elisp and a few lines of C in xdisp.c. It would be very cool if it could be done in 100% elisp, but a small patch wouldn’t hurt either.

Update: I hope this is not the reason for the C-level hack:

http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00695.html

Write a proper CSV viewer/editor

Until that long lines bug is fixed, viewing CSV files is no fun. To remedy it for now I thought of writing something like a mixture of tabview and sc (and call it sv-mode because it’s for separated values). In other words this displays a truncated viewport where you can scroll through cells and offers keybinds to edit rows and columns or change the view to something more useful (such as sorting, filtering, etc.), something well known from curses applications. More specifically, I would try inserting the long lines, then attaching the display property to display less than that and keep updating its value on changes. No idea how navigation would work (overloading keys à la org-mode or binding something else than the normal movement commands in a keymap property?).

Write a proper hex editor

There’s the built-in hexl-mode which uses the hexl binary upon the buffer and creates a new buffer from it. This is less than ideal as it loses editing history and isn’t just an alternate view for the data you’re editing. I should check out nhexl-mode as it’s using overlays for the display trickery, but this will probably make the experience pretty slow.

Ideally I’d like to have assistance from the mode in understanding the structure of the binary file I’m looking at. The 010 editor has a binary templates feature which picks a template file and uses it to dissect the binary data into the sections of its file format. Here’s a few of them in a C-like format, using something lispier might beat them for tasks like reverse engineering a new format and getting feedback by displaying overlays on the contents.

Rewrite linum

Looks like this mode is inserting an overlay per visible line which contains the margin content. I can think of a few ways of speeding this up:

Try out SVG modeline/margin

forcer suggested on #emacs to do tentacle scrollbars. This might be possible by abusing the margin or the toolbar. See tool-bar-setup as entry point.

Meanwhile, someone did dig out sabof’s svg-mode-line and created something nicer to look at with it. I don’t really like the idea of just slapping an image on the left or right side of it and leave the rest as is because it’s about as boring as Firefox Personas. What interests me is that text used in SVG isn’t subject to explicit fallback (and fallback works out of the box), another thing to exploit would be the fact that there’s no height restriction, so this could be used to have a two-line modeline. While it is possible to replicate mouse events (the :map property in (info "(elisp) Image Descriptors") explains how), I wouldn’t really want to waste time on them.

In case I should reconsider my decision regarding images (like, for a fun blog post), I’d like to use base16+greyscale with a tiny bit of color and a cartoon bird.

Write some more graphical games

I’ve had enough fun with SVG (although I should at least finish up the animation part in svg-2048), XPM would be the next thing I’d tackle (for something like Conway’s Game of Life). By then I should have a good idea what’s better to use and could proceed with other fun games, such as clones of xeyes, breakout, tetris (replicating TGM3 would be very cool), super hexagon, something like Tower Defense. Maybe something demo-like with procedural graphics. Maybe go more abstract and whip up everything necessary to do more advanced games, like stuff reminiscent of visual novels (although, would they work without sound?), platformers, bullethell shmups, etc. Who knows whether one of those might become the next Emacs killer app.

Update: Although a game engine is probably not a good idea, it might be worth taking a look at dto’s rlx for helpful hints regarding UI and capabilities.

Write graphical demos

So far I had a flipbook (see the Quasiconf 2014 files), this could be abstracted into a video player (which converts the video into frames beforehand, mind you). The more realistical option would be extending it to become a GIF authoring environment taking a set of frames and offering preview functions for changes made to them. A pixelart editor would be very cool, especially for things like my demo on http://brause.cc/. A fully-featured SVG/Bitmap editor would be more utopian, but the groundwork for that is laid with the svg.el package (which could become a fast canvas-like) and proper bitmap embedding support in Emacs 25.1.

http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html

Finally, paying homage to the demo scene would be the silliest option I can think of, but cool if combined with audio.

Try out the bgex patch set

This allows you to make use of a XPM image as static background. Maybe that’s the way to implement the shoop from YUNOcommit.vim, assuming it supports transparency and I’d generate the right XPM on every window size change. A more advanced example would be recreating an animated clippy character and call it clippy.xpm (in resemblance of clippy.el)

https://github.com/wachikun/emacs_bgex

Update: It sort of works. Animation is terrible (everything flickers) and there’s only tiling, so you’d need to generate pngs all the time and that’s not really feasible.

Bring images into the terminal

Some crazy japanese guy wrote libsixel, a library providing encoding functions for the Sixel standard used by really old terminals (and some newer terminals, including a patched xterm) to have escape codes that are decoded as 256-color images. I can imagine this to work as transparently as possible by turning a decoded image into the respective escape codes instead of discarding it completely.

Finish bytebeat demo

I’ve started writing one by opening a pty (which is definitely not portable) and shoving chars into aplay or paplay. Currently it’s blocking, it would be better to start an asynchronous process, then send arrays of ints in regular time intervals (with a timer presumably and a bit of extra buffering). Another cool feature to implement would be having the function for creating the ints separate from this so that changing and re-evaluation changes the sounds being played accordingly. Finally, visualization of the currently processed ints would be pretty awesome, especially if it were wrapped up in a major mode depending on the library that pops up a window with a XBM or ASCII art in it.

As for the interaction style, perhaps something as minimal as lisp-interaction-mode (meep-mode anyone?) could work, with C-c C-c sending off the current buffer’s formula.

Create my own starter kit

HollywoodOS™ with SVG and something terminal-looking with lots of text over it would be a really silly one. So would be a 1984 one that makes Emacs look and behave even more arcane than usual (with reduced colors and all that).

Write a fast terminal emulator

Perhaps with FFI (not sure whether the official one or skeeto’s approach) and libtsm one could write something considerably faster than ansi-term, probably not though.

Update: Neovim did it.

Write audio demos

See my demo with Overtone for Quasiconf 2014. It would be super-cool to have something like a keyboard to play melodies, ideally by driving CSound 6 via OSC instead of Supercollider (perhaps csound-x has some hints on that). It would be even more cool to turn it into a keyboard-driven tracker to compose music and tweak synths or create samples to play.

An alternative approach would be either fixing the built-in audio support (it blocks and is WAV and AU only) to be asynchronous and work on a mixer object or using FFI and a cross-platform library.

Work on helm packages

I’m less happy about helm-smex. It would be a lot better to add a helm interface to smex directly instead of hacking something that reuses the data the ido interface creates.

Bump bug reports without replies

According to Eli Zaretskii this should be alright to do after a week without replies.

Hand in a bug for browse-url-can-use-xdg

This function is not reliable as it only works on a few select Desktop Environments and essentially replicates what xdg-open is doing already in a less complete fashion. Before handing in the bug I’ve got to find out how to detect it working in a better fashion. My rather naïve assumption would be that if there is such a binary, the Xorg session is running and executing it gives me a return code of zero, everything’s fine.

Send in a patch for debug-setup-buffer

I’ve figured out that when evaluating a buffer, this function inserts the buffer position where the error occurs. It is possible to turn that into a line number, making it a button that takes you to the file would be pretty cool and surely a good candidate for a patch and mailing list discussion since it makes the --debug-init option more useful.

Discuss --debug-init and why it’s not a default

Another candidate for the mailing list. I am still dumbfounded how one starts Emacs, gets an error at start, then is told to quit and start it again with that option to get a backtrace. Why isn’t this option made default? There doesn’t seem to be any performance penalty, it can be deactivated after successful init and for the very unlikely situation that there is stuff relying on it not spawning the debugger (instead of a generic error window) like batch processing, a new option to deactivate it could be introduced instead (and the option itself be deprecated by making it a no-op).

Investigate into the debugger to make it better

I don’t know much about the keybindings yet and am much more acquainted with edebug unfortunately. Finding out how the debug works would be very cool since it seems to always work, there have been a few posts about stackframes on the stackexchange.

There is a wonderful screenshot of a Lisp machine where the debugger runs into a division by zero and displays the faulty expression with the form causing the error highlighted in bold. That sounds even better than displaying a line number and button to jump to since evaluation does not necessarily happen to a file.

Another thing I’d like to see would be backtraces with less bytecode in them, for both aesthetical (they take up loads more screen estate) and practical (they break copy-paste on a null byte for me) reasons. It is possible to re-evaluate a function to obtain prettier display of its forms, with byte-compilation most of these are lost.

The not so S-Expression-like display of the stackframes isn’t ideal either, it looks more like functions in other languages than something lispy. Why they did that is beyond me.

Report bugs for not properly derived modes

There are a bunch of modes that ought to be derived from text-mode and prog-mode, but aren’t. All of those should be reported to make my hooks section cleaner.

Fix up the (package-initialize) mess

http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00620.html

Apparently the quick and dirty “Fix” is inserting this instruction in your init.el every time you use package.el if it wasn’t found before. Awesome. I need to go for my “social” fix and tell Marmalade, MELPA and GNU ELPA about the problem of explaining newbies about it.

Update: MELPA already got such a note, GNU ELPA got one as well. Marmalade, well, Nic Ferrier hates the very idea of using package-initialize explicitly and everyone doing it, unfortunately the issue thread devolved into offtopic.

Rediscover org-mode again after having learned elisp

I’ve stayed away from org-mode from everything else asides note taking and keeping track of things in README-style files since the configuration and elisp involved scared me off. However I’m armed with everything necessary to embark this part of my Emacs journey again, so why not go through the agenda, refiling, clocking and many more to keep track of things again?

Figure out how evil works

All I know so far from cursory glances at the sources is that it does black magic on keymaps, appears to have implemented a type system for editing commands with elisp macros and has an actually proper looking parser for ex commands. This is kind of intriguing and surely a good chance to learn advanced concepts.

However the documentation is a bit lacking when it comes to extending it. Another issue is that several critical variables are empty at definition, but filled after startup. Therefore combined reading of the sources and inspection of variables while it’s running are necessary to gain understanding in its inner workings.

Fix evil-surround

Its commands are not repeatable which sucks since they are comparatively long. Another annoying one is how lines are wrapped by introducing more lines. There doesn’t seem to be support for HTML tags either.

Fix evil-matchit

Its author doesn’t seem to be aware of idiomatic elisp at all, let alone making it integrate properly into evil. I could of course NIH my own and replicate matchit.vim as closely as possible, but I’ll try out just how far I can go to make upstream improve it since these complaints are fairly minor compared to the wrongdoings of ace-jump for instance.

Figure out how to break out of evil’s type system

While it is convenient to have operators and motions to just work with everything, some Vim plugins intentionally break the grammar to use lesser common or nonsensical command sequences for their own commands. One of the better known examples would be ysiw` which would normally do a yank operation, however in this context ys introduces wrapping of a text object, in this case it’s inside a word and the wrapping is done with backquotes around it.

In Vim this kind of trick is done by carefully thinking up all key sequences and binding the appropriate functions to them, essentially overwriting the parts of the default bindings as necessary. In evil however there is no proper solution yet, so far upstream suggested replacing an operator with a wrapper that calls the original one unless one of the bindings is the one belonging to the nefarious package. It would be a lot better to have official access to this to avoid endless cascades of wrappers outsmarting each other (it’s not as bad as in Win32 yet, but who knows how bad it will become).

Implement virtualedit=block for Evil

See cua-rect.el and the cursor text property for allowing to move into a virtual position (both after text and in tab indentation). The other problem to solve is to tell Evil that editing these virtual positions is OK, perhaps you can fill/replace them with actual spaces…

See also http://emacs.stackexchange.com/questions/14775/evil-rectangles-with-point-past-eol

Discover worthwhile Vim plugins to turn into evil packages

Should be mostly editing-related hacks, such as replacing the t, T, f, F, , , ; motions with more powerful ones that are between one-letter jumps and ace-jump style motion to arbitrary one-letter jumps by allowing one to do two-letter jumps instead.

The rest is mostly improving Vim idiosyncracies (just like there’s stuff improving Emacs idiosyncracies) and packages that come somewhat close to what already exists for Emacs (compare fugitive to magit for instance). Some exceptions are there though, such as the excellent yunocommit.vim (see company for possible approaches to overlays with images), a Flappy Bird clone and the powerline that works in terminal emulators (the many Emacs ports only support graphical instances since they actually draw bitmaps into the modeline).

An evil state for ASCII drawing would be fun, much better than arcane keybinds or ex commands. Instead you’d have operators and motions to edit and draw plus some commands to toggle stuff.

Some links:

Write something educational Emacs-related content

A game for drilling readline-bindings or generally Emacs bindings? Making it bullethell-like (who wouldn’t like shooting the heck out of… text) with powerups emulating famous packages (like paredit, ace-jump, etc.) would be so very silly.

Another thing crossing my mind would be koans.

Or even go the full route and write a book on learning proper Emacs Lisp, maybe the hard way. I suspect just summarizing useful resources would already help a lot for the aspiring new blood.

An alternative way to teach Emacs Lisp would be in form of a more elaborate game, I’m thinking of something text adventurish, but with the goal of doing more than in the koans, like by filling in the missing parts of the game. That kind of thing will of course only work in Emacs…

http://codelauren.com/ https://www.codecademy.com/

See calandria for something that will hopefully prove a subset of this (fixing things in a game to teach you programming generally instead of the programming that made up that game) is workable. TIS-100 looks a bit closer to what I’ve envisioned with its minimalistic visual style and developer-oriented UI.

Configure smartparens to start out with way less pairs

It’s annoying to fix quotes for every Lisp-related mode (text-related ones, too). I’d prefer a default auto-indent function for braces.

Integrate smartparens into evil

A separate evil state sounds best, https://github.com/syl20bnr/evil-lisp-state demonstrates how it could be done, however it regressed to accomodate for Lisp coding with https://github.com/syl20bnr/evil-lisp-state/commit/fdddd81806ccbcad8cdf04edeb47816314bda8ae.

Learn smartparens actions, do GIFcasts

There’s a ton of them, but GIFcasts only for paredit. Would be very nice to have visual reminders for them, presumably lots of work, too. byzanz-record to the rescue!

Record GIFcasts for my own packages

Demonstrating eyebrowse commands would be quite cool (and an improvement over the current “See that pretty indicator? That’s eyebrowse!”), not sure how useful it would be for other packages.

Set up an Emacs mail client

mu4e looks great, however the PKGBUILD on the AUR isn’t updated since the change that makes threading usable. Another problem is figuring out everything necessary to make mailing lists acceptable and multiple accounts for sending mail. I’ll need to keep it running parallel to mutt for a good while to figure it all out, but then I’ll hopefully be able to reap the rewards such as no more encoding issues and templates for mails (like, daily reports).

http://cmacr.ae/blog/2015/01/25/email-in-emacs/

Here’s a list of more specific things to look into:

  • Improved workflows (sifting through mail, marking all as read, undeleting, archiving, a dired interface)
  • Having one unified inbox/archive (with indicators where the mail came from)
  • Picking the sending details upon replying to something, including a reply-to-all method when having mailing lists or bug trackers as originators
  • Templates
  • Predefined views for quick switching
  • Fixing encoding mess

Hack more on circe

There’s plenty on the issue tracker. I’d find a cloud-to-butt thing funny which would replace instances of “Cloud” with a propertized “Butt” that shows the original word on hovering.

Another fun hack is displaying fools as XPM piggies instead of hiding them, ideally with the toggle function doing a bit more work (by traversing all circe buffers by looking for property changes involving lui-raw-text) on every toggle. The idea could be explored by another hack that retroactively applies fool (maybe ignore, too?) information.

I wish for hats to show up in the nicknames of messages, not only in the initial listing. The initial listing could come in sorted alphabetically (instead of being sorted by join time?). Working with IRC commands would be cool (IIUC you have sort of a callback system with commands and display handlers without the ability of determining what request the response belongs to, so this requires guessing), such as an /IDLE command (which uses the extended WHOIS form and snips out the interesting field) or a module that “stalks” other people by checking up whether they’ve joined recently and what channels they’re on (with the ISON command, maybe WHO as well).

The coolest idea I came up with is a link preview à la 4chan/imgur for images, especially animated ones. Hovering the mouse over an image link would then fire off a HTTP request (HEAD or a truncated GET?) to discover the content-type, if that content-type is an image Emacs can display, a second HTTP request is done to retrieve the image and it is stored as temporary file on disk. That image can then be mogrified with Imagemagick or displayed downscaled (via SVG and inline base64 data?), then show up in a tooltip. Caching is pretty important to avoid re-downloading the files and serving them from the cache if they’re still present, so is dealing with errors (such when someone puts the cursor away while it’s half-done or retriggers the popup by quickly putting it back in place). I can imagine extending this to display the title or filename for resources that cannot be displayed as a thumbnail.

Minimal demo:

;; (info "(elisp) ImageMagick Images")
(tooltip-show (propertize " " 'display
                          '(image :type imagemagick
                                  :file "foobar.png"
                                  :height 50)))

Configure elfeed

Now that I’ve configured newsbeuter to resemble other newsreaders with grouped feeds, using elfeed should make a lot more sense for me, especially after customizing it to be more flexible than it, like by automatically marking everything older than a month as read.

Hack on my own packages

shackle looks pretty much ok (except one open issue), form-feed needs discussion on emacs-devel for figuring out the cursor kicking issue, gotham-theme could use a lot more faces, eyebrowse is kind of stalled and can get new features.

quelpa however could need love.

Make eshell and its completion more usable

There’s apparently no completion of arguments like in zsh. Perhaps a parser of its files could be built in, alternatively for bash. Combined with company-capf this should make for very awesome argument completion.

Hack on eshell to acquire non-standard functionality

Having company-mode enabled is one of the easier examples what’s possible to do in an Emacs shell. However, I’m sure it’s possible to progress beyond that. Both finalterm (possibly magit-process as well for its foldable view and color-coded feedback) and xiki (which ironically started out as an Emacs package extending org-babel) demonstrate other cool features.

http://www.tecmint.com/wp-content/uploads/2014/01/FinalTerm.gif

Write a package for restoring former active regions

The region consists of mark and point, so saving the values of both upon deactivating an active region (with deactivate-mark-hook) for the buffer in a ring is required, similiar to what winner-mode does. Upon invoking its command, a preview with a differently colored overlay of the last selection is shown, an extra command would switch to the next one, just like C-y and M-y do. Finally, aborting would deactivate the preview (and restore the previous state by setting point to what it was, same for the mark and its state if it used to be active), selecting would deactivate it and use what the preview was displaying as basis for a new selection. That would require a temporarily active keymap, either by using a proper minor mode or a transient keymap.

Write tool for grepping Lisp code

The idea is that since Lisp code parses easily into a tree, one could read in a file (and when necessary, uncompress it on the fly with something like libarchive), parse it, then apply a shorthand graph/tree querying language to find the interesting bits.

I don’t know what kind of language though, possible inspirations are CSS selectors, jQuery selectors, XPath/SXPath, Git/Mercurial Changeset specifications, Gremlin, possibly many more.

It would be pretty snazzy to write it in CHICKEN, although there’s only separate eggs per decompression algorithm, like z3.

Update: Zippers would be pretty cool to use for this and query languages easy to compile to them.

Write tool for analysis of Emacs sources

Would be very useful to be able to find function usage with something a lot more usable than Regex-based solutions (like, tags), perhaps the previously mentioned hypothetical tool would work. Other stuff to look for is library usage and making sure it can parse both libraries and configurations for dependencies. For docstrings it’s important to keep in mind that snarfing them works differently for the internals, see make-docfile.c for further details.

Write a web UI over a scraper that uses the aforementioned tool on popular hosting solutions

A server-side tool that crawls websites like Github to detect Emacs configurations and allow for searching these (with automatic tagging this would allow for finding all configs using gnus or for writing C) would be more useful if coupled with the aforementioned search tool and would beat Github’s search for finding out the usage of an elisp feature.

Another cool thing to do with that data would be visualizing the popularity and usage of packages and their dependencies. See CrossClj for a demonstration.

Write a web UI that unifies all popular package archives

It sucks that neither Marmalade nor MELPA are particularly good at browsing and finding stuff easily. Something like Vimawesome with usage statistics would be very nice to have. Discoverability FTW.

Write a web UI to allow comparing differences between the library parts between Emacs releases

It would be very cool to find out what exactly breaks/improves between Emacs releases and have an useful UI for browsing over it, sort of like RDoc where you see docstrings and can fold out sources to peek at the implementation. Add diffing and a good overview and that should be it. The data could be static except for HEAD (with daily updates).

Make news feeds for MELPA and Marmalade releases

There’s currently twitter feeds that are mixed, not sure whether there’s anything for Marmalade even. It would be useful to have one for newly released packages and a separate one for their updates, maybe even with Changelog links (either a commit summary or a file if it exists with diffs).

Make a progress website on MELPA Stable

Not all things can be used from MELPA Stable (like, Evil). Make a website visualizing how ready it is to be actually used.

Bring comint hacks upstream

Despite comint feeling somewhat arcane, it is surprisingly useful for anything REPL-like derived from it. I have a few hacks in my config that could very well make it upstream, such as history wrap-around or partial buffer clearing.

There’s other stuff I’d still like to do, such as persistent history per buffer name/mode, similiar to what rlwrap does. Maybe an extension of that one hack started on the Stackexchange where I truncated overly long lines and added an overlay to display the original ones.

Port major modes that ought to use comint to it

I’m not sure how much sense it would make for eshell. But then I’d at least not have to redo my hacks for it again. Another candidate I have in mind is inf-ruby. Perhaps the interaction modes for Clojure, CL and Scheme would benefit from it, too.

Find comint-derived modes that could make use of syntax-highlighting

See http://emacs.stackexchange.com/questions/2293/change-syntax-highlighting-without-changing-major-mode

Improve Emacs-Scheme integration

I’m currently using M-x run-scheme which is good enough for me (will try out Geiser later). One annoying thing is that flipping through the command history can break the REPL by turning its buffer read-only and appending the last input to it every time I hit RET, then doubling the amount of input added (probably related to my hack to make it stop wrapping at the beginning and end, but still very bizarre and infuriating). Another one is that csi truncates error messages, that is not good with rainbow-delimiters-mode enabled, investigating in its sources and offering an option to forbid truncation or truncate in a smarter manner (like print in Emacs, but for backtraces only) would be useful.

Update: I’ve tried out Geiser… and it broke. It’s spamming queries and auto-completion attempts throw errors :(

Make savehist save more

See savehist-additional-variables.

Improve package.el

When it comes to its adherence to MVC, it’s pretty terrible (you need to open the view before you’re able to do anything beyond installing a package blindly) and lacks a good amount of functionality you’d just expect to be there (nothing to view changelogs, previewing packages, removing packages outside the view, searching dependencies, etc.). There’s plenty other problems lurking in there including installation bugs.

Fix spamming bugs for rcirc (and ERC?)

There’s at the very least a bug making RET RET on the nicklist in rcirc send the entire nicklist to the channel. One possible solution would be special-casing the nicklist, a more general one would involve a paste protection for both long messages and messages containing newlines with tresholds for both.

There is spam protection present in development versions of ERC, but it’s not enabled out of the box. An one-line patch should remedy that once it’s made it into a release and into Emacs.

Write package for hacking on keymaps

There’s nothing just previewing them properly or more than the bare minimum for creating them. Just doing some research on those and nice-to-haves would be nice for a blog.

Explore Hydra a bit more

I’ve replaced my helm-fkeys package successfully with it, however its aspect of repeatable actions definitely sounds interesting, too. Obvious candidates would be window resizing and font size changes, perhaps other stuff like macrostep as well.

Finish up nekobot

I’ve started writing a bot using Circe, my prefered IRC client. Two unexpected difficulties cropped up though, for one I didn’t find any ready-made library to select parts of html (which would have been necessary to write extensions dealing with web services), the other one is that its author decided to rewrite its internals after hearing of my endeavor. Once that rewrite is fully done (most of it is, there’s tests and bugs to be fixed), writing a bot should become simpler.

Implement zippers in elisp

These look pretty great for traversing trees in a lispy manner (and even modifying them!) and simple to implement. I’ll probably steal the API from Clojure and implement them with as little recursion as possible (as demonstrated by the very basic cl-zipper). A zip- namespace for the generic functions should work (though, hmm, I could steal the still unused z.el…), additionally to that an esxml-zip- namespace for the esxml-specific things to have (and aliases to everything else?). In case I shouldn’t like them (even with threading macros), a function compiling a CSS selector to a list of zipper instructions should do the trick.

Add a CSS selector thing to ESXML

Port FORMAT to elisp

Self-explanatory. format is actually a complicated wrapper around sprintf which is sort of a letdown. It would be neat to have something more powerful than that when the situation calls for it.

See also https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/pprint/cl_format.clj

edit: It has been done: https://marmalade-repo.org/packages/cl-format

Port ITERATE to elisp

LOOP was ported, but it’s hard to extend and doesn’t look as lispy as ITERATE.

See also https://github.com/jpalmucci/clj-iterate

Port FOR to elisp

https://github.com/Shinmera/for

Port useful Scheme things to elisp

A scm-lib would be fun to have, though the prefixing would kill the fun. What I have specifically in mind is porting the SRFIs defining APIs on data structures other than lists, such as hash tables and vectors. So far I’ve only seen attempts at abstracting over hash tables, alists and plists, but pretty much nothing for vectors.

Another cool thing would be foof-loop or Racket’s for as they look easier to port and extend than ITERATE. Not only do they make for a lispier alternative to LOOP, no, they allow for easier nesting as well.

Port useful Clojure things to elisp

Same as above, but as a clj-lib.

Write a package for annotating all kinds of human-readable files

This is a pretty popular request, I should research into existing solutions for Emacs first. One half seems to be focused on linking org captures to files which is a hack at best, the other half actually puts some UI over the original buffer with overlays (but is dead).

The UI can be stolen from Google Docs or Genius (select a range of text, enter annotation in a commit-style buffer, save/discard, see a highlighted range in the original buffer). What I’m less sure about is for one the storage place of such annotations (in the same place with an appended extension or in a central directory generating subdirectories as needed?), the storage type (serializing a data structure will require defining a stable format to avoid version mismatches, renaming could be caught by using git as storage engine) and the way these annotations can be displayed (minibuffer, pop to buffer, tooltip, right margin, inline, etc.) and edited (like the commit buffers?). How useful it would be in practice would be the other question, both because I can’t imagine using it excessively and because overlays are known to cause performance issues (which won’t be addressed for now).

No idea about the name (overly? never-knows-best?).

Make a Lisp

Pretty cool guide.

I like how it looks both doable and worthwhile. A lot simpler than implementing R5RS, too. An elisp implementation will be fun to do, the recommended requirements should be a given (some things will require extra work though, like making Emacs behave properly in non-interactive mode or file IO).

There do exist implementations of languages inside Emacs, maybe one can learn from them.

http://www.emacswiki.org/emacs/bf.el http://www.splode.com/~friedman/software/emacs-lisp/src/czscm.el https://github.com/darius/escheme https://github.com/larsbrinkhoff/emacs-cl

Give elnode and friends a try and port Ring, Hiccup and Compojure

I’ve been writing a fair bit of Clojure thanks to work and really like the aforementioned trio for writing web applications (save the unreadable backtraces). No matter how silly the idea of using Emacs as web server is, doing it the Clojure way would be a fun exercise for having an easier way of experimentation with the existing implementation. Due to the still lacking abstraction over these, there’s no Compojure equivalent yet, however there are a few that can be used instead of Hiccup.

Invent Eljure

  • Standalone language running on top of Emacs
  • Intention: Small scripts
  • Not made for: Extending Emacs (see Guilemacs for that)
  • Inspired by Clojure (duh)
  • Fast startup time
  • Comprehensible error messages
  • Batteries included
  • Minimal interop abilities
  • Focus on practicality
  • Builds upon MAL

Planned extensions to MAL:

Reader macros

Regex

  • backslash doubling
  • translation of \d into [:digit:]
  • swap of () / \(\) and {} / \{\})
#"\d{4}-\d\d-\d\d"
;=> "[[:digit:]]\{4\}-[[:digit:]][[:digit:]]-[[:digit:]][[:digit:]]"

Lambda

See Clojure

Set

See Clojure. Back it with a hash table?

Comment

See Clojure. I prefer the look of #; though…

Quote

Extend it to work on vectors. Ensure unquoting works.

Namespaces

Not sure whether Python- (inspectable, dictionaries) or Scheme-style (fast, symbol manipulation), but use Clojure syntax.

Core namespace

  • Keep it small, unlike with Clojure.
  • Bit ops for instance don’t need to be there
  • Implement fn/let/try macros in terms of fn*/let*/try*

Parameter lists

  • Decide against supporting multi-arity functions?
  • Add ? as symbol in parameter lists for optional arguments
(def! foo (fn* [bar ? baz & args] ...))

Batteries

  • eljure.core
  • better process control
  • easy shelling out
  • date parsing
  • better date handling
  • better string/regex manipulation
  • files and file paths
  • networking
  • HTTP client
  • HTTP server (+ abstraction), routing, templating
  • parsing XML/HTML, zippers
  • XCB?

Write an EPUB reader for Emacs

epubmode.el just sucks. Fuco attempted to do better, but got hung up on typographically correct filling. I’ve created teapub in CHICKEN with WebKit and think one could port the approach over to Emacs with relatively little effort:

  • Thinking up a witty name (nov.el?)
  • Extract EPUB as ZIP to /tmp with unzip
  • Basic validation (checking the mimetype file and existence of a content file)
  • Parsing/searching the XML files for the documents and their order (sort of tricky given the absence of XSLT/XPATH equivalents)
  • Creating a derived mode based on Eww (sorry, Emacs 24.3 users) with extra navigation keys and stored metadata
  • Cleaning up after you’re done (sort of tricky as burying is much more common than quitting, an exit hook could work)