» Текстовый редактор

MorSe
Terminal содержит досовский набор.
А в EmEditor вообще-то помогает Reload in different Encoding->Cyrillic (Dos866).

o22

Цитата:

PaulGor
Цитата:да и IMHO, не дело для текстового редактора быть одновременно и
перекодировщиком - есть отдельные перекодировщики, и т.к. они на это и заточены,
то удобнее ими пользоваться, а в Windows-редакторе писать 'родной' кодировкой
Windows-1251...

Насчет перекодировки это необязательно, согласен, но иногда очень удобно. А вот насчет распознавания кодировки и записи только в 1251 категорически не согласен.
Я уже раньше писал, что у меня, например, часто бывает нужно открыть файл в ДОС-кодировке и записать его в ней-же. Причем текст должен быть не перекодирован и не искажен (вследствие временного перекодирования на время работы в редакторе). Очень часто после редактирования в некоторых редакторах происходит искажение спецсимволов (псевдографики или национальных символов).

Тут, конечно, UltraEdit совсем не подходит. Правда, это довольно специфическая
вещь - в настоящее время мало кто работает с файлами в
кодировке DOS-866.
В любом случае - для твоей задачи UltraEdit не подходит, а для моих -
программирование, HTML, тексты в кодировке win-1251 -
полностью подходит, т.к. в нём поддерживаются все вещи, перечисленные людьми недавно, и о котoрых я писал в предыдущем сообщении:
http://forum.ru-board.com/topic.cgi?forum=5&topic=0602&start=346
плюс ещё и поиск удобный (и если нужно - с регулярными выражениями).
Например, у меня на сайте - множество HTML файлов (все, кстати, сделаны в UltraEdit),
и я хочу найти или заменить устаревшую ссылку во всех, где она есть (точно не знаю,
в каких файлах есть такая ссылка). Сайт MS очень часто меняется, ссылки устаревают...
В UltraEdit это легко - вызвал его, выбрал опцию поиска в файлах, и все файлы, где
текст найден, показаны списком в нижней рамке, могу на каждый щёлкать и
мне в новом окне загрузиться тот файл, причём та часть, где строка найдена - как в VC++ Dev Studio
( могу этого не делать а просто сделать глобальную замену во всех своих файлах
одной ссылки на другую).

А вот EmEditor для моих целей совсем не подходит, особенно то, что он не многооконный, что например, ужасно неудобно для поиска/замены, описанной выше.

Так что под каждую задачу всё же получается свой редактор, нет универсально хорошего...

Цитата:

PaulGor
Национальные алфавиты легко настраиваются.
Для работы выбирается многоязычный шрифт, например, "Courier New" и:
- надо писать по-немецки, в windows-1252:
выбираю "Western" в списке Scripts для этого шрифта
- надо писать по-русски, в windows-1251:
выбираю "Cyrillic" в списке Scripts для этого шрифта


С учетом вышесказанного, это все теряет смысл. Мне не всегда нужно писать в какой-то определенной кодировке (с нуля), мне нужно, чтобы редактор эту кодировку сам распознал (пусть это будет польская, немецкая, как ты предлагал, или украинская ДОС-овсая, как нужно мне), и после редактирования в ней-же записал (причем корректно). Я могу даже не обратить внимания, в какой кодировке был файл, тем более что-то выбирать вручную.
Так вот упоминаемый UltraEdit этого ничего не делает. Может я плохо искал, но ты сам подтвердил, что распознавания в нем нет, а отсюда все и вытекает...

Ты прав - UltraEdit этого не делает. А какой редактор это делает для разных языков?
По-моему это принципиально невозможно - 'д' в win1251 - это байт со значением
0xE4 (код буквы - 228).
Немецкая буква a-умляют - тоже 0xE4 (код буквы - 228) в кодировке 1252 -
в простом тексте это просто байт, как понять, немецкий он или русский?

PaulGor

Цитата:

Тут, конечно, UltraEdit совсем не подходит. Правда, это довольно специфическая
вещь - в настоящее время мало кто работает с файлами в
кодировке DOS-866.

Да тут дело не совсем именно в 866 кодировке.
Речь, скорее, о возможности поддержки любой кодировки, даже пользовательской.


Цитата:

