Decisions on functionality of this package

[afinne]

As I've looked through the source and documentation and discussions that have been made for this package, I have found that there are two different ways of using incremental search that are "competing" both in the source and in the documentation. I have tried to define the differences here:

1. Should the search field be initialized with the previous search, or with an empty search?

• Currently, the previous search is shown, which interferes with the 'slurp' functionality
  2) Should 'Enter' close the search and leave the cursor in the current position, or search for the next instance of the search term?
• Currently, the search is closed
  3) Should Cmd-I browse through search history, or find the next instance of the current search term?
• Currently, it finds the next instance

As I noted these down, I realised that it is the history feature that messes things up. Do we want a search history? Me, personally, use incremental search as a throw-away quick search, so I don't feel the need for a search history.

[gangstead]

@afinne I've made you a collaborator. I trust your good judgement whichever way you want to go with it.

[gangstead]

As to the question of the issue having Enter close the search while you are searching always seemed backwards to me. We already have Escape to close the search and in the core find-and-replace module Enter advances to the next match. I think our package should do the same.

I have no strong feelings for the search history other, but I do have a preference for incremental search acting like core find-and-replace whenever possible.

I also think the slurp command key could use some re-imagining. If Cmd-I opens incremental search and advances to the next match, Cmd+Shift+I searches backwards I think slurp should be another modifier added to Cmd-I, like Ctrl-Cmd-I or Opt-Cmd-I. I'm not sure what the equivalent for windows users is though.

[afinne]

I went back and looked at the initial discussion of incremental search feature that prompted the creation of this package. It can be seen at https://discuss.atom.io/t/incremental-search/1831/13 . It feels like the original intention was to make it behave somewhat like the same feature in Emacs. Looking at the code, it is implemented in that direction too. I think that our best option is to get everything working in accordance to the original intent, and afterwards (with input from users of the package), decide on which direction to take the functionality in the future.

I have a small update in the works that tries to sort out the small issues that remain.

[afinne]

Implementation in #51
Documentation updated in #52

[GreenAsJade]

@afinne ... you're a collaborator: I wonder if you could pull your own PR and also the one that fixes the boxes piling up at the bottom?

[gangstead]

@GreenAsJade sorry about not noticing these. I had watched the repository but had not set it to generate notification emails on new issues/ PRs. I added a question to your issue because I want to test #59 locally to make sure it fixes your issue before I merge it.

[GreenAsJade]

Thanks for the reply! I realised that the change I need (fixing the boxes piling up) is trivial to hack into the code in the installed package, so in the mean time that's what I've done :)