Насколько это нужно начинающим? Будет ли это часто используемым? Прослеживаются ли частые вопросы по этой теме на форумах? Если да, то это уже один из возможных поводов внедрения этого функционала. Если нет - стоит подумать нужно ли оно.
В то же время, хотя в первую очередь стоит реализовывать достаточно нужный (ссылка на первый пункт) пользователям функционал, ограничивать себя только этим - не стоит. Запас - дело хорошее. Но, есть риск сделать никому ненужные или нужные, но малому количеству пользователей по отношению ко всему их количеству “плюшки”.
Сделать “исключение” раз, а потом и ещё - легче, чем первый. Не превратится ли учебный модуль с подобными предложениями в что-то громоздкое для изучения, как Windows Forms/WPF/Avalonia? По капле и наберётся море возможностей… И не факт, что все будут востребованы. Это - противоположное мнение.
Добавлю, что нет чёткой последовательности исправления Issue, благодаря чему становится возможным откладывать некоторые улучшения и исправления надолго. Была бы чётко-прослеживаемая последовательность действий - было бы легче и пользователям и разработчикам. И претензии пользователей по поводу почему что-то не исправляется быстро объяснялись простым способом - очередь до данной Issue не дошла. Разумеется, планировка займёт время, но впоследствии повысит производительность работы.
Если бы IDE поддерживала ToDo-списки не только в плане подсветки синтаксиса, то было бы гораздо удобнее с ними работать. Иначе - если ToDo раскиданы по коду (ведь, никто не запрещает помещать ToDo именно в том месте, где надо что-то реализовать или исправить, а не одним списком в одном месте) - искать достаточно не удобно.
Не любое увеличение функционала усложняет обучение. Вещи как доп. кнопки в IDE или конструкторы в конце их списка - легко игнорируются любым адекватным человеком, в процессе обучения, пока другой (более релевантной) информации полно.
Конечно, поддержка IDE была бы приятна, но не стоит преувеличивать эту необходимость. Сейчас вообще речь про ToDo список 1 модуля.
Вот у OpenCLABC 1 центральный список по общим улучшениям всего модуля, в начале файла + несколько //ToDo по всему модулю, по которым легко пройти с Ctrl+F, потому что это 1 файл.
В моём сообщении и не говорилось про IDE (в трёх пунктах).
Говорится про один модуль, но ToDo уже используется, например, в PABCSystem. И они раскиданы по модулю. Про необходимость (!) и не говорилось, было сказано:
и всё.
Необязательно так же будет и у других. Кроме того, не забывайте про режим проекта - там может быть не один файл, ведь проекты на это и рассчитаны. Обычный поиск здесь как “палочка-выручалочка” уже не поможет. Ибо искать придётся в каждом (!) файле, что небыстро. Кроме того, сам ToDo - может быть вообще не ToDo (в привычном нам понимании), а каким-то литералом в коде или идентификатором (или его частью), что обязует писать регулярные выражения для нормального поиска (если нет уверенности в том, что ToDo только в комментариях). Так что проблемы возможны даже в границах одного файла, что делает решение через обычный поиск напрямую зависимым от кода и неустойчивым к “экзотическим” случаям.
Я предлагаю (если и делать), то сделать для начала по-простому, в формате:
<line> <label> <description> <file>
, где:
<line> - номер строки
<label> - ToDo/FixMe/Hack
<description> - текст до конца строки после “метки”
<file> - имя файла, в котором определена “метка”
Последнее имеет смысл для проектов, для однофайловых вещей - без этого понятно где находится ToDo/FixMe/Hack.
Реализация в DevC++ (взял её в качестве примера, поскольку она простая IDE, скорее для обучения, чем для профессиональной разработки):
Да, не собираемся. GraphWpf используют школьники - им картинки из файлов - единственно возможное.
Школьники не создают проекты.
Реализация изображений в ресурсах с поддержкой IDE - непростое дело. Во-первых - да - такая фича может быть востребована 2-3 человеками. Во-вторых, желающие ее реализовать имеют разное представление о сложности и скорее всего будут тянуть в сторону профессиональной разработки, в итоге эта возможность вообще не будет востребована никем.
Ну и - нужен разработчик, который взялся бы за интерфейс, а не точечно “Это надо, то надо”
Есть интересный момент - в языке много средств для решения различных задач, но сама IDE простая. Я не спорю с тем, что в обучении - это позволит сконцентрироваться на написании кода без отвлечений на интерфейс. Но, с другой стороны, продвинутым пользователям средств IDE будет маловато. Аналогия - дать повару много продуктов для приготовления его шедевра, но дать мало инструментов для этого. Такая же проблема есть в онлайн средах разработки - порой поддерживаются самые современные версии компиляторов, но не предоставляется обширных средств для работы с кодом. И именно поэтому desktop-ные IDE всегда будут впереди браузерных. Но, также первые (как и PascalABC.NET, например), позволяют небольшое что-то быстро написать. И поэтому делать Visual Studio 2 я не вижу смысла. В свете этого у меня есть сомнения на счёт нужности поддержки ToDo из IDE, хотя, для продвинутых (!) пользователей это была бы полезная вещь.
Когда есть много нерешенных проблем с сопровождением программного продукта, можно выбирать разные стратегии. Первая - решать их в порядке возрастания трудоемкости. Это самообман, но психологически комфортно из-за быстрого убывания общего количества проблем. Вторая - затыкать наиболее существенные дыры. Это разумно с точки зрения поддержки продукта - снижается потенциальное количество пользователей, “нарвавшихся” на проблему, что в свою очередь, работает на общественное мнение о продукте. Это как в дырявом днище лодки: если в большую дыру поступает воды больше, чем в десятки щелей, надо дыру латать, а не щели. И третья стратегия - перемежать латание крупных дыр с мелкими. Пока латаем мелкую, думем, как залатать крупную. Скорее всего это - оптимум.
По поводу ToDo списков мы думали, это было бы полезно для студентов и продвинутых школьников скажем как задания в частичном проекте. Но вещь не настолько критичная, и заняться некому - да.
Более важная вещь - подчистка интерфейсных элементов для разрешений 200% и выше. Что то мы сделали, но там обязательно надо переделывать это, потому что растет число пользователей с такими мониторами
Только, Вы преподаватель, а преподаватель может давать задания студентам и школьникам. Плагинами к PascalABC.NET могли бы заниматься Ваши ученики, ровно как и интерфейсом (в то время как Вы бы с @ibond сосредоточились бы на компиляторе).
Я думаю, что преподаватель имеет право дать темы проектов, например, для зачёта по предмету, связанные с PascalABC.NET, среди всех остальных. Разумеется, будет лучше, если каждый сам сможет выбрать тему, чтобы не было «навязывания». И интересующиеся PascalABC.NET вполне могут выбрать тему, связанную с ним. В итоге и разработчики будут рады и ученики, что получили зачёт по предмету и опыт совместной разработки.
Не знаю об этой ошибке. Первый раз слышу. А нет ли какой закономерности - например, при имени файла с пробелами и русскими буквами или при запуске из архива или Temp-каталога?
Что касается ошибки о которой говорил @RAlex - она наблюдается после подтормаживания. К примеру, у меня на ноуте всё время не хватало оперативки, поэтому если IDE не была использована некоторое время - её кидало в файл подкачки. И вот когда я возвращался и пытался запустить программу - IDE зависала пока её загружало из файла подкачки. И после этого зависания могло выдать ошибку.
Что касается ошибки которая серьёзно мешает - посмотрите на скриншот, там куча русских букв, знак скобочки и пробелы, перед местом где имя файла порезало. И разрез находится посреди слова, между буквами п и р.
Ну, я уже сказал, копайте в сторону забытых Stream.Flush при передаче данных, это явно его симптомы.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021