Use Mcedit as IDE - parse compiler output and navigate to error locations

[lstranger]

I love mcedit as easy-to-use editor and use it to edit my source files. And there is a feature which I miss the most yet since I've written my sources under DOS using Multi-Edit. The feature is a possibility to do next:
a) start a build for the file you currently edit (by keypress or menu);
b) redirect build output into temp file;
c) parse the output and find all errors (and warnings) remembering them;
d) if no errors found then show a message about that;
e) if error found then move cursor (in the file you edit) at row and column where the error is found;
f) handle 'next error' and 'previous error' (with keybindings too).
(a) and (c) should be configurable per syntax. Also would be nice to have a possibility to define a specific build command for some directory which overrides default one from syntax.

[andrew_b]

mcedit is a simple text editor not IDE.

[ossi]

oh, look - there was already an issue for that (reference: discussion in #4196). :D

qt creator uses a generalized "task list" concept, so technically speaking one can implement this without making it only about coding. a reasonable use case would be running a markdown/rst/asciidoc/... parser to generate a navigable table of contents. or a generic spell check.

the only complication is that the location list needs to be kept (reasonably) up-to-date when file is edited, as otherwise usability suffers a lot.

as for the configurable build command, that could be a particular type of user menu entry.

of course one can still declare this out of scope, but measured by the complexity and specificity of several other mcedit features, it seems just about right.

[psprint]

I wouldn't call this an IDE-level feature. Vim implements this and it's not an IDE – running :make, :cnext, :cprev allows to browse the error list. And, oh look, they even have the "C scope creep" thing :( ;) What a crime :]

[ossi]

vim doesn't claim to be a simple editor, though - before "real" IDEs came to unix, it was one of the two main contenders for programmers' affection.

i don't think we should be too strict about that, given not exactly simple features like syntax highlighting and multi-windowing, but general usefulness and maintainability should be kept in mind. i think this one qualifies.