[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] Various clean up in preparation for libtextstyle
From: |
Bruno Haible |
Subject: |
Re: [PATCH 0/3] Various clean up in preparation for libtextstyle |
Date: |
Wed, 20 Mar 2019 02:25:31 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; ) |
Hi Akim,
> > Would it help, if there was (for example in gnulib) a file that serves
> > as replacement for <textstyle.h>, for when libtextstyle was not found?
> > Roughly like the attached one.
>
> Oh yes! That would be most helpful!
>
> I have checked that the file you sent was sufficient to cover
> Bison's needs, and it's almost perfect:
Thanks, I have added it as a module to gnulib. With the _GL_UNUSED markers
and some other tweaks.
> > if (color_mode == color_yes
> > || (color_mode == color_tty && isatty (STDERR_FILENO)))
> > {
> > style_file_prepare ("BISON_DIAGNOSTICS_STYLE", NULL,
> > pkgdatadir (),
> > "diagnostics.css");
> > /* As a fallback, use the default in the current directory. */
> > struct stat statbuf;
> > if ((style_file_name == NULL || stat (style_file_name, &statbuf) < 0)
> > && stat ("diagnostics.css", &statbuf) == 0)
> > style_file_name = "diagnostics.css";
> > }
> > else
> > /* No styling. */
> > style_file_name = NULL;
>
> which requires style_file_name to really exist, the #define won't do.
> Maybe a set_style_file_name would be better?
Such code is necessarily application-dependent. I think, a
'#if HAVE_LIBTEXTSTYLE' around the entire block is the best approach
here.
> BTW: did you really want the user to specify the .css part? In the
> command line I prefer --style=foo to --style=foo.css, but we should
> definitely have a single convention (which could be to support both:
> add .css if the name has no extension).
The documentation contains a section
The end user's perspective > The --style option > Creating your own style
files
The very idea of the library is that the user can customize it. Thus
I like to emphasize that the styling is done by a *file*. That
--style=foo does not refer to a magic token 'foo', but instead to
a file 'foo'.
Removing the suffix of file names is something predominantly done in
the Windows world. For my feeling, it hampers the understanding of
a user who wants to understand how things work. I, for my part,
am opposed to the "let's present it as a black box" approach
regarding software.
If a user feels that '--style=$HOME/foo.css' is too long to write, they
can use the environment variable or a wrapper script.
Bruno