No description
Find a file
Brandon Orther e07972cffb Gracefully handle +ivy-tasks match errors
When trying to use +ivy-tasks in one of my projects it was failing w/ error:
`(Stack overflow in regexp matcher)`. This was due to ripgrep searching a folder
in the project root containing a minified bootstrap CSS source map file (which
had a `TODO:` in it). Since that file was a single line of text concatenated
together, the regex was getting passed ~540KB of text.

To make it easier to recognize what is causing +ivy-tasks to fail I wrapped the
failing code in `condition-case-unless-debug` and report the error and the file
causing the error using `message!`. So now if there is a failure during the
extraction of task from the search cmd's results it moves onto the next and
alerts the user in separate pop-up.

To avoid including the bootstrap file in the ripgrep search result, I added a
`.ignore` file to the project that tells `rg` to ignore it.

NOTE: I was surprised that this problem file was include in the ivy-tasks search
because I expected the search to respect projectile ignore settings. Respecting
projectile's ignored/unignored files and directories wouldn't be too difficult
considering projectile provides a robust collection of functions to help support
this. Also projectile's `projectile-ag` function is a great reference.
2017-08-15 00:37:24 -07:00
bin Rename bin/doctor => bin/doom-doctor 2017-07-09 22:48:54 +02:00
core Refactor core-keybinds 2017-07-27 19:10:01 +02:00
modules Gracefully handle +ivy-tasks match errors 2017-08-15 00:37:24 -07:00
.gitignore Ignore only root init.el 2017-06-13 11:38:02 +03:00
.travis.yml Remove DEBUG=1 from travis build 2017-06-28 18:02:15 +02:00
CHANGELOG.org Update changelog 2017-07-14 15:21:09 +02:00
init.example.el Merge pull request #150 from bandresen/feature_hydra 2017-07-17 12:41:08 +02:00
init.test.el feature/workspaces: add some unit tests 2017-07-08 21:10:39 +02:00
LICENSE Update license 2017-01-06 17:33:43 -05:00
Makefile Refactor makefile 2017-07-09 22:55:06 +02:00
README.md v2.0.4 bump + update README 2017-07-14 15:27:36 +02:00

Release tag Master Build Status Develop Build Status MIT

Main screenshot

This is an Emacs configuration for a stubborn, shell-dwelling and melodramatic vimmer disappointed with the text-editor status quo.

Doom tries to: look and act like modern editors (whatever that means to me on any given day), espouse vim's modal philosophy as best it can and strive to surpass vim in any way possible. It fits my needs as a software developer, indie game developer, scientist and doom enthusiast.

It was written for Emacs 25.1+ on MacOS 10.11+ and Arch Linux 4.7+. I use vim everywhere else.

Installation

git clone https://github.com/hlissner/.emacs.d ~/.emacs.d
cd ~/.emacs.d
cp init.example.el init.el  # maybe edit init.el
make install

# Have problems? Run this to check for common issues with your setup
make doctor

Once you've tweaked the config to your liking, you may optionally byte-compile it. DOOM is designed to benefit from this. It will boost startup times and make Emacs feel a bit snappier in general.

make compile  # may take a while
# or
make core     # faster alternative; only compiles init.el & core files

# If you byte-compile, changes to the config won't take effect until you
# recompile or delete the byte-compiled files with:
make clean

Package Management

Plugins can be managed from the command line with make:

make install     # install missing plugins
make update      # update installed plugins
make autoremove  # remove unused plugins
# be sure to run install and autoremove after modifying init.el

# run this if you change autoload files
make autoloads

# this is the equivalent of running all four of the above commands
make

# you can run any make command with DEBUG=1 for extra logging, and YES=1 to
# auto-accept confirmation prompts:
DEBUG=1 make install
YES=1 make update

These commands are also available from within Emacs:

  • doom/packages-install
  • doom/packages-update
  • doom/packages-autoremove
  • doom/reload-autoloads

Deciphering my emacs.d

So you want to grok this madness. Here are a few suggestions:

Highlights

  • A popup management system using shackle to minimize mental context switching while dealing with temporary or disposable buffers.
  • Per-project code-style settings with editorconfig. Let someone else argue about tabs versus spaces (spaces, of course).
  • Workspaces & session persistence with persp-mode. Provides tab emulation that vaguely resembles vim's tabs.
  • Project & workspace-restricted buffer navigation and functions.
  • A vim-centric environment with evil-mode
  • Fast search utilities:
  • Inline/live code evaluation (using quickrun) and REPLs for a variety of languages, including Ruby, Python, PHP, JS, Elisp, Haskell, Lua and more.
  • Minimalistic diffs in the fringe with git-gutter-fringe.
  • A do-what-I-mean jump-to-definition implementation that tries its darnest to find the definition of what you're looking at. It tries major-mode commands, xref (experimental Emacs library), dumb-jump, ctags (WIP), then ripgrep or the_silver_searcher.
  • Snippets and file-templates with yasnippet & auto-yasnippet.
  • A smarter, perdier, Atom-inspired mode-line that adds:
    • evil-search/iedit/evil-substitute mode-line integration
    • Macro-recording indicator
    • Python/ruby version in mode-line (for rbenv/pyenv)
  • Emacs as an:
    • Email client (using mu4e & offlineimap)
    • Presentation app (using org-tree-slides, ox-reveal, +present/big-mode & impatient-mode)
    • RSS feed reader (using elfeed)
    • Word Processor (using LaTeX, Org and Markdown)

Troubleshooting

My config wasn't intended for public use, but I'm happy to help you use or crib from it.

  • If you have questions, drop me a line at henrik@lissner.net.
  • If you have issues running or setting up DOOM, use make doctor to diagnose any common problems.
  • If you still can't make sense of it, run DEBUG=1 make doctor and include it with your bug report.

And please include steps to reproduce your issue, if possible.

Contributing

I welcome contributions of any kind: documentation, bug fixes/reports, extra modules, even elisp tips. Really, don't hesitate to tell me my Elisp-fu sucks! I'm eager to learn.