(https://github.com/ruby/reline/pull/566)
* Avoid referencing IOGate from IOGate classes
The only time those classes being used is when themselves being the IOGate.
So when referencing to IOGate, it's better to use `self` instead.
* Avoid referencing to IOGate from LineEditor directly
* Avoid referencing to IOGate from Core directly
* Reference to Reline.core directly
* Replace Reline::IOGate with Reline.core.io_gate
* Test existing behavior
Typing Ctrl-D ends editing but typing <Del> does not.
Also renamed a test that is not testing ed_delete_next_char but
key_delete.
* Check if line empty first in em_delete
By distributivity of AND over OR, we can factor out this condition. This
will make the next commit simpler.
* Use em_delete in key_delete
When the editing mode is emacs, use `em_delete` in `key_delete`. We need
to add a condition though to `em_delete`, because it implements both
`delete-char` and `end-of-file`. We only want the `end-of-file` behavior
is the key is really Ctrl-D.
This matches the behavior of the <Del> key with readline, i.e. deleting
the next character if there is one, but not moving the cursor, while not
finishing the editing if there are no characters.
The kill-line was called when C-u was entered, so it is now called unix-line-discard.
In readline(3):
> unix-line-discard (C-u)
> Kill backward from point to the beginning of the line.
> The killed text is saved on the kill-ring.
27570d195e
The method "input_keys" in test/reline/helper.rb handles a single-byte
and 8-bit charater as an input with the meta key.
However, "test_halfwidth_kana_width_dakuten" in test/reline/test_key_actor_emacs.rb
uses a string that contains "hankaku" characters.
A "hankaku" character is not with the meta key, but it is a single-byte
and 8-bit character on Windows-31J encoding, which confused "input_keys"
method. This caused the following error.
41997092/job/ejm77qxgvnlpdwvg
```
1) Failure:
Reline::KeyActor::Emacs::Test#test_halfwidth_kana_width_dakuten [C:/projects/ruby/test/reline/test_key_actor_emacs.rb:2311]:
<"\xB6\xDE\xB7\xDE\xB9\xDE\xBA\xDE" (#<Encoding:Windows-31J>)> expected but was
<"\e^\e^\e^\e:\e^" (#<Encoding:Windows-31J>)> in <Terminal #<Encoding:Windows-31J>>
.
<8> expected but was
<10>.
Finished tests in 1045.472722s, 19.3922 tests/s, 2609.4320 assertions/s.
```
This change introduces "input_raw_keys" that does not convert a
single-byte and 8-bit character to "with the meta key", and use it in
the test in question.
f6ae0e5d19
The vi mode can handle "argument number" before an operator or a motion,
such as, "3x" (equals "xxx"), and "3l" (equals "lll"). In the emacs
mode, GNU Readline can handle argument number with meta key, like
"Meta+3 x" (equals "xxx").
9183cc2e8b
For ruby/ruby repository's AppVeyor CI (Windows environment), `Reline::IOGate.encoding` will be changed from `UTF-8` to `Windows-31J` after the test is run.
So, when `test/reline/test_key_actor_emacs.rb` is loaded, `Reline::IOGate.encoding == Encoding::UTF_8` will be `true`,
but at the time of test execution, `Reline::IOGate.encoding` is `Windows-31J`.
For this reason, I changed the test method to check `Reline::IOGate.encoding` in the test method.
10e1ce3320
The command prompt on Windows always uses Unicode to take input and print
output but most Reline implementation depends on Encoding.default_external.
This commit introduces an abstracted structure about the encoding of Reline.
IRB should show a menu first if a completed list has plural items. But just
shows document without menu if a completed list with plural items includes a
perfect matched item. The behavior is a bug. This commit fixes it.
In the incremental search by C-r, search word is saved when it's determined. In
the next incremental search by C-r, if a user presses C-r again with the empty
search word, the determined previous search word is used to search.
