» Notepad++ (часть 2)

regist123

Цитата:

Цитата:
 Я за это время нашел ссылку на плагин Штирлица, он вполне решает задачу

Беру слова обратно. Штирлиц не решает задачу, потому что схема WIN->MAC не работает автоматически и соответственно не срабатывает в плагине.
Твой пример [more=не обрабатывается]
[Службы Файловых вирусов]
[Обычные вредные службы]
------------
также не обрабатывается и текст этого сообщения, если нажать редактировать и скопировать до конца твоего примера[/more]

Добавлено:
Gideon Vi
Попробовал выложенный тобой патч на своей русской экзешке.
(не написано что надо положить патч в директорию с экзешкой
В сведениях о патче написано создан DUP2 http://diablo2oo2.cjb.net)
Вроде работает в отношении MAC
Потом сравнил экзешки, чего делает:

ISO_8859-8 ISO-8859-8
заменено на пропуски NUL

x-mac-cyrillic xmaccyrillic
первая часть x-mac-cyrillic заменено на пропуски NUL

Ну и еще захватил какой-то один символ в начале файла.
--------
В принципе эти 2 замены легко сделать вручную с помощью того же Npp

Подкину-ка я еще живительной субстанции на лопасти этого вентилятора.

Откройте этот файл в сабже. Добейтесь того, чтобы файл отображался нормально. Кто добьется - просьба поделиться способом.

http://rghost.net/8GJ76sxMG

Update
В архиве 3 файла. UTF16LE, UTF16LE with BOM, pic.jpg.

Задача срачующимся участникам интеллигентной дискуссии...
Нет, господ срачующихся лучше не надо. Пусть они и дальше варятся в своем болоте дискутируют. А обычным гражданам, не лишенным чувства любопытства, задача следующая: открыть файл chineseUTF16LE.txt (без BOM) в сабже, чтобы сабж показал текст файла так как на картинке.

Да, файл специально содержит некорректные символы. Так задумано.

ItsJustMe

Цитата:

Добейтесь того, чтобы файл отображался нормально.

Ты имеешь ввиду чтобы отображалось как в блокноте?
Не [more=получается.]
Похоже блокнот вырезает "Нуль"-символы
Логика такая:
-------
Открой прогу XYplorer, вкладка внизу - Просмотр. Выбери там вручную свою кодировку.
Увидишь предупреждающее сообщение насчет Null-символов.
Потом сравни эту смесь китайского и то что видишь в блокноте.
Тексты будут равны.
Получается что действительно дело в этих Nul символах, которые Npp традиционно показывает.
-------
С другой стороны Npp должен показывать эти иероглифы рядом с нуль символами, чего-то здесь опять не так.[/more]

DmitryFedorov

Цитата:

Ты имеешь ввиду чтобы отображалось как в блокноте?

Да.

Цитата:

Блокнот вырезает "Нуль"-символы

Некорректные символы блокнот не вырезает, а заменяет на маааленькие прямоугольнички.


Цитата:

Этого не получится.

И я о том же. Блокнот может открыть этот файл, а сабж никак.

Предыдущий пост обновлен.

Добавлено:
Я таки провел то исследование "детектора", о котором говорил ранее. По результатам этого исследования и родился этот эксперимент с файлом UTF-16LE.

Цитата:

Задача срачующимся ..: открыть файл.. Так задумано.

Хочешь доказать степень невменяемости?! Жене сталь такое задание.

DmitryFedorov

Цитата:

Не буду все обсасывать но все что ты говорил до этого, мало того что само по себе не имеет логики, все это противоречит твоему новому аргументу.
И в итоге ты не доказываешь, не проясняешь свою позицию, а все время увиливаешь пытаясь оказаться правым.
Это не первый раз. Я усё помню.

Кратко о том коде: Он проверяет каждую букву текста на совпадение с несколькими символами на наличие некоторых. Кстати в той статье было описано хотя бы 500 символов, а в этом коде нет ограничения, наверно это неправильно файлы то могут быть большими. Я думаю эти символы часто-встречающиеся, как я и говорил. И когда символ совпадает то на счётчик кодировки добавляется очко (+1), итак, какая кодировка наберёт больше всего очков. Далее проверка какая набрала больше всех и она назначается как угаданная.

Цитата:

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

Допустим ты исключил 0-127, это не даёт преимущества в определении кодировки. Если бы кодировки были одинаковы в русском алфавите, то ты с большей вероятностью не определил бы кодировку по прочим символам, так как эти прочие символы отсутствовали бы в тексте. По поводу картинки - ты видел как выглядят другие кодировки в кодировке 1251, поэтому ты легко определяешь кодировку, иногда, особенно ту что с большинством PPP, ты визуально вместо частых гласных видишь частые заглавные буквы PPP, так что даже визуально тот же принцип.

Цитата:

ты без труда найдешь кодировку

там нет отсчета, нет координат. кодировка это таблица символов. Представь, что я загадал что 1=А, 5=В, 9=Г, потом даю тебе цифры 951 и говорю, что здесь написано? Потом я даю тебе расшифровку и ты понимаешь что понимается под этими цифрами. Проще пареной репы? А теперь посложнее, я даю тебе десяток разных расшифровок, какой ты воспользуешься? Каждая таблица вернёт тебе некое содержимое, какое будет очевидным? Да никакое, они имеют равную ценность. Предположим ты подставляешь разные расшифровки и какая то одна даёт тебе вменяемый текст. Вот момент где ты ошибся, потому что комп не может определить где вменяемый текст в отличии от тебя. Да можно было бы прогнать тексты по словарю, присутствует ли эта последовательность чтобы определить вменяемость текста. И опять же алгоритм определения кодировки содержащий словарь просто увеличил бы код N++ на несколько мегабайт. А учитывая все языки - несколько сотен мегабайт.

Жуть. После того как я проверил обнаружение кодировки Npp через XYplorer (там ну очень быстро можно просмотреть файл в любой кодировке и задать любую кодировку) я убедился что Npp вааще не фурычит для USC-2.
--------
Кроме того при просмотре в какой-то кодировке Npp, не всегда, но меняет файл (иконка становится красной) и требует сохранения.
-------
В общем теперь никакого доверия.

AZJIO2 Пойми - это просто мое [more=мнение.] Я мнение не поменял. Ты меня не убедил, я все внимательно прочитал. Я бы сделал по другому и всё бы работало. Ты не понимаешь простой вещи: какая бы ни была кодировка я ее всегда найду, найду по основному набору символов кирилицы. А уж какие там доп. символы тоже найду если они есть. А если их нет то будет обнаружена основная кодировка. Решение с кодировками одного и того же языка идиотское. Обусловлено оно не тупоумием а тем, что когда шло развитие, нашу страну не учитывали. К примеру даже сейчас покупаешь товар (не в России конечно), а там есть инструкция на каком-то болгарском, сербском, но не на русском. Или к примеру проверка орфографии - образец решения проблемы через жопу.
Решение с кодировками настолько дурное что даже программисты, пишущие спец программы не могут это охватить. Из-за этого тупого решения у нас не работают всякие вещи типа сортировки без учета регистра, и вообще этот идиотизм создал столько проблем что их не счесть.
Как правило такие решения маркетинговые. Для денег. Список ну очень большой.

добавил Если ты отслеживаешь действия нашей страны, то наверняка заметил что уже есть проект создания собственного программного обеспечения.
Когда отшлифуют систему, ты увидишь новые кодировки типа RU1, RU2, RU3 которые заменят идиотские OEM, ISO. В основе будет конечно нынешняя кодировка по умолчанию CP1251, потому что ее порядок повторен в UTF8 и далее UTF16...
Нашли что русский язык - значит cp1251, есть спец символы IBM для DOS, значит к примеру RU2. Нет спец символов осталась 1251 и так вплоть до MAC.
Или ты хочешь сказать мне что кодировку cp1251 сегодня трудно определить?!
[/more]

DmitryFedorov 16:48 15-03-2016
Цитата:

Беру слова обратно. Штирлиц не решает задачу, потому что схема WIN->MAC не работает автоматически и соответственно не срабатывает в плагине. Твой пример не обрабатывается [?]

DmitryFedorov 16:48 15-03-2016
Цитата:

также не обрабатывается и текст этого сообщения, если нажать редактировать и скопировать до конца твоего примера

Вообще-то в таком виде обрабатывается. Например выделить все текст, потом выбрать режим Turbo 5 - весь текст корректно исправило. Но это всё равно костыль.
Главная ведь проблема, когда начинаешь текст и не замечаешь, что он открыт в неправильной кодировке.

Добавлено:
ItsJustMe 17:30 15-03-2016
Цитата:

участникам интеллигентной дискуссии следующая: открыть файл chineseUTF16LE.txt (без BOM) в сабже, чтобы сабж показал текст файла так как на картинке.

Хоть и не участник спора, но ... не совсем как на картинке, но так не сойдёт?
http://i75.fastpic.ru/big/2016/0315/19/c9682e4b5fd8405cc27ea963ecba0119.png

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

Тогда при открытии нельзя будет сделать эту ремарку
Цитата:

Главная ведь проблема, когда начинаешь текст и не замечаешь, что он открыт в неправильной кодировке.

Только если убрать как в патче еще и автообнаружение ISO 8859-5, то что останется?
OEM 866 - не работает
Koi8-R - автообнаружение не работает, только вот проверил.
Не лучше ли пока снять галку. Ведь толку все равно нет. По крайней мере в локали, поддерживающей русский.

Может это только у нас так?
Надо ж столько лет делать и на тебе, всё хреново. Даже китайский, который ему как родной.

Добавлено:

Цитата:

Вообще-то в таком виде обрабатывается.

неа, неправильно обрабатывается.
Идет вместо цитата:
читата:

Цитата:

Из-за этого тупого решения у нас не работают всякие вещи типа сортировки без учета регистра.

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

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

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



Цитата:

Надо ж столько лет делать и на тебе, всё хреново. Даже китайский, который ему как родной

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

regist123

Цитата:

Хоть и не участник спора

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


Цитата:

не совсем как на картинке, но так не сойдёт?

Думаю, ты и сам видишь, что npp файл открыл некорректно. То, что видно на твоем скрине, это npp открыл UTF-16 как ANSI. Попробуй открыть файл UTF16 with BOM - их npp умеет открывать. А вот без BOM, если в файле есть некорректные символы, не умеет. А тот же Notepad их открывает без проблем.
Да, и проблема не в том, что npp не может своим мега-детектором определить кодировку файла при открытии, а в том, что такие файлы (UTF16 w/o BOM with incorrect chars) он не может открыть в принципе, что бы пользователь ни пытался сделать. Я, к примеру, пытался играться с меню Encoding, но так и не смог добиться, чтобы npp отобразил файл правильно. Поэтому и прошу свободных от дискуссии граждан тоже принять участие в эксперименте. Может, кто сможет открыть этот файл в сабже?

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

Daniyar91
Охота тебе каждый раз по носу получать?

Цитата:

например у меня работает сортировка без учета регистра.

Сортировка для русских символов в Npp не работает. Не работает она также и в плагине TextFX
Вот тебе пример сортировки на букву Д. Она учитывает регистр.
Дурак
Дурнее
Дурноватый
дурак
дурнее
дурноватый
Чтобы сортировка заработала, нужно специально прописать учет локали. Это возможно. Но автор об этом не знает. (Но например в УльтраЭдит это применяется: там так и пишется, что будет медленней. Я переводил эту прогу для себя и при случае могу и показать где.)

Цитата:

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

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

Цитата:

Одному такое делать нереально сложно

Если бы автор использовал стандартное решение он бы имел результат как в XYplorer или как "Блокноте". Автор об этом писал и написал что он применил свое "эвристическое" решение и извинялся заранее за то что оно не может дать 100 процентного результата. Справку надо читать. Языков автор знает несколько. Один из них китайский. И тем более странно что с ним неувязки.
-----------
Это ведь твои слова:

Цитата:

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

Может перестанешь меня терроризировать? Мне действительно не интересно твое мнение: еще ни разу оно не было конструктивным, подчерпнуть нечего. Ты меня что? как бесплатный источник информации используешь?
Пойми я ведь могу и не так мягко отвечать.


Добавлено:
ItsJustMe

Цитата:

И если пользуется, то почему? Я, например, им вообще не пользуюсь, ковыряю только из любопытства.

Я пользуюсь потому что привык и потому что когда пробовал другое мне не нравилось. Пытался заменить например УльтраЭдитом но не перешел.
Причины тяжело сформулировать.
Ну наверное главное потому что прога делает авто-резервирование. Мне не надо заботиться о том что файлы не сохранены.
Потому что открывает относительно большие файлы.
Потому что открывает их так что показывает символы 0-31, которые все остальные проги прячут. (хотя мне конечно не нравится жуткий мешающий чтению черный цвет)
Потом при случае есть плагины.
Поиск и замена очень удобны.
В итоге в этом редакторе я работаю быстрее и могу сделать то что в другом редакторе как-то не получается.

Добавлено:

Цитата:

Я, к примеру, пытался играться с меню Encoding, но так и не смог добиться, чтобы npp отобразил файл правильно.

Я вот не пойму почему ты считаешь что отображение в Блокноте абсолютно правильное?
Я конечно понимаю что там стоят иероглифы и ты хочешь их увидеть как и в блокноте.
Но это официальный, не специальный метод отображения.

А с позиции Npp надо показывать символы 0-31 когда они внутри есть.
Ну например ты открываешь какую-то экзешку. Там внутри куча Nul-символов, есть и иероглифы и что? Ты же не требуешь чтобы все эти 0-31 символы не учитывались при показе? Другое дело метка BOM - тут типа спец задание: давай отобрази меня плевать как получится, но так как написано в метке BOM, литералы не отображаются а иероглифы показываются.

Для достижения своей цели попробуй удалить вручную (по другому вроде никак) все эти промежуточные литерал-символы. Может тогда файл откроется как надо с иероглифами. Автоматически это наверное можно сделать в каком-то Hex-редакторе.

Кстати UltraEdit тоже этот файл не открывает. Там даже нет возможности принудительно указать что это мол файл UTF16LE. Есть только возможность задать ANSI кодировку.
С другой стороны если открыть этот же файл с меткой BOM - то файл откроется как надо, с иероглифами. Все как в Npp. Так что если Монстр делает как Npp, то это уже скорей не ошибка, а какое-то правило о котором мы не знаем.

ItsJustMe 07:42 16-03-2016
Цитата:

Думаю, ты и сам видишь, что npp файл открыл некорректно. То, что видно на твоем скрине, это npp открыл UTF-16 как ANSI. Попробуй открыть файл UTF16 with BOM - их npp умеет открывать. А вот без BOM, если в файле есть некорректные символы, не умеет. А тот же Notepad их открывает без проблем. Да, и проблема не в том, что npp не может своим мега-детектором определить кодировку файла при открытии, а в том, что такие файлы (UTF16 w/o BOM with incorrect chars) он не может открыть в принципе, что бы пользователь ни пытался сделать. Я, к примеру, пытался играться с меню Encoding, но так и не смог добиться, чтобы npp отобразил файл правильно. Поэтому и прошу свободных от дискуссии граждан тоже принять участие в эксперименте. Может, кто сможет открыть этот файл в сабже?

Не совсем понял, что нужно.

1) Npp не всегда правильно опознает кодировку - это факт с которым вроде все согласны.
2) В UTF8 with BOM в начале файла есть три байта, в UTF16 with BOM - два байта (этот самый БУМ) который указывает в какой кодировке файл, что позволяет правильно его открывать. С этим тоже вроде ни у кого возражений нет.
____________

