» SynWrite Editor

Значит сессия скипается при наличии пар. комстроки, логично это

Не всегда распознаёт вложенные блочные комментарии, например такой текст в c-файле будет подсвечен неправильно:

Код:
/*
void func(uint32_t var)
{
uint32_t var2; /* comment */
var2=var;
}
*/

>>Не всегда распознаёт вложенные блочные комментарии
Что бы это значило
Оно и не должно в С подсвечиваться, посмотрите regex парсера для коментов. Он и не может поймать такой комент.


Кстати, сделал аннонс НОВОГО редактора. См мой форум Synwrite. Пока есть альфа с маллым числом настроек. Где-то штук 20.

CudaText
Может создам тему на руборд
Редактор пока есть под Win32, Linux x64 gtk2

Alextpp
А с SynWrite какие планы?

Может кто еще не знает, вот тема про новый редактор.

Цитата:

Оно и не должно в С подсвечиваться, посмотрите regex парсера для коментов. Он и не может поймать такой комент.

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

Alextpp
Попробовал прогу. Мог бы быть чудесный редактор, вначале именно это ощущение.
Но буквально через 5 минут видишь что прога тормозит даже на файлах размером 2 МБ.
-----------
Сделана она не вчера. Веры в то, что после таких наворотов она "заработает" без тормозов нет. Так что очень, очень жаль. И понятно после этого почему прога не вытеснила Npp.

Хотя я бы на месте автора отключил бы все что тормозит. Снабдил это все предупреждениями и доработал до состояния после которого это ВСЁ можно использовать.
И дал бы проге вторую жизнь вместо создания прог типа КудаТекст.

(у меня вообще-то подозрение что прога более или менее станет работать после отключения "проверки правописания" вернее сказать проверки орфографии. В notepad++ эта фича сделана как плагин, который можно отключить, хотя он вообще не напрягает прогу)
---------
Пока придется использовать программулину как удобный вариант для очень малых файлов.

ну я согласен что файлы 2Мб могут тормозить, скроллится неплавно, и тп. Но файлы до 100-200К нормально

CudaText == мой движок.
Synwrite = чужой медленный движок


Сделать движок Сина быстрым НЕЛЬЗЯ
так что вот

Тогда надо хотя бы CudaText делать по принципу автомата Калашникова.
Т.е. проверять на таком старом компе чтобы и не мучиться над вопросом, а как работает прога? Чтобы ответ был - идеально.
И чтобы навороты проверялись.
Сначала - ничего что касается программных дел. Лишь редактор текста. Но чтоб по полной - и тебе кодировка, и тебе локализация (хотя бы одна).
И потихоньку все чего есть в Npp, плюс собственное (это сортировка, которая в Npp только с учетом регистра)
И когда это все заработает с проверкой орфографии быстро и как надо. Тогда привинтить лексеры.
-------
Почему автомат Калашникова ценят? А работает он всегда. При любых обстоятельствах.
Надо чтоб прога не жрала память, быстро закрывалась. Грузила процессор кратко и не висла.
-------
КудаТекст - некудышное название. Попробуйте Блокнот. И по русски понятно, и по английски. И проги такой нет (у них это слово как бы вымерло).
------
Из того что есть в Npp и чего нет у вас - это авто бэкап или "делать копии несохраненных вкладок при их изменении"
Горячо рекомендую сделать в самом начале и не напороться на косяк который там длился больше года: т.е. чтобы документы не портились при замене и других действиях выполняемых в момент авто-сохранения.

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

>>для проверки орфографии у вас нечитаемый файл. С нестандартно большим числом статей

не понял, о чем это.
У меня движок Addict spell check

Добавлено:
насчет Cuda все не так. у меня свое "видение".
не сначала проверку орфографии а ПОТОМ.
не сначала локализацию а вообще не надо. может через год.
скорость проверять надо.
я это делаю.

