Eli Zaretskii <eliz@gnu.org> writes:

>> +data.  If @var{allow-partial} is @code{nil}, on failure, the function
>
> We usually say "nil or omitted" for optional arguments.  Also, I'd say
> "then on failure, ...", otherwise this could be misinterpreted as if
> "on failure" qualifies the "is nil" part.
>
> Same comment regarding the doc string of the function.

Makes sense, done.

>> +leaves the region unchanged and returns @code{nil}.  Otherwise, it
>> +returns the number of bytes that were not decompressed and replaces
>> +the region text by whatever data was successfully decompressed.  This
>> +function can be called only in unibyte buffers.
>
> Maybe it would make sense here to say that this emulates what 'gzip'
> does?

Hmm, maybe.  I've added a mention of this, not sure if it actually
helps.

>> +  Lisp_Object ret = Qt;
>>    if (inflate_status != Z_STREAM_END)
>> +    {
>> +      if (!NILP (allow_partial))
>> +        ret = make_int (iend - pos_byte);

> Hmm... should we display a warning message, like gzip does?

Not unconditionally, I'd say.  In the example which prompted this bug
thread, a warning would just be a nuisance.  We could just leave it up
to the caller to print a warning message if they want, e.g.:

   (unless (eq t (zlib-decompress-region START END t))
     (message "Incomplete decompression"))

Or perhaps instead of returning the byte count, return an error
indicator which the caller could use to contruct a warning message (this
could allow for a slightly more specific message)?  Or maybe it's easier
if the ALLOW-PARTIAL parameter could have another possible value to
control display of the warning message?