Hyprland, Gentoo, Unix-way

Своё, родное, handmade

light

#!/bin/sh

SYSFS_BACKLIGHT="/sys/class/backlight"

DEV=`find $SYSFS_BACKLIGHT -type l | head -1`

if [ ! $DEV ]; then
	echo GPU not found :\(;
	exit 1
fi

FILE=$DEV/brightness
LIGHT=`cat $FILE`
MAX=`cat $DEV/max_brightness`
MIN=$(( $MAX / 100 ))

if [ "$1" ]; then
	if echo "$1" | grep -qE '^[+-]?[0-9]+%?$'; then
		case $1 in
			*%)
				LEN=`expr length $1`
				PERCENT=`expr substr $1 1 $((LEN - 1))`
				case $PERCENT in
					[+-]*)
						PERCENT=$((LIGHT * 100 / MAX + PERCENT))
				esac
				if [ $PERCENT -lt 1 ]; then
					PERCENT=1
				elif [ $PERCENT -gt 100 ]; then
					PERCENT=100
				fi
				VALUE=$((MAX * PERCENT))
				if [ $((VALUE % 100)) = 0 ]; then
					LIGHT=$((VALUE / 100))
				else
					LIGHT=$((VALUE / 100 + 1))
				fi
				echo $LIGHT > $FILE
				;;
			*)
				VALUE=$1
				case $VALUE in
					[+-]*)
						VALUE=$((LIGHT + VALUE))
				esac
				if [ $VALUE -lt $MIN ]; then
					VALUE=$MIN
				elif [ $VALUE -gt $MAX ]; then
					VALUE=$MAX
				fi
				echo $VALUE > $FILE
				LIGHT=$VALUE
		esac
	else
		echo Incorrect syntax!
		exit 2
	fi
fi

echo "$LIGHT/$MAX ($((LIGHT * 100 / MAX))%)"

Hyprland, […] Unix-way

Сразу начал с взаимоисключающих параграфов… (%

WM (поправьте, если это композитор: я в музыке слаб).

Wayland в принципе комбайн и не соответствует принципам UNIX Way и KISS: это и менеджер окон, и композитор с визуальными эффектами, и менеджер буфера обмена, и ещё много чего (may vary).

А по поводу предпочтений спорить не стану — фломастеры разные.

Какое-то весьма узкое определение модульности. Почему конкретно компоненты, которые в иксах являются сервером иксов, wm и композитором должны быть даже не библиотеками, а отдельными процессами/бинарниками, если их функциональность при реализации достаточно сложного взаимодействия может быть совсем не ортогональной, и почему разделение должно быть именно таким?

Строго говоря, в реализации вейландов есть место и такому разделению, например вынос xwayland за пределы композитора https://github.com/Supreeeme/xwayland-satellite

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

Вообще, на мой взгляд, юниксвей фундаментализм - это признак какого-то, ну, ограниченного кругозора и в целом <5 лет плотной разработки под юниксы.

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

Юниксвей это идеология, никакая не рекомендация, и если человек идеолог, он неприемлет неюниксвейные продукты. И да, один единствнный xwayland недостаточен, чтобы wayland можно было назвать юниксвейным. А сервер, вм и композитник должны быть разными процессами потому что они выполняют… разные задачи) Часто ты открываешь калькулятор с целью зайти на ЛОР?

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

Ну и зачем быть «идеологом»? Это непродуктивно.

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

Лишь на первый взгляд

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

Юниксового принципа «умножай компоненты до бесконечности» нет. Юникс — про инструменты, а не про is-odd.

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

А это признак широкого кругозора и богатого опыта, верно?

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

Ну и зачем быть «идеологом»? Это непродуктивно.

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

Лишь на первый взгляд

Как и на второй, а на третий у меня глаз не хватает.

Можно подробнее: какая практика показывает грустные последствия?

а на третий у меня глаз не хватает.

Так паук же ж! :)

Wayland — это протокол.

А Вы рассуждаете про популярные wayland-композиторы. Да, они монолитны в угоду производительности.

Никто не запрещает реализовать окружение как набор микросервисов. В River, например, управление окнами — отдельный компонент.

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

То есть не юниксвейны. ^_~