есть недоделка. длинная строчка 10К символов все портит ..

Цитата:

CudaText == мой движок.
Synwrite = чужой медленный движок

Я по простецки проверил насколько быстр CudaText
файл 2млн строк 56МБ
Npp первое открытие - 5сек
CudaText 45сек и потом (уже после открытия) 2мин грузит процессор.
------------
не такой уж и быстрый этот движок. Стоит ли на него тратиться?


Добавлено:

Цитата:

>>для проверки орфографии у вас нечитаемый файл. С нестандартно большим числом статей
 
не понял, о чем это.
У меня движок Addict spell check

Я о файле ..\SynWrite\Dictionaries\russian.adm
Он не читаемый.
Движок в Npp - Hunspell (по памяти) и к нему прилагаются файлы словаря. И они читаемы.

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

Добавлено:

Цитата:

скорость проверять надо.
я это делаю.
 
есть недоделка. длинная строчка 10К символов все портит ..

В файле который я создал для проверки нет длинных строчек. Все они не больше 200 символов.
Это просто несколько копий файла словаря для проверки орфорграфии, объединенные в один файл.

Добавлено:
И притом еще память. Явная утечка памяти. Объем памяти растет на глазах. Через 2 мин это уже по 450Мб виртуальной и физической памяти. С одним файлом размером 56Мб!!
(ну это вы найдете конечно, и всё таки: правильное видение растет отсюда)

Про "нечитаемый" spell chk
http://synwrite.sourceforge.net/forums/viewtopic.php?f=6&t=1338&hilit=Hunspell

Я не имел ввиду ошибку проги (в результате чего нет проверки орфорграфии в SynWrite), говоря про нечитаемый файл словаря. Я имел ввиду что словарь невозможно править и читать глазами, что это нехорошо и неправильно, не более.
Я понял, что в КудаТекст будет Hunspell и все возможно встанет на свое место.
(Менять в глобальных настройка компа Region -> Format, чтобы проверить как работает орфография в SynWrite не собираюсь.)


Добавлено:
Кстати раз уж и ваш движок не такой быстрый как надо, может стоит обратиться к тому движку от которого растут ноги у Npp?
Код у Npp открытый, отработанный, его можно использовать.
Если вы переделаете или используете часть кода никто вам слова не скажет. Но возможно появится наконец прога в которой есть то чего нет Npp и в то же время без недостатков ваших движков.
Заманчиво было бы иметь такую прогу.


Лицензия у NPP такая:
Эта программа является свободным программным обеспечением; Вы можете распространять и (или) изменять её на условиях либо GNU General Public License, опубликованной фондом свободного программного обеспечения, либо на условиях второй версии лицензии, либо (по вашему выбору) любой более поздней версии.

Эта программа распространяется в надежде, что она будет полезной, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; даже без подразумеваемых о ТОВАРНОСТИ или ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ. Смотрите GNU General Public License для более подробной информации.

Вместе с программой вы должны получить копию GNU General Public License; Если нет, то пишите в фонд свободного программного обеспечения: Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

хотите писать на движке NPP. Пишите.

не ко мне

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

Протестировал 5 редакторов, тест был такой -- открыл файл с 689'400 строк, нажал CTRL+A, подождал пока редактор выделит весь текст, и нажал TAB, подождал пока редактор добавит отступ для всего текста. И вот результаты Первая колонка - название редактора, вторая - время за которое редактор выделил текст, третья - за сколько редактор сдвинул текст.

Там где стоит >4, это означает что редактор не успел сдвинуть текст за 4 минуты, я и его закрыл с помощью диспетчера задач, отдельно надо сказать про VS Code - через несколько секунд после нажатия TAB, редактор "спросил" -- "что-то долго выполняется операция, отменить ее?" я нажил , продолжить, а через 4 минуты, просто выбрал в меню выход, т.е. редактор всегда реагировал на мои действия а не завис, как остальные.

