| Age | Commit message (Collapse) | Author |
|---|
|
text_paragraph_prev():
Bring back the previous usage of text_iterator_byte_get() in the
while conditional and text_iterator_char_prev() in the loop body.
Fixes #1028 - { moves back a paragraph too much if cursor at start of line
|
|
Fix #873
|
|
|
|
|
|
This fixes empty backward searches ?$ starting at the line end.
|
|
Previously, searches wrapping around did not report any results if they
started from within the eventual match. Fix this by enlarging the search
area to the whole text after reaching the first boundary.
See also #787.
|
|
The regex anchors ^ and $ must not match at the start/end of the search
range unless it is preceded/succeeded by a new line.
This is implemented at the text-motion layer by passing the appropriate
REG_NOT{B,E}OL flags to the search backend, meaning the caller can
influence the anchor behavior depending on the context. This is important
as for example in the command language the anchors apply to existing
selections, not line boundaries.
|
|
1) “$” matches in the middle of the text.
visvis
^ - standing here
\/ - at first we search forward-\
\_/ - wrap, if nothing found <---/
After wrapping, in the second range “$” will treat end of the range
as EOL so “/vis$” will wisely match and moves cursor to the first
column.
2) No match after wrapping.
vissssss
^^ - standing here or here
\\____/ - search this before wrapping ---\
V - search range after wrapping <--/
“/vis” will *not* match (after wrapping), because it crosses ranges.
---
So the real solution would be that instead of the end position, the
start position of the possible match should be limited because a match
can cross the search ranges. To keep things simple, simply search two
whole text after wrapping.
visvis
\____/
|
|
The special characters array doesn't contain the tab character thus causing issue 711.
By adding the tab character to the array, quotes are matched correctly across tab characters, too.
Although much less used, other white space characters such as \v, \f, and \r should perhaps be added as well.
|
|
|
|
|
|
The standard says "if an encoding error occurs ... the conversion state
is unspecified".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some people might prefer this for <Backspace> behavior. Except for that
and debugging purposes using `ga` and `g8` it is not yet that useful.
|
|
This also eliminates dead code as reported by CID 142387.
|
|
|
|
|
|
|
|
These do not really belong into the editor core. If desired they
could be implemented in Lua instead.
|
|
|
|
|
|
Prefer quotation marks on the same line to when looking for matching pairs.
Improves #358.
|
|
|
|
|
|
|
|
|
|
Should be "is_word_boundary"
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
|
|
This partially reversts the "Fix to/till movements" commit
0d4093c3371079c5f75055338f0341f684542465
The pos += len hunk was interfering with other code which does
not want this behavior. The original issue should be fixed directly
within the to/till movements.
|
|
|
|
|
|
This is inherently a tricky thing to do because we cannot rely on
the current display state. The reason being that the position/cursor
which is modified might not currently be in the visible area.
Tabs are a particular problem because they have a variable display
width. However this new code is certainly not worse than the current
behaviour which relies on text_line_char_{get,set} and thus simply
counts graphemes.
Not yet completely convinced that this is the right approach.
|
|
|
|
|
|
|
|
- split the functions, so the algorithms are more clear
- paragraph movements work backwards
- paragraph movements work consistently with \r\n line breaks always placing the
cursor on the first character of the first empty line before/after the
paragraph
- sentence movements now work better at BOF/EOF
- save a few lines of code
|
|
|
|
Some corner cases allowed to move between lines with the to/till movements.
The change in find_prev serves two purposes. When searching for a string which
the cursor is already above the match, this match is returned (pos += len).
Secondly there was a failure when searching for strings with len == 1 which lead
to `matched == 0` which was always true, even if the string was not found,
therefore leading to a wrong return value.
|
|
|
|
The signedness of char is implemenation defined, calling the is*
type of functions with negative values leads to undefined behaviour.
|
|
|
|
Currently symbols inside a string are ignored. This means that if
the opening (closing) symbol is inside (outside) the string while
the closing (opening) one is outside (inside), it will not be
matched.
It is not yet clear whether this "optimization" is useful.
Closes #97
|
|
|
|
Brackets which occur inside strings are ignored.
|
|
They behave not like in vim, but instead try to find the
start/end of C-like function definitions.
The first character stands for the direction [ for backwards,
] for forwards. The second character denotes the start [ or
end ] respectively.
|
|
It is after all a stupid O(n*m) algorithm, hence restart after
a failed partial match.
Code like this would benefit from a proper test suite ...
|
