Результаты опроса пользователей Emacs

Некоторые юзают даже notepad/nano. Вопрос не о том, кто что юзает, а о том, какой инструмент является оптимальным для решения какой-то задачи

Ответ такой же: некоторые юзают даже notepad/nano. Вопрос не о том, кто что юзает, а о том, какой инструмент является оптимальным для решения какой-то задачи

Но из него нельзя сделать todo

Из любого текстового файла можно сделать todo

А в org-mode ещё и интеграция с календарём…

Это нужно не всем. Я, например, не пользуюсь календарём. У меня даты в todo записаны

Даже отдельные приложения-планировщики сосут у org-mode стоя на табуретке.

Всё зависит от потребностей. Кому-то и taskwarrior вполне

А так-то да, никто и не спорит о том, что org-mode мощное средство:)

Я, например, не пользуюсь календарём. У меня даты в todo записаны

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

Кому-то и taskwarrior вполне

Он требует слишком много времени на само ведение todo. Я пытался несколько раз. Проще оказалось вести в текстовом файле.

А так-то да, никто и не спорит о том, что org-mode мощное средство:)

Не обязательно использовать org-mode на 100%, но там даже ведение todo сделано удобно.

Мне не нравится Emacs за ориентированное на осьминогов управление (у меня лапки, я нишмок ☹), но отрицать что в нём есть такой крутой функционал просто глупо. Конкретно org-mode в Emacs сделан просто шикарно, и это уже достойный повод дать Emacs шанс стать рабочим инструментом даже для такого упоротого вимера (vi-like не прикручен разве что в GIMP) как я. :3

Контроль версий важен именно сам по себе в первую очередь (структура изменений - это уже специфика). Например, книгу могут писать коллективом авторов, одна глава - один файл, один автор.

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

Теоретически да, на практике окружение будет тебя стачивать

Тут соглашусь. Если можно что-то делать через жопу, люди обязательно будут так делать.

Какие удобные инструменты для коллективной работы и «контроля версий» в контексте написания именно художественной литературы или, ну я не знаю там, законопроектов, допустим, ты знаешь? Возможно, у тебя есть концептуальные идеи в разрезе той критики, что звучала здесь в адрес традиционных dvcs?

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

И это в том числе.

Далее, что мешает разбивать текст по строкам?

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

Но изменения могут быть и косметическими, типа пропущенной запятой. И вот у тебя коммит, в котором всё разбито по строкам, и коммент: исправлена пунктуация. Ну и в чем проблема?

Хотя бы в том, что «построчность» в каком-либо виде здесь - инородная составляющая. Возможно, кроме диалогов в тексте.

Кроме построчного diff существует пословный, который игнорирует перевод строки.

А в emacs есть очень удобная кнопка M-q (fill-paragraph) которая существенно упрощает работу с абзацами. Отредактировал и тут же подогнал по ширине.

Научруку моему отслеживать правки статьи на гитхабе очень даже нравилось.

Какие удобные инструменты для коллективной работы

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

концептуальные идеи в разрезе той критики

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

Кроме того, хотелось бы иметь поддержку параллельных абзацев. Т.е. по сути ветки, но не глобальной, а с привязкой к единице управления (абзацу). Также неплохо было бы иметь возможность тегирования абзацев по отдельности. Например чтобы организовать нумерацию абзацев тегами, типа #c7/p11 - глава 7, абзац 11. Чтобы при коммите выбирать абзацы не только по хэшу, но и по тегу, с глобами, как это делается для имён файлов. Типа c7/p* - все абзацы седьмой главы, или даже c7/p10-p40:v2 - абзацы седьмой главы с 10 по 40 в варианте (с тегом) v2.

Слияние в такой системе при конфликтах может добавлять параллельный абзац. Дальше автор сам разруливает по смыслу.

для этого есть Scrivener и/или articy:draft

пыщь

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