По-моему это принципиально невозможно - 'д' в win1251 - это байт со значением
0xE4 (код буквы - 228).
Немецкая буква a-умляют - тоже 0xE4 (код буквы - 228) в кодировке 1252 -
в простом тексте это просто байт, как понять, немецкий он или русский?

Да ты прав, для отдельно взятого символа (если это не юникод), никак.
Вот тут и переплетается возможность (на первый взгляд вроде как не обязательная) автоопределения редактором кодировки и возможность редактором-же правильно отображать и записывать символы в этой кодировке.
Если мы имеем не один символ, а набор символов (коим является текст), то уже с большей долей вероятности можем сказать к какой кодировке (а вернее кодовой странице) этот набор символов принадлежит.
Например, если помимо того-же 228 кода, в тексте есть символы с 253 кодом (э), которого, например, нет в немецкой кодировке, то скорее всего текст все-таки, русский. Вероятность ошибки, конечно есть, если текст небольшой, но здесь все зависит от алгоритма автоопределения. Да если даже и кодировка не определилась, то выбрав ее вручную, мы однозначно укажем как редактору отображать и записывать текст, чтобы не испортить его.

o22

Цитата:

Если мы имеем не один символ, а набор символов (коим является текст), то уже с большей долей вероятности можем сказать к какой кодировке (а вернее кодовой странице) этот набор символов принадлежит.

Разве? Если на диске - простой текст, скажем a.TXT, то этот просто набор байтов
и никак нельзя узнать, из какой они кодовой таблицы - Western или Cyrillic,
ведь во всех кодовых таблицах позиции 128-255 заняты, вот они все здесь
нарисованы для всех наборов символов:
http://czyborra.com/charsets/iso8859.html
Поэтому мне кажется нельзя авто-определить, кириллический ли текст - или
ты знаешь редактор, ктороый умеет это делать?


Цитата:

Например, если помимо того-же 228 кода, в тексте есть символы с 253 кодом (э), которого, например, нет в немецкой кодировке, то скорее всего текст все-таки, русский. Вероятность ошибки, конечно есть, если текст небольшой, но здесь все зависит от алгоритма автоопределения.

Почему это ты думаешь, что в Western (нет кодировки 'немецкой', есть Western)
нет символа с кодом 253 (hex 0хFD)? Нет, в любой кодировке все позиции 128-255
обычно заняты, вот, например, картинка "Western":
http://czyborra.com/charsets/codepages.html#CP1252

Какой может быть 'алгоритм автоопределения' для набора байтов со значениями
128-255, если мы говорим о разных языках??? Никак нельзя сказать,
принадлежит ли данный набор байтов из a.TXT кодировке Western или Cyrillic или
Greek, и т.п.


Цитата:

Да если даже и кодировка не определилась, то выбрав ее вручную, мы однозначно укажем как редактору отображать и записывать текст, чтобы не испортить его.

Естественно, именно так и работает UltraEdit и большинство других простых текстовых редакторов -
вручную выбрав скрипт шрифта в UltraEdit - "Western" или Cyrillic или Greek,
я получаю правильное отображение тех самых байтов из a.TXT - то есть
это и есть ручной выбор кодировки данного текста.

И, как и большинство других неюникодовых простых текстовых редакторов,
UltraEdit не портит текст, записывая его - по определению!
Ведь такие редакторы, в отличие от юникодовых,
НЕ трогают байты - ни при загрузке, ни при отображении, ни при записи на диск.

Только юникодовые редакторы могут испортить текст, потому что они 'трогают' байты -
пытаются их интерпретировать, т.к. им надо всё время конвертировать текст
Unicode <--->не-Unicode при работе с .TXT (если только не делать юникодового .TXT).

RulNote 1.2.4
hxxp://www.rulnote.udmlink.ru/DownloadFiles/RN_Setup.zip

PaulGor

Цитата:

Разве? Если на диске - простой текст, скажем a.TXT, то этот просто набор байтов
и никак нельзя узнать, из какой они кодовой таблицы - Western или Cyrillic,
ведь во всех кодовых таблицах позиции 128-255 заняты, вот они все здесь