3) На моём скрине указана не та кодировка, в которой он должен был открыть, но текст при этом вроде правильный. Разве не это была цель эксперимента?
4) Для восстановления текста воспользовался плагином Штирлица, который
а) Похоже заменил символы 0x00 (NUL) пробелами.
б) Попытался подобрать и исправить кодировку, то есть перекодировал текст в ANSI за счёт чего не смотря на то что он был открыт не в той кодировке текст вроде правильный. А также то что убрали NUL символы он стал более читабельный.

5) Сабжем пользуюсь, а для избежания указанных проблем постарался по возможности все текстовые файлы с которыми работаю перекодировать в UTF-8 с BOM

ItsJustMe
regist123
Я вроде нашел причину почему иероглифы не показываются без метки BOM.
В общем это правило такое, которое в Npp если и регулируется то через файл настроек вручную.
В UltraEdit оно сформулировано в галке настроек которую нужно включить. Звучит так:

Разрешить правку файлов в текстовом режиме с Hex Nul-символами без преобразования этих символов в пробелы.
Т.е. в Npp это правило просто всегда работает. Nul символы показываются и мы можем не только править файл не уродуя его путем преобразования, а даже править Nul-символы с помощью меню Правка - спец-Вставка.


Добавлено:
И это правило, кстати, одна из причин по которой я использую Npp.

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

