Home | History | Annotate | Download | only in info

Lines Matching full:good

454 both cases, and we have been using similar techniques with good success
800 It is a good idea to follow the POSIX guidelines for the command-line
818 It is usually a good idea for file names given as ordinary arguments
2398 facilitates optimization by good compilers. You can also move the
2548 Beyond that, it is good to support the other free operating systems
2579 It is a good idea to define the "feature test macro" `_GNU_SOURCE'
2911 contexts, unless there is good reason to do something else because of
3008 makes it possible to produce a good quality formatted book, using TeX,
3016 documentation by conversion this way, as long as it gives good results.
3025 good for explaining how to use the program; it may be irrelevant and
3034 often they are different. An important part of learning to write good
3057 what jobs it is good for, and show how to use it for those jobs.
3064 should give a good introduction to a beginner reading through from the
3066 Bison manual is a good example of this--please take a look at it to see
3079 Bison manual provides a good example of how to do this.
3085 The Texinfo manual includes advice on preparing good index entries, see
3137 The only good way to use documentation strings in writing a good
3138 manual is to use them as a source of information for writing good text.
3187 can be a good idea to include the program's license in a large manual;
3289 advised that it is a good idea to include them, for the sake of
3335 not a good idea, since searching for `jump-to-register' or
3743 it is a good idea to set the suffix list explicitly using only the
3829 It is a good idea to avoid creating symbolic links in makefiles,
4741 is also good to explain the purpose of each of the first-level
4832 program, or that its existence is in any way a good thing. The goal