GNU bug report logs - #36337
26.1; XBM images are sometimes not displayed correctly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36337 in the body.
You can then email your comments to 36337 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 09:15:30 +0200

Please start Emacs with "$ emacs -Q", and insert the form:

    (let* ((width 100)
           (height 100)
           (data (make-bool-vector (* width height) t)))
      (insert "\n")
      (insert-image `(image :type xbm
                            :data ,data
                            :width ,width
                            :height ,height) "t")
      (insert "\n"))

Please move point to the end of the form, and evaluate it with C-x C-e.

This displays a 100x100 XBM image. However, the bottom of the image is
not displayed as intended: I see a mix of black and white pixels at the
bottom of the image, whereas I intend it to be filled with black pixels.

For comparison, it works correctly when I change both width and height
from 100 to 200, or both to 400, and also for several other values.

In GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
 of 2018-09-22
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000

Configured features:
XPM JPEG TIFF GIF PNG GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES THREADS LCMS2

Message #8 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Markus Triska <triska <at> metalevel.at>
Cc: 36337 <at> debbugs.gnu.org
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 08:05:55 +0000

[Message part 1 (text/plain, inline)]

The code does indeed assume that it is passed a bool vector which is
padded to a multiple of 8 bits per line, but doesn't verify that the
bool vector it is passed indeed matches this format, so it displays
past the end of the bool vector.

This is easy enough to fix by rewriting the bool vector, but that's
potentially very slow (on debug builds), so maybe we shouldn't do
that?

Does the attached patch work for you?



On Sun, Jun 23, 2019 at 7:16 AM Markus Triska <triska <at> metalevel.at> wrote:
>
>
> Please start Emacs with "$ emacs -Q", and insert the form:
>
>     (let* ((width 100)
>            (height 100)
>            (data (make-bool-vector (* width height) t)))
>       (insert "\n")
>       (insert-image `(image :type xbm
>                             :data ,data
>                             :width ,width
>                             :height ,height) "t")
>       (insert "\n"))
>
> Please move point to the end of the form, and evaluate it with C-x C-e.
>
> This displays a 100x100 XBM image. However, the bottom of the image is
> not displayed as intended: I see a mix of black and white pixels at the
> bottom of the image, whereas I intend it to be filled with black pixels.
>
> For comparison, it works correctly when I change both width and height
> from 100 to 200, or both to 400, and also for several other values.
>
> In GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
>  of 2018-09-22
> Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
>
> Configured features:
> XPM JPEG TIFF GIF PNG GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE XFT
> ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES THREADS LCMS2
>
>
>
>

[0001-Don-t-assume-the-width-of-xbm-images-is-divisible-by.patch (text/x-patch, attachment)]

Message #11 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 10:22:12 +0200

Pip Cet <pipcet <at> gmail.com> writes:

> Does the attached patch work for you?

Yes, it works, thank you very much!

All the best,
Markus

Message #14 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 17:29:31 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 23 Jun 2019 08:05:55 +0000
> Cc: 36337 <at> debbugs.gnu.org
> 
> The code does indeed assume that it is passed a bool vector which is
> padded to a multiple of 8 bits per line, but doesn't verify that the
> bool vector it is passed indeed matches this format, so it displays
> past the end of the bool vector.
> 
> This is easy enough to fix by rewriting the bool vector, but that's
> potentially very slow (on debug builds), so maybe we shouldn't do
> that?
> 
> Does the attached patch work for you?

Thanks, but I really hope there's a more elegant solution.  If not,
maybe we should simply require that both width and height be an
integral multiple of 8 in this case.

Message #17 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 16:26:16 +0000

On Sun, Jun 23, 2019 at 2:29 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sun, 23 Jun 2019 08:05:55 +0000
> > Cc: 36337 <at> debbugs.gnu.org
> > This is easy enough to fix by rewriting the bool vector, but that's
> > potentially very slow (on debug builds), so maybe we shouldn't do
> > that?
> >
> > Does the attached patch work for you?
>
> Thanks, but I really hope there's a more elegant solution.

