A modest proposal

[simont]

When you compile a source file and get multiple compile errors, there are two conflicting principles governing the order in which you go through the source file fixing them.

On the one hand, you want to fix the errors from the top downwards, because of the possibility that some errors are cascades from others: fixing earlier errors may cause later ones to turn into non-errors or shed light on what the problem really was.

On the other hand, if you fix an early error in a way that changes the number of lines in the source file, then you have to mentally adjust all the line numbers in the subsequent error messages. Do this multiple times and you're looking at keeping a running track of the cumulative change to the file's line count as you edit, which you didn't really want to have to hold in your head at the same time as the more important state regarding the problems you're fixing.

The solution is simple. Line numbers in source files should be indexed backwards from the end, with line 0 being the part of the file after the final newline, line 1 the line before that, and so on. If compilers reported errors using those line numbers, and programmers' text editors displayed the same line numbers, then there would no longer be a conflict: you'd fix compile errors from the top of the file downwards, each error message would have a correct line number when you reached it, and you'd only see cascade errors after fixing the primary error that caused them.

Comments

[feanelwa.livejournal.com]

That's a good idea!

[ewx.livejournal.com]

Or have the compiler/editor integration able to cope with the line number changes...

[simont]

I've never been a fan of tight compiler/editor integration. It either requires O(number of compilers × number of editors) work to set up, or it fails to give people an independent choice of compiler and editor. And in any case, I quite often find myself in silly situations involving running my editor on one machine and my compiler on another, at which point I tend to be glad I'm not committed to tightly coupling the two.

My proposal requires O(number of compilers + number of editors) work to set up, and copes transparently with arbitrarily silly compile arrangements. The only real point against it is that it's barking mad.

[ewx.livejournal.com]

The relevant integration here is the editor being able to parse error messages to find the source file and line, something that's indispensable even if it doesn't perform cleverness regarding changes to the source file.

[simont]

But there's at least an implicit requirement to have the compiler's error messages show up in the editor in the first place. Cutting and pasting the whole lot into a compiler-error-oriented editor buffer, and arranging to have the source file pathnames translated between the compiler's and editor's filesystem views (e.g. translating Windows to Unix path separators and prepending the right top-level source directory) would be significantly more inconvenient than just typing a three- or four-digit line number every time I want to move to the next error.

[ewx.livejournal.com]

That's a trivial variant of getting the output of any other command into your editor - also something that's indispensable for other reasons.

[gareth-rees.livejournal.com]

there's at least an implicit requirement to have the compiler's error messages show up in the editor in the first place

In Emacs, you type M-x compile RET and then enter your command (typically make).

translating Windows to Unix path separators and prepending the right top-level source directory

Emacs does this automatically. And it can handle cygwin paths too using the cygwin-mount library.

(I don't want to sound like an Emacs zealot so I'll stop now...)

[pm215]

Of course M-x compile doesn't work quite so well when you're running your compile on one machine and the editor on another...

[gareth-rees.livejournal.com]

In that case, wouldn't you type something like M-x compile RET ssh user@host make RET? (Or whatever mechanism you use to run a command remotely.) You probably also need to organize some form of path translation in this case: that's what file-name-handler-alist is for.

[pm215]

The approved mechanism in this case is to run a command saying "I want an interactive session on a random machine, give me an xterm" and then do everything in that xterm or things spawned from it. sshing into the machines directly is frowned upon. I suppose one could do compiles as a batch job but that feels distressingly 1970s.

(I'm sure something is possible, it just needs more tuits than I've come up with so far.)

[simont]

I'm currently contemplating the idea of running an appropriately configured sshd under my own uid as my primary interactive-session process, and sshing in to that from my desktop box. That way all my processes are still children of the process they ought to be, which means in particular that if CPU-time accounting is going on then it will still give the right answers, but I also get to use sensible X forwarding and so forth.

[pm215]

The sshd idea sounds neat but also sounds like it makes it even easier to accidentally leave interactive sessions running over the weekend ;-)

[gareth-rees.livejournal.com]

you have to mentally adjust all the line numbers in the subsequent error messages

Or you could use a development environment which handles this book-keeping for you. This need not involve any compiler/editor integration at all. For example, Emacs has a "compilation-mode" for reading the output of compilers; for each error message in the compiler's output it creates a marker (a kind of bookmark) for the original position of the error in the file. This marker stays with the text even if you add or delete lines above or below it, so you just run the command ‘next-error’ to go to the next error without needing to do any mental adjustment. I'm sure other programmer editors do something similar.

[simont]

I do occasionally wonder about defecting to Emacs from my current choice of Jed (which is basically Emacs-like in its key bindings but completely different under the hood). At the time I made the choice, Jed had far better syntax highlighting and was considerably smaller and faster; these days Moore's Law has rendered the latter points largely irrelevant, Jed's syntax highlighting has got noticeably worse, and I imagine people have been hard at work improving Emacs's.

My primary reason not to is that I'd have to translate ten years' worth of accumulated editor configuration written in Jed's embedded scripting language, including my personal MUA...

[gareth-rees.livejournal.com]

You might want to have a look. Emacs went through a bit of a doldrums in the early 2000s as it took six years to bring out version 21 *. But now it seems back on track, and if you used to be a fan, but haven't used it since version 20 I think you may be pleasantly surprised with version 22.

* Native windowing system integration was pretty tough, but I think the big problem was Unicode. Emacs was a victim of being a first mover here: in the 1990s it had adopted its own system (MULE) for integration of multilingual character sets, so when Unicode turned out to be the standard way to achieve this, MULE had to be backed out while the rather complex interface remained backwards compatible to avoid breaking a vast installed codebase.

[pne.livejournal.com]

Jed's syntax highlighting has got noticeably worse

That must have taken some special effort.

