Re: underscores in gnulib file names

[Bruno Haible]

Paul Eggert wrote:
> > How about the "..h" suffix, e.g., stdlib..h?  Do we care enough
> > about 8.3 limitations to worry about that?
> 
> I don't think we do nowadays, no.  Might some software get confused by
> the "..h" extension?  Emacs treats "..h" like ".h"; perhaps that's
> good enough.

kate and vi apply the same syntax coloring to getopt..h as to getopt.h as
well. So, yes, on this side, "..h" is as good as ".h".

> But I like the brevity of "..h".

The brevity strikes back sometimes: when an outsider sees fcntl_.h and
fcntl--.h, neither of it is self-descriptive.

I would prefer to have ".in" in the file name, reminding the substitution
process that is the same as for Makefile.in -> Makefile. So I propose a
suffix ".in.h".

But the Emacs developers may not want file names with two dots in them:
Such file names need renaming on DOS and on VMS. There are currently no
such file names in Emacs.

> I'd rather not have gnulib-tool rename files as it imports them, as
> that adds confusion.

One could reduce this confusion by having gnulib-tool add a comment in the
first line
  /* This file is originally called getopt_int.h in gnulib. */
when it names the file.

But anyway, the file getopt_int.h comes from glibc. There are only 4 choices:
  - You convince the glibc maintainers to rename getopt_int.h in glibc.
  - The file name is different in glibc than in gnulib.
  - The file name is different in gnulib than in emacs.
  - You convince the emacs maintainers to accept a file name getopt_int.h.

Bruno