Заняты все, это точно. Но все-ли используются ?
Возьмем Cyrrilic.
В каком русском тексте используются символы ЂЃѓ†‡€‰ЉЊЌЋЏђљњќћџ, которые в Cyrrilic присутствуют ? А на этих знакоместах в другой кодировке (пусть и Western) могут быть "рабочие", или другими словами, используемые в языке символы. Ладно, не буду говорить за Western, мне лениво смотреть какие там символы в ней на этих знакоместах, но в ДОС-овской кодировке на этих знакоместах псевдографика, что с большой долей вероятности может говорить о том, что этот текст может быть ДОСовским.


Цитата:

Почему это ты думаешь, что в Western (нет кодировки 'немецкой', есть Western)
нет символа с кодом 253 (hex 0хFD)? Нет, в любой кодировке все позиции 128-255
обычно заняты, вот, например, картинка "Western":

Да пофиг, хоть немецкой, хоть турецкой, подход везде един. 253 код я привел только для примера (см. мое сообщение), а тем более, что в немецком языке символа, находящегося на 253 знакоместе как раз и нет.
В алфавите может быть от 25 до 35 букв, а в кодовой странице их 256, диапазоне 128-255 соответсвенно 128. Остальное забито "возможно используемыми" или неиспользуемыми символами. На этом и основываются все алгоритмы автоопределения кодировки.

Здесь я еще ничего не говорю о методе основанном на "характерных сочетаниях символов", который еще более интеллектуален и позволяет определить кодировку почти на 100%

Цитата:

Поэтому мне кажется нельзя авто-определить, кириллический ли текст - или
ты знаешь редактор, ктороый умеет это делать?

Ты не прав, во многих редакторах это рядовая фича.
Тот-же всем известный простенький Bred это делает легко.
Или редактор RulNote, на который вон ссылку дал YUNGA и которым я пользуюсь.
Да чего далеко ходить. В своих программах я применяю функцию определения кодировки dbf-файлов, написанную собственноручно. Правда определяется только DOS и Win-1251 кодировки, но этого для меня достаточно.

Цитата:

Только юникодовые редакторы могут испортить текст, потому что они 'трогают' байты - пытаются их интерпретировать, т.к. им надо всё время конвертировать текст
Unicode <--->не-Unicode при работе с .TXT (если только не делать юникодового .TXT).

А это уже полный бред. Даже объяснять неохота.
Посмотри, если не влом, RulNote.
Почитай FAQ к нему и документацию.

o22

Цитата:

PaulGor:
Поэтому мне кажется нельзя авто-определить, кириллический ли текст - или
ты знаешь редактор, ктороый умеет это делать?

Ты не прав, во многих редакторах это рядовая фича.
Тот-же всем известный простенький Bred это делает легко.
Или редактор RulNote, на который вон ссылку дал YUNGA и которым я пользуюсь.
Да чего далеко ходить. В своих программах я применяю функцию определения кодировки dbf-файлов, написанную собственноручно. Правда определяется только DOS и Win-1251 кодировки, но этого для меня достаточно.

Может, я ошибаюсь, но мне кажется в большинстве русских редакторов
авто-определение - только для кириллицы - как у тебя, то есть, если задано, что текст -
кириллический, то они могут определить какой именно - KOI8-R, DOS-866, win1251.
Это (в рамках одного языка) - естественно - сделать достаточно легко...
А мы говорили (на основе твоего примера - 'польский, немецкий, русский') о
авто-определении для разных языков.
Если в Bred загрузить польский или немецкий текст, я не думаю, что он это дело
авто-определит


Цитата:

PaulGor
Только юникодовые редакторы могут испортить текст, потому что они 'трогают' байты - пытаются их интерпретировать, т.к. им надо всё время конвертировать текст
Unicode <--->не-Unicode при работе с .TXT (если только не делать юникодового .TXT).

А это уже полный бред. Даже объяснять неохота.
Посмотри, если не влом, RulNote.
Почитай FAQ к нему и документацию.

Ты не обратил внимания на слово 'могут' (я его сейчас выделил в цитате выше),
я ведь не писал. что юникодовые редакторы всегда портят текст.

Обычно текст 'портится' в юникодовом редакторе, если
(а) такой редактор или не имеет соответствующей гибкой настройки,
или
(б) имеет, но пользователь не знает про неё:

