Emacs *

Принцип минимальной навигации

Некоторое время назад я разработал режим GNU Emacs для редактирования конфигурационных файлов операционной системы Embox. Кроме всестороннего изучения Emacs Lisp мне потребовалось разобраться со структурой модуля режима, а также процессом и требованиями к публикации пакетов в MELPA, наиболее популярном архиве пакетов для GNU Emacs. В этом руководстве я расскажу, что нужно знать, чтобы написать свой собственный режим, и как опубликовать свой собственный пакет.

Если совсем коротко: «грамотный DevOps» (Literate DevOps) – это использование принципов «грамотного программирования» (Literate programming) для работы с инфраструктурой в виде кода. Термин Literate DevOps придумал Говард Абрамс, и он же показал, как реализовать его с помощью Emacs и Org.

Теперь подробнее.

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

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

Звучит прекрасно, не так ли? Может, когда‑то и казалось сказками, однако не сейчас.

Кто-то из вас наверняка задавался вопросом: а нельзя ли программировать Arduino на чём-то более современном и удобном? Вот и я задавался. И нашёл Rust (не то, чтобы я о нём не знал). И на нём можно программировать микроконтроллеры AVR и платы Arduino, построенные на них. И здесь я расскажу о том, как настроить среду разработчика на Rust в Linux, GNU Emacs и Visual Studio Code и как запрограммировать Arduino Uno на моргание светодиодом.

#![no_std]
#![no_main]

use ruduino::Pin;
use ruduino::cores::current::{port};

#[no_mangle]
pub extern fn main() {
    port::B5::set_output();

    loop {
        port::B5::set_high();
        ruduino::delay::delay_ms(1000);
        port::B5::set_low();
        ruduino::delay::delay_ms(1000);
    }
}

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

Считаю, что такое стандартное объяснение популярности LSP – неверное. Ниже предложу вам альтернативную трактовку.

К старту курса по тестированию на Python при помощи шаблона Read the Docs, пакетов restclient, ob-restclient и Org Mode в Emacs напишем красивую, полезную документацию API, которая генерируется автоматически и легко отображается на статическом сайте.

Насколько я знаю многие программисты используют VIM, а некоторые также используют VIM, но они это делают в EVIL (злом) режиме, это значит, что эти люди понимают все прелести VIM (быстрое редактирование текста без использования мыши, наличие нескольких режимов и т.д.). Но также я знаю, что VIM был сделан несколько миллионов лет назад, для программистов того времени, поэтому VIM использует не все возможности которые мог бы, например: Клавиша для входа в командный режим находится фиг знает где, в самой жопе самом углу клавиатуры (и. да я знаю что это можно легко поправить в .vimrc), также если я захочу поменять свой редактируемый файл, то мне нужно:

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

Позвольте мне начать с пары слов для тех кто не в курсе. Lisp - это семейство языков, включая Common Lisp, Emacs Lisp и несколько диалектов, которые...

Чтобы начать

M-x list-packages

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

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

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

Часто приходится видеть, как новички пробуют Common Lisp и потом жалуются, что с ним невозможно нормально работать. Как правило, это происходит из-за того, что они не понимают как настроить себе процесс, обеспечивающий тот самый "быстрый отклик" от среды разработки, когда ты поменял функцию, скомпилировал её и изменения тут же начали использоваться внутри уже "бегущей" прогрммы без её перезапуска.

Понять, как это выглядит, можно посмотрев какой-нибудь ролик на youtube, где демонстрируется интерактивная разработка на Common Lisp.

Впервые про TECO я прочитал в пародийной статье Real Programmers Don't Use Pascal, написанной незадолго до моего рождения. Там было написано, что настоящие программисты не используют новомодные редакторы EMACS и VI:

Нет, Настоящий Программист хочет редактор вида «Просил? Так получай!» — сложный, загадочный, мощный, не прощающий ошибок, опасный. TECO, если быть точным.

Оригинал

No, the Real Programmer wants a `you asked for it, you got it' text editor — complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

Это меня заинтриговало. Что за зверь такой, можно ли его пощупать? Википедия рассказала, что TECO — это Text Editor & COrrector, создан он в 1962-м году в DEC и использовался на компьютерах семейства PDP, а позже на системах OpenVMS. Оказалось, что существует порт на Си, который поддерживается энтузиастами в актуальном состоянии и собирается под современными операционными системами. Вот я и решил почувствовать себя настоящим программистом хотя бы немножко.