[Top][All Lists]

[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

> 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 

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]