kwh@bentley.UUCP (KW Heuer) (05/26/86)
In article <146@cs.qmc.ac.uk> qmc-cs!liam (William Roberts) writes: >I use programs like "cb" and "indent" to get my C programs >indented according to what they *REALLY* mean, as opposed to >what I intended them to mean (indicated by MY indenting). This >can be quite illuminating.... I presume you then compare it to the original. Yes, that's a useful trick. However, if indentation always reflects your intention, then eliminating the braces and making indentation significant would prevent this type of bug in the first place! Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
gordon@sneaky (05/31/86)
> ... > However, if indentation always reflects your intention, then eliminating the > braces and making indentation significant would prevent this type of bug in > the first place! > > Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Does anyone have an ANSI standard for where you're supposed to set your tab stops? Determining "amount of indentation" from the whitespace characters in the source isn't that straightforward. Try ordering these sequences of leading white space (presumed to be preceeded by a newline or the beginning of the file, and followed by a statement) by "amount of indentation", without having to supply information to the compiler about what kind of terminal the source was written for (which isn't usually, of course, the same as the terminal, if any, you are running the compilation from): 9 spaces 2 tabs 15 spaces 16 spaces 17 spaces 1 space, 2 tabs 3 tabs 5 spaces, tab, 1 space, tab 3 spaces, formfeed, 3 spaces, tab, tab 3 spaces, formfeed, 15 spaces formfeed, 15 spaces 2,000 spaces, formfeed, 6 spaces 7 spaces, tab, 7 spaces, tab 2 tabs, 1 space 4 spaces, tab, 4 spaces, tab null string (statement starts in first character of the line) formfeed Is control-K (VT) defined as white space? If so, you get more interesting and confusing combinations. Your terminal's tabs ARE set at column (left edge = column 1) 7, 15, 30, and 72, aren't they? :-) Do tabs expand relative to the edge of the terminal, or the edge of the window the compiler is running in? What happens if the window changes during compilation? Gordon Burditt ...!convex!ctvax!trsvax!sneaky!gordon
greg@utcsri.UUCP (Gregory Smith) (06/05/86)
In article <-18363551@sneaky> gordon@sneaky writes: ^^^^^ ???? > >> ... >> However, if indentation always reflects your intention, then eliminating the >> braces and making indentation significant would prevent this type of bug in >> the first place! >> >> Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint > >Does anyone have an ANSI standard for where you're supposed to set your >tab stops? Determining "amount of indentation" from the whitespace >characters in the source isn't that straightforward. Try ordering >these sequences of leading white space (presumed to be preceeded by >a newline or the beginning of the file, and followed by a statement) >by "amount of indentation", without having to supply information >to the compiler about what kind of terminal the source was written for >(which isn't usually, of course, the same as the terminal, if any, you >are running the compilation from): [ examples deleted ] Correct me if I'm wrong, but I was under the impression that UN*X tabs are at columns 1,9,17,25 etc and that this is not recommended, but in fact *required* to get anywhere (e.g. ls emits tabs ). If your terminal doesn't have tabs or has "wrong" tabs, the terminal handler has ways and means of making it work (i.e. expanding tabs to spaces on their way to the terminal ). So if your terminal has tabs but they are "wrong", and you do not enable tab-expansion, you will suffer from inconsistency between the physical appearance of your screen and the system's idea of its appearance. In the very least, you won't be able to delete tabs properly. >Your terminal's tabs ARE set at column (left edge = column 1) 7, 15, 30, >and 72, aren't they? :-) :-) indeed. > >Do tabs expand relative to the edge of the terminal, or the edge of the >window the compiler is running in? What happens if the window changes >during compilation? > The same thing that happens if you move your terminal 2 inches to the left during compilation. If you have windows which can move left and right, then obviously the terminal's physical tabs cannot be used as the places where the cursor stops when you hit <TAB> ( although they may still be used for cursor positioning ). -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
guy@sun.uucp (Guy Harris) (06/10/86)
> In article <-18363551@sneaky> gordon@sneaky writes: > ^^^^^ ???? It's a "notesfiles" site, presumably; they don't use the ordinal number of the article to generate the article ID. They don't have to, either; the article ID merely has to be unique. > Correct me if I'm wrong, but I was under the impression that UN*X tabs > are at columns 1,9,17,25 etc and that this is not recommended, but in > fact *required* to get anywhere (e.g. ls emits tabs ). Sort of, but not really. There's a hack which dates back to PWB/UNIX, and is still around in System V, where you can stick a "tab specification" into a file indicating where the tab stops should be for that file. I think the S5 "ed" will do its own tab expansion on output if it's editing such a file, and there are programs to do the tab expansion on files like that for printing. The S5 "tabs" command can take a "tab specification" and set the hardware tabs according to that specification, or can read a file and set the tabs for the tab specification in that file. I don't think the "vi" supplied with S5 knows about them, however. Given what PWB/UNIX was originally intended for, it should be obvious why this "tab specification" stuff was stuck into PWB/UNIX. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
bls@mtx5w.UUCP (Bernard Smith) (06/11/86)
> > In article <-18363551@sneaky> gordon@sneaky writes: > > ^^^^^ ???? > > It's a "notesfiles" site, presumably; they don't use the ordinal number > of the article to generate the article ID. They don't have to, either; the > article ID merely has to be unique. > > > Correct me if I'm wrong, but I was under the impression that UN*X tabs > > are at columns 1,9,17,25 etc and that this is not recommended, but in > > fact *required* to get anywhere (e.g. ls emits tabs ). > > Sort of, but not really. There's a hack which dates back to PWB/UNIX, and > is still around in System V, where you can stick a "tab specification" into > a file indicating where the tab stops should be for that file. I think the > S5 "ed" will do its own tab expansion on output if it's editing such a file, > and there are programs to do the tab expansion on files like that for > printing. The S5 "tabs" command can take a "tab specification" and set the > hardware tabs according to that specification, or can read a file and set > the tabs for the tab specification in that file. I don't think the "vi" > supplied with S5 knows about them, however. Given what PWB/UNIX was > originally intended for, it should be obvious why this "tab specification" > stuff was stuck into PWB/UNIX. > -- Tab specifications can be passed to vi (in S5) using a file .exrc in your home directory: I use tabs every four columns (1, 5, 9, etc.) and my .exrc file contains (in part) set ts=4 shiftwidth=4 set ht=4 Bernard Smith, AT&TIS, Middletown, N.J.