В River, например, управление окнами — отдельный компонент.

И конфиг в виде шелл-портянки (хотя можно на любом языке накидать). (=

Хочется тайлинга с повсеместным vim-like управлением

Как любила говорить одна подруга - чего же мне сегодня хочется? Да говна хочется!

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

а нафига? Есть отличная утилитка light - даже в стандартном наборе ебилдов. emerge light - и никакой лапши башевой не нужно.

Вяленд такой вяленд, модульный настолько что этих модулей уже понаписано-понаделано вагон, и всеравно каждый лепит какую-то несуразную лапшу… Ну учитывая желание поесть глобальный vim-like на лопате в общем-то ождаемо.

Давно экстраполировать личные привычки на всех стало нормой?

Мне лично «нормально и удобно» не юзать мышь, так как привык. Так просто быстрее в основном.

Работа с яркостью дисплея — файловая абстракция на Линукс. Так и что теперь, чтобы читать/записывать один файл, отдельную программу компилять?

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

А тот light из ебилдов, который Вы указали, ведёт на отсутсвующий гитхаб-репозиторий :)

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

light из ебилдов быстрый и эффективный бинарник. Зачем тебе репозиторий - не ясно, он же из сорсов собирается. Открыл исходник да посмотрел.

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

Еще понимаю если бы ты делал что-то что light не умеет -скажем читал датчик света и подгонял яркость по нему. Или по времени суток что-то творил.

Qui-Gon зря перешел на личности. Лучше расскажи как именно переход с мыши на клавиатуру повлиял на твою работу. У мыши довольно сильные преимущества (простота, однообразность, пространственная аналогия, оптимизированные под мышь UI), которые нельзя отмахнуть простым «она медленная». Клавиатура же, как минимум, фрагментирована на программном уровне (у всех свои сочетания), имеет слабый discoverability (приходится специально читать маны и тренироваться, чтобы познать более простой или эффективный способ решения проблемы), сложно использовать в расслабленном режиме (руки постоянно чем-то заняты) или одной рукой, большая склонность к RSI при высоких нагрузках.

Конечно, расскажу!

Утверждение «Vim позволяет редактировать текст со скоростью мысли» — это правда. Действия Vim в итоге уходят в мышечную память. Невозможно запомнить всё разом, но, часто используя одни и те же паттерны, начинаешь вводить их на автомате, не думая. В каком ещё редакторе я могу точечно перемещаться (по словам, абзадцам, блокам кода, поиску) и при том молниеносно, по нажатии одной-двух клавиш?

Мнение, что Вим переусложнянт привычное перемещение и редактирование — ошибочно. Можно настроить, чтобы он запускался сразу в insert-mode с привычными редакторские и сокращениями: Ctr+F — поиск, Ctrl+S — сохранение. Но, кроме того, он даёт неограниченные возможности расширения — это программируемый редактор, который подстраивается под твой стиль работы со временем.

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

А так я настраиваю инструменты под себя и не жалуюсь — однообразие на лицо. По той же причине по возможности юзаю текстовый интерфейс повсеместно.

Мышь нужна редко. Ей трудно попасть, если элемент маленький. Её единственное предназначение — графические редакторы. На моём thinkpad есть досадная особенность: при большой нагрузке тачпад и мышь подвержены инпутлагу.

Спасибо за развёрнутый ответ. Ниже я критикую не ваш выбор, а парадигму, которая за ним стоит.

В каком ещё редакторе я могу точечно перемещаться (по словам, абзадцам, блокам кода, поиску) и при том молниеносно, по нажатии одной-двух клавиш?

