[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plain text matching with regex: RE_PLAIN
From: |
Bruno Haible |
Subject: |
Re: Plain text matching with regex: RE_PLAIN |
Date: |
Sun, 19 Sep 2010 15:33:47 +0200 |
User-agent: |
KMail/1.9.9 |
Hello Reuben,
> Some questions, having read the documentation:
>
> 1. There doesn't seem to be a default value for --local-dir. I used
> local-lib; is there a recommended value?
I use --local-dir=gnulib-local; others use --local-dir=gl/override or
--local-dir=gl.
> It would be nice to have a default, both to encourage compatible naming
> and to avoid the need for --local-dir when the default value is used.
I disagree. Similar naming is not a goal; everyone is free to name the
directories in his package the way he likes. And --local-dir is a very
important option; it shouldn't be implicit. Additionally, we want to
allow multiple --local-dir options in the future.
> 2. There's a remark that is unclear to me: "(This kind of kitchen-sink
> module is not needed when you
> use the @command{gnulib-tool} option @samp{--makefile-name}.)" How
> does --makefile-name help in this case?
It doesn't force you to move stuff that you would have written in a
Makefile.am in a gnulib module description; it allows you to keep the
Makefile.am like you originally wanted.
> 3. It seems to me that the structure of this section of the
> documentation could be clearer: in particular, it seems that all the
> things listed that you "can do" to add local code are, rather than
> fixed options, consequences of the file override rules listed below.
> Hence, I suggest reordering the page to first explain the rule, and
> then say that "as a result, you can..." and list the things you can
> do, which are effectively recommended ways to exploit the file
> overrides (there may be other good ways, or other bad ways).
People try to read a minimum of documentation usually. They don't want
to read details just to understand a little later what they can use them
for. For this reason, I write documentation on purpose in a way that
presents first the possible uses and then only the gory details. (At
least for those pieces of software where the uses are limited.)
First I answer the question "What can I do with this software?",
then only the question "How do I do it?"
Bruno
- Re: new module 'regex-quote', (continued)
- Re: new module 'regex-quote', Bruno Haible, 2010/09/20
- Re: new module 'regex-quote', Bruce Korb, 2010/09/20
- Re: new module 'regex-quote', Reuben Thomas, 2010/09/20
- Re: new module 'regex-quote', Bruno Haible, 2010/09/20
- Re: new module 'regex-quote', Reuben Thomas, 2010/09/21
- Re: new module 'regex-quote', Bruno Haible, 2010/09/25
- Re: new module 'regex-quote', Reuben Thomas, 2010/09/29
- Re: new module 'regex-quote', Bruno Haible, 2010/09/25
- Re: new module 'regex-quote', Reuben Thomas, 2010/09/29
- Re: Plain text matching with regex: RE_PLAIN, Reuben Thomas, 2010/09/19
- Re: Plain text matching with regex: RE_PLAIN,
Bruno Haible <=
- Re: Plain text matching with regex: RE_PLAIN, Reuben Thomas, 2010/09/19