Примерно то же самое я почувствовал когда увидел в cmd Windows 10 нормальный selection flow. Раньше был исключительно прямоугольник.

Там ещё и ANSI коды для 256 цветов теперь поддерживаются. Нет, это не сон. :)

Aaaaaa!!!

Таладна. Когда я обнаружил, что ресайз работает по-человечески, вот это был shock and awe. Осталось только дождаться поддержки UTF-8 из коробки.

Он поддерживается, но не по умолчанию. Интуитивная юзер-френдли команда chcp 65001 включает поддержку. Ну и шрифт нужно не абы какой выбрать, а чтобы нужные буковки в нем были.

К сожалению, никакой «поддержки» Юникода не появляется, это всего лишь хак, задающий интерпретацию символов во вводе и выводе интерпретатора, и справляющийся разве что с листингом непредставимых в одной кодировке имён файлов.

Как известно, в Windows никакого UTF-8 нет, а есть юникодное API, работающее с двухбайтными (ну, для начала) символами в UTF-16LE, и ANSI API, работающее с однобайтными символами в текущей системной кодировке. После "chcp 65001" функции _A не перекомпилируются магически в функции _W, и мы имеем все те радости, глюки и падения, которые получает человек, решивший по-быстрому пихнуть в char[] строку UTF-8 без глобального пересмотра всех используемых библиотек.

ANSI-кодировки символов с переменной шириной (MBCS) в Windows тоже существуют, в версиях для азиатских и других языков, но в них как раз-таки система и приложения пересобраны с библиотеками, переписанными для работы с такими кодировками. UTF-8 не является одной из поддерживаемых локалей.

В Powershell есть юникод (поскольку это никакая не консоль, а REPL для C#, работающий с его объектами), в UNIX-подсистеме, по идее, тоже должны были что-то нормальное для работы программ придумать (не совместимое со старой консолью, очевидно).

Вы меня, похоже, неправильно поняли. chcp отвечает за преобразование байтов, отправляемых в консоль, в видимые пользователю на экране буковки (и обратно, из нажимаемых кнопочек в байты). Все. chcp 65001 делает так, что это преобразование преобразует из/в UTF-8. Я имел в виду только это и больше ничего. Ни о каких локалях и W и A APIs и библиотеках речи нет, это из другой оперы совсем.

…А в результате данных операций в указанные функции попадает поток в UTF-8, с переменной шириной символа и сложными правилами кодирования и декодирования, хотя там его никто не ждёт.

В результате, например, привычный .bat-файл в однобайтной кодировке может не запуститься в кодовой странице 65001, поскольку содержит последовательности символов, не разрешённые в UTF-8. Или программа упадёт из-за того, что в файле (не консоли), который она честно читает в соответствии с заданными настройками окружения, будут символы, которых нет в шрифте (В ШРИФТЕ!) консоли. Последнее, впрочем, и без Юникода можно было организовать.

> сложными правилами кодирования и декодирования

А зачем его кодировать и декодировать? В задачу большинства программ это не входит. Байты нужно хранить и пересылать как есть, а декодированием занимаются специально обученные сущности (консоль, например).

Консольные программы под вендой, которым таки да нужно понимать символы, либо читают wchar_t (и тогда им все равно, что там за code page в любом случае), либо рассчитаны на какую-то одну legacy code page (и тогда они подлежат утилизации в биореакторе).

> хотя там его никто не ждёт

Кто включил 65001, тот именно UTF-8 и ждет. Вот я, например. Включил 65001, жду UTF-8, его получаю, и ничего такого катастрофического не происходит.

> может не запуститься в кодовой странице 65001

Он может не запуститься и в любой другой странице, отличной от той, в которой головотяп его писал. В большинстве страниц есть коды, не соответствующие никаким символам. Вывод такого кода в консоль приводит к всяческим неприятностям.

> в файле (не консоли), который она честно читает в соответствии с заданными настройками окружения, будут символы, которых нет в шрифте

Это какая-то фантазия. Если легального символа нет в шрифте консоли, консоль его заменяет на квадратик, вопросительный знак или какую другую кракозябру, это раз. Чтение из файла совершенно никак с этим не связано, это два. Я проверял.

> Байты нужно хранить и пересылать как есть

Переслал тебе length(s) байтов, у одного результата строка обрывается посреди символа, у другой функции стек мусором затёрт, куда сам сядешь, куда мать посадишь?

> Это какая-то фантазия.

Невероятно, но факт: замена шрифта на растровый 256-символьный делает больно даже программам уровня «прочесть строку из файла 1 — записать строку в файл 2».

> Если легального символа нет в шрифте консоли, консоль его заменяет на квадратик, вопросительный знак или какую другую кракозябру, это раз.

Это три разных подмены, и как минимум две из них происходят совсем не в коде вывода на экран данных консоли; отнюдь не «раз».

Юникод? В консольной подсистеме Windows? Чтобы программы перестали падать, даже не взаимодействуя с консолью? Никогда!

> Наверное, конец света действительно близок.

А он будет кончаться на 0xA или 0xD, 0xA? ))

Лучший коммент :)

Или "А он будет кончаться на ^Z или ^D?"

Вау! Да так он уже скоро с Notepad++ конкурировать будет ;)

Ну Яблы же перешли на Юникс, чому бы Окнам не?

Вот когда он синтаксис красить начнет - тогда и я поверю ;)

Это пока только в insider build?

Кажется, да, я запутался уже с их терминологией.

Ну после того как винда щетай из коробки заражена убунтой... уже сложно удивить

Это вы про что? Я пропустил совсем...

Собственно, поэтому и блокнот стали чинить

Пора заводить таг "муравей"?

После такой новости я не удивлюсь даже, если Notepad станет строчки нумеровать.

"Extended" - это в смысле, notepad теперь распознает ситуацию, когда «новая строка» есть, а «возврата каретки» нет.

Мрачно лезу в Википедию:

The Unicode standard defines a number of characters that conforming applications should recognize as line terminators:[5]
LF: Line Feed, U+000A
VT: Vertical Tab, U+000B
FF: Form Feed, U+000C
CR: Carriage Return, U+000D
CR+LF: CR (U+000D) followed by LF (U+000A)
NEL: Next Line, U+0085
LS: Line Separator, U+2028
PS: Paragraph Separator, U+2029

Есть над чем работать...

Program Files/Sublime Text/uninstall.exe

Так всё логично: сначала нативные драйвера для SQL Server-а из линукса, потом отсутствие претензий к Mono, потом Linux Subsystem в Windows 10, потом и Visual Studio Core в линукс...

Here is an even more ominous sign: https://opensource.microsoft.com/?keyword=linux