Я считаю, что здесь скрыт недостаток, проданный как достоинство. Проблему перемещения по произвольным регионам решает мышь, буквально. Хочешь — по символам, хочешь — по методам, причём единообразно, без хрупких трюков вроде /^{. Чтобы достичь этой свободы владения, клавиатуре пришлось придумать уникальные сочетания под каждую подзадачу: ←, →, ↑, ↓, b, B, w, W, e, E, /, ?, PgUp, PgDown, ^U, ^D, ^F, ^B, — и это минимум. Тот факт, что одну клавишу быстрее нажать, чем перевести курсор, нивелируется тем, что их приходится чаще нажимать, чем один раз поставить курсор мыши в нужное место. Это особенно заметно при выделении текста в vim.

Автор vi признаёт эту проблему 1:

The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing.

Мнение, что Вим переусложнянт привычное перемещение и редактирование — ошибочно

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

Ctr+F — поиск, Ctrl+S — сохранение

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

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

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

Потому и использую vim-like управление везде, где можно: в браузере, графических обозревателях, WM.

Некоторые метафоры vi не переносятся на другие интерфейсы. Например, какой способ отсортировать файлы в файловом менеджере ближе всего к духу vi? !}sort не сработает. В ranger (фм с vi управлением) это “o”, что вообще неожиданно. То есть проблема явной фрагментации не решена, а заменена на минное поле.

Браузер — это, кстати, самое сильное притягивание за уши. Vimperator вообще не соответствует базовой модели vi.

вот запустил я новую для себя программу: где в её панели управления сверху будет поиск?

Примерно сверху справа. В общем случае, решением этой проблемы занимаются Human Interface Guidelines, самые популярные у Google, Apple, GNOME и Microsoft.

Кстати, конкретно этот тест проходит даже используемый мной редактор Acme из 90-х годов. Буквально сейчас это понял. В нем поиск не прям справа в углу, а последний элемент на панели. То есть общий принцип работает даже в нестандартных интерфейсах.

По той же причине по возможности юзаю текстовый интерфейс повсеместно.

За это жирный плюс, но текстовый интерфейс бывает разный. Псевдографика вроде htop — это уже далеко не тот текст, который можно обработать в текстовом редакторе или прогнать через скрипт.

Ей трудно попасть, если элемент маленький.

Решается медленным курсором. Я постоянно выделяю мышью единичные символы, включая запятые, с пропорциональным (то есть узким) шрифтом.

Её единственное предназначение — графические редакторы.

“The same equations have the same solutions.”

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

Проблему перемещения по произвольным регионам решает мышь, буквально. Хочешь — по символам, хочешь — по методам

Да, только в случае с Vim’ом мне не нужно тратить усилия, чтобы отыскать визуально конец слова/предложения и точно попасть мышей: просто жмёшь одну кнопку — программа просчитывает, как ей подобает. А я уверен в инструменте. Выше Вы упоминали, что работать указателем менее энергозатратно: можно расслабленно, одной рукой. Я же возражаю: надо найти область и прицелиться — тоже труд. В Вим этот неблагодарный труд сведён на нет :)

Это особенно заметно при выделении текста в vim.

В 90% случаев работаю паттерны. Мне выделить слово быстрее через viw, нежели дабл-клик. Выделить строку — быстро, абзац — быстро. А если это не структурный элемент (абзац, предложение, слово), то и мышкой приходится нацелить. И часто, в попыхах промахнёшся выделением. Мышью — перевыделять, в Вим — РЕЖИМ выделения: можно расширить привычными командами управления.

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

Мой тезис как раз и заключался в том, что Вим может работать как обычный редактор. Прочтите про простой режим vim -y. Из мана:

Makes Vim behave like a click-and-type editor.

А ещё вим графический, с табами и панельками, как всякий мейнстримовый эдитор. Но! Отличие в том, что он даёт возможность углубиться и (конечно, ценой упорства, кривая обучения крутая) редактировать текст со скоростью мысли. Ваш тезис, что постигать мудрёное управление Вим — это учить два языка, ошибочно: по такой логике, любая система плагинов в редакторе — новый язык. Так-то оно так, не всем нужно. Но why not?

В ranger (фм с vi управлением) это “o”, что вообще неожиданно. То есть проблема явной фрагментации не решена, а заменена на минное поле.

Файловые менеджеры — лишняя сущность. Есть coreutils, findutils. И встроенный файловый менеджер Вима. Ярлык «vim-like» не делает софт хорошим — такого я не утверждал. Ranger — дерьмо. Взгляните лучше на vifm.

Vimperator вообще не соответствует базовой модели vi.

И снова: на примерах плохой реализации доказывать, что концепция слаба — ошибка логики. Нормальные примеры: Vimium, Tridactyl, QuteBrowser

