Комментарии 167
Все бы хорошо, но визуально отличить лигатуру == от одинарного = довольно проблематично.
+25
в js будет ещё хуже, там надо == от === отличать
+5
а чем плохо использование символа ≡ для ===?
+12
Можно сделать тройное равно для == и четверное для === :)
-1
наверное только тем что количество знакомест разное. При удалении толи сразу весь ≡ удалять, толи сначала превращать его в ==, и наоборот, при вводе, внезапно два знакоместа превращаются в одно после печати третьего =. А длинное ≡≡≡ будет выглядеть непривычно.
0
А уж если попадется что-то вроде такого
то вообще пиши пропало. Мало того, что половина парсеров не понимает, что тут регуляка делится на ноль, ещё и лигатура будет неправильно намекать.
/0//0
то вообще пиши пропало. Мало того, что половина парсеров не понимает, что тут регуляка делится на ноль, ещё и лигатура будет неправильно намекать.
0
НЛО прилетело и опубликовало эту надпись здесь
+25
лигатура же вдвое шире, чем одинарный =. Так что должно быть легко.
-1
Сомневаюсь в этом. Вот пример:
Если строки у вас идут друг под другом, то да, отличить легко. Если у вас между этими строками будет одна пустая — уже сложнее. Следующий код, написанный этим шрифтом, будет тоже тяжел для восприятия:
А уж сколько интересных часов вас ждет в отладчике, если вы в условии вместо == поставите оператор присваивания.
Если строки у вас идут друг под другом, то да, отличить легко. Если у вас между этими строками будет одна пустая — уже сложнее. Следующий код, написанный этим шрифтом, будет тоже тяжел для восприятия:
a = b == c
А уж сколько интересных часов вас ждет в отладчике, если вы в условии вместо == поставите оператор присваивания.
+1
Про Hasklig: Я был уверен, что перечёркнутый знак равенства это !=, а оказалось, что это /=. Незачёт.
В Fira Code вроде получше, но трудности с различием =, == и === остались.
В Fira Code вроде получше, но трудности с различием =, == и === остались.
+1
И всё-таки, когда у '≠' я стираю один символ, и появляется '!', это как-то сбивает.
+3
Учитывая, что в Haskell операция «не равно» пишется именно как
/=
, не вижу проблемы.+5
Об этом не знал. Тогда всё ок по данному параметру.
0
Проблема в том что в Haskell это комбинация «не равно», а во всех других языках — «разделить и присвоить». Поэтому я такую лигатуру делать не стал.
+3
Логично. Но с другой стороны «направление мысли» с использованием лигатур ещё не обрело популярность, а уже споткнулось о подобную проблему.
+2
Просто для разных языков нужны разные шрифты.
Или, если идти дальше, также как для обычных языков есть юникод, также и для программистских языков должен быть свой юникод по штуке на язык.
Или, если идти дальше, также как для обычных языков есть юникод, также и для программистских языков должен быть свой юникод по штуке на язык.
0
Если он будет «по штуке на язык», то какой в этом вообще смысл?
+3
Юникод потому и юникод, что он один. Он записывает графические символы, а не их семантические особенности. Если лигатура <> выглядит одинаково в Haskell и SQL, то ей будет соответствовать один символ PROGRAMMING LIGATURE <>. Если же /= выглядит по-разному в Haskell и C++, то это будут два отдельных символа: PROGRAMMING LIGATURE /= (NEGATION) и PROGRAMMING LIGATURE /= (DIVISION).
+1
Да, только в юникод не лигатуры заносятся, а символы., Т.е. будет просто символ Negation и символ Division with assignment.
0
Костыли.
Я уже как-то высказывал мысль, что идеальное решение нехватки спецсимволов (которое ощущается кстати во многих современных языках программирования) — это:
1. консорциуму Unicode нужно выбрать из всего множества символов 25 самых востребованных спецсимволов и назначить (продублировать) их на коды с 0x01 по 0x2F (исключая символы POSIX — пробел, табуляции, null, backspace и переносы строк). Т.е. по сути включить в ASCII. Ибо «управляющие коды для печатных устройств» это уже анахронизм.
2. производителям клавиатур нанести эти дополнительные символы на буквенные клавиши как дополнительные символы, которые можно ввести с каким-то сочетанием шифтовых клавиш.
Конечно будет какой-то переходный период, но зато потом — красота:)
Я уже как-то высказывал мысль, что идеальное решение нехватки спецсимволов (которое ощущается кстати во многих современных языках программирования) — это:
1. консорциуму Unicode нужно выбрать из всего множества символов 25 самых востребованных спецсимволов и назначить (продублировать) их на коды с 0x01 по 0x2F (исключая символы POSIX — пробел, табуляции, null, backspace и переносы строк). Т.е. по сути включить в ASCII. Ибо «управляющие коды для печатных устройств» это уже анахронизм.
2. производителям клавиатур нанести эти дополнительные символы на буквенные клавиши как дополнительные символы, которые можно ввести с каким-то сочетанием шифтовых клавиш.
Конечно будет какой-то переходный период, но зато потом — красота:)
0
Не стоит недооценивать живучесть «анахронизмов».
+8
И специальные клавитуры для разработчиков. Красотень просто таки.
+6
НЛО прилетело и опубликовало эту надпись здесь
Это кстати совсем не бредовая мысль. Я бы хотел нажимать скобки и все символы из ряда шифт+цифра одной кнопкой а не комбинацией из двух. Как программисту, это бы мне кучу усилий сэкономило.
+2
НЛО прилетело и опубликовало эту надпись здесь
Не решает. Нужен еще один дополнительный ряд кнопок. На самом деле программисты это куча народу и если они за правильно сделанной ориентированной на них клавиатурой в очередь выстроятся, вот и бизнес готов. Люди вон страдают что в русской раскладке запятую приходится с шифтом набирать, а у программиста спецсимвол или скобка каждые пять букв встречаются. Если убрать из уравнения шифт, руки просто порхать начнут, и усталость раза в полтора снизится.
0
НЛО прилетело и опубликовало эту надпись здесь
Это известно что emacs не для людей xrtc.net/f/pixen/emacs_user_at_work_by_earlcolour-d38aj2x.jpg
+3
Угу, он для программистов в основном. Кстати, один из немногих редакторов, которые позволяют делать всё, не переключаясь на стрелки и мышку.
И, возвращаясь к теме топика, в нём есть prettify-symbols-mode.
И, возвращаясь к теме топика, в нём есть prettify-symbols-mode.
0
Есть раскладка «русская машинопись».
(а цифры с цифроблока набирать)
(а цифры с цифроблока набирать)
0
Я использую уже 2 года Logitech G510. Слева три блока по 6 программируемых клавиш. Можно делать отдельные профили для каждого приложения. Если и этого мало, вверху есть переключалка режимов М1 М2 М3. Соответственно в каждом хоткеи могут быть свои. На практике я ни разу с М1 не переключался.
Единственный минус — софт не позволяет перемешивать глобальные и локальные хоткеи. Т.е. нельзя сказать G1-G6 всегда вот это, а G7-G18 в зависимости от приложения. Если создается профиль для приложения, то глобальные хоткеи приходится копировать. Отчасти это компенсируется тем, что профили можно хранить в памяти самой клавиатуры, и будучи единожды настроенными они уже никогда не пропадут.
Единственный минус — софт не позволяет перемешивать глобальные и локальные хоткеи. Т.е. нельзя сказать G1-G6 всегда вот это, а G7-G18 в зависимости от приложения. Если создается профиль для приложения, то глобальные хоткеи приходится копировать. Отчасти это компенсируется тем, что профили можно хранить в памяти самой клавиатуры, и будучи единожды настроенными они уже никогда не пропадут.
0
Круто! И какие у вас хоткеи стоят на эти кнопки?
0
Попробуйте клавиатуру полноформатную для кассовых аппаратов. Там есть пара рядов полностью программируемых клавиш…
0
можно ссылку как это примерно выглядит?
0
Сейчас в любой более-менее вменяемой геймерской клавиатуре есть возможность перепрограммировать любую клавишу. Но не хотелось бы жертвовать чем-то одним в угоду другого. А дополнительный ряд решает проблему, да. Только выглядит отстойно на тех примерах, что Вы скинули.
0
github.com/mudasobwa/huya-xkb/ — может быть, вам будет интересно. Привыкаешь месяц, потом радости вагон. Если не кодировать бухгалтерские ведомости.
0
ээ а как это работает?
0
Я почитал комментарии, уже увидел, что вы, судя по всему, на винде. Тогда, к сожалению, никак. Для *nix в первой строчке README — установочный скрипт.
0
Нет, я не спрашиваю как это установить, и нет, я не на винде. Мне интересно как это работает, а там ничего не написано про то что это и зачем: на каждой кнопке нарисовано по 4 символа, как выбирается какой из них будет вводиться? Нужно зажимать клавишу-модификатор?
0
А, ага, правый альт для третьего и AltGr+Shift для четвертого уровня. Нарисовать такую раскладку — небольшое достижение, я хотел лишь сказать, что 1) мысль набирать скобки и всякие «равно» в одно нажатие приходила не вам одному (я именно про то, что у меня все символы в первом регистре); 2) когда есть репозиторий, откуда оно раскатывается на любую машину в один копи-паст, уже не так страшно привыкать.
0
Т.е. в этой раскладке просто поменяны цифры и символы на них, цифра с шифтом, а символ без шифта. Возможно это не так уж плохо для программирования, в конце концов цифры не так часто нужны. Но дополнительный ряд это все равно лучше.
0
Еще закрывающие скобки все сдвинуты во второй регистр, IDE их почти везде сам закрывает. Цифры еще бывают на доп. клавиатуре. Дополнительный ряд сломает 10-пальцевый набор, мне кажется.
0
Хотя бы потому, что программисты занимаются не только программированием. Т.е. либо набирать цифры с шифтом везде, где они могут пригодиться ещё, либо сделать переключение «режимов», что ещё хуже. Хотя Num pad в данном случае может помочь.
0
Она ужасна тем, что ставится не отдельно, а патчит «default». Я не мастер в конфигурировании раскладок для Linux, но ведь есть способ добавлять её в качестве отдельной группы «xkb_symbols», не затирая намертво стандартную раскладку?
Спасибо хотя бы за то, что в папке /usr/share/X11/xkb/symbols остаётся резервная копия старой раскладки, чтобы её можно было восстановить.
Но, вообще, за идею спасибо. Я только недавно на Linux переехал и мне нужно было найти способ облегчить ввод некоторых символов (без того, чтобы заниматься пальцевой камасутрой с Compose key). Теперь хотя бы знаю, где можно вносить изменения в раскладку.
Спасибо хотя бы за то, что в папке /usr/share/X11/xkb/symbols остаётся резервная копия старой раскладки, чтобы её можно было восстановить.
Краткая инструкция для тех, кто хочет вернуть стандартную раскладку обратно
cd /usr/share/X11/xkb/symbols
sudo mv -f ru.orig ru
sudo rm /var/lib/xkb/*xkm 2>/dev/null
Но, вообще, за идею спасибо. Я только недавно на Linux переехал и мне нужно было найти способ облегчить ввод некоторых символов (без того, чтобы заниматься пальцевой камасутрой с Compose key). Теперь хотя бы знаю, где можно вносить изменения в раскладку.
0
Это сознательный выбор: мне нужен был oneliner для раскатки на новую машину. Было два варианта: патчить symbols, или патчить ru. Это же не туториал, это инструмент, сделанный для себя.
0
Ну, тут вам виднее. Единственное, я бы в инструкции предупреждал других пользователей, что затирается стандартная раскладка, если бы выкладывал подобную вещь в открытый доступ, и давал бы какую-нибудь информацию о том, как всё вернуть обратно.
Кстати, в install.sh (как и в мою краткую инструкцию) можно ещё добавить команду «setxkbmap» — прямо так, без параметров. Тогда изменения раскладки применятся сразу. Без этого, после установки вашей раскладки нужно либо перелогиниться/перезагрузиться, либо сделать какие-нибудь изменения в настройках клавиатуры, чтобы изменённая раскладка подгрузилась в память.
Кстати, в install.sh (как и в мою краткую инструкцию) можно ещё добавить команду «setxkbmap» — прямо так, без параметров. Тогда изменения раскладки применятся сразу. Без этого, после установки вашей раскладки нужно либо перелогиниться/перезагрузиться, либо сделать какие-нибудь изменения в настройках клавиатуры, чтобы изменённая раскладка подгрузилась в память.
0
Я не планировал «других пользователей» :)
setxkbmap нужен для вычистки какого-нибудь двухуровневого кэша, наверное, мне с ходу сложно себе представить, откуда после rm /var/lib/xkb/*xkm иксы возьмут старую раскладку. На убунту и генту, по крайней мере, никаких плясок не нужно.
setxkbmap нужен для вычистки какого-нибудь двухуровневого кэша, наверное, мне с ходу сложно себе представить, откуда после rm /var/lib/xkb/*xkm иксы возьмут старую раскладку. На убунту и генту, по крайней мере, никаких плясок не нужно.
0
сложно себе представить, откуда после rm /var/lib/xkb/*xkm иксы возьмут старую раскладку
Из оперативной памяти — наверняка. :)
В Kubuntu без setxkbmap изменения мгновенно не проявляются. Я прямо в окне консоли тестировал. Устанавливал вашу раскладку и тут же в консоли пытался вводить цифры в русской раскладке — вводились цифры. И только после setxkbmap начали вводиться знаки препинания вместо цифр, как и ожидалось от раскладки.
Я думаю, это всё не зависит от разновидности линуксов, это особенности X11. У вас без плясок работает, наверняка, потому, что вы не пробовали пользоваться раскладкой мгновенно после её установки, не отходя от кассы — когда ru или es раскладка уже есть в настройках на момент запуска install.sh. А так, если после install.sh компьютер перезагружался, или был релогин, или если в настройках клавиатуры сделано любое изменение или вообще, что угодно, дёргающее иксы, то всё, конечно же, нормально обновляется.
Но я могу и ошибаться. Всё же, я не так давно окончательно переехал на линукс, хотя и пользовался им эпизодически крайние лет 14-15. Так что, у меня хорошего понимания архитектуры ОС пока ещё нет. :)
0
Кхм. Я пробовал, конечно, пользоавться сразу, это же раскладка, а не агнрибёрдс. После установки нужно разок щелкнуть переключателем, на моих дистрибутивах он напрямую вызывает setxkbmap. Подозреваю, что в kubuntu переключатель раскладок вводит еще один уровень абстракции, коотрый и занимается кэшированием.
0
Не хочу рассказывать Вам про широкоиспользуемый telnet, но…
А ещё в эти управляющие символы входят перенос строки \n, любимый в windows возврат каретки \r, знак табуляции \t — это только то, что постоянно встречается любому пользователю, про стандартные терминальные escape, EOT, и прочие bell и backspace даже говорить не хочу (хоть и можно придумать какую-нибудь увлекательную систему, где они не должны быть вводимыми, а должны распознаваться и обрабатываться непосредственно средой).
А ещё в эти управляющие символы входят перенос строки \n, любимый в windows возврат каретки \r, знак табуляции \t — это только то, что постоянно встречается любому пользователю, про стандартные терминальные escape, EOT, и прочие bell и backspace даже говорить не хочу (хоть и можно придумать какую-нибудь увлекательную систему, где они не должны быть вводимыми, а должны распознаваться и обрабатываться непосредственно средой).
+1
Я уточнил, что не все символы 0x00..0x2f, а только те которые не входят в набор POSIX. То есть все, исключая \0, \a, \b, \t, \n, \v, \f, \r.
По поводу телнета… текстовый файл в формате UTF8 тоже содержит коды 0x00 — 0x2f, и ничего.
По поводу телнета… текстовый файл в формате UTF8 тоже содержит коды 0x00 — 0x2f, и ничего.
0
В текстовой консоли используются все спецсимволы, им соответствуют сочетания клавиш от ctrl+A до ctrl+Z. telnet немного не в тему, он просто передаёт любые байты по сети, а их интерпретация уже осуществляется терминалом. А тут уже некорректен пример про utf-8, если в терминале выставлена соответствующая кодировка, то интерпретация происходит не на уровне отдельных байтов, а на уровне символов, состоящих из нескольких байтов (для utf-8 — от одного до шести вроде).
0
Да фигня, ASCII не надо менять — unicode уже достаточно хорошо поддерживается везде. Единственная проблема это удобно их вводить. Я использую типографскую раскладку, постоянно и очень естественно ввожу правильные кавычки, длинные тире, стрелки, никаких революций для этого не требуется. В языках кое-где можно сделать биндинги на юникодные символы (Хаскель их нативно понимает, в Clojure def/defmacro и вперед), но это украсит только мой личный код, даже коллег я не уверен что смогу уговорить.
0
На этом моменте я вставлю свою традиционную фразу о том, что пора бы забить на использование plain text для кода, а перейти на более богатый формат, способный хранить некое подобие AST. Тогда, во-первых, имеем профит с тулзами, которым нужно понимать структуру кода (хотя бы всякие diff/merge), а во-вторых, имеем отдельно модель-представление, т.е. рендерь как хочешь, никаких больше кровавых войн по поводу табов и пробелов или скобок на новой строке. Не говоря, конечно, о возможности вставить диаграмму прямо в коммент.
-1
Грамотно спроектированный язык программирования (т.е. в том числе и с учетом быстрого парсинга для IDE) позволит все это получить и на plain text тоже. Ведь какая разница — plain text, xml, binary xml или что-то подобное — все равно это файл с набором байт. Грамотный plain text будет отличаться от «богатого формата» только тем, что в нем будет использоваться какое-то подмножество символов, а не все множество 0x00..0xFF. А иметь возможность открыть файлик в любом текстовом редакторе это весьма полезно (по крайней мере до тех пор, пока не получил распространение какой-то универсальный двоичный формат для представления произвольных иерархических данных).
В современных языках не хватает в первую очередь скобок — одни только шаблоны на угловых скобках всю красоту ломают. Поэтому такие мысли и возникают — добавить еще пару-тройку скобок, простейшие стрелки и возможно какие-то универсальные математические/типографские символы…
В современных языках не хватает в первую очередь скобок — одни только шаблоны на угловых скобках всю красоту ломают. Поэтому такие мысли и возникают — добавить еще пару-тройку скобок, простейшие стрелки и возможно какие-то универсальные математические/типографские символы…
-1
Редактор в JetBrains MPS видели?
0
Добавлю, пожалуй, небольшое разъяснение. Вы сейчас рассматривали моё предложение с ортогональной точки зрения. Что-то в духе «зачем нам нужен docx, если он, как и plain text, всего лишь набор байтов? Давайте делать таблички ASCII-символами, а картинки не вставлять вовсе, потому что иметь возможность открыть файлик в любом текстовом редакторе — это весьма полезно».
0
Да я понял ваше предложение. Я и сам так думал когда-то.
В действительности написание программ в виде текста — это очень сильный стереотип, и разрушить его не так-то просто. Фактически, для этого нужно заново продумать самые фундаментальные вещи — так как даже элементарные операции типа copy и paste там будут (и должны) работать немного не так (а иногда и совсем не так). Программистам свойственно активно править код, нарушая при этом корректную структуру кода. Взяли и убрали закрывающую скобку… взяли и поставили открывающий комментарий, сидим и думаем где-бы его закрыть… В любом редакторе AST такое будет невозможно. То есть там в принципе будет невозможно сломать синтаксическое дерево, поэтому сам способ работы с кодом должен быть каким-то другим. А текстовые клавиатуры рассчитаны именно на ввод текста, а не узлов AST.
В действительности написание программ в виде текста — это очень сильный стереотип, и разрушить его не так-то просто. Фактически, для этого нужно заново продумать самые фундаментальные вещи — так как даже элементарные операции типа copy и paste там будут (и должны) работать немного не так (а иногда и совсем не так). Программистам свойственно активно править код, нарушая при этом корректную структуру кода. Взяли и убрали закрывающую скобку… взяли и поставили открывающий комментарий, сидим и думаем где-бы его закрыть… В любом редакторе AST такое будет невозможно. То есть там в принципе будет невозможно сломать синтаксическое дерево, поэтому сам способ работы с кодом должен быть каким-то другим. А текстовые клавиатуры рассчитаны именно на ввод текста, а не узлов AST.
0
Вы прямо markdown описали :) Ну, или любой другой язык разметки в plain text, например, *wiki.
0
Технически может это и нечто похоже. Похожее в том смысле, что в языках разметки можно вставить табличку или картинку, используя специальный синтаксис. Проблема в том, что если вы захотите встатить картинку в Markdown как-то так
но проипёте при этом, например, восклицательный знак, то документ становится невалидным в том смысле, что никакой картинки там уже не будет. А в том же MS Word это сделать (в похожем случае) достаточно сложно, если не невозможно.
Ну и нельзя не заметить, что Markdown — это просто текст. А с плейн-текстом есть следующая проблема: если вы пишете какой-то код, а потом, допустим, решаете переименовать функцию, вам нужно будет сделать это во всех местах. Да и diff будет выглядеть просто как одна строка, которую заменили другой строкой. Вы можете там точно так же ошибиться в принципе, как в примере выше. Или где-то в месте использования, допустим, можете забыть переименовать функцию. Если же хранить код в древовидном виде, близком к тому, в который код в plain-text преобразует компилятор, а также парсер IDE и прочие тулзы, то ваша функция фактически будет просто узлом в дереве с атрибутом «имя», а места использования этой функции — лишь ссылки на этот узел. Переименовали в одном месте — в остальных ничего менять не надо.
Выше NeoCode верно заметил, что в некоторых случаях такой подход повлечёт за собой необходимость избавиться от некоторых навыков работы и приобрести новые. Но я считаю, проблема решаема.
![Alt text](/path/to/img.jpg)
но проипёте при этом, например, восклицательный знак, то документ становится невалидным в том смысле, что никакой картинки там уже не будет. А в том же MS Word это сделать (в похожем случае) достаточно сложно, если не невозможно.
Ну и нельзя не заметить, что Markdown — это просто текст. А с плейн-текстом есть следующая проблема: если вы пишете какой-то код, а потом, допустим, решаете переименовать функцию, вам нужно будет сделать это во всех местах. Да и diff будет выглядеть просто как одна строка, которую заменили другой строкой. Вы можете там точно так же ошибиться в принципе, как в примере выше. Или где-то в месте использования, допустим, можете забыть переименовать функцию. Если же хранить код в древовидном виде, близком к тому, в который код в plain-text преобразует компилятор, а также парсер IDE и прочие тулзы, то ваша функция фактически будет просто узлом в дереве с атрибутом «имя», а места использования этой функции — лишь ссылки на этот узел. Переименовали в одном месте — в остальных ничего менять не надо.
Выше NeoCode верно заметил, что в некоторых случаях такой подход повлечёт за собой необходимость избавиться от некоторых навыков работы и приобрести новые. Но я считаю, проблема решаема.
0
Unicode везде есть, согласен; но я не случайно упомянул набор символов ASCII (который сейчас тоже является частью Unicode) — тут дело в том, чтобы символы были на всех клавиатурах мира; а поскольку ASCII есть везде, то логично включить их именно в ASCII, задействовав неиспользуемые коды. Кроме того, еще немало текстовых файлов создается и хранится именно в ASCII, и ничего плохого в этом нет.
-1
Во-первых, даже 32-х символов явно не хватит для всех хотелок. Во-вторых не очень понятно зачем что-то впихивать в ASCII во времена победившего Unicode.
+2
Ну так сложилось, что весь Unicode по факту делится на две части: символы, которые присутстуют на всех клавиатурах мира, и которые присутствуют только на части клавиатур. К первой группе относятся английские буквы, цифры и базовые символы из ASCII. Именно этот набор символов и принято использовать в языках программирования, по понятным причинам — чтобы разработчикам допустим из Европы не пришлось иметь дело с идентификаторами из китайских иероглифов.
То есть Unicode победил только в части внутрикомпьютерного представления информации; на клавиатурах для всего Unicode к сожалению просто нет места, поэтому там по-прежнему господствует ASCII, а Unicode представлен лишь частично и совершенно по-разному в зависимости от страны.
Отсюда и предложение с использованием незадействованных кодов… за счет своего расположения они ассоциированы с частью Unicode, доступной на клавиатурах всего мира (бывший ASCII).
То есть Unicode победил только в части внутрикомпьютерного представления информации; на клавиатурах для всего Unicode к сожалению просто нет места, поэтому там по-прежнему господствует ASCII, а Unicode представлен лишь частично и совершенно по-разному в зависимости от страны.
Отсюда и предложение с использованием незадействованных кодов… за счет своего расположения они ассоциированы с частью Unicode, доступной на клавиатурах всего мира (бывший ASCII).
+1
Про Unicode на клавиатурах, конечно, согласен, но что-то я не пойму, где на клавиатуре кнопки для неиспользуемых символов ASCII?
0
Как вторые (третьи для локализованных клавиатур) символы на буквах. И букв по количеству как раз примерно сколько, сколько там неиспользуемых кодов, так что все сходится:)
0
Так если нужна специальная раскладка чтобы такие символы вводить, почему бы не забиндить туда нормальные юникодные символы которые _уже есть_, а не придумывать и двигать опять стандарт?
0
Возможно это чисто психологический момент, но однобайтовые символы (т.е. из той части unicode которая раньше была ascii) воспринимаются как более «фундаментальные» что-ли. Где-то в одной группе с латинскими буквами и цифрами, которые есть везде — на любой клавиатуре, в любом шрифте, в любой локализации, которые прочитаются гарантированно правильно из любого файла.
Соответственно, нужно выбрать из множества unicode 25 наиболее важных символов и забиндить. Можно было бы даже голосование в интернете устроить:)
И еще огромное количество файлов, в том числе и исходных кодов, существует в однобайтовой кодировке, и в этом нет ничего плохого.
Соответственно, нужно выбрать из множества unicode 25 наиболее важных символов и забиндить. Можно было бы даже голосование в интернете устроить:)
И еще огромное количество файлов, в том числе и исходных кодов, существует в однобайтовой кодировке, и в этом нет ничего плохого.
0
В любом языке полно составных знаков: ->, <=, ++, :=. По смыслу это один символ, но составленный из нескольких более простых. Мозгу требуются дополнительные усилия на то, чтобы считать и объединять такие конструкции на лету.
По-моему, проблема высосана из пальца. Никаких дополнительных усилий тренированному мозгу не требуется, чтобы заниматься иероглифическим чтением. Вот прямо сейчас вы читаете мой комментарий, не объединяя на лету буквы в слова, а воспринимая слова целиком как единое целое.
+18
Отдельно стоит отметить, что хоть тут и нет проблемы затрудненного восприятия, возможно, для кого-то есть проблема эстетического характера, ведь составные операторы могут быть субъективно некрасивы.
+3
Более того, в подтверждение, если в части слов убрать некоторые бквы (гласные, к примеру), текст всё равно будет прчтн и понят, и только при детальном рссмтрни можно заметить подвох. Вообще, имхо, программерский шрифт не должен изменять вид вводимого кода, а том количество WTF/min может сильно возрасти.
0
Объединение дефисов и угловых скобок продольной линией плохо смотрится…
+1
Я вижу несколько проблем:
1. Набор лигатур для разных языков программирования будет разным.
2. Даже в одном языке программирования одно и то же сочетание символов может значить разные вещи. Например в C++ '>>' может быть как оператором сдвига, так и двумя закрывающими скобками в шаблонах, и в идеале должны отображаться по-разному. То есть без разбора языка тут не всегда можно обойтись.
1. Набор лигатур для разных языков программирования будет разным.
2. Даже в одном языке программирования одно и то же сочетание символов может значить разные вещи. Например в C++ '>>' может быть как оператором сдвига, так и двумя закрывающими скобками в шаблонах, и в идеале должны отображаться по-разному. То есть без разбора языка тут не всегда можно обойтись.
+4
Ну я пока из принципиального наткнулся только на разное значение /= в Хаскелле и во всех остальных языках. Понятно что на J наверное на таком шрифте не попрограммируешь :)
Плюс, сами по себе лигатуры не навязывают никакой семантики. Как раньше >> выглядел одинаково в семантически разных контекстах, так и сейчас будет выглядеть одинаково.
Про закрывающие скобки в C++, вроде бы есть практика их специально разделять пробелом чтобы не смущать компилятор неоднозначностями?
Плюс, сами по себе лигатуры не навязывают никакой семантики. Как раньше >> выглядел одинаково в семантически разных контекстах, так и сейчас будет выглядеть одинаково.
Про закрывающие скобки в C++, вроде бы есть практика их специально разделять пробелом чтобы не смущать компилятор неоднозначностями?
0
1. Ну с ходу:
2. Использование >> в шаблонах было нелегальным в старых стандартах, но было разрешено в C++11.
a<-b
в C++ значит: a больше чем (минус b). Но будет нарисована стрелка.2. Использование >> в шаблонах было нелегальным в старых стандартах, но было разрешено в C++11.
+4
Мне кажется, если не замахиваться на изменение символов, а просто сделать выравненные символы, то это было бы и функционально и эстетично. Слишком уж много неоднозначностей может вызвать.
+1
Очень клевая штука. Думаю, станет популярной, когда появится поддержка Sublime Text и WebStorm. Я бы себе поставил.
+2
Когда саблайм и идея научатся нормально показывать юникод, вы хотели сказать :)
-1
А саблайм не умеет показывать нормально уникод? Нормально — это как?
0
Умеет. Лигатуры — это не юникод, это фишка open type font. В редакторах кода они как правило отключены за ненадобностью и чтобы fi в один символ не схлопывался (в некоторые моноширинные шрифты добавляют такую лигатуру).
0
Нормально, с моей точки зрения, это не так:
habrastorage.org/files/8a8/580/f86/8a8580f8674542b8925ee1f774dad8c8.png
habrastorage.org/files/8a8/580/f86/8a8580f8674542b8925ee1f774dad8c8.png
0
А вставьте этот текст сюда же, пожалуйста, хочу у себя посмотреть.
0
А, нашел, у меня это выглядит так:
0
А вот это уже странно. Попробуйте шрифт поменять. Потому что у меня-то хоть объяснимо с точки зрения разработчиков редактора кода: «покажем комбинируемый символ отдельно». А у вас похоже на проблемы с комбинируемыми акутами в самом шрифте. ОС какая? Давайте все-таки текстами обменяемся: «Barçelona Barçelona». В первом слове ASCII-8, во втором — комбинируемая диакритика.
0
Второе слово вашего текста выглядит просто как Barcelona (неотличимо, без лишних пробелов или отступов), однако после c-таки нечто есть, при удалении 'c' стирается за 2 backspace. В названии же вкладки всё выглядит корректно.
ОС Windows, Sublime Text 3, Lucida Sans Unicode. Разные шрифты не помогают.
ОС Windows, Sublime Text 3, Lucida Sans Unicode. Разные шрифты не помогают.
0
А можешь выложить какие-то более живые примеры кода?
0
habrastorage.org/files/a29/609/56d/a2960956d5dd46279fa19f4956c219e9.png
habrastorage.org/files/a44/485/451/a4448545134b47559710471fd285a4fd.png
habrastorage.org/files/1e5/af4/713/1e5af4713a884ac1a6490f35379ee4ac.png
habrastorage.org/files/707/64f/b1c/70764fb1cc3a4014be69b3b845779ddd.png
habrastorage.org/files/2d2/55e/194/2d255e19481d4ad8bbe88702a40ad4b6.png
habrastorage.org/files/a44/485/451/a4448545134b47559710471fd285a4fd.png
habrastorage.org/files/1e5/af4/713/1e5af4713a884ac1a6490f35379ee4ac.png
habrastorage.org/files/707/64f/b1c/70764fb1cc3a4014be69b3b845779ddd.png
habrastorage.org/files/2d2/55e/194/2d255e19481d4ad8bbe88702a40ad4b6.png
+1
Гигантское спасибо.
Единственный вопрос: вы Fira выбрали потому, что вам она нравится? Почему, к примеру, не Ubuntu Mono? У них какая-то неприятная лицензия?
Единственный вопрос: вы Fira выбрали потому, что вам она нравится? Почему, к примеру, не Ubuntu Mono? У них какая-то неприятная лицензия?
0
Ага, он у меня и до этого стоял рабочим шрифтом.
0
Эх, вот всегда в людях, создающих маленькие шедевры, не все идеально :)
0
Кстати да, как замутить такую фишку на своём шрифте? Какие программы для этого нужны + входной формат исходного шрифта?
0
Я думаю, идеально, как всегда, попросить исходники и работать в том же тулинге, что и автор шрифта. Я взял trial version RoboFont, им декомпилировал otf в ufo и в нем же рисовал лигатуры, прописал feature liga и экспортил обратно в otf. Я в шрифтах слабо разбираюсь, но как программист подозреваю что там куча информации могла потеряться в таком процессе реверс-инжиниринга. Мозилла выкладывает исходники Fira Mono в UFO, но я не смог ни одним редактором их открыть к сожалению.
+1
В том же тулинге, что автор шрифта, с гарантией не удастся; я подозреваю, профессиональные инструменты стоят как крыло от боинга.
0
Ну да, зато у RoboFont и Glyphs.app например есть 30-дневный триал, так что можно выкрутиться.
0
Интересно, можно ли как-то автоматизировать этот процесс. Если шрифт юникодный, то в нем ведь все эти стрелочки уже есть, нужно просто перенести их в лигатуры, добавив нужное количество пространства по бокам для выравнивания, так?
0
Если часть лигатуры совпадёт с поиском по коду (например, ищу! в блоке кода), что будет выделено?
+1
Зависит от редактора, похоже. В LightTable поиск разбивает лигатуру, а простой selection нет:
habrastorage.org/files/b5f/ba2/b36/b5fba2b362904648b759c4c1e1360172.png
habrastorage.org/files/c24/0e1/27a/c240e127aab145e890dd86eb1c711eae.png
А в Atom ничего не портится:
habrastorage.org/files/737/7f7/4d7/7377f74d715349dfbec4e4a8e6fe1a32.png
habrastorage.org/files/b5f/ba2/b36/b5fba2b362904648b759c4c1e1360172.png
habrastorage.org/files/c24/0e1/27a/c240e127aab145e890dd86eb1c711eae.png
А в Atom ничего не портится:
habrastorage.org/files/737/7f7/4d7/7377f74d715349dfbec4e4a8e6fe1a32.png
+1
Атом использует codebase хрома, а хром очень аккуратно относится к поиску по юникоду (даже слишком аккуратно). Например, поиск по этой странице «ℝ» найдет over9000 вхождений.
0
Так и LightTable тоже. Лигатуры с юникодом никак не связаны, они здесь все из ASCII состоят если что. Вопрос в том как отображать выделение, или найденные результаты. LightTable вставляет дополнительный span похоже и подкрашивает его цветом. На границе span-а понятно что лигатур не будет. А в atom просто рисуют поверх, наверное в доп. слое.
+1
В VS тоже вроде все ок (лигатуры всегда рисуются, поиск подсвечивает найденную половину).
0
Есть мнение, что эти стрелочки, чёрточки и прочие закорючки вообще не улучшают понятность кода. Лучше использовать слова или хотя бы сокращения.
Я и обычные-то лигатуры типа «fi» считаю ерундой и непонятно они зачем нужны в компьютерный век, а тут ещё и специальные какие-то.
Я и обычные-то лигатуры типа «fi» считаю ерундой и непонятно они зачем нужны в компьютерный век, а тут ещё и специальные какие-то.
-2
Очень спорное решение, явно все на этот шрифт не перейдут, учить новичков смысла нет, тех кто уже привык к текущему положению дел в большинстве случаев не перетащить. Да и совсем не понятно почему страдает читабельность кода в текущем виде. Программист личность аскетичная и его радует не новый вид символов, а качество программного кода.
+5
А при чем тут общественное мнение, простите? Это шрифт в моем редакторе, почему он должен нравиться кому-то еще?
0
Есть ответное мнение, что хороший программист тяготеет к прекрасному. И прекрасное выражается не только в «красивом» коде, но и красивом UI, который они проектируют или которым пользуются сами.
0
Не туда ответил. Хотел на уровень выше.
0
Есть мнение, что я абсолютно с вами согласен; я как раз возражал тезису «явно все на этот шрифт не перейдут». Я-то сразу перешел.
0
К сожалению, лигатурами невозможно добиться всего, чего хотелось бы, ибо не хватает возможности задавать контекст.
Например, было бы (возможно не для всех) круто, если бы
C конъюнкцией и дизъюнкцией, допустим, тоже сложно. Можно заменять
Кстати, почему в Fira Code есть сочетание
Нет совершенства :(
Например, было бы (возможно не для всех) круто, если бы
!
или not
в логических выражениях заменялся на ¬. А в хаскеле с ним ещё и другая проблема. C конъюнкцией и дизъюнкцией, допустим, тоже сложно. Можно заменять
&&
на ∧, а вот ||
в некоторых языках используется в list comprehensions, а не как logical or.Кстати, почему в Fira Code есть сочетание
/>
для тегов, но нет </
? Нет совершенства :(
0
Да… в C++ особенно весело будет «заменять && на ∧». Как прикажете отличать от ^?
+1
Как два пальца: заменяем
^
на ⊕
, и вуаля.0
Нет, Halt имел ввиду, что && в C++ используется также для обозначения rvalue references, и в таком качестве не должен ни на что заменяться.
0
Контекст и склеивание символов в лигатуры — это не проблемы лигатур. Если не считать шрифты абсолютным отображением байтов в памяти, то такой проблемы нет. На диске лежит
&&
, парсер читает оператор-конъюнкции, редактор выдаёт глиф LOGICAL AND (U+2227), рендерер выбранного шрифта отображает ∧.+1
Мне понравилось, как вводятся уникодные в Agda2, сделал аналогично в SublimeText в UnicodeMath. С учётом наличия в Haskell base-unicode-symbols и прагмы UnicodeSyntax, выходит удобно.
0
Вашим плагином я пользуюсь каждый рабочий день и очень благодарен. Но всё же это вставка юникодных символов, а тут меняется только отображение. Раньше пользовался vim-conceal для этого, но это третий тип решения и привязано к редактору…
0
Посоветуйте, пожалуйста, моноширный шрифт, имеющий различное написание кириллицы и латининицы. Очень хотелось бы видеть русские буквы, написанные случайно вместо латинских.
0
Любой шрифт, в котором кириллических букв попросту нет.
-1
Это не совсем то, что нужно. Насколько я понимаю, в зависимости от редактора, будет отображаться либо первым попавшимся ему шрифтом, либо символ-заглушка (т.е. будет непонятно, что написано кириллицей). Хотелось бы просто комфортной работы (конкретно, в Visual Studio) и одновременного понимания, в каких местах используются русские буквы.
Сейчас в подобных случаях использую поиск по регулярному выражению [а-я] (VS очень удобно подсвечивает все найденные места), но для этого нужно делать дополнительные действия (т.е. выполнить поиск).
Сейчас в подобных случаях использую поиск по регулярному выражению [а-я] (VS очень удобно подсвечивает все найденные места), но для этого нужно делать дополнительные действия (т.е. выполнить поиск).
0
Не могу понять вот что: если в спецификации языка написано, что после вот таких символов ставится, скажем, набор знаков "::" или "-->", то зачем менять то, что написать в стандарте, на то, что захотелось левой пятке?
Я понимаю, что привычные в почти любом языке переменные i, j, k можно заменить на картинку смайлика (причем даже разный: скажем, переменную i целого типа — на смайлик «белый», а float — на «черный», но — зачем?.. Из буханки вот тоже многое можно сотворить…
Лигатуры — выход изящный, но уж очень он на любителя!
Я понимаю, что привычные в почти любом языке переменные i, j, k можно заменить на картинку смайлика (причем даже разный: скажем, переменную i целого типа — на смайлик «белый», а float — на «черный», но — зачем?.. Из буханки вот тоже многое можно сотворить…
Лигатуры — выход изящный, но уж очень он на любителя!
-1
В Visual Studio у меня не работает :-(. Нужно создать на UserVoice предложение
0
Что именно у вас не работает? У меня на VS 2013 вроде бы полет нормальный.
0
Что-то не фурычит. Вот Fira Code:
А вот Droid Sans Mono:
А вот Droid Sans Mono:
0
Так gVim же в списке No support. Откройте нормальным редактором
0
Эмм. Это вообще с каких пор это ненормальный редактор?! Низачот.
P.S. Если другие фонты работают, а Ваш — нет, проблемы, наверное в редакторе, да, так?
P.P.S. Если Вы не поняли, лигатуры работают. Но кодировка слетает.
P.S. Если другие фонты работают, а Ваш — нет, проблемы, наверное в редакторе, да, так?
P.P.S. Если Вы не поняли, лигатуры работают. Но кодировка слетает.
0
Ну да, проблема в редакторе, чему вы так удивляетесь? Поддержка лигатур — отдельная фича, она либо реализована, либо нет, либо реализована неправильно. Откройте страницу github.com/i-tu/Hasklig и прочитайте:
No support. Some editors have replaced standard font rendering engines with custom ones and don't support ligatures:
* gVim (output corrupted. A patch exists, but it has not been incorporated into mainstream gVim.)
No support. Some editors have replaced standard font rendering engines with custom ones and don't support ligatures:
* gVim (output corrupted. A patch exists, but it has not been incorporated into mainstream gVim.)
+2
По смыслу это один символ, но составленный из нескольких более простых
Нет. Это один символ (единица информации), составленный из нескольких знаков (единица написания).
А статья отличная!
0
Хотя и не вижу (для себя) профита от шрифтов с лигатурами: код должен выглядеть так, как ты его символ за символом вводил, но за работу спасибо! Открыл для себя Fira Mono, добавил в свою коллекцию: htrd.su/wiki/zhurnal/2010-11-27_13.25_shrifty_dlja_koda
0
del
0
Оперделенно, нововведение заслуживает внимания — это настолько же лучше текущего положения вещей, насколько математическая формула записанная спецсимволами лучше жалкого ASCII-подобия. Ну и с лигатурами выход интересный.
+1
В emacs есть пакет, который заменяет при отображении lambda в коде лисповых программ на соответствующую греческую букву (исходный код остаётся неизменным). Такой подход позволяет использовать в листингах на разных языках разные наборы замен.
0
только выравнивание едет, да?
0
Смысл моего комментария в том, что надо делать это не на уровне лигатур (а то ведь придётся делать несколько шрифтов для разных языков), а на уровне редактора, но по тем же принципам (моноширинность и т.п.).
+2
>Мозгу требуются дополнительные усилия на то, чтобы считать и объединять такие конструкции на лету
А много дополнительных усилий мозгу требуется на то, чтобы считатьлигатуры буквы
Для выделения образа мозгу не требуется его графическая связность. Поэтому и токен
А много дополнительных усилий мозгу требуется на то, чтобы считать
Ы
, Ё
, Й
? Опознать число 10
?Для выделения образа мозгу не требуется его графическая связность. Поэтому и токен
>=
или !=
мозг выделяет с такой же лёгкостью, как графически неразрывный символ. Вот отделять от окружающих символов пространством требуется для упрощения восприятия в любом случае. Поэтому a = 5
, но не a=5
.+1
А на eclipse под виндой это как-то можно завести? Шрифт поставил, выбрал, но эклипсу это до фени.
0
Такому шрифту нужен конфигуратор, включать-выключать фичи
И чтобы каждый мог запилить свою фичу легко и просто
И чтобы каждый мог запилить свою фичу легко и просто
0
Это здорово, использовать ≤ ≥ ≠ вместо >= <= !=. Ну а остальное есть в Юникоде, для примера: ≪ ≫ ⩵ ⩶ ⇔ ⟺ ⬄ ⇒ ⇐. Осталось только сделать раскладку для клавиатур и научить языки программирования понимать эти символы.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моноширинные шрифты с программистскими лигатурами