* Improve buffer view relocation after jumping to a far-away location
When the cursor is moved to a location which is far away from the
current location (e.g. after a search or a goto line), the buffer view
is always relocated in such a way that the cursor is at the bottom or
at the top (minus scrollmargin), i.e. as if we just scrolled to this
location. It's not like in other editors, and IMHO it's annoying. When
we jump to a new location far away, we usually want to see more of its
context, so the cursor should be placed closer to the center of the
view, not near its edges.
This change implements the behavior similar to other editors:
- If the distance between the new and the old location is less than one
frame (i.e. the view either doesn't change or just slightly "shifts")
then the current behavior remains unchanged.
- Otherwise the current line is placed at 25% of the window height.
* Postpone calling onBufPaneOpen until the initial resize
It is currently not possible to find out the geometry of a newly created
bufpane in onBufPaneOpen lua callback: bp:GetView() returns {0,0,0,0}
instead of the actual window. The reason is that the bufpane view is not
properly initialized yet when the bufpane is created and the callback is
triggered. It is initialized a bit later, at the initial resize.
So postpone calling onBufPaneOpen until after the initial resize.
* Improve buffer view relocation when opening a file at a far-away location
When a file is opened with the initial cursor location at a given line
which is far away from the beginning of the file, the buffer view is
relocated so that the cursor is at the bottom (minus scrollmargin)
as if we just scrolled to this line, which is annoying since we'd rather
like to see more of the context of this initial location.
So implement the behavior similar to the earlier commit (which addresses
a similar issue about jumping far away after a search or goto):
- If the initial cursor location is less than one frame away from the
beginning of the buffer, keep the existing behavior i.e. just display
the beginning of the buffer.
- Otherwise place the cursor location at 25% of the window height.
* Support for highlighting all search matches (hlsearch)
hlsearch is implemented efficiently using the buffer's line array,
somewhat similarly to the syntax highlighting.
Unlike the syntax highlighter which highlights the entire file,
hlsearch searches for matches for the displayed lines only.
Matches are searched when the given line is displayed first time
or after it was modified. Otherwise the previously found matches
are used.
* Add UnhighlightSearch action
and add it to the list of actions triggered by Esc key by default.
* Add comment explaining the purpose of search map
* Add hlsearch colors to colorschemes
Mostly just copied from the corresponding original (mostly vim) colorschemes.
* Highlight matches during/after replace as well
As a side effect it also changes the last search value, i.e. affects FindNext
and FindPrevious, but it's probably fine. In vim it works the same way.
* Improve hlsearch option description
* Adds command "tabmove ±n", for better tab management
* Added tabmove to help:commands
* Replace uses of util.Min, util.Max with util.Clamp
Browsing code and discovered `util.Clamp`, ideal for this section of my code
* oops, missed an arg
* Typo, again
See https://golang.org/pkg/regexp/syntax/ for the
supported syntax. Here are some examples:
```
replace "(foo)" "$1-bar"
replace "(foo)" "${1}-bar"
replace "(?P<group>foo)" "$group-bar"
replace "(?P<group>foo)" "$group-bar"
replace "(?P<key>\w+):\s+(?P<value>\w+)$" "$key=$value"
```
Closes#1115
The autosave option is now specified as an integer, which denotes
the number of seconds to wait between saving the file. If the option
is 0, then autosaving is disabled. If the option is given by the user
as a boolean, it will be converted to 8 if true, and 0 if false.
Fixes#1479
With the new backup option, the autosave option is no longer useful.
Since it never really worked well in the first place, it has been
removed.
Closes#1420