Ну да, модно использовать мышь — под это точат интерфейсы. А ещё модно перегружать продукт фреймворками, проприетарный софт, ИИ по поводу и без… И сторонники оного предоставят аргументы в защиту. Ведь тысячи мух не могут ошибаться… А Линукс как был андеграундом, так (отчасти) и остаётся — не закапывайте концепцию управления клавиатурой, хотя бы во имя разнообразия.

И я согласен, что мышь — универсальный интерфейс. Но вот аналогия: ноги — универсальный инструмент ходьбы: теоретически, можно дотопать до любой точки материка. Но можно использовтаь транспорт, который доставит точно к цели, точно ко времени, притом быстро, даже если я не знаю, как дотуда добраться. Примерно так устроено перемещение в Вим: в конец файла, в предыдущее положение, в конец абзаца (даже если не видно конца абзаца) и т.д. и т.п. Можно разгрузить голову и сосредоточиться на редактировании. И ещё раз: кривая обучения жестокая. Но, вопреки Вашему убеждению, я уверен, что это окупается, хоть и не всем подойдёт. Нравится Вам acme — чудно! Но утверждать, что «овчинка выделки не стоит»… Отучайтесь говорить за всех, а то демогогия какая-то. Последний тейк я вообще не выкупил: управляя с клавиатуры, перемещаясь по тексту, тоже мыслю пространственно.

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

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

Но серьёзно, какая разница конкретному пользователю, которому это удобно, и который с радостью использует всю эту функциональность, в принципе должно быть дело до «всех»? Я тоже постоянно вляпываюсь в подобные дискуссии: человек узнаёт, что я использую Vim, а также много где (хоть и не везде — тут без фанатизма) vim-подобный интерфейс, затем начинает мне объяснять, что я делаю что-то неправильно — есть же мышь, с которой собеседник родился, и которая почти так же интуитивна как сиська. Начинаешь объяснять, быстрее, эффективнее, приятнее и удобнее в итоге по-vim’овски, а в ответ получаешь что-то вроде «и что же, теперь каждой тёте-бухгалтерше маны читать? она хоть выйти из вима сможет, азаза». Ну типа… с какого перепуга на мой выбор должны влиять проблемы тёти-бухгалтрерши?

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

интерфейса, где это делается одним универсальным жестом

За эту универсальность приходится платить. Тем, что мышью надо постоянно целиться. По-сто-ян-но. Ещё и глаза при этом задействовать гораздо интенсивнее, чем при работе с клавиатурой. У клавиатуры выше порог вхождения. Но после того, как ты освоил комбинации во всех постоянно применяемых программах – ты отдыхаешь, они нажимаются на автомате.

Миллиметр – универсальная единица измерения. Но почему-то расстояния между городами в миллиметрах никто не меряет. Хотя вполне можно. Просто слишком утомительно (как и постоянно елозить мышью) и много цифр вбивать. А некоторые ещё и морскими милями пользуются, проказники этакие.

Мышь позволяет перенести пространственные навыки для решения новых задач.