И да, размещение символов в кодовой таблице, никак не мешате реализации не мение быстрого алгоритма сортировки без учета регистра. Мы всегда, за время O(1) можем определить что символ является буквой, какая буква сопостовляется этой (маленькой -> заглавная, и на оборот).

Напиши об этом автору Npp, а то он бедный и тупой никак не может сообразить что все так просто.
Твой любимый CudaText может сортировать только благодаря тому что его автор нашел в свое время решение, но ты ведь не спросишь его чего ему это стоило.

regist123

Цитата:

Не совсем понял, что нужно.

Попробую разъяснить.

Цитата:

Npp не всегда правильно опознает кодировку - это факт с которым вроде все согласны.

И я с этим согласен. Но я затевал эксперимент не для того, чтобы что-то доказать или опровергнуть. Не хочу участвовать в интеллигентной дискуссии.

Цитата:

В UTF8 with BOM в начале файла есть три байта, в UTF16 with BOM - два байта (этот самый БУМ) который указывает в какой кодировке файл, что позволяет правильно его открывать. С этим тоже вроде ни у кого возражений нет.

Нет возражений.

Цитата:

но текст при этом вроде правильный

В том-то и дело, что текст неправильный. Я специально приложил картинку с правильным.

Цитата:

Разве не это была цель эксперимента?