Код: CudaText | 0 | 31 сек.
SciTE | 2 сек. | 53 сек.
Visual Studio Code | 0 | >4 мин.
ST3 | 0 | >4 мин.
NPP | 2 сек. | >4 мин.

Daniyar91

Цитата:

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

Во-первых каюсь: до меня не дошло полностью, что движок CudaText свой и автор может его переписать как он хочет.

Далее: Я говорил о скорости движка. А это в первую очередь открытие файла.
Действие которое вы предложили весьма нестандартное.
У меня на него Npp действительно реагировал раза в два дольше. Правда я открыл все тот же файл в два млн. коротких строк.

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

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

Это время должно составлять десятые, сотые доли секунды. А у CudaText - это целая секунда.
Здесь он явно проигрывает Npp, где я глазами просто не вижу тормозов на том же файле.

Далее идет время сохранения изменений.

Notepad++__Открытие-3-5сек._Ввод символа_0сек_Сохранение_2-4сек_
CudaText___Открытие-40сек.__Ввод символа_1сек_Сохранение_10-12сек_

Далее идет расход памяти. С каждым открытием CudaText набирает и набирает памяти.
К примеру после трех открытий и закрытий файла он у меня ест без единого файла 430 МБ оперативы и 650МБ выделенной виртуальной памяти.

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

Пока всё очень и очень плохо.

Добавлено:
Идеалом по всем показателям является наверно УльтраЭдит. Она и жрет мало, и открывает очень большие файлы и конечно никаких задержек при печати.
Код вроде никогда не светили, но принцип движка там по сравнению с Npp другой абсолютно. Это обсуждалось в Инете. Так что самое лучшее - это подумать о правильном принципе, который кстати используется не только в УльтраЭдит, а в любой проге которая может редактировать текст в районе гигабайта.

Часто ли приходится править такие большие файлы? лично мне нет.

Цитата:

Далее идет расход памяти. С каждым открытием CudaText набирает и набирает памяти.
К примеру после трех открытий и закрытий файла он у меня ест без единого файла 430 МБ оперативы

СudaText еще даже не бета-версия, так что, это нормально...

Думаю, не нужно больше здесь писать про NPP и CudaText, т.к. эта тема про другой редактор.

upd:
Мне нравится SynWrite, тем что в нем много всяких фичь, чтобы кодить, но самое главное это очень удобное создание собственных лексеров.

Daniyar91
Мне тоже понравился SynWrite. Всё чего надо есть. Но некрасиво его иметь лишь как редактор небольших файлов кода.
Я за то чтобы он заменил Npp, но раз в SynWrite проблема с движком, так уж путь новый движок будет нормальным. Потом это обрастет чем надо и будет конфетка.

Тогда будут пользователи и приемники. А так это работа одного энтузиаста. Когда-нить ему надоест и прога умрет.


Цитата:

Часто ли приходится править такие большие файлы? лично мне нет.

Такая постановка вопроса неверна. Большие файлы я открываю конечно. Но их размер нужен лишь для того чтобы наладить движок. Он должен эти файлы обрабатывать. Тогда и с наворотами есть шанс что прога будет работать.
Сейчас я например не очень уверен что дело лишь в движке. Ведь к проге присобачены лексеры. И размер их не мал: full.lxl - это файл на пределе возможностей самой проги, почти два МБ.
А что если всё замедление идет отсюда?

Цитата:

Думаю, не нужно больше здесь писать про NPP и CudaText, т.к. эта тема про другой редактор.

Думаю что тема CudaText открыта слишком рано. Когда будут пользователи этой проги - тогда темой можно начать пользоваться.
А пока прогой пользоваться нельзя чего туда писать то? Для того чтобы не получить ответа? Не логично.

NPP медленней, и ультраедит тоже медленный, при открытии того файла, стоял лексер Text, отключаю лексер, и текст сдвигается за 14 сек. а в ультроедит за 17.

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

