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
