Could you show an example of how to load the vimkeys file in .liq
Joe-Withey opened this issue · 9 comments
Hi Joe
Many things have changed since I discluded vimkeys as a core option. I have changed the program to be more "app" centric than "keybinding" centric. I have tried to rewrite vimkeys.clj to vimapp.clj to accommodate those changes. I have attached the vimapp.clj (rename vimapp.clj.txt to vimapp.clj) file.
If everything was perfect, it should have been possible to overwrite the default app with vimapp using (editor/set-default-app vimapp/run).
Unfortunately this will not have effect, since most global keybindings have already been loaded with the old default app as target. (I will consider that a bug. (editor/set-default-app ...) should have global effect.)
A workaround will be to reassign the global keybindings to load files using vimapp, like this:
(editor/set-global-key :C-f #(findfileapp/run vimapp/run))
If you use this in the .liq file, all files will be opened with the vim key bindings. (Not "scratch", since it is loaded before .liq).
So add vimapp.clj to the classpath and write the following in .liq:
(ns user
(:require [dk.salza.liq.apps.findfileapp :as findfileapp]
[dk.salza.liq.editor :as editor]
[vimapp :as vimapp]))
(editor/set-global-key :C-f #(findfileapp/run vimapp/run))
I will add fixing "set-default-app" to my todo list.
Notice that vimapp.clj is not just a sample file with some vim keybindings.
Best regards,
Mogens
(editor/set-default-app ...) problem have been fixed now.
Thanks for the help. We can probably close this now.
I really like this project. I'm a vim user and I'm learning clojure, for me being able to work in an environment where I can use vim bindings with the ability to write plugins for an editor in clojure is really appealing. I dislike the vim extension layer API.
Do you have anything like a roadmap for this project? It's really well written and I'd love to be able to work with it to create what I'm looking for as a perfect editing experience but my clojure / tty knowledge is not there yet for me to get going yet. That being said I'm really interested in what your aims, goals and rationales are on the future of the project.
Hi Joe
I happy that you like the project :-) I do not have a written roadmap for the project, but I do have some thought on, what I am aiming for. Originally I made it for my self, because I wanted that editor. I made it open source, because I do benefit a lot from open source and I want to contribute back. It the same time, if I make the editor easily extensible, I might actually, at some time, get features in return, that other people provide.
To answer where I am going, I will first answer, where I am. For that part that I am using, the core functionality is actually done. I use it many hours a day, at work and at home. If I need something, I extend it. If the extensions needs something in core, I create what is needed in the core.
What I am struggling with, is making a clean cut between the core functionality and the extensions. It is easy for me to extend, because I know the code, but it is not easy for others. I think a lot about, how to solve this. When the core gets more clean and with well defined boundries, it should be easy to just branch it and build a vim-like editor on top, or an Emacs like editor on top. I want functionality to be "on top" and not "merged in". This should allow improvements to core functionality and extensions to be shareable with projects that already build on top of Liquid. Imagine someone creates project called liquid-vim that depends on Liquid. Then someone else creates an extensions, like a build-in browser. In that case I want it to be easy, for the sister project liquid-vim, to also benefit from the build-in browser extension. (I actually sometimes consider doing this liquid-vim, just to make it easier for others to get used to Liquid. I do also think a lot about, how to make it easier for others to start using Liquid.)
For some of my own use cases, I already created a flag called "--minimal", allowing me to start Liquid without any default settings, making it possible to initiate the editor in a whole other way - maybe for a whole other purpose than text editing.
The thing I am currently working on is cleaning up and trying to define what is "core". I will also consider doing a liquid-vim project, because that might help revealing what belongs to core and what not and make transition easier for new people that are used to vim. The vimapp.clj I send to you, is probably not the best way if we want to approximate vim deeper than just keymapping. It will be better to start Liquid in more barebone state and initiate the defaults with vim in mind.
I hope this makes sense. Part of what I have written is just me thinking out loud :-)
Best regards,
Mogens
Perhaps the core is the minimum code needed to start the code, but with no or nearly no keybindings. You would have entry points (an API) to functions that do the minimum needed for the editor, but the actual keybindings would be extensions. Your preferred keybindings would be the default keybinding extension.
Yes, there should be a base core with no key-bindings and no window division and on top of that, some default settings. And it should be possible to very easily detach the defaults and make your own. It is a bit difficult at the moment, because the defaults are loaded before the .liq file. This means you have to "undo" some old defaults first. It is easier to do in a new project, where Liquid is importet using a modified core.clj.
What I have to do is separate out the default settings from core.clj and load those after loading .liq. This should allow one to set a flag in .liq preventing the load of defaults.
I also need to have a more veldefined notions of "app", "keybindings", "syntex highlight", etc. I do have those concepts now, but they are just maps and functions without rules and restrictions. I will learn spec and see, if that is the right tool to make clearifications. "No rules" is good, because you can do what you want. At the same time it is bad, because you do not know, what will work correctly and what might be broken later.
Again I am thinking while writing. Thank you for your inputs. I think I have some clear tasks for my next iteration.
Btw, I just started a liquid-vim project, to see how far I can get in vim direction. I will publish that to github later.
My clojure and java knowledge is very limited but would it be possible for a user to create a project directory under a .liq/ directory - an install task could scaffold this for the user - where we could require the liquid namespaces and write and load plugins? This is by no means a recommendation but it is something I've thought about, it'd make for a very neat and tidy means of extension, the editor would then be used as a sort of core library.
Hi Joe
It is a good suggestion. I have done something like that in my own local setup, to try out an approach similar to what you suggest. I start Liquid with the following command:
java -cp \
$HOME/.liq.d/*:\
$HOME/.liq.d:\
$HOME/proj/liquid/src:\
$HOME/proj/liquid/resources:\
$HOME/proj/additives/src:\
$HOME/m/lib2 \
clojure.main -m dk.salza.liq.core --load=$HOME/m/settings/.liq "$@"
This way, all jar files in ".liq.d" will be loaded and be accesible from within liquid. (I really like that I can load any java library, nomatter if they are made as extensions or not.) Also I have some scripts lying around in different folder, which I also have added.
Where I want to go is for people to be able to extend Liquid by just doing a "git clone " in the ".liq.d" folder. This can be done by creating a bash command to just add every subfolder to the classpath. (Somehow java does not support * for folders, only jar files.)
I have not looked at clojure 1.9 yet, but I will do soon, and I have a feeling that some of the new stuff regarding the "clj" command might actually support some easy way to do this :-)
Btw, if you copy core.clj and adjust it to your needs, you can just replace "dk.salza.liq.core" with the new classpath to load Liquid in a very customized way. (It is a hack, but it will add even more control than the .liq file.) But I intend to clean up core.clj to give the .liq file a bit more power when Liquid starts up, so people do not need to hack stuff to make it work as they want. I just want "git clone my-nice-extension" and then some entry in the .liq file to load the needed parts of the extensions.
Take a look at this one: https://github.com/mogenslund/liquid-vim