Файл на котором я тестировал редакторы - json, но с расширение txt. когда я в Cuda выбрал соответствующий лексер, то он конечно замедлился, но работать можно было, а NPP и ультроедит вообще не вывозят.

Так что думаю, твои выводы, были поспешны.

Значит мой ДВИЖОК на уровне.
Сцинтилла NPP уже чего-то хуже
Уже есть то что лучше, а ЕЩЕ КАРЕТКИ

Alextpp
Наверное в лексере Text files, нужно убрать расширение txt, чтобы при открытии TXT-файлов, не было выбрано лексеров, и скорость редактирования больших файлов будет нормальной, а кому нужно сворачивание абзацев - пусть руками лексер выбирают.

Alextpp
Я уверен похвальба тут ни к чему.
Движок надо блюсти а в критике искать то, что улучшит прогу.
------------
Допустим движок лучше и я просто не могу этого увидеть.
Значит проблема в том чтобы не "опустить" достоинства движка до такого уровня чтобы я ждал секунду прежде чем напечатаю следующую букву. А это пока факт.

Daniyar91

Цитата:

Так что думаю, твои выводы, были поспешны.

Мои выводы логичны. И все они верные.
Первый - лексеры грузят.
Второй - проверять надо редактирование. Проверил - доложил. результат 1 секунда вместо 0 секунд. (И т.п. Как отключить Лексер я не нашел. Вроде как этого нет в КудаТекст).
Третье - хоть так хоть эдак печать должна быть без задержки (т.е. этого нигде нет), открытие должно быть тоже быстрое.
Да и видение мое развития проги подтвердилось. Не было бы лексеров возможно не о чем было бы говорить.
Т.е. сначала должен быть редактор а потом всё остальное.
----------
Я прекрасно понимаю сколько работы у автора проги, и то надо и это. Глаз замылен, внимание идет на мелочи от них многое зависит. Вокруг куча идиотов которые как по нотам разыгрывают басню "слон живописец".

Автору желаю поменьше слушать тех кто хвалит и помнить что опереться можно лишь на то что сопротивляется.

Цитата:

Проверил - доложил. результат 1 секунда вместо 0 секунд.

А если в NPP выбрать лексер то вообще не сможешь редактировать... я не говорю что Cuda такой неибический редактор, я говорю что не хуже других.

Цитата:

Как отключить Лексер я не нашел.

Там где выбираешь лексер, в самом верху списка будет пункт (none), а чтобы выбрать лексер, надо щелкнуть мышкой в строке состояния, по названию текущего лексера (четвертая часть строки состояния; 1-я -- строки\колонки, 2-я -- кодировка, 3-я -- тип конца строки, 4-я -- текущий лекскер).

Цитата:

А если в NPP выбрать лексер то вообще не сможешь редактировать...

Сначала сменил в Npp язык Normal text file на Ini. Прога подумала 13 секунд и файл ожил.
Ввод символа и ввод новой строки без задержки.
Сменил на Xml - прога застыла намертво.
-----(обновил текст в этой секции)
Сменил на том же файле в CudaText язык Текст на None
Ввод символа - без задержки
Ввод новой строки - с задержкой в четверть секунды.
Эта четверть секунды только выглядит как мелочь.
На деле обычный ввод текста (с Enter в конце ввода) в Npp зависит получается только от скорости моей печати.
А в CudaText, если я например делаю 10 Enter-ов и затем ввожу два-три символа (чтобы увидеть потом что операция выполнена) - это длится аж 15 секунд.
Т.е. подряд вводить Enter - еще хуже, результат: почти 1.5 секунды на Enter.
-----
И заметь очень долгое открытие (плюс к тому очень долгое сохранение). И как заставить открывать текстовый формат быстро или без выбора синтаксиса языка, т.е. без Лексера - это может сделать только автор. Тут у него еще много работы. Потому что авто-сохранение (после того как оно работает в Npp) - вынужденная необходимость.