Не говоря уже про ветки и их слияние, которое тоже должно учитывать структуру текста.

такое наверно можно написать вот в таком духе irmin : Key-Value хранилище из MirageOS unikernel, которое для хранения использует Git (или что напишешь) и где можно определять свои структуры и способы их слияния, автоматического разрешения конфликтов (по структуре).

но всё равно как такой «структурный diff» должен выглядеть толком не понятно. разбирать на какое-то NLP представление и там чего-то сравнивать? будет типа ужоса в стиле xmldiff завёрнутого.

в общем, сложно сообразить как такой «структурный редактор» со «структурными диффами» должен выглядеть – чтобы им было удобно пользоваться.

у переводчиков например есть память переводов, у техписов – DITA где через XML такую память можно merge-ить полуавтоматически. но там XML, да.

+ merging data structures

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

как будто бы что-то плохое

вопрос про то как ты собрался коммитить произвольный кусок который автор считает изменением «по смыслу», а не то что git посчитал изменением «фактически по строчкам»

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

чего-то подобного было в дипломе Cris Martens про linear temporal logic для нелинейного повествования, она там емнип сабж на окамле реализованный (по сути применённый как пролог, только более оптимизированный, cepf) использовала для раскрытия такой логики.

например, про ромео и джульетту. и все эти ветки сюжетные. там в итоге на dot граф полуавтомаГически формировался по такой вот логической программе в linear temporal logic.

потом вот на каком-то таком типа Irmin Key-Value хранилище (хранимом и в Git object database в том числе) потом такое слияние/разрешение конфликтов можно формализовать и автоматизировать, см. ссылки выше.

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

чтобы такой «структурный diff» к «структурному редактору» написать.

Ты можешь написать несколько альтернативных вариантов абзаца и они все «правильные» и должны какое-то время существовать параллельно. Это не ложится в последовательные коммиты-фиксы от слова совсем.

Literate Programming code chunks/documentation chunks, например. для законченных смысловых единиц как single source.

при написании текстов совсем другой воркфлоу. В коде ты движешься от «нет кода», через «кривой код» к «правильный код». С текстом у тебя нет конкретного «правильного текста». Ты можешь написать несколько альтернативных вариантов абзаца и они все «правильные» и должны какое-то время существовать параллельно. Это не ложится в последовательные коммиты-фиксы от слова совсем.

вообще какой-нибудь Memex для Emacs напоминает, например.

это, да это хорошее

ну я не знаю там, законопроектов

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

Поверь, vim не хуже ostorybook

Ну вот я не знала что емаксеры любят gui.

C vim вообще не так

что емаксеры любят gui

Там gui чисто номинальный. Просто вьюпорт в котором emacs себя рисует. Всякие свистелки типа тулбара судя по опросу большинство отключает. Я тоже отключаю и делаю окно в full screen без заголовка и рамок.

Ну вот я не знала что емаксеры любят gui.

Ты зачем пол сменила?

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

Напрасно. Говно этот vim.

Напрасно. Говно этот vim.

А что не говно? Если начал квакать про говно, то ты должен обосновать свои потуги

А что не говно? Если начал квакать про говно, то ты должен обосновать свои потуги

Так я захожу квакнуть раз в месяц :). Когда же обосновывать? Но попробую…

Итак, существует окончательная и не подлежащая сомнениям книга — библия юзеринтерфейсов — покойного Джефа Раскина: «The Humane Interface». В ней недвусмысленно указано: модальный интерфейс есть зло!

К этому я лично пришёл ещё много лет назад. Я тогда использовал vim, кастомизируя его, добавляя шорткаты… И в какой-то момент обнаружил, что работаю практически всегда в insert-моде. Потому что интерфейс, лять, должен быть прозрачным: в любой момент нажатие клавишной комбинации должно приводить к одинаковому результату. Тогда я сказал себе: Вася, не би мозг, а просто используй Emacs.

Отсюда и вывод: vim — говно.