Rock_maniak_forever wrote:Стандартный в CP866 (созданный в Windows).

Хм... для Виндовс родной является кодировка 1251.

Mario wrote:

popovpa wrote:Должен ли работать CapsLock? То-есть нажимаю пошли прописные буквы. Через Shift работает.

CapsLock не поддержан на системном уровне (т.е. в драйвере клавиатуры) в приложении также не реализовано.

С ревизии 2171 поведение CAPS LOCK для режима ASCII кодов стало как в нормальных системах, т.е. при включенном CAPS LOCK генерируются заглавные буквы, если нажать еще и SHIFT, то маленькие. Во всех программах вроде работает нормально, по крайней мере в KEYASCII и использующих EditBox. Исключением является Tinypad - который каким-то образом игнорирует. Надо разбираться с кодом Tinypad.

UPD Проблема в том что Тинипад использует не ASCII коды, а режим сканкодов. Придется сделать реализацию CAPS LOCK в программе отдельно.

С ревизии 2172 в Tinypad правильно обрабатывается CAPS LOCK для вводимых символов.

З.Ы. КАПСИТЕ на здоровье!

Спасибо огромное!

Ужасно не удобно, что не работает Ctrl+End.

Leency wrote:Ужасно не удобно, что не работает Ctrl+End.

Есть альтернатива в виде:
Ctrl + PageUP в начало документа
Ctrl + PageDown в конец документа
а собственно Home и End использованы для:
Ctrl + Home в начало текущей страницы
Ctrl + End в конец текущей страницы

Вопрос отпал. В свежей SVN, того бага не наблюдается.

Добавил потсветку, для файлов с расширением .mac (SVN 2103).

В Тинипаде жутко не хватает возврата назад (истории изменений), обычно (в редакторах других ОС) вызываемой по хоткею Ctrl+Z.
Меня интересует реализация. В целом я конечно понимаю как приблизительно это работает, но меня смущает то как при удалении сохраняется набранный текст. Ведь мало просто повторить взад все выполненные действия, если это было добавление места или текста то удалить, чтобы вернуть взад, всегда можно, а вот родить обратно текст который был невозможно (ну, нету его уже физически в структуре). Следовательно я так думаю что создаются какие-то контрольные точки с измененным или удаленным куском и из него оно восстанавливается. Причем создается вероятно какой-то кольцевой буфер или что-то подобное с логической точки зрения или просто ссылка на адрес выделенной под это дело области памяти. Однако выделять ради пары символов страницу в 4 Кб крайне неэффективно и думается мне просто область для истории прирастает и убывает. Получается все-же кольцевой буфер.

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

в vim-e реализован просто буфер истории измененений. Удалил блок текста - он сохраняется там. Буфер реализован в виде стека.

Статьи по теме.
http://habrahabr.ru/company/devexpress/blog/104163/
http://habrahabr.ru/company/devexpress/blog/104167/

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

SoUrcerer
Спасибо. Статьи вероятно были бы полезны, если бы я писал на яву, но мне как ассемблерщику материал из них сложно из них употребить -слишком они в описании на специфику ЯВУ упирают.

Mario
Даже если ты скушаешь мегабайт лишней памяти этого никто не заметит.

Сергей - с такими рассуждениями можно ядро начинать на C# писать.
Я ассемблерщик или кто?

Вот после таких допущений нас как раз легко обвинить, что никаких преимуществ написание на ассемблере не дает. Там мегабайт прирастили, здесь еще один забыли, кап-кап-кап...

http://en.wikiquote.org/wiki/Talk:Bill_Gates

640K ought to be enough for anybody

philpirj@habr: каждый раз, когда ты пишешь int i вместо short i, сотни пользователей вынуждены докупать планку памяти

Mario, там главное не код, а ход мыслей.