Re: [PATCH 0/3] Various clean up in preparation for libtextstyle

[Akim Demaille]

Hi Bruno,

I missed your message, sorry!

> Le 20 mars 2019 à 02:25, Bruno Haible <address@hidden> a écrit :
> 
>> 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.

I'm installing this for the last missing bit:

commit 56ac5495091fdd233a07c95602ff595bbe536cc9
Author: Akim Demaille <address@hidden>
Date:   Fri Mar 22 20:05:46 2019 +0100

  libtextstyle-optional: Fix compiler warnings.

  * lib/textstyle.in.h (html_styled_ostream_create): Flag arguments
  as unused.

diff --git a/ChangeLog b/ChangeLog
index 62c522e65..457caa9ad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-22  Akim Demaille  <address@hidden>
+
+       libtextstyle-optional: Fix compiler warnings.
+       * lib/textstyle.in.h (html_styled_ostream_create): Flag arguments
+       as unused.
+
2019-03-19  Akim Demaille  <address@hidden>

        bitset: fix memory leaks
diff --git a/lib/textstyle.in.h b/lib/textstyle.in.h
index 65fa6707a..3eb71938f 100644
--- a/lib/textstyle.in.h
+++ b/lib/textstyle.in.h
@@ -319,7 +319,8 @@ term_styled_ostream_create (int fd, const char *filename,
typedef styled_ostream_t html_styled_ostream_t;

static inline html_styled_ostream_t
-html_styled_ostream_create (ostream_t destination, const char *css_filename)
+html_styled_ostream_create (ostream_t destination _GL_UNUSED,
+                            const char *css_filename _GL_UNUSED)
{
 abort ();
 return 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.

Ok, it makes sense.


>> 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.

Yes, I certainly do not want to hide this.  I see your point but still would 
not have made that decision; but the current behavior was made on purpose, it 
has a rationale, so I'll be happy to live with that.

Cheers!