Я соглашусь, что при освоении совсем новых программ мышь удобнее. Но вот ты каждый день осваиваешь совсем новое? Как только освоился, какие в программе действия, в каком меню что лежит – становится проще выучить хоткеи. Удобство и порог вхождения – разные понятия. В общем случае ортогональные. А когда второе пытаются выдать за первое – становятся взаимоисключающими. :(

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

Так кто его призывает взваливать на всех пользователей? У пользователя должна быть свобода выбора, причём выбора в рамках одной программы. Благо средствами мейнстримных графических тулкитов это делается очень легко. (Причём если макросы это действительно в какой-то степени программирование, то базовый набор хоткеев никакого программирования не требует, это просто набор хоткеев.)

Примером почти идеальной в этом плане (именно в этом) программы был старый Microsoft Word до 2003 версии включительно, пока не прискакал Баллмер и не притащил туда мерзотный риббон. Там мало того, что 99,9% всех действий можно было выполнить как клавиатурой, так и мышью, так обеими это тоже можно было делать разными способами. Мышь – меню либо панель инструментов. Клавиатура – отдельные хоткеи или хоткеи, встроенные в меню. Меню же обеспечивало плавный переход от мыши к клавиатуре и (по желанию) назад. А ещё для продвинутых есть макросы и хоткеи на них. До 4-5 способов на каждое действие, и это хорошо!

В риббоне, кстати, менюшные хоткеи оставили, но они утратили мнемонический смысл. Человеку, который видел только риббон, чрезвычайно сложно понять, почему Alt+а ы ы (на русском) это вставка ссылки. А вот из меню это было очевидно. То есть техника плавного перехода от мыши к клавиатуре и назад утрачена. Когда 60-80% свидетелей Word 2003 уйдут на пенсию, эти хоткеи подленько и потихоньку («в крысу», как сейчас говорят) выкинут и останется только жрать кактус, ну или обвешиваться макросами на каждой машине. Sad but true.

Мышь – отличное указательное устройство. Но немного странно делать указательное устройство главным устройством ввода для вещей, не сводящихся естественным образом к набору координат. Всё через мышь, даже небо, даже Аллах.

P.S. Я тут, кстати, подумал, что vim завоевал бы гораздо больше поклонников, если присобачить к нему меню в староборландовском TUI-стиле (кто застал Turbo Vision, тот поймёт, о чём я). Отключаемое, естественно. Тот самый плавный переход клава-мышь и назад.

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

Откуда ты знаешь, не посмотрев, что тебе нужно попасть в следующий абзац? В чём состоит глубокий смысл не смотреть куда курсор встанет в следующий момент?

Vim — не исключение из сознательного цикла look/parse/keystroke.

надо найти область и прицелиться — тоже [неблагодарный] труд … И часто, в попыхах промахнёшся выделением.

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

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

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

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

[вим] даёт возможность углубиться и … редактировать текст со скоростью мысли.

Я сегодня провёл два эксперимента. Первый — продублировать строку, заменив в копии значение, взятое из другого места из видимой области. Очень частая задача при написании кода (например, добавить вывод переменной). Результат — 7 секунд как в vi, так и в моём редакторе.

Второй эксперимент: заменить orderPropPasspotSellerVALUE на orderPropSellerPassport, перенеся Passport на место VALUE. Мне пришлось сделать 0fP;dftfrplde, что заняло 10 секунд. В простом редакторе я это сделал за 7 секунд через контекстные меню (то есть без ctrl C и ctrl V), в своём — за 5.

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

Мой тезис как раз и заключался в том, что Вим может работать как обычный редактор.

Зачем? У тех, кому это нужно, есть другой инструмент под эту задачу. Те, кому нужен вим, этот изи-режим будет лишний раз под руку лезть.

(Про два языка было именно в этом контексте.)

Файловые менеджеры — лишняя сущность. Есть coreutils, findutils.

Лишняя она или нет здесь не важно. Важно то, что парадигма vi при переносе на новые интерфейсы порождает фрагментацию в управлении. Этот недостаток не решается признанием файловых менеджеров идеологическими врагами.

Ranger — дерьмо

С чего вдруг? Авторы, вообще-то, старались. Да, не смогли перенести всю семантику 1-к-1, но ведь сохранили основной дух — однобуквенные команды для самых частых операций. Сортировка — вполне частое явление в контексте файловых менеджеров.

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

Vimperator вообще не соответствует базовой модели vi.

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

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

Отучайтесь говорить за всех, а то демогогия какая-то.

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

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

Вы говорили, что мышь подходит только для графических редакторов. То есть там, где двухмерное измерение — первичная часть системы, в отличие от текста. Это очень распространённый аргумент. На что я возразил: различия — не причина отказываться от аналогий.

Под «всеми» я имею ввиду только профессиональных пользователей — основная аудитория vim. Система, которая ожидает, что пользователь сам позаботится о базовом комфорте, не только даёт ему свободу, но и обременяет сложными системными проблемами. Это даже для профессиональных пользователей далеко не всегда плюс.

Я считаю, что создатели программы по умолчанию лучше всего осведомлены о вопросе. У них намного больше знаний и опыта, чтобы принять верное решение. Они должны сформулировать базовые принципы, идиомы, дефолт. В виме это присутствует в значительной степени. Но та часть, которая называется «я не знаю, сделай сам как хочешь» — это не продукт знаний дизайнера, а неразведанная территория, где неподготовленному пользователю (а мы все такими были когда-то) не на кого положиться, кроме своего недостаточного опыта.

За эту универсальность приходится платить.

Универсальность — не обязательно неудобство. Отвёртки с насадками и ножи шеф-повара достаточно удобны даже для профессионалов. И мышь тоже.

Удобство и порог вхождения – разные понятия.

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

Универсальность — не обязательно неудобство. Отвёртки с насадками и ножи шеф-повара достаточно удобны даже для профессионалов. И мышь тоже.

Аналогия не является доказательством. Если шеф-повару может быть удобно делать всё одним ножом, это вовсе не означает, что делать всё мышью тоже удобно. Что мы, собственно, и наблюдаем в реальности — опытные пользователи обычно используют как минимум далеко не только мышь.

Десятичную систему счисления легче освоить, чем двоичную, и она удобнее в подавляющем большинстве случаев.

Это неправда. Десятичная система не удобнее других в большинстве случаев, она удобна исключительно из-за того, что это язык, то есть средство передачи информации, и должна быть стандартизирована для всех — с целью эффективности этой самой передачи. Двенадцатиричная система, например, при этом удобнее в бытовой жизни, и не зря до сих пор многое дюжинами и полдюжинами считают. Хотя бы потому что 12 делится на 2, 3, 4 и 6, а 10 — только на 2 и 5. А для «компьютерных» нужд шестнадцатиричная удобнее. Десятичная стала стандартом вовсе не потому что она объективно удобнее хоть для чего-то, а потому что так исторически сложилось, и потому что пальцев 10.

Аналогия не является доказательством.

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

Шучу. Но аналогия - это инструмент dyonya («vim - транспорт, мышь - ноги») и hobbit («мышь - миллиметр»). Я же лишь хотел сказать, что универсальность - не обязательно неудобство, а отвёртка с насадками и нож шеф-повара - примеры, а не аналогии. Нужно смотреть каждый индивидуальный случай, а не экстраполировать.

опытные пользователи обычно используют как минимум далеко не только мышь

С этим я не буду спорить. Клавиатура - хороший инструмент для ввода нового текста, который может быть настолько же коротким как сочетание клавиш («cp»/«mv»/«rm»). Но даже сочетания клавиш - хороший duct tape, которым просто нельзя злоупотреблять.

Десятичная система не [объективно] удобнее других в большинстве случаев

Возможно. Я не подумал об этом. Но чисто практически она всё равно удобнее, потмоу что 99.9% мира пропитаны десятичной системой.

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

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

Ну то есть, если бы шеф-повар был не шефом, а чистильщиком картошки, который занимается только этим, он наверняка не использовал бы свой универсальный нож, а взял бы тот, которым удобнее именно чистить картошку.

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

Возможно. Я не подумал об этом. Но чисто практически она всё равно удобнее, потмоу что 99.9% мира пропитаны десятичной системой.

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

затраты на переключение с одного на другое

Я не думаю, что проблема в переключении как таковом. Это мышечный процесс, но он автоматический и подсознательный. Проблема возникает, когда у пользователя нет предпочтения. Он привык одновременно и к мыши, и к клавиатуре, и они его тянут в противоположные направления. Скажем, левша не хочет убирать руку с мыши, но ему приходится, чтобы сделать ctrl C и ctrl V. Вот это реальная когнитивная нагрузка.

Кстати, переключение с клавиатуры на мышь - это явное физиологическое явление, тренируемое до автоматизма. А вот необходимость помнить текущий режим - нет. Пользователи vi решают эту проблему, максимально сокращая время пребывания в режиме редактирования. Подход верный, но он же создаёт ложные ожидания, что все правки короткие, в то время как в ~10% случаев они не короткие и пользователь стоит на грани между непредвиденной ошибкой и сознательным контролем режима.

В целом, это недостаток, который автор vi тоже признал 1:

Q: What would you do differently?

A: . . . One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me.

есть задачи, для которых всё равно клавиатура необходима, и эти задачи важны и могут представлять из себя чуть ли не больше половины задач

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

Но так не обязательно должно быть, точно не для инструментов для профессионалов, где порог входа можно слегка приподнять ради удобства. В macOS можно вставить текст в середину слова только клавиатурой, но не мышью. Контекстные меню, где Cut/Copy/Paste первые в списке, на всех платформах могут непредсказуемо всплыть либо ниже курсора (удобно), либо над ним (далеко от курсора). Два принципиально разных буфера обмена в Linux мешают сделать процесс работы бессознательным (всегда есть риск ошибиться в выборе буфера). В контекстном меню инструментов разработчика Chromium собрано целых 6 способов копирования («Copy value,» «Copy property path,» «Copy string contents,» «Copy string as JavaScript literal,» «Copy string as JSON literal») и ещё один (самый предсказуемый «Copy») в самом конце скрыт до тех пор, пока текст не выделен. Это всё проблемы UI, а не мыши.

клавиатура — это тот самый шеф-нож или отвёртка с насадками

Стандарт универсальности сменился. Я не говорил о том, что мышь может служить единственным средством ввода. В этом плане для плотника смартфон будет не так универсален, как молоток, который ему нужен всегда. Я говорил об универсальности относительно UI: многие проблемы можно решить единой пространственной аналогией.

Я говорил об универсальности относительно UI: многие проблемы можно решить единой пространственной аналогией.

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

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

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

Интерфейс макоси изначально не был ориентирован на профессионального пользователя. Там изначально была знаменитая мышь с одной кнопкой, когда нормой было три. Сегодня же макось - это франкенштейн, а не чистый case study.

Использование мыши в профессиональном контексте - это пример Plan 9. Пример необычный, не всеобъемлющий, но важный, потому что показывает, что эффективность можно достичь даже в простой системе, без UI сложнее ядерного реактора и без мыши с десятью кнопками.

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

Не стану опровергать ваш личный опыт, но он не единственный. Мне известен по крайне мере один убеждённый пользователь, покинувший Emacs ради мыши 1. Значит не всё упирается в личный опыт.

Не стану опровергать ваш личный опыт, но он не единственный.

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

Мне известен по крайне мере один убеждённый пользователь, покинувший Emacs ради мыши 1. Значит не всё упирается в личный опыт.

Нет, это ничего не значит, ровным счётом. Здесь нарушена логика, из первого утверждения не следует второе.

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

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

Да, но обсуждать объективные достоинства и недостатки - можно.

Здесь нарушена логика, из первого утверждения не следует второе.

Там нет причины и следствия, сорри если запутал. Это цельное наблюдение: убеждённый пользователь с богатым личным опытом покинул Emacs, по сути обесценил свой опыт.

Я совсем забыл про тачпад в контексте обсуждения затрат на переключение. Тачпад под клавиатурой настолько сильно близко к обоим рукам, что их использование сливается чуть ли не воедино. Есть нишевый подход, в которых нажатие на ctrl/alt модифицирует клик мыши — это как раз возможно благодаря тому, что клавиатура и тачпад находятся очень близко друг к другу.

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

В юникс-вей ещё «всё есть файл», так что

между этими программами должен быть стандартный механизм взаимодействия

это файл.

Программы взаимодействуют с композитором через сокет, который является файлом. Чем не юникс-вей?

https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html

One example I often raise to illustrate the design ideals of Plan 9 is to compare its approach to network programming with that of the Unix standard, Berkeley sockets. BSD sockets fly in the face of Unix sensibilities and are quite alien on the system, though by now everyone has developed stockholm syndrome with respect to them so they don’t notice. When everything is supposed to be a file on Unix, why is it that the networking API is entirely implemented with special-purpose syscalls and ioctls? On Unix, creating a TCP connection involves calling the “socket” syscall to create a magic file descriptor, then the “connect” syscall to establish a connection. Plan 9 is much more Unix in its approach: you open /net/tcp/clone to reserve a connection, and read the connection ID from it. Then you open /net/tcp/n/ctl and write “connect 127.0.0.1!80” to it, where “n” is that connection ID. Now you can open /net/tcp/n/data and that file is a full-duplex stream. No magic syscalls, and you can trivially implement it in a shell script.