Now, the highlight line is created by replacing non-tab characters with
spaces, and keeping all hard tabs as-is. This means the highlight line
has the completely same indentation as the code snippet line.
Fixes#738f20fa542
- Add UNICODE_VERSION,... to deal with new location of some
of the emoji-related data files.
- Introduce class BreakFile to handle various file properties.
- Adapt main code to use BreakFile.
In ISO-2022-JP, the bytes use to code are the same as those for "<>".
This adds regression tests to make sure that these bytes, when representing
湿, are NOT escaped with encode("ISO-2022-JP, xml: :text) or similar.
These are additional regression tests for #12052.
Before this commit, const_get with inherit=true and constant lookup
expressions searched the ancestors of the starting point in an order
different from `starting_point.ancestors`.
Items in the ancestry list introduced through prepend were searched
after searching the module they were prepended into. This oddity allowed
for situations where constant lookups gave different results even though
`starting_point.ancestors` is the same.
Do the lookup in the same order as `starting_point.ancestors` by
skipping classes and modules that have an origin iclass. The origin
iclass is in the super chain after the prepended modules.
Note that just like before this commit, the starting point of the
constant lookup is always the first item that we search, regardless of
the presence of any prepended modules.
[Bug #17887]
... instead of exact matching. I'm now creating a built-in gem that
modifies Exception's error message, so the expectation value is changed.
IMO, it is good to check that did_you_mean suggestion is NOT added in
the uncorrectable case.
ebe88ec4d2
When using a non-ASCII compatible source and destination encoding
and xml escaping (the :xml option to String#encode), the resulting
string was broken, as it used the correct non-ASCII compatible
encoding, but contained data that was ASCII-compatible instead of
compatible with the string's encoding.
Work around this issue by detecting the case where both the
source and destination encoding are non-ASCII compatible, and
transcoding the source string from the non-ASCII compatible
encoding to UTF-8. The xml escaping code will correctly handle
the UTF-8 source string and the return the correctly encoded
and escaped value.
Fixes [Bug #12052]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
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
It is unclear why this was implemented, I assume
it was for performance back in 2006.
However today, this compression defeats bytecode caching
entirely and end up being counter productive.
ae3703c1d0
This was already documented as being ignored, but it wasn't being
ignored, causing an issue in a particular case where a UTF-8
pattern was provided and a filename was tested that wasn't valid
UTF-8.
Fixes [Bug #14456]
If the type is ADJUST we don't want to treat it like an INSN so we have
to check the type before reading from `insn_info.events`.
[Bug #18001] [ruby-core:104371]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>