Нет, цель эксперимента - заставить сабж открыть этот файл в UTF-16LE.

Посмотри на это вот с какой стороны:
1. Открываем некоторый файл в сабже. Ну, например, тот же тестовый 1251.
2. Сабж определил кодировку неправильно, и мы это видим по неправильному тексту. Например, он определил ее как 1255, то есть иврит. Или как MAC. Ты и сам такое наблюдал.
3. Что мы делаем в таком случае? Меняем кодировку. Поменяли, и voila - файл отображается правильно. И да, если даже в нашем 1251 есть какие-то левые символы, то мы все равно сможем в сабже открыть его как 1251: в результате левые символы так и останутся левыми, а остальной текст отобразиться правильно.

То же самое я хочу проделать и с тестовым файлом в UTF-16LE. Ну, открыл сабж его неправильно - не велика беда. Переключаем кодировку и все. Но в том-то и дело, что я не смог этого сделать. Я не смог переключить кодировку на UTF-16LE.

И да, насчет левых символов в тестовом файле. Другие редакторы это не смущает, как видишь. Даже Notepad не смущает.

Отсюда цель эксперимента можно сформулировать примерно так:
Как для файла в UTF-16LE без BOM, открытого с неправильно определенной кодировкой, поменять кодировку на UTF-16LE. Мне интересно, можно ли это сделать (что, надо сказать, умеет большинство текстовых редакторов - подумаешь задача - переключить кодировку), или же сабж, как это ни удивительно, этого не умеет.

