| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vim-patch:9.2.1175: setreg() block width wrong for unprintable chars
When yanking, the width of a <c-v>{motion}y register
is determined by the virtual colums of the text. However
in setreg() in 'b' mode use an idosyncratic width measurement
where C0 control chars (ASCII 0x00 - 0x19) and invalid UTF-8 bytes
have width 1 instead of their display width (2 or 4 cells).
Consider the following test case:
let strings = ['"reference', '"Übel', "\"aa\x07bb", "\"qq\x82", "\"x\nbabbel"]
for string in strings
call append('$', string)
exec "normal G0\<c-v>$\"ay"
let one = getregtype('a')
if string != strings[-1]
call setreg("b", string, 'b')
let two = getregtype('b')
else
let two = "na"
endif
call setreg("c", [string], 'b')
let three = getregtype('c')
call append('$', '"yank: '.one.", string: ".two.", list: ".three)
endfor
AFter this fix, all the three ways of measuring the width gives
equal values (or two, in the case of not being able to use setreg()
with a plain string in the first case)
|
| |
|
|
|
|
|
|
| |
part of a series, next big one is gonna be bring utf_ptr2schar and
friends into the New world. after that it might be worth brushing of
some benchmarks and re-microoptimize the hottest loops.
also some const-y constess but it is fine.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
'isident' decides how env var names are parsed, which is more
"confusing" than "useful":
- Changing 'isident' (for 'define' or "\i") can break `$NAME` expansion.
- Its default byte ranges let multibyte names work on Windows (`$aあ`)
but not Unix (`$é`).
Solution:
Ignore 'isident' when parsing env var names.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
For an incomplete sequence at the end of the string, utf_ptr2len_len()
reports more bytes than are there, and mb_utf_index_to_bytes() returns
that position unclamped:
vim.str_byteindex('ab\xf0\x9f', 'utf-16', 3, false) --> 6
on a 4 byte string. LSP callers use the result as a column, so
nvim_buf_set_extmark() then fails with "Invalid 'col': out of range".
Solution:
Clamp the returned byte index to the length of the string.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies to the callsites which already used utf_ptr2CharInfo
and then utfc_next. There is more work to be done, but this
is a lagom bisectable unit.
A lot of code is still wounded by the historical distinction between
"low" characters (c < 128) and "high" characters, with the UTF-8
specific rules behind compiler flags and virtual function calls. As a
result, there are both ptr2cells() and utf_ptr2cells(). My work aims at
slowly reintegrating the realms. As such, we consider ptr2cells() the
"correct" abstraction as is matches what actually is printed in a
displayed message and buffer text without extra bells and whistles,
except for tabs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
strdisplaywidth('ทำ') is 1, but that cluster needs two cells. A SpacingMark has
positive advance width (Unicode core spec D55), so it cannot share its base's
cell: no Thai font fits a consonant plus SARA AM (U+0E33) in one cell, the
narrowest needing 119% of one and most 180-210%, measured against a 0.600 em
cell. UAX#29 GB9a keeps the mark in its base's cluster, which is correct for
segmentation and says nothing about width.
setcellwidths() cannot work around it, because the collapse is per cluster, not
per codepoint.
Vim reports 2 here. Devanagari and Bengali matras and Khmer and Tamil vowel
signs are the same case.
Solution:
Add a cell for each remaining codepoint in the cluster whose boundclass is
UTF8PROC_BOUNDCLASS_SPACINGMARK, clamped to the maximum cells per cluster.
Segmentation is untouched, so the cursor and selection still treat the cluster
as one unit.
U+FF9E and U+FF9F, the halfwidth katakana sound marks, are Grapheme_Extend
rather than SpacingMark, so they are matched separately. This is not a general
solution for grapheme extenders that carry width -- that needs a queryable
table -- but it does fix the reported regressions for Thai and Japanese
(refs #34733).
AI-assisted
fixes #34733
|
| |\
| |
| | |
build(vim-patch): n/a channel,terminal,test,unicode patches
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Nvim uses utf8proc or an older process involving "src/unicode/"
and "download-unicode-files.sh" to decouple unicode characters
from "mbyte.c".
These unicode patches should be auto N/A but the diff hunk xfuncname
is wrong for utf_char2cells().
Is it because of the `#ifdef`?
Need a volunteer to inspect if these patches still have relevant
changes
Nvim
```c
/// same as utf_composinglike but operating on UCS-4 values
bool utf_iscomposing(int c1, int c2, GraphemeState *state)
{
return (!utf8proc_grapheme_break_stateful(c1, c2, state)
|| arabic_combine(c1, c2));
}
```
Vim
```c
/*
* Return TRUE if "c" is a composing UTF-8 character. This means it will be
* drawn on top of the preceding character.
* Based on code from Markus Kuhn.
*/
int
utf_iscomposing(int c)
{
// Sorted list of non-overlapping intervals.
// Generated by ../runtime/tools/unicode.vim.
static struct interval combining[] =
{
{0x0300, 0x036f},
{0x0483, 0x0489},
{0x0591, 0x05bd},
// ...
{0x0300, 0x036f},
{0x0483, 0x0489},
{0x0591, 0x05bd},
};
return intable(combining, sizeof(combining), c);
}
```
|
| |/
|
|
|
|
|
|
| |
Problem: Accepting "iso8859" 'encoding' as "iso-8859-".
Solution: use "iso8859" as "iso-8859-1".
https://github.com/vim/vim/commit/1349bd712cf7d24dc65408c523dd7deb30224f80
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Problem: curswant not set on 8g8
Solution: Set curswant, adjust tests (Emilien Breton)
closes: vim/vim#20979
https://github.com/vim/vim/commit/7fe5cb35f988774745750f89d8adf215c060f57b
Co-authored-by: Emilien Breton <bricktech2000@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
`getchar.c` is a quirky name and doesn't align with our existing
`os/input.c` and `tui/input.c` modules, which encompass the same topic
at different layers.
Solution:
Rename `getchar.c` => `input.c` for discoverability.
Introduce `dialog.c` for functionality related to showing confirm
prompts, dialogs, etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix(iconv): conversion to utf-16be using iconv is inconsistent
vim-patch:9.2.0769
Problem: enc_canonize function changes utf-16be to utf-16 but in linux
type utf-16 defaults to utf-16le.
Solution: Creating a separate entry for utf-16be in enc_canon_table.
Note: the effect is only visible on iconv implementations that
treat "utf-16" and "utf-16be" differently, so the test does
not necessarily fail on an unpatched Vim. But the bug is
visible in vim.iconv. (Manoj Panda)
from: vim/vim@2a63f74
closes: neovim#40262
Signed-off-by: Manoj Panda <manojpandawork@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(#35869)
Problem: mbyte contains overlapping list of utf_classes table
Solution: Update table to contain non-overlapping list (Yuta Yamamoto)
closes: vim/vim#18362
https://github.com/vim/vim/commit/9fa8a114b250cc0eeab2bc93eac66eaa08ae2187
Co-authored-by: Yuta Yamamoto <jichael.y.yuta1995@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: in terminal mode, adjust_topline moves curwin's cursor to the last row
so set_topline tails the non-scrollback area. This may result in the observed
cursor position remaining tailed in events within the focused terminal, rather
than reflecting the actual cursor position.
Solution: use the focused terminal's actual cursor position immediately, rather
than relying on the next terminal_check_cursor call in terminal_check to set it.
Note: Maybe also possible for terminal mode cursor position to be stale
(reporting the normal mode position) when switching buffers in events to another
terminal until the next terminal_check call? (or until refresh_terminal is
called for it) Maybe not worth fixing that, though.
|
| |
|
|
|
|
|
|
|
| |
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the preprocessor before generating prototypes provides some
"niceties" but the places that rely on these are pretty few.
Vastly simplifying the BUILD SYSTEM is a better trade-off.
Unbalancing { } blocks due to the preprocessor is cringe anyway (think
of the tree-sitter trees!), write these in a different way.
Add some workarounds for plattform specific features.
INCLUDE_GENERATED_DECLARATIONS flag is now technically redundant,
but will be cleaned up in a follow-up PR as it is a big mess.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
vim.uv.os_setenv gets "stuck" per-key. #32550
Caused by the internal `envmap` cache. #7920
:echo $FOO <-- prints nothing
:lua vim.uv.os_setenv("FOO", "bar")
:echo $FOO <-- prints bar (as expected)
:lua vim.uv.os_setenv("FOO", "fizz")
:echo $FOO <-- prints bar, still (not expected. Should be "fizz")
:lua vim.uv.os_unsetenv("FOO")
:echo $FOO <-- prints bar, still (not expected. Should be nothing)
:lua vim.uv.os_setenv("FOO", "buzz")
:echo $FOO <-- prints bar, still (not expected. Should be "buzz")
Solution:
- Remove the `envmap` cache.
- Callers to `os_getenv` must free the result.
- Update all call-sites.
- Introduce `os_getenv_noalloc`.
- Extend `os_env_exists()` the `nonempty` parameter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#33323)
Problem: inline word diff treats multibyte chars as word char
(after 9.1.1243)
Solution: treat all non-alphanumeric characters as non-word characters
(Yee Cheng Chin)
Previously inline word diff simply used Vim's definition of keyword to
determine what is a word, which leads to multi-byte character classes
such as emojis and CJK (Chinese/Japanese/Korean) characters all
classifying as word characters, leading to entire sentences being
grouped as a single word which does not provide meaningful information
in a diff highlight.
Fix this by treating all non-alphanumeric characters (with class number
above 2) as non-word characters, as there is usually no benefit in using
word diff on them. These include CJK characters, emojis, and also
subscript/superscript numbers. Meanwhile, multi-byte characters like
Cyrillic and Greek letters will still continue to considered as words.
Note that this is slightly inconsistent with how words are defined
elsewhere, as Vim usually considers any character with class >=2 to be
a "word".
related: vim/vim#16881 (diff inline highlight)
closes: vim/vim#17050
https://github.com/vim/vim/commit/9aa120f7ada592ed03b37f4de8ee413c5385f123
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
|
| | |
|
| |
|
| |
Result of `make iwyu` (after some "fixups").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Option metadata like list of valid values for an option and
option flags are not listed in the `options.lua` file and are instead
manually defined in C, which means option metadata is split between
several places.
Solution: Put metadata such as list of valid values for an option and
option flags in `options.lua`, and autogenerate the corresponding C
variables and enums.
Supersedes #28659
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
| |
|
|
|
|
|
| |
while the implementation is not tied to screen chars, it is a reasonable
expectation to support the same size. If nvim is able to display a
multibyte character, it will accept the same character as input,
including in normal mode commands like r{char}
|
| |
|
|
|
|
|
| |
Co-authored-by: David Pedersen <limero@me.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Leo Schlosser <Leo.Schlosser@Student.HTW-Berlin.de>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
| |
|
|
| |
fixes #30400
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
'fillchars' invalid (#30289)
Problem: Resetting cell widths can make 'listchars' or 'fillchars'
invalid.
Solution: Check for conflicts when resetting cell widths (zeertzjq).
closes: vim/vim#15629
https://github.com/vim/vim/commit/66f65a46c5d169f20f780721d4f74d4729855b96
|
| |\
| |
| | |
fix(multibyte): handle backspace of wide clusters in replace mode
|
| | |
| |
| |
| |
| | |
Make utf_head_off more robust against invalid sequences
and embedded NUL chars
|
| |/
|
|
|
|
|
|
|
|
| |
Problem: resetting setcellwidth() doesn't update the screen
Solution: Redraw after clearing the cellwidth table (Ken Takata)
closes: vim/vim#15628
https://github.com/vim/vim/commit/539e9b571ae2a80dfa8a42eb132ad9f65f0bbcbc
Co-authored-by: Ken Takata <kentkt@csc.jp>
|
| |
|
|
|
|
|
|
|
| |
Some sequences beginning with ASCII might be rendered as emoji, as for
instance emoji 1️⃣ which is encoded as ascii 0x31 + U+FE0F + U+20E3.
While it is tricky to make the width of such sequences configurable,
we can make TUI be careful with such sequences and reset the cursor,
just like for Extended_Pictogram based sequences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit intentionally aims at preserving existing behavior as much
as possible while replacing our build step to convert unicode data
files into binary tables, which corresponding lookups in utf8proc.
Actual improvements in behavior will be a followup.
The only change in behavior is that 'emoji' option will turn some
more codepoints into double with. Nvim used the "Emoji" and
"Emoji_Presentation" properties to define emojis, while utf8proc
only exposes the Extended_Pictographic property from the emoji table.
This is a superset of the previous emoji properties. As only
codepoints above 0x1f000 are affected by the 'emoji' option, this means
that the following chars are now treated as double-width, instead of
single-width like in previous nvim versions:
🀀 🀁 🀂 🀃 🀅 🀆 🀇 🀈 🀉 🀊 🀋 🀌 🀍 🀎 🀏 🀐 🀑 🀒 🀓 🀔 🀕 🀖 🀗 🀘 🀙 🀚 🀛 🀜 🀝 🀞 🀟 🀠 🀡 🀢 🀣 🀤
🀥 🀦 🀧 🀨 🀩 🀪 🀫 🀰 🀱 🀲 🀳 🀴 🀵 🀶 🀷 🀸 🀹 🀺 🀻 🀼 🀽 🀾 🀿 🁀 🁁 🁂 🁃 🁄 🁅 🁆 🁇 🁈 🁉 🁊 🁋 🁌
🁍 🁎 🁏 🁐 🁑 🁒 🁓 🁔 🁕 🁖 🁗 🁘 🁙 🁚 🁛 🁜 🁝 🁞 🁟 🁠 🁡 🁢 🁣 🁤 🁥 🁦 🁧 🁨 🁩 🁪 🁫 🁬 🁭 🁮 🁯 🁰
🁱 🁲 🁳 🁴 🁵 🁶 🁷 🁸 🁹 🁺 🁻 🁼 🁽 🁾 🁿 🂀 🂁 🂂 🂃 🂄 🂅 🂆 🂇 🂈 🂉 🂊 🂋 🂌 🂍 🂎 🂏 🂐 🂑 🂒 🂓 🂠
🂡 🂢 🂣 🂤 🂥 🂦 🂧 🂨 🂩 🂪 🂫 🂬 🂭 🂮 🂱 🂲 🂳 🂴 🂵 🂶 🂷 🂸 🂹 🂺 🂻 🂼 🂽 🂾 🂿 🃁 🃂 🃃 🃄 🃅 🃆 🃇
🃈 🃉 🃊 🃋 🃌 🃍 🃎 🃑 🃒 🃓 🃔 🃕 🃖 🃗 🃘 🃙 🃚 🃛 🃜 🃝 🃞 🃟 🃠 🃡 🃢 🃣 🃤 🃥 🃦 🃧 🃨 🃩 🃪 🃫 🃬 🃭
🃮 🃯 🃰 🃱 🃲 🃳 🃴 🃵 🄍 🄎 🄏 🄯 🅬 🅭 🅮 🅯 🆭 🌢 🌣 🎔 🎕 🎘 🎜 🎝 🏱 🏲 🏶 📾 🕆 🕇 🕈 🕏 🕨 🕩 🕪 🕫
🕬 🕭 🕮 🕱 🕲 🕻 🕼 🕽 🕾 🕿 🖀 🖁 🖂 🖃 🖄 🖅 🖆 🖈 🖉 🖎 🖏 🖑 🖒 🖓 🖔 🖗 🖘 🖙 🖚 🖛 🖜 🖝 🖞 🖟 🖠 🖡
🖢 🖣 🖦 🖧 🖩 🖪 🖫 🖬 🖭 🖮 🖯 🖰 🖳 🖴 🖵 🖶 🖷 🖸 🖹 🖺 🖻 🖽 🖾 🖿 🗀 🗁 🗅 🗆 🗇 🗈 🗉 🗊 🗋 🗌 🗍 🗎
🗏 🗐 🗔 🗕 🗖 🗗 🗘 🗙 🗚 🗛 🗟 🗠 🗢 🗤 🗥 🗦 🗧 🗩 🗪 🗫 🗬 🗭 🗮 🗰 🗱 🗲 🗴 🗵 🗶 🗷 🗸 🗹 🛆 🛇 🛈 🛉
🛊 🛓 🛔 🛦 🛧 🛨 🛪 🛱 🛲 🝴 🝵 🝶 🝻 🝼 🝽 🝾 🝿 🟕 🟖 🟗 🟘 🟙 🢰 🢱 🨀 🨁 🨂 🨃 🨄 🨅 🨆 🨇 🨈 🨉 🨊 🨋
🨌 🨍 🨎 🨏 🨐 🨑 🨒 🨓 🨔 🨕 🨖 🨗 🨘 🨙 🨚 🨛 🨜 🨝 🨞 🨟 🨠 🨡 🨢 🨣 🨤 🨥 🨦 🨧 🨨 🨩 🨪 🨫 🨬 🨭 🨮 🨯
🨰 🨱 🨲 🨳 🨴 🨵 🨶 🨷 🨸 🨹 🨺 🨻 🨼 🨽 🨾 🨿 🩀 🩁 🩂 🩃 🩄 🩅 🩆 🩇 🩈 🩉 🩊 🩋 🩌 🩍 🩎 🩏 🩐 🩑 🩒 🩓
🩠 🩡 🩢 🩣 🩤 🩥 🩦 🩧 🩨 🩩 🩪 🩫 🩬 🩭
|
| |
|
|
|
|
|
|
|
| |
Use the grapheme break algorithm from utf8proc to support grapheme
clusters from recent unicode versions.
Handle variant selector VS16 turning some codepoints into double-width
emoji. This means we need to use ptr2cells rather than char2cells when
possible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to `CaseFolding-15.1.0.txt`, full casefolding should be
preferred over simple casefolding as it's considered to be more correct.
Since utf8proc already provides full casefolding it makes sense to
switch to it. This will also remove a lot of unnecessary build code.
Temporary exceptions are made for two sets characters:
- `ß` will still be considered `ß` (instead of `ss`) as using a full
casefolding requires interfering with upstream spell files in some
form.
- `İ` will still be considered `İ` (instead of `i̇`) as using full
casefolding requires making a value judgement on the "correct"
behavior. There are two, equally valid case-insensetive comparison for
this character according to unicode. It is essentially up to the
implementor to decide which conversion is correct. For this reason it
might make sense to allow users to decide which conversion should be
done as an added option to `casemap` in a future PR.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case-insensitive
Problem: regex: wrong match when searching multi-byte char
case-insensitive (diffsetter)
Solution: Apply proper case-folding for characters and search-string
This patch does the following 4 things:
1) When the regexp engine compares two utf-8 codepoints case
insensitive it may match an adjacent character, because it assumes
it can step over as many bytes as the pattern contains.
This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some
single-byte value.
Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.
However in that case, it should only step over the single byte value
's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
* we try to match the correct length for the pattern and the text
* in case of a match, we step over it correctly
There is one tricky thing for the backtracing engine. We also need to
calculate correctly the number of bytes to compare the 2 different
utf-8 strings s1 and s2. So we will count the number of characters in
s1 that the byte len specified. Then we count the number of bytes to
step over the same number of characters in string s2 and then we can
correctly compare the 2 utf-8 strings.
2) A similar thing can happen for the NFA engine, when skipping to the
next character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over.
So this needs to be adjusted in find_match_text() as well.
3) A related issue turned out, when prog->match_text is actually empty.
In that case we should try to find the next match and skip this
condition.
4) When comparing characters using collections, we must also apply case
folding to each character in the collection and not just to the
current character from the search string. This doesn't apply to the
NFA engine, because internally it converts collections to branches
[abc] -> a\|b\|c
fixes: vim/vim#14294
closes: vim/vim#14756
https://github.com/vim/vim/commit/22e8e12d9f5034e1984db0c567b281fda4de8dd7
N/A patches:
vim-patch:9.0.1771: regex: combining chars in collections not handled
vim-patch:9.0.1777: patch 9.0.1771 causes problems
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
| |
utf8proc already defines LATIN CAPITAL LETTER SHARP S (ẞ) to be the
uppercase variant of LATIN SMALL LETTER SHARP S (ß), so this special
workaround when using `gU` is no longer needed on the neovim side.
|
| |
|
|
|
| |
The comment "German sharp s is lower case but has no upper case
equivalent." is no longer true and is therefore not needed anymore.
|
| | |
|
| |
|
|
|
| |
revert: "refactor: use S_LEN(s) instead of s, n (#29219)"
This reverts commit c37695a5d5f2e8914fff86f3581bed70b4c85d3c.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem: Wrong cursor position after using setcellwidths().
Solution: Invalidate cursor position in addition to redrawing.
(zeertzjq)
closes: vim/vim#14545
https://github.com/vim/vim/commit/05aacec6ab5c7ed8a13bbdca2f0005d6a1816230
Reorder functions in test_utf8.vim to match upstream.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|< |
