The dot Command not able to repeat text inserted by "Auto-complete"
Hi, I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without. So, for example after "pri" have been typed, auto-complete gives a candidate menu and I selected the "printf" from the menu, I then hit "RET" and the text "printf" got inserted. I then hit ESC and move the point to somewhere else, I hit "." wanted to get "printf" inserted again but I ended up getting the exact keyboard sequence I had typed which is "pri"+new line. I guess this will not be an "easy" fix so if it will take too much time and there are still more important stuff out there then please just ignore it for now. I'm sorry that at least in the next 5 months I will not be able to contribute things more complicated than or as complicated as "isearch opens and closes hidden text" like I did before, because I'm still new to elisp and is currently under extreme stress from my project at work. Thanks, York
Am Mon, 15 Aug 2011 14:54:44 -0400 schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days. Frank
Oh man, you are great!!! Thanks a lot! On Mon, Aug 15, 2011 at 4:50 PM, Frank Fischer < [email protected]> wrote:
Am Mon, 15 Aug 2011 14:54:44 -0400 schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more. Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems. (evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore) (defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.") (defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change))) Hope it works, Frank
Hi Frank, Thank you very much for this. I just did a few quick tests which appeared to be working perfectly fine. I'm using auto-complet a lot every day so I will report back problems if I will notice any but my feeling is that it is going to work. Thanks again for the wonderful works. York On Tue, Aug 16, 2011 at 5:59 AM, Frank Fischer < [email protected]> wrote: Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more. Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems. (evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore) (defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.") (defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change))) Hope it works, Frank _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Hi, It had happened a few times today that dot command was not repeating the previous insertion, but rather some other command, e.g. it was repeating "switch-buffer" a minute ago, and currently is repeating the "C-h k ." command. Right now it is working properly again. I don't know how to reproduce this yet. York On Tue, Aug 16, 2011 at 11:45 AM, York Zhao <[email protected]> wrote: Hi Frank, Thank you very much for this. I just did a few quick tests which appeared to be working perfectly fine. I'm using auto-complet a lot every day so I will report back problems if I will notice any but my feeling is that it is going to work. Thanks again for the wonderful works. York On Tue, Aug 16, 2011 at 5:59 AM, Frank Fischer < [email protected]> wrote: Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more. Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems. (evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore) (defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.") (defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change))) Hope it works, Frank _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
I can reproduce the problem now: 1. Hit "i" to enter Insert state and type something 2. Esc to exit insert 3. Hit "." and it will work fine 3. Hit "C-x b" to switch to other buffer 4. Hit "." in the new buffer and "switch-buffer" command will be repeated York On Thu, Aug 18, 2011 at 5:14 PM, York Zhao <[email protected]> wrote: Hi, It had happened a few times today that dot command was not repeating the previous insertion, but rather some other command, e.g. it was repeating "switch-buffer" a minute ago, and currently is repeating the "C-h k ." command. Right now it is working properly again. I don't know how to reproduce this yet. York On Tue, Aug 16, 2011 at 11:45 AM, York Zhao <[email protected]> wrote: Hi Frank, Thank you very much for this. I just did a few quick tests which appeared to be working perfectly fine. I'm using auto-complet a lot every day so I will report back problems if I will notice any but my feeling is that it is going to work. Thanks again for the wonderful works. York On Tue, Aug 16, 2011 at 5:59 AM, Frank Fischer < [email protected]> wrote: Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more. Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems. (evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore) (defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.") (defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change))) Hope it works, Frank _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Thu, Aug 18, 2011 at 05:34:54PM -0400, York Zhao wrote:
I can reproduce the problem now:
1. Hit "i" to enter Insert state and type something 2. Esc to exit insert 3. Hit "." and it will work fine 3. Hit "C-x b" to switch to other buffer 4. Hit "." in the new buffer and "switch-buffer" command will be repeated
Thanks for the report. I realised it on my own but wasn't able to reproduce it ;) Anyway, it should be fixed in d9c1ed78. Note that I have cleaned up some parts of the repeat system, so there may be new bugs ... Frank
York
On Thu, Aug 18, 2011 at 5:14 PM, York Zhao <[email protected]> wrote: Hi,
It had happened a few times today that dot command was not repeating the previous insertion, but rather some other command, e.g. it was repeating "switch-buffer" a minute ago, and currently is repeating the "C-h k ." command. Right now it is working properly again. I don't know how to reproduce this yet.
York
On Tue, Aug 16, 2011 at 11:45 AM, York Zhao <[email protected]> wrote: Hi Frank,
Thank you very much for this. I just did a few quick tests which appeared to be working perfectly fine. I'm using auto-complet a lot every day so I will report back problems if I will notice any but my feeling is that it is going to work. Thanks again for the wonderful works.
York
On Tue, Aug 16, 2011 at 5:59 AM, Frank Fischer < [email protected]> wrote: Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more.
Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems.
(evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore)
(defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.")
(defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change)))
Hope it works, Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
-- Frank Fischer Chemnitz University of Technology, Department of Mathematics eMail: [email protected] Tel.: +49 (371) 531-36913
Thanks Frank, I will report back new bugs if I found them. York On Fri, Aug 19, 2011 at 4:03 AM, Frank Fischer < [email protected]> wrote: On Thu, Aug 18, 2011 at 05:34:54PM -0400, York Zhao wrote:
I can reproduce the problem now:
1. Hit "i" to enter Insert state and type something 2. Esc to exit insert 3. Hit "." and it will work fine 3. Hit "C-x b" to switch to other buffer 4. Hit "." in the new buffer and "switch-buffer" command will be repeated
Thanks for the report. I realised it on my own but wasn't able to reproduce it ;) Anyway, it should be fixed in d9c1ed78. Note that I have cleaned up some parts of the repeat system, so there may be new bugs ... Frank
York
On Thu, Aug 18, 2011 at 5:14 PM, York Zhao <[email protected]> wrote: Hi,
It had happened a few times today that dot command was not repeating the previous insertion, but rather some other command, e.g. it was repeating "switch-buffer" a minute ago, and currently is repeating the "C-h k ." command. Right now it is working properly again. I don't know how to reproduce this yet.
York
On Tue, Aug 16, 2011 at 11:45 AM, York Zhao <[email protected]> wrote: Hi Frank,
Thank you very much for this. I just did a few quick tests which appeared
to
be working perfectly fine. I'm using auto-complet a lot every day so I will report back problems if I will notice any but my feeling is that it is going to work. Thanks again for the wonderful works.
York
On Tue, Aug 16, 2011 at 5:59 AM, Frank Fischer < [email protected]> wrote: Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more.
Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems.
(evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore)
(defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.")
(defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change)))
Hope it works, Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
-- Frank Fischer Chemnitz University of Technology, Department of Mathematics eMail: [email protected] Tel.: +49 (371) 531-36913 _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Ok, I've found new problems, here is the sequence to reproduce: 1. At the beginning of a empty line, I typed "i" 2. Type "aaa" and the line becomes "aaa" 3. "Esc" 4. "i" 5. "eee" and the line becomes "aaaeee" 6. "Esc" 7. Type "." and the line becomes "aaaeeeeee" 8. Type "C-." and the becomes "aaaeeeaaa" while it should be "aaaeeeeeeaaa" Hope this helps. York On Fri, Aug 19, 2011 at 11:10 AM, York Zhao <[email protected]> wrote: Thanks Frank, I will report back new bugs if I found them. York On Fri, Aug 19, 2011 at 4:03 AM, Frank Fischer < [email protected]> wrote: On Thu, Aug 18, 2011 at 05:34:54PM -0400, York Zhao wrote:
I can reproduce the problem now:
1. Hit "i" to enter Insert state and type something 2. Esc to exit insert 3. Hit "." and it will work fine 3. Hit "C-x b" to switch to other buffer 4. Hit "." in the new buffer and "switch-buffer" command will be repeated
Thanks for the report. I realised it on my own but wasn't able to reproduce it ;) Anyway, it should be fixed in d9c1ed78. Note that I have cleaned up some parts of the repeat system, so there may be new bugs ... Frank
York
On Thu, Aug 18, 2011 at 5:14 PM, York Zhao <[email protected]> wrote: Hi,
It had happened a few times today that dot command was not repeating the previous insertion, but rather some other command, e.g. it was repeating "switch-buffer" a minute ago, and currently is repeating the "C-h k ." command. Right now it is working properly again. I don't know how to reproduce this yet.
York
On Tue, Aug 16, 2011 at 11:45 AM, York Zhao <[email protected]> wrote: Hi Frank,
Thank you very much for this. I just did a few quick tests which appeared
to
be working perfectly fine. I'm using auto-complet a lot every day so I will report back problems if I will notice any but my feeling is that it is going to work. Thanks again for the wonderful works.
York
On Tue, Aug 16, 2011 at 5:59 AM, Frank Fischer < [email protected]> wrote: Am Montag, 15. August 2011 schrieb Frank Fischer:
Am Mon, 15 Aug 2011 14:54:44 -0400
schrieb York Zhao <[email protected]>:
Hi,
I've been having this problem for a while and it is now my biggest complain to Evil because other than Evil itself, "auto-complete" is the next thing I can't be living without.
In fact, the change based repeation system (in contrast to the key-stroke based one, I described both in another mail and it will hopefully find its way in the docs) is designed exactly for these cases and I'm quite confident that this is indeed not a big problem. I just haven't activated it yet, but I'm going to have a look at it in the next days.
In turned out to be a little bit more difficult than a thought. Activating the change-based repeation for auto-complete worked well except in one case: when the completion is done near the end of the buffer. The reason is that in this case auto-complete adds a few newlines to the end of the buffer in order to show its popup-menu (those newlines are removed when the popup closes). The problem is that these insertions/deletions are, well, buffer-changes and therefore confused the recording. Even worse, the popup menu is triggered by a timer and not by a command, therefore there is no command active when the first buffer changes appear and this confuses the system even more.
Luckily, Evil had already had the ability to execute arbitrary functions to realize a repeation, there just was no way to specify such a function for a command. I added this functionality in d15b75a5. The following code should equip auto-complete with working repeation. I'm going to cleanup the repeation code, especially the definition of user-defined repeation functions, a little bit, so don't assume this as a stable example but feel free to test and tell us about problems.
(evil-set-command-properties 'ac-complete :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-expand :repeat 'evil-ac-repeat) (evil-set-command-properties 'ac-next :repeat 'ignore) (evil-set-command-properties 'ac-previous :repeat 'ignore)
(defvar evil-ac-prefix-len nil "The length of the prefix of the current item to be completed.")
(defun evil-ac-repeat (flag) "Record the changes for auto-completion." (if (eq flag 'pre) (setq evil-ac-prefix-len (length ac-prefix)) ;; Add change to remove the prefix (evil-repeat-record-change (list (- evil-ac-prefix-len) "" evil-ac-prefix-len)) ;; Add change to insert the full completed text (evil-repeat-record-change (list (- evil-ac-prefix-len) (buffer-substring-no-properties (- evil-repeat-pos evil-ac-prefix-len) (point)) 0)) ;; Finish repeation (evil-repeat-record-change)))
Hope it works, Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
-- Frank Fischer Chemnitz University of Technology, Department of Mathematics eMail: [email protected] Tel.: +49 (371) 531-36913 _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Am Fri, 19 Aug 2011 11:35:41 -0400 schrieb York Zhao <[email protected]>:
Ok, I've found new problems, here is the sequence to reproduce:
1. At the beginning of a empty line, I typed "i" 2. Type "aaa" and the line becomes "aaa" 3. "Esc" 4. "i" 5. "eee" and the line becomes "aaaeee" 6. "Esc" 7. Type "." and the line becomes "aaaeeeeee" 8. Type "C-." and the becomes "aaaeeeaaa" while it should be "aaaeeeeeeaaa"
No, it should be aaaeeeaaa. C-. is bound to `evil-pop-repeat' and it replaces the just repeated command with the previously recorded one. This is similar to Emacs' kill ring, where you can use C-y to paste some yanked text and M-y the replace this text with previously yanked text rotating the kill-ring. Evil arranges recorded commands similarly in a "repeat-ring" and C-. cycles through that ring when used immediately after a ".", hence the behavior you describe is by intention. In order to get "aaaeeeeeeaaa" use . two times followed by a C-. Frank
Thanks for the clarification and yes it is more useful for the "C-." to behave in the way you explained. However, there is still some problems I believe around here. After the 8 steps I listed in the previous email, and maybe keep pressing "C-." a few more times, undo all the changes so far and restart the above 8 steps again, this time when pressing the "C-." for the first time the line becomes "aaaeeeaaa" which is good, however, pressing "C-." again would clear the line as well as the "Buffer Modified Flag" (buffer indicated as "no change") as opposed to changing the line to "aaaeeeeee", pressing "C-." the third time would mess up the next line in the buffer. Hope this helps. York On Fri, Aug 19, 2011 at 12:46 PM, Frank Fischer < [email protected]> wrote: Am Fri, 19 Aug 2011 11:35:41 -0400 schrieb York Zhao <[email protected]>:
Ok, I've found new problems, here is the sequence to reproduce:
1. At the beginning of a empty line, I typed "i" 2. Type "aaa" and the line becomes "aaa" 3. "Esc" 4. "i" 5. "eee" and the line becomes "aaaeee" 6. "Esc" 7. Type "." and the line becomes "aaaeeeeee" 8. Type "C-." and the becomes "aaaeeeaaa" while it should be "aaaeeeeeeaaa"
No, it should be aaaeeeaaa. C-. is bound to `evil-pop-repeat' and it replaces the just repeated command with the previously recorded one. This is similar to Emacs' kill ring, where you can use C-y to paste some yanked text and M-y the replace this text with previously yanked text rotating the kill-ring. Evil arranges recorded commands similarly in a "repeat-ring" and C-. cycles through that ring when used immediately after a ".", hence the behavior you describe is by intention. In order to get "aaaeeeeeeaaa" use . two times followed by a C-. Frank _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Am Fri, 19 Aug 2011 13:15:44 -0400 schrieb York Zhao <[email protected]>:
Thanks for the clarification and yes it is more useful for the "C-." to behave in the way you explained.
However, there is still some problems I believe around here. After the 8 steps I listed in the previous email, and maybe keep pressing "C-." a few more times, undo all the changes so far and restart the above 8 steps again, this time when pressing the "C-." for the first time the line becomes "aaaeeeaaa" which is good, however, pressing "C-." again would clear the line as well as the "Buffer Modified Flag" (buffer indicated as "no change") as opposed to changing the line to "aaaeeeeee", pressing "C-." the third time would mess up the next line in the buffer.
Sorry, but I can't reproduce that right now. Could you give a detailed key-sequence, please, I'm probably doing something wrong. Frank
Here's the sequence: 1. make emacs 2. "C-h v evil-move-cursor-back" 3. Click on "customize this variable" 4. Toggle the value to "off" 5. Click on "Set for current session" 6. Click on "Exit" 7. In the "Scratch" buffer type "i" 8. Type "aaa" 9. Type ESC 10. Type "i" 11. Type "eee" 12. Type ESC 13. Type "." 14. Type "C-." 15. Type "C-." again and you end up in the "Customize" buffer. York On Fri, Aug 19, 2011 at 1:59 PM, Frank Fischer < [email protected]> wrote: Am Fri, 19 Aug 2011 13:15:44 -0400 schrieb York Zhao <[email protected]>:
Thanks for the clarification and yes it is more useful for the "C-." to behave in the way you explained.
However, there is still some problems I believe around here. After the 8 steps I listed in the previous email, and maybe keep pressing "C-." a few more times, undo all the changes so far and restart the above 8 steps again, this time when pressing the "C-." for the first time the line becomes "aaaeeeaaa" which is good, however, pressing "C-." again would clear the line as well as the "Buffer Modified Flag" (buffer indicated as "no change") as opposed to changing the line to "aaaeeeeee", pressing "C-." the third time would mess up the next line in the buffer.
Sorry, but I can't reproduce that right now. Could you give a detailed key-sequence, please, I'm probably doing something wrong. Frank _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Am Freitag, 19. August 2011 schrieb York Zhao:
Here's the sequence:
1. make emacs 2. "C-h v evil-move-cursor-back" 3. Click on "customize this variable" 4. Toggle the value to "off" 5. Click on "Set for current session" 6. Click on "Exit" 7. In the "Scratch" buffer type "i" 8. Type "aaa" 9. Type ESC 10. Type "i" 11. Type "eee" 12. Type ESC 13. Type "." 14. Type "C-." 15. Type "C-." again and you end up in the "Customize" buffer.
You ran into two problems here, one that can (and should) be fixed relatively easily, the other is very hard to make right. The easy one (I haven't fixed yet) is the following. pop-repeat works by using undo to unrepeat the repeated command and then replay the next command in the repeat ring. The problem arises if the first repeated command (the one that should be reverted and replaced by the next one) did not perform any change in the buffer. In this case no undo information is recored und the call to `evil-pop-repeat', which just undos the last command would undo not the repeated command (because this one did not do anything) but the command before that. That's the reason why you may end up with an empty *scratch* buffer - the insertion of the inserted text is actually reverted accidentally. Well, this should not be too difficult to fix. The second issue is much more serious and probably impossible to do right. The repeat system records *any* command that is performed in a buffer, this includes editing command but also any other thinkable command. C-h v is bound to `describe-variable' which is just another command. Evil-commands have a special :repeat property which specifies if and how those commands should be recorded for repeation. Standard Emacs commands do not have such information. Therefore it is very difficult for Emacs to decide whether a certain command is an editing command or not. They all look the same. But editing commands *have to* be recorded and can't be ignored because otherwise all those little mode-specific editing functions, which usually are no Evil commands, won't be repeatable anymore (e.g., indent-region). Therefore Evil currently has the following rules, which all abort the recording of repeat information for the active command: 1. commands that end up in a different buffer (e.g., switch-buffer) 2. commands that force an abort (i.e., have the property :repeat abort) 3. commands that are invoked by mouse events 4. commands in the minibuffer 5. in Emacs-state nothing is recorded So one way to prevent certain commands from being recorded would be to use `evil-declare-abort-repeat' on that commands (e.g., for all describe-* commands, `eval-expression', `execute-extended-command', ...) but this would require a lot of functions to be marked. Another compromise could be to record non-Evil commands only in insert-state (as it is done with motions) and to ignore them in normal-state. This would cause, e.g., `describe-variable' to be ignored when called from normal-state (which should be the usual case) but go into the repeat-info when used in insert-state. But it would also make other non-Evil commands to be unrepeatable when called from normal-state. In any case, it will always be possible to make unusual commands invade the repeat-information and I see no 100% safe way to prevent this. Frank
The easy one (I haven't fixed yet) is the following. pop-repeat works by using undo to unrepeat the repeated command and then replay the next command in the repeat ring. The problem arises if the first repeated command (the one that should be reverted and replaced by the next one) did not perform any change in the buffer. In this case no undo information is recored und the call to `evil-pop-repeat', which just undos the last command would undo not the repeated command (because this one did not do anything) but the command before that. That's the reason why you may end up with an empty *scratch* buffer - the insertion of the inserted text is actually reverted accidentally. Well, this should not be too difficult to fix.
The version I'm current using is commit "b46489" which I'm not sure should have the fix for the first problem. But it seems to be working better now except that there are still issues: - make emacs - C-h k M-. (This splits horizontally into two windows with the original one on - the left side and a help window on the right side. - Type "i" - Type "aaa" - Type ESC - Type "a" - Type "bbb" - Type ESC - Type "." - Type "C-." a few more times and you will get the buffer messed up
the second issue is much more serious and probably impossible to do right.
Let's see how it goes Also I noticed that "M-." never has any effect, maybe I'm missing anything here? Thank you very much for your hard working. York
Am Mon, 22 Aug 2011 12:19:14 -0400 schrieb York Zhao <[email protected]>:
The easy one (I haven't fixed yet) is the following. pop-repeat works by using undo to unrepeat the repeated command and then replay the next command in the repeat ring. The problem arises if the first repeated command (the one that should be reverted and replaced by the next one) did not perform any change in the buffer. In this case no undo information is recored und the call to `evil-pop-repeat', which just undos the last command would undo not the repeated command (because this one did not do anything) but the command before that. That's the reason why you may end up with an empty *scratch* buffer - the insertion of the inserted text is actually reverted accidentally. Well, this should not be too difficult to fix.
The version I'm current using is commit "b46489" which I'm not sure should have the fix for the first problem. But it seems to be working better now except that there are still issues:
The first problem is still unfixed. The second one is undecided ;)
- make emacs - C-h k M-. (This splits horizontally into two windows with the original one on - the left side and a help window on the right side. - Type "i" - Type "aaa" - Type ESC - Type "a" - Type "bbb" - Type ESC - Type "." - Type "C-." a few more times and you will get the buffer messed up
You ran again in both problems: C-h k M-. is a command which should be abort recording of repeat information (second issue). The repeated use of C-. runs in the undo-problematic because C-h k M-. is *not* an editor command and hence does not change the buffer (first issue).
the second issue is much more serious and probably impossible to do right.
Let's see how it goes
Also I noticed that "M-." never has any effect, maybe I'm missing anything here?
No, that's a bug. Frank -- Frank Fischer Chemnitz University of Technology, Department of Mathematics eMail: [email protected] Tel.: +49 (371) 531-36913
You ran again in both problems: C-h k M-. is a command which should be abort recording of repeat information (second issue). The repeated use of C-. runs in the undo-problematic because C-h k M-. is *not* an editor command and hence does not change the buffer (first issue).
Thanks for the explanation, hopefully you will still come up with some sort of solution.
York Zhao <[email protected]> writes:
You ran again in both problems: C-h k M-. is a command which should be abort recording of repeat information (second issue). The repeated use of C-. runs in the undo-problematic because C-h k M-. is *not* an editor command and hence does not change the buffer (first issue).
The first issue (undoing too much) should be fixed in c122336. Furthermore M-. (`evil-repeat-pop-next') should work, too. The second issue (which commands should abort recording of repeation) is still open. Frank
Thanks Frank. York On Tue, Aug 23, 2011 at 4:51 AM, Frank Fischer <[email protected]> wrote:
York Zhao <[email protected]> writes:
You ran again in both problems: C-h k M-. is a command which should be abort recording of repeat information (second issue). The repeated use of C-. runs in the undo-problematic because C-h k M-. is *not* an editor command and hence does not change the buffer (first issue).
The first issue (undoing too much) should be fixed in c122336. Furthermore M-. (`evil-repeat-pop-next') should work, too.
The second issue (which commands should abort recording of repeation) is still open.
Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
participants (2)
-
Frank Fischer -
York Zhao