Или же можно сформулировать так: может ли сабж работать с файлами UTF-16LE, содержащими некорректные символы. Ну хорошо, если сабж такой пурист, что отказывается работать с такими файлами, то тоже не велика беда. Есть другие редакторы, не такие привередливые.

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

Отсюда, кстати, и вопрос про использование сабжа. Учитывая, что есть другие, более удобные (ИМХО!!!!) редакторы, пользуется ли кто сабжем.

Как это ни удивительно, один ответ уже есть. Жизнь полна сюрпризов.
Ой, два ответа. Ответ из одной строчки я сослепу сначала не заметил.

Update:
Млиииин! Я понял, в чем моя ошибка! Вас всех (а главное, тебя, как единственного, помогающего мне в этом эксперименте), смущают иероглифы в тестовом файле. Ну, согласен, неудачно я выбрал файл для данной аудитории.
Исправляюсь:
http://rghost.net/67JwKLG9P

Условия и цели эксперимента те же.

Да, и вот еще что. Нажатие на пункты меню Encoding\Convert... крашит сабж. Предположительно Convert to ANSI.

DmitryFedorov

Цитата:

Чтобы сортировка заработала, нужно специально прописать учет локали.

то есть создать алгоритм? а то если прописать куда-то что у меня русский было бы просто чтобы этим не воспользовался бы автор.