Do you really mean, worse in absolute? Or merely "not as good as what other programs offer these days"?

If the former, I wonder what made people take something that works and make it worse.

[simont]

Yes, I do mean worse in absolute terms. What happened was, there were two separate highlighting mechanisms in Jed. One was a sort of ad-hoc thing hard-coded in the editor's C core, which was basically just about usable for highlighting C and could also be extended to other basically programming-language-shaped syntaxes by configuring it at the general level of "this is the comment character, this is the list of operators, these are delimiters etc". The other was based on regular expressions and was much more flexible and general, and in particular one could configure it entirely in the customisation language to be suitable for things that had nothing at all to do with programming languages. I had hoped that highlighting schemes based on the former would gradually migrate to the latter and then the former would be thrown away, but it appears that in fact the latter has fallen into disuse and more and more language modes are reverting to the (now somewhat souped up but still not really as flexible as it should be) former. I think part of the reason for this is that the maintainers didn't really understand the regexp-based scheme, so when it came to adding new features they tended to graft them on to the one they knew how to modify.

[geekette8.livejournal.com]

Yep, even Visual Studio manages this. Something like Alt-F4 (or just F4 maybe, I can't remember) moves to the next error.

[samholloway.livejournal.com]

VS seems to track the changes very well. If you click on an error message, you nearly always get taken to the correct line, even after having made substantial changes elsewhere in the file. That way, the line numbers become quite irrelevant. VS only gets really confused if you actually delete the line that the error itself was on.

[andrewducker]

F8. Alt-F4 is "close window" and F4 is "Properties".

And yeah, it's very nice.

And if it starts to lose where the errors are then I just hit compile again - even with reasonably large systems it's only 30 seconds to do a build.

[reenigne.livejournal.com]

Another way might be for an editor to have two sets of line numbers - the normal set plus a set which is "the line this text was on the last time it was loaded or renumbered". Then you can fix the errors in whatever order you like, and only the editors need to change. Navigating could get confusing if fixing early errors entailed moving lots of code around, but that's a problem with negative numbering too.

The old DOS assembler A86 had a rather different way of solving this problem - it injected its error messages right into the source files! It actually worked surprisingly well, but it would probably cause too much confusion these days.

[gerald_duck]

Agreed about editors having a mode where line numbers don't change until you hit the magic button. That would be potentially very useful, while probably not too much trouble to implement.

[cartesiandaemon.livejournal.com]

Now I find myself using "a modest proposal" in some kind of meta-sarcastic way, for things that ought to actually be modest, but turn out to be a giant hurdle... :)

[simont]

I think I used it in pretty much the canonical fashion, to propose a measure which would literally speaking solve the stated problem but has sufficient other undesirable features that it's clear that it not only can't be adopted but can't even have been a serious suggestion in the first place.

(Though, curiously, I hadn't known about Swift's work when I used the title yesterday. I had somehow absorbed through cultural osmosis the general tone of things for which that title was appropriate, and it was only after I posted it that it occurred to me to look up what else it had been used for. I was pleased to find I'd got it pretty much right.)

[cartesiandaemon.livejournal.com]

:) Yeah, I can't remember when I actually looked up the original, I know osmosis had filled the phrase in (complete with nuance) earlier on :)

Although when I use it in mostly the original sense, it actually tends to be something like how I read this post -- a nominal solution, which sounds completely ridiculous, and you describe as a "modest proposal" to make it clear you're not yet advocating it, yet you can't help but wonder if maybe it _would_ be sensible after all.

[simont]

Mmm. I think to some extent it's a mistake to try to draw a sharp distinction between a surprisingly sensible-sounding wacky idea and a surprisingly wacky serious suggestion; the art lies precisely in aiming consciously for the borderline between the two. If the reader can't quite tell whether I was serious or not, that's a mark of success :-)

[cartesiandaemon.livejournal.com]

LOL. Yeah. I certainly enjoy living on that edge -- I like to measure the success of a joke by the length of time before someone laughs, assuming they eventually do :)

But I have to admit I also use irony in situations like this as a defense; if I come up with a wacky idea, I'll phrase it as a "modest proposal" in order to raise it, but not feel the need to justify it. Which is useful, if it invites some objective consideration of the problem and potential solution, but is also questionable, in that it would be more honest to simply say "I had this idea, is there any merit, or is it _just_ silly?" :)

[gerald_duck]

Unfortunately, I tend to fix the lexically later errors first, because I can't be bothered with scrollback. Only if something non-trivial is broken do I go back and start from the top.

[gerald_duck]

…though I now realise the lexically earlier errors could be printed last as a further convenience. It would involve the compiler in some tedious cacheing of error messages, but it's going to have to do that anyway, because it doesn't know the line numbers for any of the errors until it's finished. The alternative would be to cache the input file or make two passes, but hopefully the volume of errors emitted is less than the size of the source file. (Until you screw up entertainingly with C++, at any rate.)

[naath.livejournal.com]

What, you don't recompile (or attempt to) every time you fix an error? (this being my standard approach to "all the errors will have moved now and half of them were probably cascades from that one and I can't be bothered to look at them all")

[simont]

Depends very much on the error. Sometimes I can see that 90% of the remaining errors are likely to be cascades from one, so I fix that and immediately recompile so as to avoid having to sift through the rest myself. But if I can see that the errors are separate and unrelated (an undeclared hippo here, a wombat of the wrong type there, an elephant passed to a function that expected a gibbon elsewhere) then it saves time to just go through and fix as many obviously distinct problems as I can trivially identify.

[cartesiandaemon.livejournal.com]

an undeclared hippo here, a wombat of the wrong type there, an elephant passed to a function that expected a gibbon elsewhere

LOL. I love your metaphor. It sounds like line-numbers are the least of the problems with your errors, though :)