а) Notepad - юникодовый он под Win 2000/XP - попробуй загрузить туда
русский .TXT на нерусской системе или немецкий (польский) .TXT на русской
системе - сам увидишь, что текст испорчен - и поправить нельзя
б) Word 2000/XP - попробуй загрузить туда русский .TXT на нерусской системе или
немецкий (польский, ...) .TXT на русской системе - сам увидишь, что текст испорчен.
Только если пользователь знает, что надо сначала выставить нужную опцию
в меню ("Подтверждать конверсию при загрузке") и ещё несколько шагов (описанных по ссылке ниже), только тогда текст не испортится:
http://ourworld.compuserve.com/homepages/PaulGor/cp_win.htm#txt

PaulGor

Цитата:

Если в Bred загрузить польский или немецкий текст, я не думаю, что он это дело
авто-определит

Нет, конечно. В нем другой подход. Полистай топик раньше, если есть желание, я об этом писал.
Просто примером Бреда я хотел показать, что автоопределение не есть невозможным.
Бред "заточен" именно под эти кодировки. Ничто не мешает его "заточить" и под другие.
Просто такая цель его автором не ставилась.
PaulGor

Цитата:

Ты не обратил внимания на слово 'могут' (я его сейчас выделил в цитате выше),
я ведь не писал. что юникодовые редакторы всегда портят текст.

Согласен. Не обратил. Но тут правильнее будет сказать не "портят", а "неверно отображают", что сразу-же становится очевидным и легко исправимым.
За ссылку спасибо.

o22


Цитата:

PaulGor:

Цитата:Если в Bred загрузить польский или немецкий текст, я не думаю, что он это дело
авто-определит

Нет, конечно. В нем другой подход. Полистай топик раньше, если есть желание, я об этом писал.
Просто примером Бреда я хотел показать, что автоопределение не есть невозможным.
Бред "заточен" именно под эти кодировки. Ничто не мешает его "заточить" и под другие.
Просто такая цель его автором не ставилась.

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

Кстати, хотел поблагодарить за ссылку на RulNote - вот он (если конечно нужные
таблицы загрузить) авто-определил мне немецкий текст (вернее, Western European encoding текст), потом - польский (вернее Central European encoding текст),
ну русский естественно, сбился только на Baltic (литовский, латышский).


Цитата:

правильнее будет сказать не "портят", а "неверно отображают", что сразу-же становится очевидным и легко исправимым.

Нет, как раз 'портят':
а) неюникодовые редакторы не трогают байты загружаемого текста и поэтому
могут только неверно отобразить. Например, если у меня в UltraEdit рабочий шрифт
в данный момент - "Courier New(Cyrillic)", а my.TXT содержит немецкий текст,
то я вместо a-umlaut увижу 'д' - что легко исправимо - только Script поменять
у шрифта на "Western"

б) юникодовые же редакторы 'трогают', конвертируют байты из my.TXT,
поэтому могут их испортить (опять же, НЕюникодовые редакторы
в принципе не могут испортить, т.к. загружают/выгружают байты 'as is')
и исправить это нелегко а иногда (в случае с Notepad 2000/XP) -
просто невозможно (легко ведь проверить - загрузив немецкий .TXT на русской
системе или наоборот - неисправимо).
А именно:
- в файле - немецкая а-umlaut, это байт 0xE4 (в Win-1251 это 'д')
- если система - русская (кириллица Win-1251 является системной кодовой
страницей - system code page), и редактор не знает, что в файле -
немецкие буквы, то байт этот 'испортится' - он превратится в юникодовое
значение согласно схеме Win-1251 ---> Unicode, вместо того, чтобы
быть переконвертированным по схеме Win-1252 Western ---> Unicode
и превратится в 2 байта 0x0434 вместо 0x00E4 -
совершенно другое значение, испорченное.

То же самое будет если русский текст загружать на английской машине
(то есть, где system code page = 1252 Western) - русская 'д, которая
в файле представлена как байт 0хЕ4, переконвертируется в неверное
юникодовое значение 0x00E4 (т.к. будет принята за a-umlaut) вместо
корректного 0x0434.


Это не только с редакторами юникодовоыми происходит, но с любым юникодовом
продуктом, например, Java или ASP - если при чтении текстового файла, где внутри -
текст в кодировке, отличающейся от системной кодовой страницы, не указать эту
кодировку, то текст сильно 'испортится' - совершенно не те байты получатся...

PaulGor

Цитата:

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