Цитата:

Напиши об этом автору Npp, а то он бедный и тупой никак не может сообразить что все так просто.
Твой любимый CudaText может сортировать только благодаря тому что его автор нашел в свое время решение, но ты ведь не спросишь его чего ему это стоило.

Алгоритм прост. Итак:
1. Таблица не по-порядку, значит надо для диапазона 128-255 сделать порядок сортировки, например:
1=а
2=А
3=б
4=Б
и т.д.
2. Нужно перекодировать текст в цифру, то есть заменить А на 1, и т.д.
3. Создать таблицу строка|числовой эквивалент
4. Сортировать таблицу по числовому эквиваленту перемещая строки в те же позиции.
5. В цикле сортированную колонку соединить в строку с разделителем "перенос строки" и выложить это в окно редактора.
Всё.

Замучился я тебя уже учить бесплатно

ItsJustMe
1. Если что мы не срачуемся, не мешай людям общаться и искать истину. Просто некоторым такая форма общения нравится по другому никак.
2. Твой файл я хотел потестить, но "rghost.net" у меня выдаёт "Error 451. Доступ запрещен." сначала спутал с "rghost.ru" работало же, а тут ".net", ладно полез в статьи обхода защиты, которую нонейм уже пол года предлагает, скачал "Tor Browser", не запустился, попробовал ещё пару вариантов, дистрибутивы нестандартные, не люблю не deb или rpm, а tar.xz, которые вручную пихать в "/opt" не доверенные проги. Да и время добивать у меня нет, и так на DmitryFedorov убил час, придётся в следующий выходной свои задумки осуществлять по работе.
.
Да N++ работает с бинарными файлами и можно их править, тот же блокнот сохранит без 0-31 символов и файл можно сразу на помойку, в общем смотреть можно сохранять нельзя. Сразу при открытии видно что файл содержит бинарные символы и знаешь что многие редакторы просто поломают этот файл, а программисты может специально, может не специально напихают эти символы 0-31 например для разделения блоков текста.
Так же под N++ у меня написано много скриптов и они работают и есть библиотека для непосредственного взаимодействия со scintilla. Создание собственного синтаксиса подсветки. В общем как я не пытался другие редакторы настроить стиль опробовать внешние скрипты, ни один даже рядом не валялся.

Подскажите в Notepad++ есть такая же плюшка как и в AkelPad - CodeFold, а именно просмотр и переключение между функциями, в отдельном окне. Удобно для кодинга

AZJIO2 16:50 16-03-2016
Цитата:

хотел потестить, но "rghost.net" у меня выдаёт "Error 451. Доступ запрещен."

http://www58.zippyshare.com/v/7zqIyK36/file.html
14:18 16-03-2016
Цитата:

Нажатие на пункты меню Encoding\Convert... крашит сабж. Предположительно Convert to ANSI.

У меня не крешит. Версия сабжа 6.9. В какой последовательности на кнопки жать?

А по кодировке действительно немного странно. Моя гипотеза: на каком-то спец. символе спотыкается и не может дальше корректно обработать документ (в данном случае сменить кодировку).

