| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If the X selection is updated in post-command hook and the command has
been a deletion, then the text to be put in the X selection is not
correct. In particular, if this text is empty then the X selection
would be updated with an empty string which may cause strange side
effects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These functions are not only called from `evil-with-single-undo`, but
also when insert state starts and ends.
|
|
A call to `evil-with-single-undo` within the body of another call may
end the outer instance. We guard this with the new variable, so an
inner call does nothing.
|
|
According to Vim's doc, the 'r' command should always insert exactly
one newline character, no matter how many characters have been
replaced.
|
|
Fixes issue #250.
|
|
We also update the version information in `evil-version`.
Why no sed anymore? Emacs is easier to work with in Makefiles.
And Emacs should be available anyway, shouldn't it?
This addresses issue #250.
|
|
This addresses #249.
|
|
`evil-jump-item` is syntax sensitive: if (point) is not in a
string/comment only the string/comment content is considered, if
(point) is not in a string or comment, strings and comments are
skipped.
In one situation this may not be desired: if (point) is within a
string but no jump-target is found within the string. Then the old behavior would not move (point) at all. This is a common case in programming modes, e.g.
printf("some text");
If point is within the string literal, then `evil-jump-point` should
move to the opening parenthesis.
The new behavior of `evil-jump-item` is now to look after the end of
the string as if it has been called right after the end of string, if
no appropriate jump target could be found within the string.
This addresses issue #249.
|
|
The functions `evil-in-string-p`, `evil-string-beginning` and
`evil-string-end` now use the parsing capabilities of Emacs directly
instead of using the simple loop-and-check approach of
`evil-find-beginning` and `evil-find-end`.
The function `evil-paren-range` is improved as well, using the parser
directly instead of looping over `evil-string-p`, which led to an
O(n^2) algorithm.
|
|
This argument type, used for :set-initial-state, still used a very old
code that is wrong with the current completion system. This change
fixes the definition of the completer, adds a new interactive type
<state> and changes the interactive code of
`evil-ex-set-initial-state` accordingly.
|
|
Formerly, only "\t" has been bound in `evil-ex-completion-map`. This
change ensures that tab calls the correct command even if [tab] is
bound in the parent keymap, `minibuffer-local-completion-map`.
|
|
|
|
|
|
|
|
This header caused the marmalade-repo.org to crash when trying to
upload the package. The ELPA package file should therefore contain
nothing but the call to `define-package`.
|
|
|
|
`looking-back` can be a *very* expensive operation in general: it
checks *each* buffer position before point for whether the regexp
starting at this position matches. If the regexp does not match, then
eventually *each* position up to the beginning of the buffer is
checked, which may lead to bad performance in large buffers. But
usually the minimal starting position when calling `looking-back` can
be bounded, e.g. by (line-beginning-position) if the match can only be
in the current line.
Because of this potential performance problems, we add an explicit
reasonably good limit to each call to `looking-back` that does not
change the result.
|
|
The insertion point in block visual state insertion is the first resp.
last column in the first line. The cursor *must* be moved to this
column, even if that column does not exist, yet, because it's within a
TAB or after the eol.
This fixes #245.
|
|
|
|
is not enabled.
|
|
|
|
If the current buffer (to be saved) is an indirect buffer, use the
base buffer's associated file name.
This fixes #244.
|
|
|
|
|
|
|
|
|
|
This is an enhanced version of merge request #38. In addition to
certain code cleanups, `evil-jump-item` works with arbitrary block
comment pairs (not only /* ... */) and it recognises #elif
preprocessor statements.
|
|
This change uses Emacs syntax capabilities to detect beginning and
ends of block comments. So this movement is no longer restricted to
/* */ pairs in C-like languages but works with any proper paired
comment delimiters.
|
|
Need new `evil-comment-in-p` function.
|
|
The functions `evil-in-comment-p`, `evil-comment-beginning` and
`evil-comment-end` use now Emacs syntax information available by
(syntax-ppss) and (syntax-char) to determine the beginning and end of
a comment.
|
|
According to Vim, `evil-jump-item` should handle an #elif statement
like an #else statement, i.e. should stop there. Unfortunately, #elif
statements are ignored by hideif functions. This changeset modifies
hideif's regular expressions locally so that #elif statements are
matched like #else statements.
|
|
The hideif package provides a full interface for all necessary steps
to detect and move between pre-processor conditionals. Thus, we rely
on hideif's interface instead of own regular expressions.
|
|
If an explicit count is specified for `evil-jump-item`, point should
go to count % of the buffer. This is independent of the current major
mode, so this test must come first.
|
|
for c-mode.
|
|
same level of conditionals in c-mode.
|
|
|
|
Both stopped to work since evil-pkg.el contains a comment at the
beginning of the file.
|
|
Some Emacs modes may offer an incomplete indentation implementation.
If `indent-according-to-mode' signals an error, it prevents
`evil-open-above' and `evil-open-below' from entering Insert state.
Reorder the code so that Insert state is entered first.
|
|
If (point) is placed on a TAB during a block selection, the selection
should include all columns covered by the TAB.
The new implementation takes care of this as well as a correct
extension to eol. The visual selection should now conform the region
affected by `evil-apply-on-block`.
|
|
`evil-apply-on-block` did not handle the case of a visual extension to the eol correctly.
This change unifies `evil-apply-on-block` and
`evil-apply-on-rectangle` into a single function. The only difference
between two is that the former should pass buffer positions the latter
column numbers to the function to be applied on the block. This can
now be chosen by a parameter of `evil-apply-on-block`.
`evil-apply-on-rectangle` is now a simple convenience wrapper always
passing the columns.
|
|
The old behavior, using `evil-apply-on-block`, considered a TAB as a
single character, thus replacing the TAB with exactly one character.
This leads to an unexpected visual impression, because one TAB usually
represents several spaces.
The new implementation uses `evil-apply-on-rectangle` and deals
explicitly with the columns covered by the block in each line. TABS
are converted to spaces if required.
|
|
`evil-insert-line`, usually bound to "I", should always move point to
the first non-blank character of the line (according to vim). This
should be independent from `evil-auto-indent`. That option should only
influence the (automatic) indentation of `evil-open-above` and
`evil-open-below`.
This change makes `evil-insert-line` call `back-to-indentation`
unconditionally.
This fixes #171.
|
|
The mouse handling code deactivates the visual selection when the
button is released and point has not been moved. While this is desired
for character selection, it is not expected for word, line or block
selections. This causes, e.g., the selected line to disappear if the
button is released after triple clicking without moving point.
The reason is that the visual selection does not correspond to (point)
and (mark) in these cases. In fact, a visual line selection (and word
or block selection) should *always* be considered as if point or mark
has been changed.
This change augments the point/mark test by adding a test whether the
current visual selection type is line or block or if `click-count`
equals 1 (which corresponds to word selection).
This fixes #238.
|