I thought there had to be, but I've yet to think of anything that's
unequivocally better.

My suggestion would be to expand `substring' to work on bool vectors,
then building a vector of bool vectors and using the existing code for
that case. Less code in image.c, plus a new utility function that
might be generally useful. (However, do we want to encourage people to
use bool vectors?)

I don't think performance is an issue, though, and you might disagree.

> If not,
> maybe we should simply require that both width and height be an
> integral multiple of 8 in this case.

Why would you require the height to be a multiple of 8?

Message #20 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 19:40:56 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 23 Jun 2019 16:26:16 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> My suggestion would be to expand `substring' to work on bool vectors,
> then building a vector of bool vectors and using the existing code for
> that case. Less code in image.c, plus a new utility function that
> might be generally useful.

Or maybe we should have a variant of make-bool-vector that accepts 2
dimension s instead of just one?

> (However, do we want to encourage people to use bool vectors?)

Why not?  Evidently, it's convenient in this particular use case.

> > If not,
> > maybe we should simply require that both width and height be an
> > integral multiple of 8 in this case.
> 
> Why would you require the height to be a multiple of 8?

You are right, width is enough.

Message #23 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 19:16:04 +0000

[Message part 1 (text/plain, inline)]

On Sun, Jun 23, 2019 at 4:41 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sun, 23 Jun 2019 16:26:16 +0000
> > Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> >
> > My suggestion would be to expand `substring' to work on bool vectors,
> > then building a vector of bool vectors and using the existing code for
> > that case. Less code in image.c, plus a new utility function that
> > might be generally useful.
>
> Or maybe we should have a variant of make-bool-vector that accepts 2
> dimension s instead of just one?

I don't really see how that would be generally useful, to be honest.
In fact, I just played around with removing bool vector support
entirely.

> > (However, do we want to encourage people to use bool vectors?)
> Why not?

We seem to lack even very basic functions for interacting with bool
vectors, and hardly anyone appears to be using them. Even the :stipple
face property doesn't. Emacs starts up fine with bool vector support
removed. We can use vectors of nil/t (in most cases) or unibyte
strings or bignums (which have arbitrary size limits now, but
bigbignums would be just a few lines of code, I think).

And people _think_ bool vectors have a natural presentation as bytes,
but they don't, because some people start with the most significant
bit.

So I just don't see where bool vectors fit in.

> Evidently, it's convenient in this particular use case.

Is the convenience worth a thousand lines of code (much of it C) and
documentation?

[0001-Don-t-assume-the-width-of-xbm-images-is-divisible-by.patch (text/x-patch, attachment)]

Message #26 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Fri, 28 Jun 2019 10:57:56 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 23 Jun 2019 19:16:04 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> > Or maybe we should have a variant of make-bool-vector that accepts 2
> > dimension s instead of just one?
> 
> I don't really see how that would be generally useful, to be honest.

For one, it would be useful in this particular case.  Or would you
rather require the width of XBM be an integral multiple of 8?

> In fact, I just played around with removing bool vector support
> entirely.
> 
> > > (However, do we want to encourage people to use bool vectors?)
> > Why not?
> 
> We seem to lack even very basic functions for interacting with bool
> vectors, and hardly anyone appears to be using them. Even the :stipple
> face property doesn't. Emacs starts up fine with bool vector support
> removed. We can use vectors of nil/t (in most cases) or unibyte
> strings or bignums (which have arbitrary size limits now, but
> bigbignums would be just a few lines of code, I think).
> 
> And people _think_ bool vectors have a natural presentation as bytes,
> but they don't, because some people start with the most significant
> bit.
> 
> So I just don't see where bool vectors fit in.

I'm sorry, but I object to removing a feature that has been with us
since Emacs 19, for which we installed new operations just recently in
Emacs 24.  Emacs is too stable a program to remove such basic features
because we cannot immediately see where they fit in.  Please consider
them as "fitting in" by definition; we can only remove them if there
are very good _positive_ reasons for removal, not because we cannot
find reasons _not_ to remove them.

> > Evidently, it's convenient in this particular use case.
> 
> Is the convenience worth a thousand lines of code (much of it C) and
> documentation?

Not necessarily; it might mean that the proposed solution is not the
best one.

What you propose is not what I think I had in mind.  I meant to extend
make-bool-vector (or make a new function, if extending proves
inconvenient or inelegant) that generates a bool-vector given 2
dimensions, not one.  Then such vectors could be used to create XBM
images of arbitrary dimensions.  We could even call this new function
something like make-xbm-data or somesuch, if its utility is limited to
XBM images.

Thanks.

Message #29 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Fri, 28 Jun 2019 08:29:04 +0000

On Fri, Jun 28, 2019 at 7:58 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sun, 23 Jun 2019 19:16:04 +0000
> > Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> >
> > > Or maybe we should have a variant of make-bool-vector that accepts 2
> > > dimension s instead of just one?
> >
> > I don't really see how that would be generally useful, to be honest.
>
> For one, it would be useful in this particular case.  Or would you
> rather require the width of XBM be an integral multiple of 8?

Having thought about it, I would rather require the bool vector passed
to XBM to be in the right format: the width can be 100, but the
stride, specified by a new :stride argument, must be the smallest
multiple of 8 greater or equal to the width. If you don't want that,
pass a vector of bool vectors which is copied together, but let's not
pretend we can take a 10,000-bit bool vector and display it
efficiently.

I think my mistake was not to distinguish between stride and width,
but we can easily do so. Shall I prepare a patch?

> > In fact, I just played around with removing bool vector support
> > entirely.

> I'm sorry, but I object to removing a feature that has been with us
> since Emacs 19

Okay. Thanks for taking the time to explain. One serious question,
though unrelated to the current bug: do you think it is just the Lisp
API that we're stuck with for eternity, or is the C representation of
bool vectors forbidden territory as well?

> , for which we installed new operations just recently in Emacs 24.

If we add new features for bool vectors, they might stick out less.
People might actually start using them. That would invalidate my
earlier argument.

> What you propose is not what I think I had in mind.  I meant to extend
> make-bool-vector (or make a new function, if extending proves
> inconvenient or inelegant) that generates a bool-vector given 2
> dimensions, not one.  Then such vectors could be used to create XBM
> images of arbitrary dimensions.  We could even call this new function
> something like make-xbm-data or somesuch, if its utility is limited to
> XBM images.

How is a vector of bool vectors different from a 2-dimensional bool
vector, from the point of view of Lisp? If I understand you correctly,
you would like two-dimensional bool vectors to be represented in
memory in the XBM format.

As for the problem at hand, how would you feel about adding a :stride
argument which must be a multiple of 8 and ensures that the bool
vector passed to the XBM code has the right memory layout?

Message #32 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Fri, 28 Jun 2019 15:43:15 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 28 Jun 2019 08:29:04 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> On Fri, Jun 28, 2019 at 7:58 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > From: Pip Cet <pipcet <at> gmail.com>
> > > Date: Sun, 23 Jun 2019 19:16:04 +0000
> 
> Having thought about it, I would rather require the bool vector passed
> to XBM to be in the right format: the width can be 100, but the
> stride, specified by a new :stride argument, must be the smallest
> multiple of 8 greater or equal to the width. If you don't want that,
> pass a vector of bool vectors which is copied together, but let's not
> pretend we can take a 10,000-bit bool vector and display it
> efficiently.

I'm not sure I understand what you mean, exactly.  Can you show an
example of the new API?

> I think my mistake was not to distinguish between stride and width,
> but we can easily do so. Shall I prepare a patch?

Maybe a patch will be the best means to explain what you mean, but if
you'd like to show it before you invest too much effort, please show
an example.

> > I'm sorry, but I object to removing a feature that has been with us
> > since Emacs 19
> 
> Okay. Thanks for taking the time to explain. One serious question,
> though unrelated to the current bug: do you think it is just the Lisp
> API that we're stuck with for eternity, or is the C representation of
> bool vectors forbidden territory as well?

The external public APIs are the primary concern; they should be
changed in backward-compatible manner (e.g., by adding &optional
arguments or adding compatible interpretations of existing arguments).
C-level implementation details matter only inasmuch as they affect the
provided features visible by callers (e.g., signaling errors in some
cases or producing certain results in specific use cases), and also if
they affect other related functionalities.

> > What you propose is not what I think I had in mind.  I meant to extend
> > make-bool-vector (or make a new function, if extending proves
> > inconvenient or inelegant) that generates a bool-vector given 2
> > dimensions, not one.  Then such vectors could be used to create XBM
> > images of arbitrary dimensions.  We could even call this new function
> > something like make-xbm-data or somesuch, if its utility is limited to
> > XBM images.
> 
> How is a vector of bool vectors different from a 2-dimensional bool
> vector, from the point of view of Lisp?

I didn't mean to introduce a 2-dimensional bool-vector, I meant to be
able to create a unidimensional vector in a way that it could be then
used as data for XBM.  In practice, that means the number of bits in
the vector will be more than strictly required by multiplying the two
dimensions.

> As for the problem at hand, how would you feel about adding a :stride
> argument which must be a multiple of 8 and ensures that the bool
> vector passed to the XBM code has the right memory layout?

Could be fine, but I'd like to see an example of using such an API
before I make up my mind.

Thanks.

Message #35 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sat, 29 Jun 2019 07:20:26 +0000

[Message part 1 (text/plain, inline)]

On Fri, Jun 28, 2019 at 12:45 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Having thought about it, I would rather require the bool vector passed
> > to XBM to be in the right format: the width can be 100, but the
> > stride, specified by a new :stride argument, must be the smallest
> > multiple of 8 greater or equal to the width. If you don't want that,
> > pass a vector of bool vectors which is copied together, but let's not
> > pretend we can take a 10,000-bit bool vector and display it
> > efficiently.
>
> I'm not sure I understand what you mean, exactly.  Can you show an
> example of the new API?

No major changes, just that :stride is passed in along with :height
and :width (optional for now, but strongly recommended by the
documentation). See attached patch.

[0001-Allow-a-stride-argument-so-XBM-boolvecs-are-in-the-r.patch (text/x-patch, attachment)]

Message #38 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sat, 29 Jun 2019 10:56:12 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 29 Jun 2019 07:20:26 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> > I'm not sure I understand what you mean, exactly.  Can you show an
> > example of the new API?
> 
> No major changes, just that :stride is passed in along with :height
> and :width (optional for now, but strongly recommended by the
> documentation). See attached patch.

Fine with me, but please indent with indent-tabs-mode set to non-nil,
to be consistent with the surrounding indentation.

Also, this change needs to be called out in NEWS.

Thanks.

Message #41 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sat, 29 Jun 2019 08:25:21 +0000

[Message part 1 (text/plain, inline)]

On Sat, Jun 29, 2019 at 7:56 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> Fine with me, but please indent with indent-tabs-mode set to non-nil,
> to be consistent with the surrounding indentation.

Oops. I actually have indent-tabs-mode set to t, so I hope whatever
caused that didn't go wrong in other places.

> Also, this change needs to be called out in NEWS.

How's this?

[0001-Allow-a-stride-argument-so-XBM-boolvecs-are-in-the-r.patch (text/x-patch, attachment)]

Message #44 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sat, 29 Jun 2019 12:54:02 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 29 Jun 2019 08:25:21 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> > Also, this change needs to be called out in NEWS.
> 
> How's this?

It's fine, but I wonder whether the NEWS entry should contain a more
clear message about this new attribute.  Don't we want to say that
this attribute _must_ be used if :width is not an integral multiple of
8, or else the XBM image will come out slightly garbled?  The text you
wrote doesn't spell that out, and also its last sentence is about
internal implementation details, which I'm not sure matter to the
reader.

Thanks.

Message #47 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 09:48:31 +0000

[Message part 1 (text/plain, inline)]

On Sat, Jun 29, 2019 at 9:54 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> It's fine, but I wonder whether the NEWS entry should contain a more
> clear message about this new attribute.

It should :-)

> Don't we want to say that
> this attribute _must_ be used if :width is not an integral multiple of
> 8, or else the XBM image will come out slightly garbled?

It won't come out at all (I'm not sure the worst-case scenario of
shifting each successive line by an extra 7 pixels counts as
"slightly" garbled).

Slightly changed patch attached.

[0001-Allow-a-stride-argument-so-XBM-boolvecs-are-in-the-r.patch (text/x-patch, attachment)]

Message #50 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 17:34:15 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 30 Jun 2019 09:48:31 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> +A string or a bool-vector containing the bits of the image (plus
> +perhaps some extra bits at the end that will not be used).  It should
> +contain at least @var{stride} * @code{height} bits, where @var{stride}
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should be @w{@code{@var{stride} * @code{height}}}, sorry I didn't
notice this before.

Otherwise, this LGTM, thanks.

Message #53 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 14:53:24 +0000

On Sun, Jun 30, 2019 at 2:34 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > +A string or a bool-vector containing the bits of the image (plus
> > +perhaps some extra bits at the end that will not be used).  It should
> > +contain at least @var{stride} * @code{height} bits, where @var{stride}
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This should be @w{@code{@var{stride} * @code{height}}}, sorry I didn't
> notice this before.

Thanks, but maybe @w{@code{@var{stride} * @var{height}}} would be more correct?

Message #56 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 18:15:20 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 30 Jun 2019 14:53:24 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> Thanks, but maybe @w{@code{@var{stride} * @var{height}}} would be more correct?

Yes, of course.

Message #59 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 15:36:17 +0000

[Message part 1 (text/plain, inline)]

On Sun, Jun 30, 2019 at 3:15 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Thanks, but maybe @w{@code{@var{stride} * @var{height}}} would be more correct?
>
> Yes, of course.

Okay, I wasn't sure. Updated patch attached.

[0001-Allow-a-stride-argument-so-XBM-boolvecs-are-in-the-r.patch (text/x-patch, attachment)]

Message #62 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 19:09:40 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 30 Jun 2019 15:36:17 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> On Sun, Jun 30, 2019 at 3:15 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Thanks, but maybe @w{@code{@var{stride} * @var{height}}} would be more correct?
> >
> > Yes, of course.
> 
> Okay, I wasn't sure. Updated patch attached.

You removed the @w{...}, which IMO is important with long
expressions.  Other than that, looks good.

Message #65 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 17:12:53 +0000

[Message part 1 (text/plain, inline)]

> You removed the @w{...}, which IMO is important with long
> expressions.  Other than that, looks good.

You're right. I got it right in the email, so I don't know what happened there.

How's this?

[0001-Allow-a-stride-argument-so-XBM-boolvecs-are-in-the-r.patch (text/x-patch, attachment)]

Message #68 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 30 Jun 2019 20:35:06 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 30 Jun 2019 17:12:53 +0000
> Cc: triska <at> metalevel.at, 36337 <at> debbugs.gnu.org
> 
> From a10f0e6d67521ca1598ea0dd18cca0829eded517 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 29 Jun 2019 07:15:52 +0000
> Subject: [PATCH] Allow a :stride argument so XBM boolvecs are in the right
>  format.
> 
> Bug#36337
> 
> * src/image.c (xbm_image_p): Explicitly specify the right stride if a
>   bool vector is used as argument.
> * doc/lispref/display.texi (XBM Images): Describe bool vectors
>   accurately.
> * etc/NEWS: Document the change.

This is fine, thanks.

Message #71 received at 36337 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36337 <at> debbugs.gnu.org, triska <at> metalevel.at, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Tue, 24 Sep 2019 18:35:53 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Bug#36337
>> 
>> * src/image.c (xbm_image_p): Explicitly specify the right stride if a
>>   bool vector is used as argument.
>> * doc/lispref/display.texi (XBM Images): Describe bool vectors
>>   accurately.
>> * etc/NEWS: Document the change.
>
> This is fine, thanks.

This was 12 weeks ago, but the patch hadn't been applied (and looked
good to me, too), so I've now done so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.