Какое внутреннее предствление символов лучше подходит для текстового редактора?

Use QString, Luke. Для внутреннего представления UTF-16 — вполне разумный компромисс

wchar_t

Осторожнее. «широкие» кодировоки не камильфо, как только потребуется поддержка композитных символов. А так, на вкус и цвет

Для внутреннего представления UTF-16 — вполне разумный компромисс

Какой-то странный компромисс - не нашим, не вашим. С широкими символами удобно «передвигаться» по тексту. UTF-16 в этом смысле ничем не лучше UTF-8, только для UTF-8 хотя бы стандартная сишная библиотека есть на худой конец.

https://en.wikipedia.org/wiki/Rope_(data_structure)

С широкими символами удобно «передвигаться» по тексту.

Чем удобно? «Широкие символы» точно так же могут содержать комбинируемые знаки, поэтому всё равно придётся прочесать всю строку и построить индекс, по какому адресу начинается каждый кластер графем. В этом смысле «широкие символы» ничем не лучше UTF-8.

У UTF-16 фиксированный размер символа, соответственно, при размещении текста длинными непрерывными блоками можно гарантировать неизменное время доступа к случайному символу ценой большего расхода памяти и ограничению числа возможных значений. С UTF-8 так уже не получится

и не только.
http://www.averylaird.com/programming/the%20text%20editor/2017/09/30/the-piece-table/

http://www.finseth.com/craft/

Самый правильный редактор — без преобразования. Хранить надо так, как оно есть в файле, т. е. raw. Преобразования происходят при отображении и при вводе. Binary accuracy, короче.

Многие символы занимают больше двух байтов. В UTF-16 даже русская буква Ё может не поместиться, если её представлять как Е + двоеточие.

При загрузке текста в буфер неплохо бы избавиться от таких штук заменой на эквивалентный символ.

В чём «правильность»?

удобно «передвигаться» по тексту

Бгг. Нет

фиксированный размер символа

Был когда-то. А сейчас это мультибайт

Композиция - дороговато будет

Добро пожаловать в 2018 с год compound emojis: 🏳️‍🌈

Замени-ка мне а́ на эквивалентный символ.

если её представлять как Е + двоеточие

Если так — да. Поэтому я и назвал UTF-16 компромиссом, а не идеальным решением

А сейчас это мультибайт

Ты не путаешь с UTF-8? Насколько мне известно, UTF-16 и UTF-32 фиксированы в своём размере

Ждём поддержки в resvg.

Нет.

А вот об этом я и забыл, ибо не пользуюсь

«Суррогатные пары» эта шняга называется

Это не от меня зависит. Нужно чтобы все сопутствующие либы обновили Unicode до 11 версии.

cast utf8nowhere

Зачем звал?

Ник у тебя подходящий. Ну и сказать что-нибудб заодно

Ну вообще я за UTF-8 везде. Как видно из URL в профиле.

Про Rope тут уже сказали.

Лучше всего хранить так, как хранят уже существующие текстовые редакторы и не писать новых редакторов.

Можешь свой вариант придумать для внутреннего представления исходя из своих целей.

Написать хороший текстовый редактор не так легко, как кажется.

utf32

Написать хороший текстовый редактор не так легко, как кажется.

Поэтому хорошего до сих пор и нет. Увы.

Лучше как массив графем храни. А графемы в UTF-8 NFC.

Это чтобы файл, который ты не менял, всё равно при сохранении изменился, если был не в NFC-форме?

Это чтобы поиск делать. Если ты файл перезаписываешь, значит уже поменял и формат определяется кодировкой записи.

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html же.

wchar_t — слишком низкоуровнево, как и мультибайтовые строки и, в целом, юникод.

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html же.

Он вот эту букву 👩‍❤️‍💋‍👩 воспринимает как 4 символа. Так что тоже не совсем верно. Но подход правильный.

неплохо бы избавиться от таких штук заменой на эквивалентный символ

Это не всегда возможно.

В своём firefox я могу выделить мышью 4 отдельных символа (👩‍ ❤️‍💋‍👩) в этой букве, поэтому он не одинок.

Нет у UTF16 никакой фиксированности, любой символ за пределами BMP требует кодирования двумя суррогатами, например, emoji. Типичная ошибка, которую UTF16 провоцирует - обрабатывать его как UCS-2, устаревший в 1990-х годах.

Use QString, Luke.

Дожили. Кодеры кроме Qt ничего не знают.

Увы, но std::string — боль

один выстрел - один труп. Т.е. один символ - один объект.

могу выделить мышью 4 отдельных символа (👩‍ ❤️‍💋‍👩)

(👩‍ ❤️‍💋‍👩) и (👩‍❤️‍💋‍👩) — разные строки. Первая — три символа (один из них пробел), вторая — один.

поэтому он не одинок

Так Unicode вообще сложная штука. В этой строке в зависимости от программы до 8 символов распознаётся

Т.е. один символ - один объект.

Беда юникода в том, что нет однозначного понятия «символ».

Это у тебя понятия нет, а в юникоде есть однозначное понятие "grapheme cluster".

Это у тебя понятия нет, а в юникоде есть однозначное понятие «grapheme cluster».

Сколько графемных кластеров в слове «mach»? 3 или 4?

И ещё есть, например, «coffin». Тут 6 графемных кластеров и всего 4 глифа.