#+TODO: TODO | INPROGRESS | DONE INVALID
#+OPTIONS: todo:t

* Learn from other people's Emacs configurations

- https://github.com/purcell/emacs.d
- https://github.com/magnars/.emacs.d
- https://github.com/Fuco1/.emacs.d
- https://github.com/skeeto/.emacs.d
- https://github.com/mbriggs/.emacs.d
- https://github.com/cofi/dotfiles
- https://github.com/pkkm/.emacs.d
- http://doc.rix.si/org/fsem.html
- https://github.com/syl20bnr/spacemacs/blob/develop/doc/DOCUMENTATION.org

* 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 [[https://github.com/Fuco1/autobookmarks][autobookmarks]] instead.

* DONE 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 [[https://github.com/tetracat/sallet][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
[[https://github.com/wasamasa/dotemacs/blob/master/init.org][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, [[https://github.com/kiwanami/emacs-ctable][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?):

- http://staff.science.uva.nl/~dominik/Tools/cdlatex/cdlatex.el
- http://www.gnu.org/software/auctex/reftex.html
- http://www.gnu.org/software/auctex/index.html
- https://github.com/jhpalmieri/ultratex
- http://www.emacswiki.org/emacs/WhizzyTeX
- http://www.ctan.org/tex-archive/support/ite/
- http://www.yatex.org/

* 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
[[https://github.com/Khan/KaTeX][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 [[http://hergert.me/blog/2013/09/13/fuzzy-searching.html][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 [[https://github.com/Valloric/ycmd/][ycmd]], [[https://github.com/junegunn/fzf][fzf]], [[https://github.com/garybernhardt/selecta][selecta]],
[[https://github.com/thoughtbot/pick][pick]], etc.), yet nobody did wire them up to Emacs yet.

- https://github.com/nixprime/cpsm
- https://github.com/burke/matcher
- https://github.com/jhawthorn/fzy/blob/master/ALGORITHM.md

* Write a pure elisp torrent client

- https://cheatdeath.github.io/research-bittorrent-doc/
- http://pietro.menna.net.br/recurse-center/rust/2015/06/19/rusty-torrent/
- https://blog.jse.li/posts/torrent/

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 and
overwrites only as many bytes as specified, ~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=?

NOTE: http://www.vidarholen.net/contents/blog/?p=479

* Help out holomorph with his =transmission= UI

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

- https://github.com/skangas/mentor
- https://github.com/skeeto/emacs-torrent
- https://i.imgur.com/xX8kgu5.png
- https://trac.transmissionbt.com/browser/trunk/extras/rpc-spec.txt
- https://github.com/skeeto/elisp-json-rpc/blob/master/json-rpc.el

* 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 [[https://www.sqlite.org/][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 [[https://github.com/skeeto/emacsql][emacsql]] for a package
doing exactly that, it could use a lower-level API for more utility
(as described [[https://github.com/skeeto/emacsql/issues/11][here]]).

The other problem is that Emacs can only read in a file completely.
No arbitrary seeking and reading allowed.  See [[http://nullprogram.com/blog/2013/09/09/][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 [[https://github.com/tonsky/datascript][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 [[http://wiki.call-cc.org/eggref/4/sql-de-lite][sql-de-lite]] (very
bare-bones, yet high-level enough) and [[http://guides.rubyonrails.org/active_record_basics.html][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 [[http://soft-dev.org/pubs/html/diekmann_tratt__eco_a_language_composition_editor/][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.

- https://emacs.stackexchange.com/questions/598/how-do-i-handle-files-with-extremely-long-lines#answer-603
- http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15555#11
- http://emacs.stackexchange.com/a/5559/10

Update: Apparently there is such a thing as [[http://www.reddit.com/r/emacs/comments/3aprkn/linumrelative_slow/csetpji][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

* INVALID 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.

- https://github.com/railwaycat/emacs-mac-port/blob/dbf18e1269297e3a6ff5441c59419ad234449c16/lisp/term/mac-win.el#L2007-L2402
- https://github.com/railwaycat/emacs-mac-port/blob/2e5ff4921e4474713878c587965b7e45a0cd12bf/src/xdisp.c#L16227-L16229
- https://github.com/asvd/naturalScroll

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

Edit: http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/pixel-scroll.el

* 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 [[http://elpa.gnu.org/packages/nhexl-mode.html][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 [[http://www.sweetscape.com/010editor/][010 editor]] has a
[[http://www.sweetscape.com/010editor/#templates][binary templates]] feature which picks a template file and uses it to
dissect the binary data into the sections of its file format.  [[http://www.sweetscape.com/010editor/templates/][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.

* INVALID 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:

- http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16545
- Do it like RMS would and use text properties (managed by font-lock?)
  to reinvent overlays
- Just fix overlay slowness
- Figure out how to put a long image in the margin and make it display
  something looking like line numbers ([[http://brause.cc/emacs-trollface.png][probably not possible]], but [[https://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00108.html][one
  can dream...]])

Edit: https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00236.html

* Experiment with SVG modeline

[[https://github.com/ocodo/.emacs.d/blob/master/plugins/ocodo-svg-mode-line.el][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 [[https://chriskempson.github.io/base16/#grayscale][base16+greyscale]] [[http://a.pomf.se/gzkfay.gif][with]] [[http://a.pomf.se/fipnjh.png][a]] [[http://a.pomf.se/uhnkjp.png][tiny]] [[http://a.pomf.se/xdgfuh.png][bit]] [[http://a.pomf.se/wlwhse.png][of]]
[[http://a.pomf.se/uokszd.png][color]] and [[http://2.bp.blogspot.com/-Zosgua6dQ9o/Tz3A0LhPF4I/AAAAAAAABX0/gapxpqgNasE/s1600/Goodnight+Punpun+v01+c01+-+010.png][a cartoon bird]].

* Experiment with SVG toolbar/margin

The toolbar is one of the first things to be disabled in an Emacs
setup.  It covers the whole frame width (unlike the mode line which
appears for each buffer window).  If you were to remove all images and
instead replace them with one image covering the full frame, you could
get a super-modeline kind of thing.  Needs more experimentation
though (especially on non-GTK setups), interaction with modes changing
the toolbar locally (such as info/help/gdb/...) and what kind of info
goes there (maybe a system info thing?)

The margin allows you to put images at the side, unlike the fringe.
For this you use the display property on buffer contents (much like
with the fringe).  The question is, what kind of images would you put
there?  [[http://x32.be/emacs-trollface.png][Trollfaces]] are funny for a while, but something more serious
is needed.

* 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 [[https://gist.github.com/dto/4112806][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.

edit: Nope, =svg.el= isn't it either.  I better stick to esxml....

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.

http://machinethink.net/blog/3d-rendering-without-shaders/
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform (matrix)

Assuming I omit the rasterizing step, this should just work when
applied to SVG as target.  No real shaders though, so either it's
going to be wireframes (hello vectrex!) or distorted textures (hello
doom!).

https://github.com/ssloy/tinyrenderer/wiki
http://lodev.org/cgtutor/raycasting.html <- wolfenstein 3d
https://medium.com/@btco_code/writing-a-retro-3d-fps-engine-from-scratch-b2a9723e6b06

https://css-tricks.com/mega-list-svg-information/

* Write textual demos

Maybe hack on https://github.com/johanvts/emacs-fireplace ?

Writing something like zone (that is acting on buffer contents), but
for interactive usage might be cool:

- asteroids (shoot at letters?)
- breakout (shoot at letters?)
- tetris (fill in the blanks)

While porting https://atom.io/packages/activate-power-mode is not
feasable, its combo mode might be...

* DONE 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 [[https://github.com/esneider/YUNOcommit.vim/][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 [[https://www.smore.com/clippy-js][animated clippy character]] and call it clippy.xpm (in resemblance of
[[https://github.com/Fuco1/clippy.el][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 [[https://github.com/saitoha/libsixel][libsixel]], a library providing encoding
functions for the [[https://en.wikipedia.org/wiki/Sixel][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.

- http://countercomplex.blogspot.de/2011/10/algorithmic-symphonies-from-one-line-of.html
- http://countercomplex.blogspot.de/2011/12/ibniz-hardcore-audiovisual-virtual.html
- https://youtu.be/vCEUyx-SxPw
- https://github.com/erlehmann/libglitch
- http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

* 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).

* Make a comparison of starter kits

https://github.com/emacs-tw/awesome-emacs#starter-kit

The punchline is that none of them are debuggable by =#emacs=.

* INVALID Write a fast terminal emulator

Perhaps with FFI (not sure whether the official one or skeeto's
approach) and [[http://www.freedesktop.org/wiki/Software/kmscon/libtsm/][libtsm]] one could write something considerably faster
than ~ansi-term~, probably not though.

Update: [[http://www.reddit.com/r/vim/comments/30btwx/neovim_now_has_a_full_terminal_emulator_mode_i/][Neovim did it]].

Update: Sort of invalid: https://github.com/akermu/emacs-libvterm

* 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
[[http://en.wikipedia.org/wiki/Csound#Csound_6][CSound 6]] via OSC instead of Supercollider (perhaps [[http://www.zogotounga.net/comp/csoundx-info.html][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.

- http://en.flossmanuals.net/csound/e-triggering-instrument-events/
- http://delysid.org/emacs/osc.html

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.

- http://wavepot.com/
- http://www.windytan.com/2014/06/headerless-train-announcements.html

* 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.

* DONE 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
[[https://github.com/nicferrier/elmarmalade/issues/102][the issue thread]] devolved into offtopic.

NOTE: write patch removing that feature and replace it with creating
an init file with these lines if none was found and emacs was started
normally (so, no quiet mode or explicitly loading a file).

* 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:

- https://github.com/haya14busa/incsearch.vim + https://github.com/junegunn/vim-oblique/
- https://github.com/junegunn/limelight.vim <- https://github.com/larstvei/Focus
- https://github.com/yssl/twcmd.vim
- https://github.com/sosmo/vim-easyreplace
- https://github.com/chrisbra/vim-diff-enhanced
- https://github.com/richsoni/vim-ecliptic
- https://github.com/kana/vim-textobj-user/wiki
- https://github.com/Shougo/vimfiler.vim
- https://github.com/Lokaltog/vim-easymotion
- https://github.com/paradigm/TextObjectify
- https://github.com/wellle/targets.vim
- https://github.com/t9md/vim-textmanip
- https://github.com/AndrewRadev/switch.vim
- https://github.com/unblevable/quick-scope
- https://github.com/jonmorehouse/vim-nav

* Discover worthwhile Vim features to port to Evil

=:help hex-editing= lists autocommands that allow you to edit binary
content with =xxd=.

* 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.

- http://vim-adventures.com/
- https://github.com/jmoon018/PacVim

Another thing crossing my mind would be koans.

- http://clojurekoans.com/
- http://clojurescriptkoans.com/
- https://github.com/google/lisp-koans

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

- http://learnvimscriptthehardway.stevelosh.com/
- http://yoo2080.wordpress.com/2011/12/31/lexical-scoping-and-dynamic-scoping-in-emacs-lisp/
- http://yoo2080.wordpress.com/2014/02/23/threading-macros-from-dash-for-emacs-lisp/
- [[http://sachachua.com/blog/series/read-lisp-tweak-emacs/]]
- [[http://bzg.fr/learn-emacs-lisp-in-15-minutes.html]]
- [[http://harryrschwartz.com/2014/04/08/an-introduction-to-emacs-lisp.html]]
- http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html
- https://github.com/bbatsov/emacs-lisp-style-guide
- https://www.gnu.org/software/emacs/manual/html_mono/eintr.html
- http://www.gnu.org/software/emacs/manual/html_mono/elisp.html
- https://github.com/chrisdone/elisp-guide

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 [[https://github.com/technomancy/calandria][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.  [[http://store.steampowered.com/app/370360/][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:

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

* 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 [[https://github.com/p-e-w/finalterm][finalterm]] (possibly magit-process as well
for its foldable view and color-coded feedback) and [[http://xiki.org/][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

* INPROGRESS 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 [[http://wiki.call-cc.org/eggref/4/z3][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 [[http://crossclj.info/][CrossClj]]
for a demonstration.

- http://ghtorrent.org/
- http://api.mongodb.org/libbson/current/parsing.html
- https://github.com/divad12/vim-awesome/blob/master/tools/scrape/github.py

* 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).

* DONE 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.  [[https://github.com/jaor/geiser/issues/58][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.

- https://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00504.html

* 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 [[https://github.com/jorgenschaefer/circe][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.

- Rewrite the bot in terms of event handlers (with as many per event
  as you like)
- Provide an object containing all context you'd need in the event
  handler, including who to respond to
- Keep the bot alive when an event handler errors out

Manga/Anime lookup: https://github.com/Nihilate/Roboragi
Elisp evaluation: https://elisp-playground.vercel.app/

* INVALID Implement zippers in elisp

- https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/huet-zipper.pdf
- https://clojure.github.io/clojure/clojure.zip-api.html
- https://github.com/danielfm/cl-zipper
- https://bitbucket.org/DerGuteMoritz/zipper/src
- http://paste.call-cc.org/paste?id=c7b2e8dfde5105479490af2d3ca942b8a6ef519f#a1
- http://blog.korny.info/2014/03/08/xml-for-fun-and-profit.html

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.

edit: Done by someone else: https://github.com/volrath/treepy.el

* DONE Add a CSS selector thing to ESXML

- https://github.com/zweifisch/enlive
- https://github.com/AdamNiederer/elquery

- https://github.com/Shinmera/lquery
- https://github.com/Shinmera/CLSS
- https://github.com/Shinmera/plump
- https://github.com/jquery/sizzle/wiki#selectors
- https://github.com/jgehring/hcxselect/
- https://bitbucket.org/grauw/grauw-lib/src/default/src/selector.js?fileviewer=file-view-default

* INVALID 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
[[https://common-lisp.net/project/iterate/doc/Don_0027t-Loop-Iterate.html][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 [[http://wiki.call-cc.org/eggref/4/foof-loop][foof-loop]] or Racket's [[http://docs.racket-lang.org/reference/for.html][for]] as they look
easier to port and extend than [[https://common-lisp.net/project/iterate/doc/Don_0027t-Loop-Iterate.html][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.

The crown-jewel being core.async, that might end up tricky considering
how it's implemented.

* 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).

- https://code.google.com/p/annot/
- https://github.com/emacsmirror/annotate/blob/master/annotate.el
- https://github.com/GoNZooo/annotate
- https://github.com/bastibe/annotate.el

- https://github.com/VincentToups/emacs-utils/blob/master/annotate.el
- http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=contrib/lisp/org-annotate-file.el;hb=HEAD
- https://github.com/tarsius/orglink
- https://github.com/girzel/org-annotate

- https://github.com/rudolfochrist/interleave

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 [[https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00616.html][won't be
addressed]] for now).

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

* DONE Make a Lisp

[[https://github.com/kanaka/mal/blob/master/process/guide.md][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 [[https://github.com/ring-clojure/ring][Ring]], [[https://github.com/weavejester/hiccup][Hiccup]] and [[https://github.com/weavejester/compojure][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.

- https://github.com/nicferrier/elnode
- https://github.com/eschulte/emacs-web-server/
- https://github.com/skeeto/emacs-web-server
- https://github.com/jrhbailey/emacs-http-server
- https://github.com/tali713/esxml
- https://github.com/philjackson/xmlgen

* 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 ={}= / =\{\}=)

#+BEGIN_SRC clojure
#"\d{4}-\d\d-\d\d"
;=> "[[:digit:]]\{4\}-[[:digit:]][[:digit:]]-[[:digit:]][[:digit:]]"
#+END_SRC

*** 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

#+BEGIN_SRC clojure
(def! foo (fn* [bar ? baz & args] ...))
#+END_SRC

** 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
- [[https://github.com/Vannil/cheerilee.el][XCB]]?

* DONE Write an EPUB reader for Emacs

[[https://www.emacswiki.org/emacs/epubmode.el][epubmode.el]] just sucks.  Fuco attempted to do better, but got hung up
on [[https://github.com/Fuco1/justify-kp][typographically correct filling]].  I've created [[https://github.com/wasamasa/teapub][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)

edit: https://github.com/bddean/emacs-ereader is a thing now, haven't
tried it yet though.

edit: I've successfully ported it and extended it way beyond the
original: https://github.com/wasamasa/nov.el

* NeoVim RPC bindings to script it in elisp

Because irony, that's why.  Emacs Lisp is after all, the best language
for hacking editors, right??

* INVALID NES emulator

I can imagine this to be doable if the NES uses tiles instead of
manipulating individual pixels.

https://github.com/AndreaOrru/LaiNES <- small codebase
https://github.com/samanthadoran/potential-disco

<axion> the NES can only blit backgrounds and sprite tiles, with palletes
<axion> see http://wiki.nesdev.com/w/index.php/PPU_rendering

edit: https://github.com/gongo/emacs-nes <- Japanese hacker beat me to
it. It's unusably slow and glitchy on anything interesting though.

* DONE Write a CHIP-8 emulator

That was a fun and educational exercise. It also proved that
generating SVG at 60FPS ain't gonna fly, I instead went for
propertized characters.

then a 8080 emulator (space invaders or pong or cp/m), then a NES
emulator, then maybe a GB emulator.

* enh-c-mode

Use libclang to write a syntax highlighting server (C? C++? Python?
Ruby? CHICKEN?)

http://www.llvm.org/devmtg/2010-11/Gregor-libclang.pdf

Note that ^ only shows off tokenization, so the highlighting would be
only marginally smarter than cc-mode, however getting *that* working
would be a useful PoC to see whether speed is acceptable.

The following lists the existing options for Vim:

https://www.reddit.com/r/vim/comments/7mkd31/clang_based_syntax_highlight_plugin_for_cc/

* Saner syntax highlighting

Pygments is pretty much the epitome of what I'd like to see and uses a
state machine for the task that allows hooking into with regex and
whatnot.  There's at least one more problem with this approach, it's
designed for batch highlighting as opposed to highlighting as you
edit, but that can be solved by keeping the parse state per line,
picking up the last parse state on the line you edit and comparing
whether the outcome is different from the last one.  If it is, you
must rehighlight every line afterwards until encountering a matching
parse state (like, if someone inserted a multi-line comment/string
character and it makes everything until the matching comment/string
character rehighlight).  Another problem is that in Emacs applying
font-lock information is only half the battle, the other half is
applying syntax table information to the string/comment/symbol things
so that Emacs can do correct movement.

Anyway, it seems that other editors did that kind of thing before,
here's a few interesting resources:

- https://github.com/google/xi-editor/blob/master/doc/rope_science/rope_science_11.md
- https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations
- https://microsoft.github.io/monaco-editor/monarch.html
- https://github.com/tree-sitter/tree-sitter (to be used by Atom)

Parsing in general:

- https://blog.adamant-lang.org/2019/dreaming-of-a-parser-generator/

* Obfuscator

Names: krey/kray/keylen/kreyren, driv.el

Strategies as seen in kreyren's code:

- Use pcase/cl-case instead of if/cond and mix them wildly
- Use format strings with useless order specifiers
- Use defvar/defun inside functions
- Mess up indentation
- Mess up closing parentheses spacing and line placement
- Replace/add license comment
- Add useless logging
- Add useless catch-all cond clause logging something useless and
  killing Emacs
- Inline trivial functions so that they're used repeatedly
- Use functions returning their argument instead of their argument
  - =identity=
  - =princ=
  - =eval= on non-quoted values
  - =quote= on simple values
  - =(funcall (lambda () thing))=
  - =(read (prin1-to-string thing))=

Strategies as seen in mplsCorwin's code:

- Macro abuse (combining eval and macros is a pretty bad sign)
- Add unused cl-defun keyword arguments with complicated default
  values

Other obfuscation strategies:

- Strip comments
- Encrypt strings
- Rename identifiers whenever possible
- Obfuscate control flow

* Minifier

Could be a special preset of the above stripping whitespace, stripping
comments, strategically renaming identifiers and doing careful
optimizations.

* Nanopass/codewalker

There's plenty codewalkers for CL, making one for elisp shouldn't be
too hard. Combine that with some compiler framework and you can make
tools processing it. For example the above obfuscator/minifier or
something actually useful.

* Linter

The existing linting solutions are suboptimal. There's elint which
doesn't do much, the byte-code compiler which assumes you're writing a
package and checkdoc which specializes to docstrings. We need more
though:

- A linter enforcing a coding style
  - It needs to be configurable, ideally towards GNU style or
    bbatsov's style guide
  - It needs to be aware of whitespace and comments
  - It needs to allow suppressing warnings on a finely grained basis
- A linter warning you about mistakes preventing inclusion into a
  package archive (MELPA does have a bit of that)
- A linter assisting you with writing Emacs code compatible with the
  Emacs versions you target (by having a database of new functionality
  per Emacs version and flagging things not supported by all targeted
  versions)

Some other work to check out:

- https://github.com/purcell/package-lint
- https://github.com/emacs-elsa/Elsa

* Bottom Scheme

https://github.com/johnwcowan/r7rs-work/blob/master/BottomScheme.md

Might be worth implementing, for example as Scheme->Emacs Lisp
source-to-source compiler.  The trickiest part is numbers probably as
there are no rational/complex numbers.