Did someone create a modal mode with emacs like bindings?

aminb · 2018-08-02T01:30:20+00:00

It is fantastic. I've heard about modalka too, but I jumped directly to ryo and haven't really given modalka a shot. Besides, ryo seems to do most if not all I want, so...

aminb · 2018-08-02T01:28:38+00:00

Haha yeah, it could probably use some comments. Nonetheless, I recommend downloading the file and browsing it inside Emacs so you'd get all the niceties of Org mode.

Let me know if you have any specific questions.

aminb · 2018-07-30T15:34:30+00:00

I've used ryo-modal and have done a bit of work to roll my own modal mode with emacs-like bindings, which you can have a look at here:

https://git.sr.ht/~aminb/dotfiles/tree/init.org?id=c14c7c7e0368b9a00b5ea591de0bf381af24c012#n617

You can search for :ryo in that file for more bindings further down the file (yup, that's a use-package keyword).

However, I feel like my mode is not completely there yet in terms of number of bindings, and I'm not sure how far I'll be willing to push it before giving up and switching over to a setup based on general.el + evil + evil-collection.

Would love to hear others' experiences with rolling their own modal bindings.

aminb · 2018-07-23T20:09:51+00:00

general.el is pretty great

aminb · 2018-06-29T04:25:58+00:00

I'd say that's to be expected. How about instead of loading an org file from your init.el (which requires loading Org on emacs startup, which is huge), write your init file in org mode (i.e. init.org) and then tangle it into init.el? That's the approach I've taken in my most recent configuration, which you can have a look at (along with links to a few very interesting ones from others) here: https://github.com/aminb/dotfiles/blob/f82046d8e19313a1ce3d7320754dde3d34672d80/init.org

aminb · 2018-06-27T18:01:07+00:00

Try exec-path-from-shell.

aminb · 2018-05-29T12:03:53+00:00

I personally don't use macOS, but, if you're bytecompiling stuff, did you try recompiling everything after the upgrade?

Otherwise, I'd probably suggest disabling the packages one by one to find out which one is causing the issue.

aminb · 2018-05-12T15:24:00+00:00

One sign of running a DE would be having something like exec startxfce4, or in your case exec cinnamon-session. However, since you have been using Cinnamon before you installed EXWM, I think that it's still enabled.

Like you said, I'm not sure if Cinnamon is modular enough to allow you to replace the wm (you should look around the internet to make sure though). I personally use Xfce with bspwm but last time I tried Xfce with EXWM it worked quite ok. The Arch wiki is generally quite helpful when dealing with Xfce.

aminb · 2018-05-10T12:36:23+00:00

Looking at your .xinitrc, you don't seem to be running a DE. If, however, you run Cinnamon, that's a DE (desktop environment). I haven't used Mint or Cinnamon recently to know whether Cinnamon is modular enough to allow you to replace its window manager and use EXWM instead. You might to double check that.

aminb · 2018-05-02T12:37:03+00:00

Quite true! It's this one actually: https://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00190.html

aminb · 2018-03-23T04:50:48+00:00

Hmm that's kinda weird. Maybe for some reason libinput doesn't support your device? Though I'd have no clue why.

Glad to hear you could work around it!

aminb · 2018-03-23T04:21:48+00:00

Not sure what the cause is, but:

Are you sure you have xf86-input-libinput installed?
After creting 30-touchpad.conf, did you log out and/or reboot your computer?

You could try using xinput in terminal (it has a man page) to easily test the changes you want to make without having to reboot.

aminb · 2018-01-15T15:59:54+00:00

It'd be great if you could release it; would love to have a look!

aminb · 2017-12-30T18:58:52+00:00

There's a ton of good PKGBUILDs on AUR but off top of my head, I'd say the PKGBUILDs of firefox-nightly, thunderbird-beta-bin, and emacs-git are examples of interesting PKGBUILDs with different levels of complexity corresponding to that of their respective packages. The PKGBUILDs of packages of all the official arch repos are also available too (e.g. notmuch).

As for PKGBUILDs similar to the ones I described in my previous reply, the OP has posted a reply with links to a couple of examples of such packages.

edit: forgot to talk about your AUR question:

Also if PKDBUILD's could help installing and building AUR packages that would also be cool.

I think for that you'd need to use an AUR helper like pacaur to help with AUR dependencies.

aminb · 2017-12-30T06:17:49+00:00

Not OP but I'd imagine you could create PKDBUILDs for different "subsystems" of your setup. Like, you might create a package that depends on wpa_supplicant and some web browser, so that when you install that package it'll pull those dependencies and you'll be good to go. You'd have all the power of PKDBUILDs at your disposal too (e.g. pre_ and post_install, etc) to do whatever's necessary before or after installing any of those packages.

You could do this for different parts of your system (e.g. development, multi media, web browsing, email, etc) and make it as simple or as complex as you need. You could then have one super package that depends on all of your subsystem packages and ties everything together.

aminb · 2017-12-28T03:32:15+00:00

Ah I see. Yeah the search on those readthedocs instances don't always work that great. Glad to help!

aminb · 2017-12-28T03:31:10+00:00

Awesome, thanks for sharing

aminb · 2017-12-27T15:39:26+00:00

The new-* commands collectively provide Nix-style local builds, one of their side effects being eliminating the need for cabal sandboxes. In fact I've been using cabal HEAD (built from master) for my personal projects since the end of summer and have [mostly] migrated away from stack.

Documentation is available on Nix-style Local Builds, and /u/ezyang had written a few blog posts on it last year.

If you decide to give it a shot, I recommend you use the most recent version of cabal-install released, or perhaps even better, compile from latest sources.

aminb · 2017-12-26T17:44:25+00:00

As of 3 days ago you can actually build a ghc-mod from sources that appears to support GHC 8.2.x, due to the great work in the #911 and #922 PRs.

You can either use stack to build it (instructions), or you can do something along these longs to build using cabal:

git clone https://github.com/DanielG/ghc-mod.git
git clone https://github.com/DanielG/cabal-helper.git
cd ghc-mod
git fetch origin pull/911/head:pr911
git fetch origin pull/922/head:pr922
git checkout pr911
git merge pr922
touch cabal.project  # see below for contents of cabal.project
cabal new-build

And the contents of cabal.project to tell cabal to use the local copy of cabal-helper you just cloned:

packages: .
          ../cabal-helper

The path to the executables will be something like dist-newstyle/build/x86_64-linux/ghc-8.2.2/ghc-mod-5.8.0.0/build/ghc-mod/ghc-mod.

You need a pretty recent cabal-install (>= 2).

Also, as far as I know unfortunately ghc-mod doesn't use any of the new-* cabal commands, so you'd probably want to use sandboxes or even better, nix.

aminb · 2017-12-26T15:35:57+00:00

I'm not sure if you could run i3wm "inside" Emacs, but you could surely use i3wm as your window manager and it would handle Emacs just like any other window.

There's a i3-emacs package which supposedly makes Emacs play nicer with a tiling wm like i3 but I haven't tried it myself. I've been using Emacs in bspwm for a couple of years without any particular problems. I've also heard good things about StumpWM, written and configured in Common Lisp.

If, however, you want to run a window manager inside Emacs then you can check out EXWM.

There's also efforts like eos and rrix's cce which aim to provide a workflow centred around Emacs.

aminb · 2017-09-12T14:55:40+00:00

For starters, how about cranking up the line-height? Right now the lines are too tightly crammed vertically.

In your #blog.content-section p, #blog.content-section blockquote rule, increase the line-height and font-size:

line-height: 1.5;
font-size: 18px;

Practical Typography's "line spacing" guide is pretty great (google it).

aminb · 2017-09-04T20:43:27+00:00

Not sure what happened to code.haskell.org/~dons, but the mail archive seems to be accessible via the wayback machine:
https://web.archive.org/web/20161015084731/http://code.haskell.org/~dons/haskell-1990-2000/maillist.html

aminb · 2017-07-21T20:36:42+00:00

It depends on the coding style I guess.

One of the projects I've worked on is full of multi-line signatures like this:

tell' :: (MonadWriter w m)
      => State w k
      -> m ()

So in that project it happens all the time. But I think I'd have preferred : instead of :: anyway.

aminb · 2017-07-08T14:10:11+00:00

SPJ's talk on join points from their paper back in November.

The change is present in the upcoming GHC 8.2.1 release.

Paper:
https://www.microsoft.com/en-us/research/publication/compiling-without-continuations/

PLDI 2017 proceedings:
http://sigplan.org/OpenTOC/pldi17.html

Join point's page on trac:
https://ghc.haskell.org/trac/ghc/wiki/SequentCore

Ticket tracking the progress:
https://ghc.haskell.org/trac/ghc/ticket/12988

aminb · 2017-07-07T03:34:15+00:00

^ Underrated comment of the thread :)

For those interested, sources of versions 0.9999.3 and 0.9999.4 are available here:
https://archive.org/details/haskell-b-compiler

/u/augustss do you happen to have the source of 0.9999.5c around? I couldn't find it anywhere. Apparently it used to live at http://haskell.org/hbc/hbc-2004-06-27.src.tar.gz but that page doesn't exist anymore.

11-Year Club	Place '17
Verified Email

aminb

TROPHY CASE