evgenium82
Для пробы скачай мой вариант сборки в шапке, чтобы сразу посмотреть все плагины: снипсет, nppExec и другие. Распакуй и запусти, это не собъёт твои настройки, так как он настроен на хранение настроек в своей папке.
Плагин называется FunctionList, хотя в Notepad++ уже встроен нативный модуль функций, но он пока не такой продвинутый как FunctionList. Справо появится список функций, клик по названию совершает прыжок к функции в тексте.

Добавлено:
ItsJustMe
На счёт неправильного файла. Вообще когда я пишу прогу и делаю парсинг кофига я делаю обход ситуации на дурака, когда пользователь нажмёт не ту кнопки в виндовом модуле, введёт неверные данные, не верно число символов или число полей. И когда начинаешь делать более качественную защиту от дурака находишь так много вариантов, что можно бесконечно делать пользователю подсказки о сделанных ошибках, попытаться распознать что он натворил и выдать ему наиболее точное решение, в какой то момент плюёшь на всё это дело и в общем всё работает. НО... зная алгоритм распознания или недостатки одного над другим можно просто соорудить такие файлы, которые для алгоритма является границей ошибки. Так что если ты даёшь именно сам заявляя что файл неправильный, и что какой то другой редактор у которого граница чуть шире в этом случае, а узким в другом, открыл этот файл, то это не честный показатель.

AZJIO2
Пробовал но никаких функций он не отображает, в настройках при попытке добавить правило вообще крашиться.

evgenium82
Там "Плагин -> Список функций". Плагин я перевёл на русский в папке плагинов есть его англоязычный оригинал DL_. Для многих языков там есть готовые настройки. Чтобы не крашился надо знать регулярные выражения. Я пользовался сборкой 4 года, сам настроил там распознавания функций AutoIt, также для новой версии встроенного модуля делал поиск функций AutoIt, всё везде работало всегда.
Если что я на работу, ответа не ждать, не задерживать дыхания....

AZJIO2
Спасибо за удочку,

AZJIO2Автор использует движок Scintilla. А ты хочешь мне втулить что он заново пишет каждый вдох и выдох. Это ты у нас типа "программист", но какой-то странный - учить могу, а сделать нет. Доступ к коду свободный, но вместо того чтобы открыть этот бесплатный учебник, ты умствуешь. Автор с твоих слов - первоклашка, который ничего не знает.
Чего ты аппелируешь ко мне? Напиши автору, если сам не можешь. Чего строишь из себя профессора?
------
И похоже ItsJustMe прав. Срачкисты вы! Цель обосрать: как два хулигана в подворотне (ты знаешь кто второй): нашли жертву и молотите без причины по очереди. Я одному ответил. Второй взял выдержку из моего ответа и давай заново. Отстань. Тебе уже и люди об этом написали.


Добавлено:
Если хочешь чтоб я тебя зауважал как человека умеющего работать с кодом - доведи свои проги до состояния при котором они будут показывать русский язык в системе без костылей подмены кодовых страниц. А то сапожник без сапог. Про неверное обнаружение кодировки пишем, а у себя черт знает что творится.

Добавлено:
ItsJustMe
Я понял что ты делаешь. Ты берешь текст. Вставляешь в Npp. Сохраняешь как USC-2 LE BOM. Потом вырезаешь символы BOM вручную, сохраняешь и затем пробуешь открыть полученное в Npp так, чтобы был виден текст, нажимая Просмотр в кодировке USC-2 LE BOM.

Заметь что если ты после этого "Просмотра" в Npp нажмешь "сохранить" - файл увеличится в два раза. Т.е. Npp попытается сохранить в кодировке USC-2 LE BOM то что находится на экране. А там другие символы и их сохранение занимает больше места.

Правильно описал проблему?
Я именно так делал как написал и получил файл такой же как у тебя.

Добавлено:
ItsJustMe Попробуй в этом случае создать файл с содержанием типа ААААА.
Эффект будет тот же. Но не будет ни одного символа для чтения при открытии в Npp.
Будет строка из литер обозначенных как (разделил пробелом чтоб было видно)
DLE EOT DLE EOT DLE EOT DLE EOT

