Hi,
Thanks for the work on the evil-mode feature, much appreciated. Me and
Fredrik are currently moving over to it from our own feature, which was
a bit of a mess. A few points after trying out the new feature:
1:
The packages emacs-evil-commentary and emacs-evil-surround might be
useful --- at least I miss them. They do however add functionality that
is not present in vanilla vi/vim. What would be the scope of
feature-emacs-evil?
2:
On lines 114/115, I replaced
(evil-global-set-key 'motion "j" 'evil-next-visual-line)
(evil-global-set-key 'motion "k" 'evil-previous-visual-line)
with
(define-key evil-motion-state-map (kbd "j") 'evil-next-visual-line)
(define-key evil-motion-state-map (kbd "k") 'evil-previous-visual-line)
(define-key evil-operator-state-map (kbd "j") 'evil-next-line)
(define-key evil-operator-state-map (kbd "k") 'evil-previous-line)
to get the behavior which I expect for commands like =d2j=. At first
glance, the first two lines of my change should have the same effect as
the two =evil-global-set-key= macros, but they do not. Not sure why.
3:
One strange behavior is that commands like =yyp= and =ddp= will not
paste the contents as new lines. Instead, the entire copied line is
pasted inline after the cursor. This happens also with our own feature
for evil-mode. However, it works just as expected (i.e. like in vi/vim)
in vanilla Emacs with evil-mode --- i.e. =emacs -q --load init.el=,
where init.el simply contains
(require 'evil)
(evil-mode 1)
I commented all features but feature-emacs in my configuration during my
testing, so this bug might come from there. So far I have not found
what causes it though. Any ideas?
4:
In my opinion, state messages like "-- INSERT --" can be hidden, as the
modeline already indicates the current state ("<I>" etc.), i.e.
(setq evil-insert-state-message nil)
(setq evil-visual-state-message nil)
5:
To make vim-converts more comfortable, consider adding something like
(with-eval-after-load
'evil-undo-fu-only
(setq evil-want-fine-undo t)
(define-key evil-normal-state-map (kbd "u") 'undo-fu-only-undo)
(define-key evil-normal-state-map (kbd "C-r") 'undo-fu-only-redo)))
in order to have vim-like undo and redo.
This mail became quite long! What do you think? We can break out the
discussion into new threads if required.
If needed I/Fredrik can make some patches :)
--
Best regards,
Johan Engstrand
On 2023-05-21 15:48, Johan Engstrand wrote:
> Hi,>
Hi Johan,
> Thanks for the work on the evil-mode feature, much appreciated. Me> and Fredrik are currently moving over to it from our own feature,> which was a bit of a mess. A few points after trying out the new> feature:>> 1: > The packages emacs-evil-commentary and emacs-evil-surround might be> useful --- at least I miss them. They do however add functionality that> is not present in vanilla vi/vim. What would be the scope of> feature-emacs-evil?
I think they fits well into emacs-evil.
>> 2: > On lines 114/115, I replaced > (evil-global-set-key 'motion "j" 'evil-next-visual-line)> (evil-global-set-key 'motion "k" 'evil-previous-visual-line)>> with> (define-key evil-motion-state-map (kbd "j") 'evil-next-visual-line)> (define-key evil-motion-state-map (kbd "k") 'evil-previous-visual-line)> (define-key evil-operator-state-map (kbd "j") 'evil-next-line)> (define-key evil-operator-state-map (kbd "k") 'evil-previous-line)>> to get the behavior which I expect for commands like =d2j=. At first> glance, the first two lines of my change should have the same effect as> the two =evil-global-set-key= macros, but they do not. Not sure why.>> 3:> One strange behavior is that commands like =yyp= and =ddp= will not> paste the contents as new lines. Instead, the entire copied line is> pasted inline after the cursor. This happens also with our own feature> for evil-mode. However, it works just as expected (i.e. like in vi/vim)> in vanilla Emacs with evil-mode --- i.e. =emacs -q --load init.el=,> where init.el simply contains>> (require 'evil)> (evil-mode 1)>> I commented all features but feature-emacs in my configuration during my> testing, so this bug might come from there. So far I have not found> what causes it though. Any ideas?>> 4:> In my opinion, state messages like "-- INSERT --" can be hidden, as the> modeline already indicates the current state ("<I>" etc.), i.e.
I would keep it on by default, because we usually don't have modeline in
rde emacs :D
We can implement it as a feature argument.
>> (setq evil-insert-state-message nil)> (setq evil-visual-state-message nil)>> 5:> To make vim-converts more comfortable, consider adding something like >> (with-eval-after-load> 'evil-undo-fu-only> (setq evil-want-fine-undo t)> (define-key evil-normal-state-map (kbd "u") 'undo-fu-only-undo)> (define-key evil-normal-state-map (kbd "C-r") 'undo-fu-only-redo)))>> in order to have vim-like undo and redo.>>> This mail became quite long! What do you think? We can break out the> discussion into new threads if required.>> If needed I/Fredrik can make some patches :)
I don't use evil, but everything above make sense and looks good to me,
so please send the patches.
Also, CCed Nicolas, who did the primary work on this feature.
--
Best regards,
Andrew Tropin
On 2023-05-22 20:44, Andrew Tropin wrote:
> On 2023-05-21 15:48, Johan Engstrand wrote:>>> Hi,>>>> Hi Johan,>>> Thanks for the work on the evil-mode feature, much appreciated. Me>> and Fredrik are currently moving over to it from our own feature,>> which was a bit of a mess. A few points after trying out the new>> feature:>>>> 1:>> The packages emacs-evil-commentary and emacs-evil-surround might be>> useful --- at least I miss them. They do however add functionality that>> is not present in vanilla vi/vim. What would be the scope of>> feature-emacs-evil?>> I think they fits well into emacs-evil.>
Fine for me!
>>>> 2:>> On lines 114/115, I replaced>> (evil-global-set-key 'motion "j" 'evil-next-visual-line)>> (evil-global-set-key 'motion "k" 'evil-previous-visual-line)>>>> with>> (define-key evil-motion-state-map (kbd "j") 'evil-next-visual-line)>> (define-key evil-motion-state-map (kbd "k") 'evil-previous-visual-line)>> (define-key evil-operator-state-map (kbd "j") 'evil-next-line)>> (define-key evil-operator-state-map (kbd "k") 'evil-previous-line)>>>> to get the behavior which I expect for commands like =d2j=. At first>> glance, the first two lines of my change should have the same effect as>> the two =evil-global-set-key= macros, but they do not. Not sure why.
Yes, we had a small bug here, if this fixes it, we would be happy to
properly integrate this fix. I haven't tried that yet, but I would be
happy to give some feedback / confirmation before merging that.
>>>> 3:>> One strange behavior is that commands like =yyp= and =ddp= will not>> paste the contents as new lines. Instead, the entire copied line is>> pasted inline after the cursor. This happens also with our own feature>> for evil-mode. However, it works just as expected (i.e. like in vi/vim)>> in vanilla Emacs with evil-mode --- i.e. =emacs -q --load init.el=,>> where init.el simply contains>>>> (require 'evil)>> (evil-mode 1)>>>> I commented all features but feature-emacs in my configuration during my>> testing, so this bug might come from there. So far I have not found>> what causes it though. Any ideas?
Not yet, I'll take a look.
>>>> 4:>> In my opinion, state messages like "-- INSERT --" can be hidden, as the>> modeline already indicates the current state ("<I>" etc.), i.e.>> I would keep it on by default, because we usually don't have modeline in> rde emacs :D>> We can implement it as a feature argument.>>>>> (setq evil-insert-state-message nil)>> (setq evil-visual-state-message nil)>>>> 5:>> To make vim-converts more comfortable, consider adding something like>>>> (with-eval-after-load>> 'evil-undo-fu-only>> (setq evil-want-fine-undo t)>> (define-key evil-normal-state-map (kbd "u") 'undo-fu-only-undo)>> (define-key evil-normal-state-map (kbd "C-r") 'undo-fu-only-redo)))>>>> in order to have vim-like undo and redo.
Yes, I'be been experimenting with this but indeed there was some
unexpected behaviour here. Vim-like copy-paste is what we want here,
we'll integrate this with pleasure.
>>>>>> This mail became quite long! What do you think? We can break out the>> discussion into new threads if required.>>>> If needed I/Fredrik can make some patches :)>> I don't use evil, but everything above make sense and looks good to me,> so please send the patches.>> Also, CCed Nicolas, who did the primary work on this feature.
I'll try the patches once you send them, also looks good to me, thanks
for your work here ;)
--
Best regards,
Nicolas Graves