Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve findfilemode to be more flexible #6

Open
mogenslund opened this issue Jan 19, 2017 · 9 comments
Open

Improve findfilemode to be more flexible #6

mogenslund opened this issue Jan 19, 2017 · 9 comments

Comments

@mogenslund
Copy link
Owner

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:

  1. To open a file in the editor
  2. To insert the path as text
  3. 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:

  1. Choosing a new file
  2. Choosing existing file
  3. Choosing existing folder
  4. Navigate to folder

On enter press

  1. If a file is choosen in the typehead, the path to that should be the result.
  2. If a folder is choosen in the typeahead the path to that should be the result.
  3. 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

@ertugrulcetin
Copy link

@mogenslund are you using your editor for daily work?

@mogenslund
Copy link
Owner Author

@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.)

@ertugrulcetin
Copy link

Cool! I was checking your code out, what does slider.clj do? it does not manipulate source code in the editor right?

@mogenslund
Copy link
Owner Author

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.

@ertugrulcetin
Copy link

Isn't moving back and forth creates lots of objects(lists), is that efficient?

@mogenslund
Copy link
Owner Author

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.

@ertugrulcetin
Copy link

Thanks for the info! It's really cool project. Can I ask some stuff about this project time to time? :)

@mogenslund
Copy link
Owner Author

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.

@ertugrulcetin
Copy link

Thanks good to know I can use Slack. Good night!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants