Nix for configuration + plugins

[rehno-lindeque]

This is quite possibly a silly idea, but I noticed that nix seems popular with the yi developers. Would there be any sense in using the nix language for configuration and the nix package manager for non-essential plugins?

• nix itself should be a reasonably small install as far as I can tell and many Haskellers already have it
• Haskell is a fine language, but I sometimes feel it doesn't lend itself to configuration very well - nix as a configuration language looks rather familiar to programmers who work with JSON on a regular basis
• plugins for yi are likely to have all sorts of transitive dependencies
  • compiling the entire set of plugins together doesn't seem very scalable, especially for people who expect their environment as a whole to work continuously through upgrades and whatnot (so the suggestion would be to have some kind of separate units for non-essential plugins)
  • also helps to pave the way for contributions from other languages

Just a thought!

[ethercrow]

My feeling is that the most reasonable way to organize yi config with plugins right now is to have a cabal file like in https://github.com/Fuuzetsu/yi-config or https://github.com/ethercrow/yi-config. This way makes it easy to build your personal editor using vanilla cabal-install, nix or stack (well, stack currently doesn't like yi.cabal, but that will get fixed someday).

[Fuuzetsu]

nix itself should be a reasonably small install as far as I can tell and many Haskellers already have it

Installing a package manager so you can configure your text editor seems wrong.

Haskell is a fine language, but I sometimes feel it doesn't lend itself to configuration very well - nix as a configuration language looks rather familiar to programmers who work with JSON on a regular basis

Well, to me at least, most of the point in Yi is precisely that I can use full-blown Haskell to configure it. nix is just awful compared to Haskell

plugins for yi are likely to have all sorts of transitive dependencies

That's OK.

compiling the entire set of plugins together doesn't seem very scalable

Why not? You don't exactly have to recompile each plugin often, what you recompile is your config file. Further, if you're using nix you probably get it from binary cache anyway.

especially for people who expect their environment as a whole to work continuously through upgrades and whatnot

You can already do that with nix though. I mean heck, you could just pin the nixpkgs commit Yi builds with and always have it build with the exact same versions of everything. I also know you can use cabal sandboxes and probably stack. How people set up their env is not much of our concern… We can try to make it easier of course but considering this issue is about nix, it's already easy, see lower down.

(so the suggestion would be to have some kind of separate units for non-essential plugins)

Write packages and put them up on Hackage. See for example yi-fuzzy-open.

I actually don't use that cabal file anymore. With nix and recent enough nixpkgs, you can just use

  yi-custom = pkgs.yi.override {
    extraPackages = p: with p; [ lens yi-fuzzy-open yi-monokai yi-snippet ];
  };

Heck, you could use nix-shell -p 'yi.override { extraPackages = p: with p; [ foo bar baz ]; }' to get Yi with the packages you specify in scope. So you can definitely already deal with dependencies and upgrades and whatnot with nix. I'm completely not interested in writing configs in nix.

[jhance]

Text editors should not depend on package managers and the whole point of yi is that I can use a real programming language for conf rather than vimscript

[rehno-lindeque]

You folk are probably right, just an idle thought I had while beginning to familiarize myself (Really cool project by the way!)

Why not? You don't exactly have to recompile each plugin often, what you recompile is your config file. Further, if you're using nix you probably get it from binary cache anyway.

By scalable, I meant only the dependency issues - but as you said, nix already solves that as well as build times neatly. I suppose that the most convenient thing from a user's perspective is if their platform's conventional package manager is recommended (e.g. apt-get on ubuntu, nix on NixOS, etc). I think it's worth keeping in mind that non-Haskell users are unlikely to fiddle around with build tools, especially if there's a confusing multitude of options. The barrier to entry for an editor needs to be pretty low to appeal to an audience like emacs/vim/sublime/atom has. The switching cost for an editor like yi is already extremely high.

the whole point of yi is that I can use a real programming language for conf rather than vimscript

I'll quickly mention what started me off on this: I wanted to explore the vim keymap for yi (I'm still a somewhat novice vim+emacs (evil-god-state right now) user, coming from sublime).

Probably this should be a different issue now or a thread on the mailing list, but right now it seems a little intimidating trying to figure out the key mappings / customizations for yi (keep in mind, I'm a new user - it's not so much of a problem with vim because the internet is sprinkled with all sorts of little config snippets... if I can't find something on google that I can copy-paste I quickly give up and move on).

I think that it might make sense to at least extract the simpler config options from the parsing and other implementation details for people looking to make a quick customization to their editor. I write Haskell in my day-job, but I still don't really have a lot of time to dig through a large code base to figure out how to make small customizations. (Don't get me wrong, I love that I can write my own parsers and whatnot if need be. Right now I mostly want to swap around a few keys and possibly mix in some emacs commands once I figure out whether or not that could be useful)

E.g. at least having all of these in one place would probably be enough to let me quickly browse through and figure out what I'd like to adapt / override in my dotfiles.

    -- Exclusive motions which treat no count as being the same as a count of 1.
    , ("h", False, moveXorSol)
    , ("l", False, moveXorEol)
    , ("<Left>", False, moveXorSol)
    , ("<Right>", False, moveXorEol)
    , ("w", False, moveForwardB unitViWord)
    , ("W", False, moveForwardB unitViWORD)
    , ("b", False, moveBackwardB unitViWord)
    , ("B", False, moveBackwardB unitViWORD)
    , ("^", False, const firstNonSpaceB)
    , ("g^", False, const firstNonSpaceB) -- TODO: respect wrapping
    , ("g0", False, const moveToSol) -- TODO: respect wrapping
    , ("<Home>", False, const moveToSol)
    -- "0" sort of belongs here, but is currently handled as a special case in some modes
    , ("|", False, \n -> moveToSol >> moveXorEol (n - 1))
    , ("(", True, moveBackwardB unitSentence)
    , (")", True, moveForwardB unitSentence)
    , ("{", True, moveBackwardB unitEmacsParagraph)
    , ("}", True, moveForwardB unitEmacsParagraph)

    -- Inclusive motions which treat no count as being the same as a count of 1.
    -- Word motions
      ("e", repeat $ genMoveB unitViWord (Forward, InsideBound) Forward)
    , ("E", repeat $ genMoveB unitViWORD (Forward, InsideBound) Forward)
    , ("ge", repeat $ genMoveB unitViWord (Forward, InsideBound) Backward)
    , ("gE", repeat $ genMoveB unitViWORD (Forward, InsideBound) Backward)

    -- etc...

[jhance]

I definitely agree that the documentation for these is subpar, but I don't think thats magically fixed by switching to a different configuration language but rather by writing better documentation.

[Fuuzetsu]

The switching cost for an editor like yi is already extremely high.

I'm pretty sure we're not aiming at anyone but Haskell hackers right now anyway. We can worry about wider adoption When It's Ready™.

[docs are subpar]

I agree, patches/doc requests welcome.

[rehno-lindeque]

I'm closing this if no one objects