From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,57547e48b4c4d9b8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-17 02:59:50 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Ada programs depend on fonts (was: aunit?) Date: Thu, 17 Apr 2003 09:59:49 +0000 (UTC) Organization: GMUGHDU Message-ID: References: NNTP-Posting-Host: d2-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1050573589 270 134.91.1.15 (17 Apr 2003 09:59:49 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Thu, 17 Apr 2003 09:59:49 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831)) Xref: archiver1.google.com comp.lang.ada:36233 Date: 2003-04-17T09:59:49+00:00 List-Id: Stephen Leake wrote: : I accept ACT's definition of "good style". Because to do otherwise : takes more time than it is worth. Hm. (For the same reason one could accept MSs definition of C++...) Why does it take less time to transform source code into ACT style than to obey one or more definitions of good style? (After all, others might have good reasons for using a different good style and that will likely lead to a bunch of programmers grimly reformatting their sources :-) But that is a matter of a source code _view_, see below, as in to model-view-controller, or structure-and-form, or shape-and-content. : Emacs, any fixed font. Of course :) : : In general, I would recommend adapting the display tools to agree with : the "standard" definition of good style (as defined by ACT, in this case). There is some interesting evidence that looking at your program in different shapes (for example on screen vs. carefully typeset) will let you see things that you do not see if you look only at the on screen version. (The same might be true of more prose like text: you see orthographical mistakes in one form of the text that you have not seen in the other.) I'm always annoyed by collegues relying on font colors, when they put /* and */ and only these 4 characters around some larger portion of source code. They say they can easily see that this part of the program is ineffective, because it appears in a color for comments. (At least Ada defeats this problem.) To me, this seems less likely to happen if people don't make their programming depend so much on font choice etc. :> (consider f (x) in most various circumstances.) Seen this way one :> might argue that -gnaty is completely unaware of any typographical :> tradition in mathematical typesetting. : : Ada source code is not meant to be typeset; that's what LaTeX is for. Depends. It might increase quality. Then, there is also Ada letters. :> It seems to be aware of typical font appearance in typical plain :> text editors, : : Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font : in bitmapped displays". Emacs is a sophisticated plain text editor, aware of a number of syntax rules for plain text. Editing Plain text, including editing program text, is complicated and Emacs can help a lot knowing the syntax rules of the plain text. (That implies syntax directed plain text navigation, and there are a few Emacs major modes that are excellent in this respect.) Ada source code is just plain text. No fancy formatting, no fonts, no colors. Ada compilers don't handle fonts and colors (note the omission of formatting, because of front ends aware of indentation). A view of Ada source code might have fonts and colors, but should programs be written in a way that is largely influenced by one view of source code? I think not. :> on typical low res displays, : : 1280 by 1024; I don't think that counts as "low res". But it is low resolution, as long as the resolution isn't around some 400 dpi. What counts is the number of pixels per visible stretch, the shape of pixels, and, if applicable, the resolution of a font. That does not necessarily have anything to do with the number of pixels of a device. : picking a good fixed with font is critical. But I've done that. I hope it's not mission critical? :-) :> I wish one could ask -gnatyX to concentrate on those aspects of :> source code which render Ada text ambigous to the human eye, like :> using l near 1 (or using l at all. Isn't there a "k instead of i in :> GNAT" policy?). : : Again a matter of good font choice; no excuse for using a font in : which 1 (one) and l (letter ell) are confused. Well, I'd rather say, no excuse for making source code depend on font choice. You have given hints in 2 paretheses, presumably because you know that different news reading software might display 1 and l differently? Who is going to maintain the program text in which IDE using what font? Yours in both respects? Source code maintenance shouldn't be a matter of choosing good font choice, should it? -- Georg (require 'ada-mode)