AZJIO2 17:30 16-03-2016
Цитата:

Плагин называется FunctionList

Интересно, а почему его нет в списке через менеджер плагинов? И по ссылке указанной в справке о плагине вместо него предлагает скачать HTMLTag_plugin_v0.50_unicode

17:52 16-03-2016
Цитата:

Для многих языков там есть готовые настройки. Чтобы не крашился надо знать регулярные выражения.

Скачал твою сборку, открываю настройки плагига, жму добавить новоё правило - сразу после нажатия на кнопку Npp крешится. Так что до написания регулярок дело дойти не успевает. Одинаково падает и русская и англ. версия плагина. Хотел проверить, может есть более стабильная новая версия, но не нашёл, где скачать.

regist123
Скачай мой. Он более новый (чем тот который закачивается через PluginManager). После него Npp не висит. Я его получается переводил. Но отложил в список ненадежных. Почему забыл. Ссылка

Добавлено:
Может потому что написано что он (FunctionList) для версии Npp 5.5, но навряд ли.
Судя по переводу это не моя работа.
Да он также убивает Npp как ты говорил. Значит надо найти его последнюю версию. Plugin manager этого не делает. Это вообще вещь которая отправляет неизвестно куда.

regist123

Цитата:

У меня не крешит. Версия сабжа 6.9. В какой последовательности на кнопки жать?

Попробуй следующую последовательность:
1. Открываешь файл UTF-16LE w/o BOM, который сабж открыть не могет.
2. Жмешь Encoding\Encode in UCS-2 LE BOM.
3. Жмешь Encoding\Convert to ANSI.

Новый файл с русским текстом получилось правильно отобразить в сабже?

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

ItsJustMe 23:31 16-03-2016
Цитата:

Попробуй следующую последовательность:

Попробовал, не падает. Правда сабж у меня с русским фейсом, но врядли это имеет значение.

Цитата:

Новый файл с русским текстом получилось правильно отобразить в сабже?

Нет
regist123 17:26 16-03-2016
Цитата:

А по кодировке действительно немного странно. Моя гипотеза: на каком-то спец. символе спотыкается и не может дальше корректно обработать документ (в данном случае сменить кодировку).

regist123

Цитата:

Попробовал, не падает.

Не падает - и ладно. Одним его грехом из 1000 стало меньше. Теперь их у него 999. Достижение!


Цитата:

А по кодировке действительно немного странно. Моя гипотеза: на каком-то спец. символе спотыкается и не может дальше корректно обработать документ (в данном случае сменить кодировку).

Нет. Это у него дизайн такой. Так задумано. Он в принципе не может открыть UTF-16LE (и тем более UTF16BE) файл без BOM. Я уже написал, что файл UTF-16 может быть абсолютно валидным, без каких-либо некорректных символов - сабж его все равно открыть не сможет. Он может открывать только UTF-16 w/o BOM файлы, содержащие только английский текст.
ИМХА-имхее-некуда

Но это еще не самое замечательное. Самое замечательное в его дизайне это то, что текст файла он хранит в памяти как есть, не преобразовывая в Unicode. Для любого другого мало-мальски грамотно сделанного редактора кодировка файла имеет значение только во время операций чтения из файла и записи в файл: открыл файл, прочитал данные, зная кодировку файла преобразовал прочитанные данные в Unicode текст, дальше просто работаем с текстом. Во время работы с текстом нам уже без разницы, какая кодировка была у прочитанного файла. Надо записать текст в файл: пишем текст в указанной юзером кодировке. Эта кодировка никак не связана с той, которая использовалась для открытия файла - она может быть такой же, а может быть другой.
Сабж же, работая с данными, не преобразовывая их в Unicode текст, имеет весь тот геморрой, который имеет. И юзер сабжа имеет геморрой. И это не говоря о его многочисленных падениях, щедро экранированных try-catch. Мы тут падаем - не страшно, юзер-то этого все равно не видит.

Вот такой вот это зверек. Завязываю я, похоже, с ним возиться - ему никакие заплатки не помогут уже.