Честно говоря большой разницы не вижу.
Главное в этом деле описать все коды, которые являются символами соответствующего алфавита(кодировки). И на основании этой информации определять вероятность того, что этот текст может принадлежать к конкретному языку (или кодировке).
Хорошо, если в редакторе это настраиваемо (как в RulNote), но и вариант "зашитой настройки" тоже очень часто дает неплохой результат.
Основная трудность здесь - когда диапазон возможных кодировок (языков) достаточно велик. Здесь падает точность определения. Но как правило их используется не более 5-6 и результаты, которые дает тот-же RulNote достаточно неплохие.


Цитата:

Кстати, хотел поблагодарить за ссылку на RulNote - вот он (если конечно нужные
таблицы загрузить) авто-определил мне немецкий текст (вернее, Western European encoding текст), потом - польский (вернее Central European encoding текст),
ну русский естественно, сбился только на Baltic (литовский, латышский).

Что и требовалось доказать. Но и на Baltic можно легко его переключить, не прибегая к лишним хитростям в виде копирование в промежуточные программы.


Цитата:

Нет, как раз 'портят':
а) неюникодовые редакторы не трогают байты загружаемого текста и поэтому
могут только неверно отобразить...

Да, если каждой возможной кодировке соответствует свой шрифт. А это есть далеко не всегда. И в этом случае редактор начинает подставлять "похожие символы" для отображения, например, той-же ДОС-овской псевдографики. И их-же потом и записывает. Меняя первоначальные коды, естественно.
Так делают очень многие "неюникодовые редакторы". Они как раз реально портят файл.
И самое подлое, что делают это незаметно для неискушенного пользователя.


Цитата:

б) юникодовые же редакторы 'трогают', конвертируют байты из my.TXT,
поэтому могут их испортить (опять же, НЕюникодовые редакторы
в принципе не могут испортить, т.к. загружают/выгружают байты 'as is')...

Отчасти согласен, но если-бы в том-же Word был простой способ сменить кодовую страницу загруженного текста, эта-бы проблема не стояла вообще.
Тот-же RulNote в случае неправильного определения кодировки (что визуально заметно) одним щелчком мыши можно "переориентировать". В любом случае реально испортить файл можно только записав его. А если ты видишь "абракадабру", то делать это кто-то вряд-ли будет.

o22

Цитата:

Цитата:PaulGor:
а) неюникодовые редакторы не трогают байты загружаемого текста и поэтому
могут только неверно отобразить...


Да, если каждой возможной кодировке соответствует свой шрифт. А это есть далеко не всегда. И в этом случае редактор начинает подставлять "похожие символы" для отображения, например, той-же ДОС-овской псевдографики. И их-же потом и записывает. Меняя первоначальные коды, естественно.
Так делают очень многие "неюникодовые редакторы". Они как раз реально портят файл.
И самое подлое, что делают это незаметно для неискушенного пользователя

Вот это интересно - я никогда таких редакторов не видел. Все, что я видел,
не трогают байты (коды) (по своей природе, это же неюникодовые текстовые редакторы,
они байты(коды) как есть загужают и как есть выгружают),
и если шрифта нужного нет, то покажут каким есть.
Например, я в UltraEdit или в другой обычный редактор загружаю японский .TXT.
Шрифта нет - ну, так я и увижу 'неверное отображение', но коды при этом
ну никак не могут поменяться! То же самое я видел сотни раз, когда на Win95
без активированного MS Multilanguage Support (то есть в шрифтах - только
Western) пытался загрузить в редактор русский или польский текст -
да, покажет неверно, но коды-то не испортит.

Наверное, ты имеешь в виду какой-то необычный 'слишком умный' редактор,
который пытается авто-определить русскую кодировку....

Всё же определение кодировок совсем не часто встречается среди функций простых
текстовых редакторов. Какой это редактор был? А то вот так влипну - напишет
мне кто-нибудь, что взял редактор XYZ, а тот ему русский текст испортил, а я
напишу в ответ, что "этого не может быть, потому что не может быть никогда"

Правда, с 1995-го я ни разу о таком не слышал, и не в плане похвальбы, а чтобы
оправдаться, что не слышал о таком и считал что неюникодовые редакторы
в принципе не могут коды (байты) менять, могу намекнуть на количество полученных
мной писем - см. ссылку "Visitors" в нижнем фрейме заглавной страницы моего сайта:
http://ourworld.compuserve.com/homepages/PaulGor/

