Improve findfilemode to be more flexible
mogenslund opened this issue · 9 comments
The dk.salza.liq.modes.findfilemode should be more flexible in the following senses:
Callback
The mode should be able to take a callback function, which will operate on the found file or folder, so it can be used in a variety of situations, including:
- To open a file in the editor
- To insert the path as text
- To evaluate the file
Selection
If there are any choices in the typeahead the first one should be selected as default (At the moment of writing this, none is selected until "next-res" command executed C-k.)
Choosing file
The rules below for choosing a file should be implemented.
There are 4 cases:
- Choosing a new file
- Choosing existing file
- Choosing existing folder
- Navigate to folder
On enter press
- If a file is choosen in the typehead, the path to that should be the result.
- If a folder is choosen in the typeahead the path to that should be the result.
- If there are no typeahead results asume the search is a new file. Use that as result.
On M-enter (3611)
The typed search content is the result (To create a new file although there is non empty typeahead results.)
On C-k
If a folder is choosen, use C-k to navigate to that folder
@mogenslund are you using your editor for daily work?
@ertugrulcetin Yes. I have used it for almost anything the last year. Both at work and at home. Since I know every inch of the code, it is very easy for me to adapt it to my needs. (My challenge is without doubt, to make it easy for everyone else.)
Cool! I was checking your code out, what does slider.clj
do? it does not manipulate source code in the editor right?
The slider contains the text in a buffer. It has a list of the characters before the cursor (in reverse order) and a list of the characters after the cursor. So moving the cursor is the same as taking a character from one list and push it to the other. That makes local cursor movements O(1).
There is also a mechanism for setting marks, to make jumps easier and to handle selections and highlights.
All edits in a text is a pure function applied to one slider to produce a new slider. Unittests are so comfortable in that setup.
Isn't moving back and forth creates lots of objects(lists), is that efficient?
It is very efficient, thanks to how Clojure does lists. A new list is created each time you move the cursor. But behind the scenes Clojure reuses almost everything from the previous list. (I was very excited the first time I made the program run, because I could not believe, it did not explode.)
I have Liquid running for days without any problems and I still do have infinite undo.
Thanks for the info! It's really cool project. Can I ask some stuff about this project time to time? :)
Of course you can. You can also contact me through Slack, if that is easier. I am mogenslund on clojurians. I am off to bed in a moment, so I will soon be unavailable until tomorrow.
Btw: I have a performance test (to prevent me from doing damage without knowing). It executes 200,000 random editor operations in half a second on the slider.
Thanks good to know I can use Slack. Good night!