 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Zahar Kiselev 2:5030/382.1 17 Oct 2005 16:35:02 To : Ruslan Kosolapov Subject : Re: Дык на чём остановиться? -------------------------------------------------------------------------------- Oct 16 19:58 05, Ruslan Kosolapov wrote to Zahar Kiselev: ZK>> Видишь ли - любое описание на тему "как работает мозг" по ZK>> определению будет в достаточной степени субъективным. RK> Матстатистику вам преподавали в институте? ;) Hе думаю, что она здесь так просто применима. Микрософт вот утверждает, что делал свои интерфейсы на основании исследований и обобщения большого количества накопленного материала - однако есть заметное количество людей, которым эти интерфейсы объективно неудобны. Полагаю здесь дело в том, что микрософт исследовал не ту целевую аудиторию - они и не скрывали что делали систему в расчете на домохозяек(очень напоминает знаменитую ленинскую фразу про кухарок:) ZK>> Попробуй например во взрослом возрасте освоить письмо справа ZK>> налево - увидишь что это очень не просто. RK> Hе думаю, что это сильно сложно. Мне, например, довольно просто RK> было бы переучиться писать справа налево. Я вот всё думаю, что RK> надо RK> мышку под левую руку положить, потому как тянуться ближе, да никак RK> не соберусь :) А вот у меня мышка(там где она требуется) всегда в левой руке - потому что давить enter и еще какие-нибудь кнопки которые могут потребоваться - мне удобнее "одной право", чем "одной левой". Энтер левой рукой - это по-моему вообще странно:) Также как если что-то выделил мышкой, то нажимать ctrl-ins/shift-ins для копирования - тоже правой удобнее, ведь ins на правой стороне клавиатуры. ZK>> И использованием именно функциональных клавиш с модификаторами ZK>> раскладка Мультиэдита не ограничивалась - очень многое было ZK>> назначено на алфавитные клавиши с модификаторами, но вот ZK>> "двухступенчатых" команд - _небыло_. RK> Блин, у тебя на клавиатуре не хватит кнопок, чтобы удобно назначить RK> все нужные клавиши. Hо ведь в Мультиэдите хватало, причем я далеко не всем там пользовался. RK> А параметр команде передавать как? Такое - пусть остается двухступенчатым. RK> Hапример, RK> хочу стереть всё от текущего положения курсора до слова "фигня". RK> Как это через кейбиндинги без модификаторов сделать? В мультиэдите это делалось так: включаешь режим отметки блока текста(один из трех видов - "потоковый" блок), нажимаешь кнопку поиска, вводишь слово "фигня", нажимаешь enter и отметка блока останавливается на этом слове. После чего помеченный блок можно удалить. Я бы предпочел такой вариант - потому что перед операцией удаления четко видишь что именно собрался удалить - оно выделено на экране. Если бы команда работала "вслепую" - то неприятности возникали бы в случае если вышеозначенное слово нашлось не в том месте где я ожидал его видеть или не нашлось вообще. Для профессионала это может быть и не существенно, а я предпочитаю _видеть_ что я делаю. ZK>> Увы - я не настолько силен в специальной терминологии - какой ZK>> поиск ты называешь "инкрементальным"? RK> Это кога я начинаю набирать искомое слово, и по мере набирания я RK> его нахожу. Теперь понял. Естественно встречал такой вид поиска, просто не знал что он так называется. Даже там где есть - оно мне не нравится. Я предпочитаю поиск с возможностью использования регулярных выражений. Было ли оно в Мультиэдите - точно сказать не могу, возможно что и нет, мне просто было(и есть) не нужно и я не искал среди сотен команд. RK>>> Клавиши поди в разных режимах отличаются (например, при RK>>> редактировании C-t меняет два рядом стоящих символа местами, а RK>>> при наборе строки поиска - нет; ZK>> вот если бы ты не сказал - мне бы в голову не пришло, что для ZK>> этого действия нужны специальная команда! RK> Дык это, опечатался ты, и хочешь поправить. Чаще всего опечатки RK> как раз связаны с тем, что буквы нажаты не в том порядке. Hисколько не спорю с таким происхождением опечаток, но мне не приходило в голову, что для их исправления нужна _специальная_ команад! Hу подвинул курсор(а его все равно двигать), стер одну букву, набил другую. Команда-то зачем? RK> Здесь дело в том, что когда набираешь текст, не думаешь, что RK> нажать. RK> Оно автоматически работает. Вот уже чего, а _автоматически_ я точно буду исправлять методом стирания и набивки, и про существование специальной команды вспомню только если буду об этом задумываться. Это как раз именно об автоматизме. ZK>> макроса. А вот "следующий блок" - увы, невозможно, так как в ZK>> одном окне редактирования в каждый момент мог быть выделен только ZK>> один блок. RK> Блок - это участок кода. Hапример, if: Hу это мы просто о разных блоках подумали:) Понятно. В Мультиэдите был режим "collapse", кода вместо этого: RK> if (a<b) { RK> print("a lt b"); RK> } Оно покажет так if (a<b) { } и можно переходить "поблочно". Пробовал, особого восторга не вызвало. Кстати - а чего это у тебя скобки не одна под другой в примере? Я бы писал так: if (a<b) { print("a lt b"); } И кстати мультиэдит умел сам после точки с запятой и нажатия энтера поставить курсор под верхнюю скобку. И даже привычные и удобные три пробела отступа соблюдал - то есть после (a<b) энтер нажимаешь - курсор становится там где надо поставить фигурную скобку, ставлю скобку, еще энтер - и курсор ставится там где надо писать print. Вот из-за таких мелких удобств я старый досовый софт и вспоминаю. И не только я как ты наверно заметил. RK> Внутри блока могут быть тоже блоки. А, фолдинга в ME не было? Пояснишь что такое фолдинг - скажу. RK>>> Пожалуйста, объясни, каким образом тебе раскраска рассеивает RK>>> внимание. Я не могу этого понять. ZK>> В тех же самых книгах по теории разработки интерфейсов сказано, ZK>> что на экране не должно быть больше чем два-три цвета ZK>> одновременно. RK> Hе встречал такого ни в одной книге. Сейчас сослаться не могу, книжка дома лежит. Hо там как раз четко указывалось на нежелательность злоупотребления цветом на экране. ZK>> Если больше - то лично у меня уже "глаза разбегаются". В свое ZK>> время я поэкспериментировал с раскраской текстов на Аде, убедился ZK>> что оно мне мешает, и забросил это. RK> Всё равно не могу понять, как цвет может мешать. У тебя же не RK> каждая буква раскрашивается. Если рядом стоят ключевое слово и переменная названная одной буквой - то и буква будет другого цвета. Я же говорю - включал этот режим, лично донастроил под исходники на Аде, потом забросил и вообще переключил редактор в черно-белый режим. И уже десять лет у меня все редакторы в черно-белом режиме. Вот редактор от mc умеет ненавязчиво подсвечивать повышенной яркостью парную скобку когда на другую скобку курсором попадаешь - это мне удобно. Мультиэдит такое тоже умел делать. RK>>> является индикатором структуры. Более того, если исходник RK>>> раскрашен, то там проще заметить опечатку (например, вместо RK>>> print написал pritn - у тебя сразу же раскраска покажет, что ты RK>>> фигню написал). ZK>> Искать такие ошибки - это забота компилятора. RK> Зачем тратить время на компиляцию, когда у тебя редактор ошибку RK> показывает? Hу я предпочитал не рыскать по тексту в поисках таких опечаток, пусть даже и выделенных цветом, а запустить компилятор в режиме "проверки синтаксиса". (при этом он не делал самое долгое - оптимизацию). А Мультиэдит умел работать с выданным компилятором списком ошибок - ставил курсор на первую и позволял переходить дальше по мере надобности. ZK>> Еще и обратный контраст? Темный на светлом - нет уж, премного ZK>> благодарю, но пожалуйста не надо. RK> У меня везде тёмный на светлом. Мне так удобнее (ну и собственно RK> многие говорят, что это реально для глаз лучше, хотя по этому RK> поводу спорить не буду, так как доводы обеих сторон не кажутся мне RK> убедительными). Выше контраст - легче смотреть. Светлый на темном имеет более высокий контраст так как не подсвечивается фоном. Zahar --- Msged/LNX 6.1.1 * Origin: mobile point - Compaq Armada 1750 + Siemens ME45 (2:5030/382.1) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/32884353d0d6.html, оценка из 5, голосов 10
|
|
|