PaulGor

Цитата:

Вот это интересно - я никогда таких редакторов не видел. Все, что я видел,
не трогают байты (коды) (по своей природе, это же неюникодовые текстовые редакторы,

Я, конечно, дико извиняюсь, что не имею достаточно времени, чтобы привести более-менее полный список обсуждавшихся в этом топике редакторов, которые страдают этой болезнью, с углубленным анализом и со всеми ссылками. Тем более, что обычно не подошедшие мне чем-либо программы я не оставляю. Но то, что у меня осталось из страдающих именно этой болезнью (как сами программы так и тестовые файлы после испытаний с ними), я здесь приведу:

- RPad32 (версия еще 2001 года)
- EditPadPro (http://www.EditPadPro.com)
- ListEdit (у меня правда версия 1.3)
- Texter (версия 2.5 http://vgsoft.by.ru/)
- PolyEdit (версия 5.0 beta 5)
- WinEditPlus (версия 2.2 - этот правда в добавок ко всему и показывает неправильно, а при попытке записать без изменений записывает совсем другое )

В чем заключался тест ?
Беру файл в кодировке DOS с наличием псевдографики.
Вручную (если функции автоопределения кодировки нет) указываю ему, что файл в кодировке DOS. Если при отражении я вижу, что вместо символов псевдографики представлены другие (тире вместо горизонтальной линии, знак равенства вместо двойной горизонтальной, двоеточие вместо вертикальной и т.д.) - все, тест не пройден, так как после изменения в нем и повторной записи первоначальные коды будут заменены на другие.
В некоторых из указанных программ нельзя указать текущую кодировку, но похожий эффект возникает при перекодировке DOS866->Win1251. Это, конечно, меньший грех, но все-равно, своего рода лукавство. В некоторых можно указать другой шрифт, но он никак не привязан к кодировке.
Выход из такой неоднозначной ситуации - возможность на каждую кодировку указать свой шрифт (как сделано в Bred, EmEditor, Tea и скорее всего UltraEdit с твоих слов) или выводить в Unicode (как сделано, например в RulNote).
Иначе компромис может дорого стоить.
Для меня сейчас фавориты:
RulNote - за очень качественное определение кодировки и ее настраиваемость. За время работы с ним ни один файл таким образом испорчен не был. Недостатки - медленное открытие файлов (скорее всего плата за определение кодировки) и отсутствие опции "Переносить длинные строки" (все никак не соберусь написать автору)
EmEditor - самый быстрый, но тяжелый в освоении и настройке. Еще недостаток - определение кодировок хромает.
Bred - скорость и автоопределение - без комментариев Недостаток - нет подсветки синтаксиса.

Тест, конечно, не полный, более того однобокий (рассматривался в основном один аспект), но как говорится, у кого что болит, тот про то и говорит

o22,

Спасибо, теперь понятно - редакторы, специально сделанные для работы с русскими
кодировками, применяют перекодировку, а тогда, естественно, коды (байты)
меняются. Это при любой перекодировке происходит - что между обычными
кодировками, что при конвертировании в Unicode и из него...

В обычных текстовых редакторах (которых большинство) такого нет - загружаешь
свой DOS-866 текст, ему и дела нет - он эти байты не трогает никак.
Найдёшь шрифт DOS-866 (http://www.kiarchive.ru/pub/windows/cyrillic/truetype/),
выставишь в качестве рабочего - Ок, твой текст виден нормально.

PaulGor

Цитата:

Спасибо, теперь понятно - редакторы, специально сделанные для работы с русскими
кодировками, применяют перекодировку,

Не совсем, среди указанных редакторов есть не только русские (например EditPadPro).
Наличие в списке в основном наших редакторов показывает только то, что именно я отдаю им предпочтение (чаще всего бесплатность, более качественное программирование, гарантированная поддержка русского). А для импортных редакторов стоят те-же проблемы (у них ведь ДОС тоже был ) . Так что русский здесь как раз не при чем.


Цитата:

В обычных текстовых редакторах (которых большинство) такого нет - загружаешь
свой DOS-866 текст, ему и дела нет - он эти байты не трогает никак.

Да, скажем так, не должен трогать. Но как показывает практика, трогает и еще как...

Цитата:

Найдёшь шрифт DOS-866 (http://www.kiarchive.ru/pub/windows/cyrillic/truetype/),
выставишь в качестве рабочего - Ок, твой текст виден нормально.

Да, именно так, но в этом случае очень желательно, чтобы этот шрифт был "привязан к кодировке", то есть при указании, что это текст досовский (или KOI-8 например), он автоматически становился текущим. А это есть уже далеко не у каждого редактора.
Но есть, оказывается, и другой вариант, и он мне больше нравится, так как это сделано в RulNote.

Добавлено
Раз разговор зашел за шрифты, не посоветуешь какой-нибудь моноширинный приличный фонт, очень желательно узкий. А то пришлось самому *.fon делать для Delphi. Хотелось-бы еще разнообразия. Сорри за офф.

o22,

Нет, моноширокого не знаю, кроме Курьера, но можно вот тут посмотреть,
в топике про поиск/коллекции шрифтов:
http://forum.ru-board.com/topic.cgi?forum=4&topic=0263#1

PaulGor
Спасибо за ссылку, загляну.
Спасибо и за интересный спор (беседу).
Надеюсь, что мы оба (а может еще кто ) из нее почерпнули много нового.

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

Pavlenko
К стандартному виндовому блокноту нет никаких примочек и плагинов, потому что они не нужны. Зачем писать плагин к Notepad'у, когда быстрее свой Notepad запрограммить, а дальше уже добавлять к нему что душе хочется. Отсюда и такое количество разнообразных текстовых редакторов в стиле Notepad/Wordpad

EmEditor (Text Editor) + куча плагинов.
http://www.emurasoft.com/

Pavlenko
Texter2 посмотри. _http://vgsoft.by.ru/texter2/

Люди, а как вам
http://www.gridinsoft.com/notepad.php ?
Он фриварный, понимает множество кодироввок. Как для себя писал...
Если есть замечания по проге, пишите, все учтем-с...

DeDok
выделение по блокам не поддерживает

стартует долго, выбрать script для шрифта невозможно, нет нескольких стандартных привычных хоткеев... плюс хотелось бы или автодополнение, или вставку стандартных ф-ций, как это сделано хотя бы и в EditPlus.

если и в самом деле есть желание, то можно все вышесказанное еще более конкретизировать, если же автора вообщем все устраивает, то не стоит и начинать.

T7
Если можно - подробнее.
Многое не ясно

Цитата:

выбрать script для шрифта невозможно

Цитата:

вставку стандартных ф-ций

какие хоткеи?

DeDok

Цитата:

Если можно - подробнее.

можно, если не в /dev/null :).

про script: стандартное окно выбора шрифта предполагает так же выбор и Script для оного: Baltic, Central European, Сyrillic, итд. в этом нет потрбености в русскоязычных Windows, видимо, однако в других случаях это очень актуально. к примеру -- в 98 SE я просто не смог увидеть русский текст, потмоу что Script'ом по умолчанию являлся Baltic.

вставка ф-ций: посмотри, как это сделанно в том же EditPlus, объяснять долго, проще один раз увидеть. вкратце -- щелчок по имени ф-ции в отдельном списке приводит к вставке в редактируемый текст заготовленный шаблон. скажем, я выбираю в списке table, щелкаю, а в документ вставляется, допустим,
Код: <table width="" border="">
</table>

T7
понял сенкс, в 1.1 версии все это будет.

А в целом, какое впечатление от редактора?

DeDok


Цитата:

понял сенкс, в 1.1 версии все это будет.

вот это я понимаю отношение разработчика к пользователю :). только imho вместо ф-ий лучше все-таки автодополнение: набрал tab, нажал Ctrl+Space, скажем, а мне все те же
Код: <table width="" border="">
</table>

Цитата:

только время запуска все-таки как-нибудь бы оптимизировать -- иногда и 20Mb, например, файлы открываются...

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

Цитата:

да, еще одна "вишня":

Тоже идея гуд. Таким макаром и компиляторы подключать с командной строки можно будет.

DeDok

Цитата:

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

кстати, да. должно помочь.

Цитата:

Тоже идея гуд. Таким макаром и компиляторы подключать с командной строки можно будет.

я к тому, отчасти, и клоню. было бы хорошо еще к этому сделать вывод результата работы отдельным окном.

Есть ли в jedit автодополнение, как в vim???