Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5337@auspex.auspex.com>
Date: 17 Jan 91 19:11:24 GMT
References: <41772@nigel.ee.udel.edu> <5293@auspex.auspex.com> <41902@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 63

>The ability to change a file without invalidating all the hardcopies
>you may have of the file.

Which requires that line numbers be something other than simply the
ordinal number of the line within the file, as I presume is the case on
the systems where you used them.

How often, if ever, did you have to "renumber" the lines in a file, say
because you needed to insert something between two lines with adjacent
line numbers?

>I never missed line numbers in a system where I would never look at a
>hardcopy (like Smalltalk).

I never miss line numbers in a system where I rarely look at hardcopies,
and even more rarely, if ever, line-number them in any case (like UNIX).

>Either is fine.  I'm considering lines and records to be the same
>thing here.

OK, then in *that* case, UNIX *does* support records, to some extent;
see "fgets()".  (Yeah, it's in "a library"; see my other posting, which
asks what the difference really is, and why it makes a difference.)

>>Lines, not records.
>
>Why don't you tell me the difference as you see it.

I'm assuming *you* saw a difference, because you didn't consider UNIX to
support "records" in the file system, but it does have a standard
interface for reading a single line from a file ("fgets()").  That
interface may not be the lowest-level interface you can use to get at
the data in a file, but then it's not the lowest-level interface on at
least some systems that *are* considered to support records "in the file
system"....

>See above.  If I get ten error messages from the compiler, I have to
>fix them in reverse order lest the line numbers get changed while
>I edit. Increasing more-sophisticated tools can be used to overcome
>this problem (like a tool that intersperses error messages into the
>source file), but I believe this to be curing the symptoms.

I don't, unless your editor on the system that handles line numbers uses
some "insert a line" primitive on the file being edited that causes a
correct line number (one between the line numbers of the lines between
which the new line is being inserted) to be chosen automatically - and
even in that case, I wouldn't consider that a solution if the
requirement to manage the file that way imposed restrictions on the view
it could give me of the file.  (I tend to use EMACSish editors that, to
a large degree, model the file as one huge character string, treating
newlines like any other character, which can be inserted or deleted, and
that let me cut arbitrary substrings of that string without regard to
line boundaries.)

Unless you have such an editor, as far as I can see you need some
specialized handling; either you need an editor that manages line
numbers, or an editor or you need either the aforementioned tool (by
which I presume you mean something such as "error") or something like
the mechanism in some EMACSish editors for running a compile, capturing
the error output, parsing it, and walking through the file(s) to which
the errors refer and going to each error.  (I don't know if those
mechanisms continue to work if you update the file before going to the
next error, but I wouldn't be surprised if they did.)