Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

撤回 (undo) 两次才能到未修改状态? #53

Closed
demon386 opened this issue May 19, 2015 · 1 comment · Fixed by #65
Closed

撤回 (undo) 两次才能到未修改状态? #53

demon386 opened this issue May 19, 2015 · 1 comment · Fixed by #65
Assignees

Comments

@demon386
Copy link
Contributor

打开一个会发生转码的文件(如 gbk),假设我打一个字符,按一次 undo,这时文件还是被修改状态。要再按一次 undo 才可以。这是否正常呢?如果是插件带来的问题,有没可能解决?

@seanliang seanliang self-assigned this May 22, 2015
@demon386
Copy link
Contributor Author

demon386 commented Aug 2, 2015

说一下为什么我遇到这个 bug。

主要是使用 sublime-Easymotion 这个插件 (https://github.com/tednaleid/sublime-EasyMotion)

它的原理似乎是通过修改文本内容来产生候选,在选了之后再通过 undo 来恢复原来内容的。我用这个插件,配合 ConvertToUTF8 的话,有时候只是在查看代码,确造成了文件变成被修改的状态,关闭的时候需要确认不保存修改,比较繁琐。

希望您能花些时间修一下这个 bug ^_^

demon386 added a commit to demon386/ConvertToUTF8 that referenced this issue Apr 24, 2016
See API reference for the meaning of the second argument of
`command_history`: https://www.sublimetext.com/docs/3/api_reference.html

This fix the following bug (seanliang#53), to reproduce:
1. Open a GBK encoded file.
2. Move the cursor down
3. Insert a char
4. Undo

After these steps, the buffer will be in a dirty status, which is not
desired.

When inspecting the content of `command` and `comman1` in the
forementioned steps, One can see the following logs:

```
command: ('insert', {'characters': 'j'}, 1); command1: ('', None, 0)
command: ('move', {'forward': True, 'by': 'lines'}, 2); command1: ('insert', {'characters': 'j'}, 1)
command: ('', None, 0); command1: ('convert_to_utf8', {'stamp': '1461504893.485919', 'detect_on_fail': False}, 1)
command: ('convert_to_utf8', {'stamp': '1461504893.485919', 'detect_on_fail': False}, 1); command1: ('', None, 1)
  1461504893.485919 {'stamp': '1461504893.485919', 'detect_on_fail': False}
``

So the problem seems to be that `move` command undesirably appears in
the command history.
seanliang added a commit that referenced this issue Apr 27, 2016
only record command that modifies the buffer (fix #53)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants