Редактор кода/IDE с возможностью цеплять картинки в качестве комментариев?

Можно, наверное, и так. Я просто сразу про Literate Haskell подумал, но для других языков такой штуки вроде нет.

В emacs org-mode есть поддержка такой штуки, как литературное программирование:

https://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming

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

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

Другим вариантом будет написать minor-mode, который вместо пути с файлом будет отображать картинку, готовые примеры можно глянуть в исходниках того же org.el (функция org-display-inline-images в org.el, если не ошибаюсь).

Кстати, правда неплохая идея, можно реализовать на досуге.

Таки да.

Тогда попробуй iimage-mode в Emacs. Режим уже входит в поставку. Включаешь режим, пишешь в буфере file://mypicture.jpg, и всё - она появится.

Вот только не надо притягивать за уши Кнута в упоротый тред, окда?

Тогда попробуй iimage-mode в Emacs.

Вот как это выглядит: https://imgur.com/a/39R5PyV

Очень плохая статья. Такое говнокомментирование я никогда не писал, даже когда был совсем зеленым нубом, т.к. в этом нет смысла. Комментировать надо либо когда в коде происходит что-то непонятное, либо каждую функцию(метод) и класс описывать для doxygen-а.

Вот только не надо притягивать за уши Кнута в упоротый тред, окда?

«не всякое оценочное суждение должно служить модификатором поведения»(c)

Во-первых, апеллирование к авторитету выставляет тебя школотой потноладошечной.

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

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

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

$ wc -l batteries.tex fast-lion.?pp Makefile fast_lion.py run.py
 1026 batteries.tex
  401 fast-lion.cpp
  112 fast-lion.hpp 
    5 Makefile
  134 fast_lion.py
   24 run.py
 1702 итого

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

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

Ну и в заключение:

template <typename T> Vec<3, T> perp(const Vec<3, T> &a){ 
	Vec<3, T> a_fabs = a.fabs(); 
	int i_min = a_fabs[0]<a_fabs[1]?0:1; 
	if(a_fabs[i_min]>a_fabs[2]) i_min = 2;
	Vec<3, T> ort; ort[i_min] = 1.; Vec<3, T> p = ort%a;
	return p/p.abs(); 
} 
template <typename T> Vec<3, T> gauss_rotate(const Vec<3, T>& a, T g){
	return rotate(a, rotate(perp(a), a*T(rand_alpha2PI*random()/a.abs()))*T(g*rand_gauss())); 
}

А теперь расскажите мне еще про то, что код должен быть лаконичным, бггг.

Спасибо. Че то у меня сходу не завелось (пишет Cannot display image: (Cannot determine image type)), но думаю разберусь...

Беда в том, что у меня все коллеги ушли в vim. Но с другой стороны это будет хороший повод для троллинга;-)

Я баловался с литературным программированием, но немного в другом ключе - писал систему, которая исходный файл раздербанивает по нескольким исходникам и запускает шелловские команды. Было забавно, получалось одним выстрелом документация с примерами в LaTeX и набор uinit-тестов, но чересчур сложно - не прижилось...

Для реальных проектов с коллегами боюсь оно точно не взлетит, но себе облегчить жизнь можно. Коллегам оставлю то что Doxygen ваяет.

Файл точно с картинкой и не битый? Путь указан правильно? Если без полного пути, то будет искать в текущей директории.

UPD. Там еще можно указывать в формате [[picture.jpg]] или </home/user/test.png>, но мне не особо нравится, так как такое может в коде встречаться. Поменять формат указания картинки можно через переменную. Там regexp свой только написать.

О, завелось! Но грустно что не умеет из поддиректорий доставать.

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

Почему не умеет? Путь укажи в поддиректорию только. И C-l можно нажимать, чтобы текст в картинку превращался.

UPD. Кроме того:

iimage-mode-image-search-path’s value is nil

Documentation:
List of directories to search for image files for iimage-mode.

А, ну если через ./picts/picture.png указывать то умеет, это норм.

.pdf он у меня похоже не тянет.

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

чёт никто не вспомнил про http://jupyter.org

https://tproger.ru/translations/jupyter-notebook-python-3/

Спасибо, я о нем не знал. Но это же очередной вариант matlab-а и ко, только в качестве языка выбран питон?

В 2050 сорцы будут не в плейнтексте, а в виде наглядых приложух на электроне

В юникодовых значках Курица или яйцо (комментарий)

Это еще почему? Литературное программирование вот об этом как раз. Но там надо программировать перемежая чанки текста и кода, показывать картинки должен редактор который такой исходник переваривает (картинки показывает которые тут возжелали), ну и этап компиляции док + сырцов обязателен при сборке.

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

Ну из новомодного для такого стиля там писатели юпитернотебука создали что то десктопное.

Вижуал басик Оберон на кабардинском, очевидно.

Помню в Dos Navigator был отличный режим рисования псевдографикой. В емаксе вроде тоже что-то такое есть.

А вообще да, не понимаю почему в 2018 году нет IDE со стикерами!

в Dos Navigator был отличный режим рисования псевдографикой

Эта функциональность совершенно точно перекочевала в современный FAR Manager.

я таки сделаю одну попытку

«you failed, try again»

Хотя нет, лучше не продолжай.

Но ведь статья не про комментирование вовсе, и даже не про компактный код.

Статья о каких-то сферических розовых единорогах в вакууме. Так никто не комментирует, даже школьники. Основная ошибка которую я встречаю — когда не прокомментирована магия, которая делается понятной спустя час ковыряний кода, ругани и желания найти автора сего непотребства. У тех кто излишне увлекается комментированием, как правило, проблемой является название переменных как a, b, c и прочие неосмысленные названия. Как только они с этим справляются, то и комментарии пропадают, иногда, к сожалению, совсем.

Dr.Racket.

Основная ошибка которую я встречаю — когда не прокомментирована магия

Значит, ты счастливый человек, не сталкиваешься с вопросами, поднимаемыми в статье, которая, повторюсь, совсем не про комментирование.