Возможно автор подумает и сделает правила открытия файлов.
Например можно открывать все файлы сначала как бы без Лексера, а потом в зависимости от времени открытия такого файла подключать обработанный паралельно кэш переработки такого файла в нужном лексере. Может даже чего изобретет. Т.е. наложит одно на другое.
------
В любом случае если автор хочет с самого начала использовать лексеры ему придется дорабатывать эту фичу.
А это большой труд. И без обратной связи и жалоб на то и это сделать такую работу очень сложно.
Насколько было бы легче, если бы был сначала доработан Редактор со всеми его фичами (там не так много уж и сложностей, которые могут тормознуть редактор)
И уже потом навернуть поверх подсветку синтаксиса, используя своих пользователей для облегчения доводки проги.
Т.е. была бы поддержка, была бы вера что это будет самая лучшая прога. Был бы энтузиазм.

Добавлено:
Мое следующее предположение. Если автор уберет утечку памяти и уменьшит нагрузку на процессор (время в течение которого прога грузит процессор после появления текста в ней), прога станет работать при прочих равных намного быстрее.
Так уже было, с прогой Radialix. Авторы убрали огрех и всё затикало (у них было немного по другому - прога всё время грузила процессор).
Кстати это было единственный случай, когда эти ребята не стали возражать и просто на следующий день нашли ошибку.
Жалко что их теперь нет с нами. Талантливые были.

>В любом случае если автор хочет с самого начала использовать лексеры придется дорабатывать эту фичу.

хватить флудить!
Ничего я добабатывать эту фичу не буду. не понял что тут дорабатывать. лексеры я и так уже пользую.

я создал тему Cuda.
но лучше туда не писать флуд.

утечку поправил

Alextpp

Цитата:

хватить флудить!
Ничего я добабатывать эту фичу не буду. не понял что тут дорабатывать. лексеры я и так уже пользую.

Блин. Чего ж тут непонятного?
Движок надо дорабатывать, чтобы прога работала.
Факты на тарелочке кладут. Задержка там при больших файлах, которой нету в других прогах.
Следовательно если сейчас не сделать (пока не наворочено) никогда не найдешь.

Как показал малюсенький опыт отключение Лексеров дает возможность увидеть где происходит кака. Т.е. это был деловой разбор по мере наших скромных возможностей, но никак не флуд. Подключение же Лексеров делает прогу вообще неработоспособной. Значит и в них что-то не так. Хотя сделаны они вроде лушче всего того что я видел на эту тему.

То что вы автор этой проги не дает вам право устраивать истерику. Достоинства вашей проги уже оценили. Об этом речи нет, никто их не оспаривает, и даже больше хотят видеть прогу на почетном первом месте.

Но с такими стартовыми глюками это невозможно. В тему Cuda писать нет смысла. Проги еще нет как таковой. Болванка. И как только она эта болванка покажет что может стать крутой прогой я сам приглашу в эту тему всех кого можно.

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

Добавлено:
Перешел по CudaText в созданную вами ветку. Будем там судя по всему пока вдвоем. Утечку проверил. Вроде увидел откуда ноги растут у остального. Читайте в ветке Cuda.

Такое объявление.
Прога заморожена на какое-то время

Причина написана тут - оффорум, тема "Delphi XE8 license needed"
(лень ссылку искать)
Наверное, это не надолго, или может надолго
Наверное, месяцев на н

Посмотрим

Сабж умеет конвертировать Escape-коды вида \u0020 в текст и обратно? Может не сам, а сторонним плагином/скриптом к нему?

часто нужны такие коды?

Стоит ли писать планин, если да, я попробую. где используется? где примеры?

Если плагина нет, то, наверное, не стоит, обойдусь Akelpad-ом. А пример - вот, хотя бы...

В js-скриптах довольно часто применяют это преобразование.