From: Pip Cet <pipcet@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36337@debbugs.gnu.org, triska@metalevel.at
Subject: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Sun, 23 Jun 2019 19:16:04 +0000 [thread overview]
Message-ID: <CAOqdjBdji=k4QnkepWEYuP6eECh2PNrWL2OufvDw4OEaQhOqNw@mail.gmail.com> (raw)
In-Reply-To: <83o92omezr.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On Sun, Jun 23, 2019 at 4:41 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sun, 23 Jun 2019 16:26:16 +0000
> > Cc: triska@metalevel.at, 36337@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?
[-- Attachment #2: 0001-Don-t-assume-the-width-of-xbm-images-is-divisible-by.patch --]
[-- Type: text/x-patch, Size: 3655 bytes --]
From 2fbff32843dceb6a903ca98a03b2f981c076d3b3 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Sun, 23 Jun 2019 08:02:18 +0000
Subject: [PATCH] Don't assume the width of xbm images is divisible by 8.
---
src/alloc.c | 2 +-
src/data.c | 20 ++++++++++++++++++++
src/fns.c | 3 +++
src/image.c | 14 +++++++++++---
4 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index 64aaa8acdf..a80fce078f 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -2210,7 +2210,7 @@ make_uninit_bool_vector (EMACS_INT nbits)
DEFUN ("make-bool-vector", Fmake_bool_vector, Smake_bool_vector, 2, 2, 0,
doc: /* Return a new bool-vector of length LENGTH, using INIT for each element.
-LENGTH must be a number. INIT matters only in whether it is t or nil. */)
+LENGTH must be a number. INIT matters only in whether it is true or nil. */)
(Lisp_Object length, Lisp_Object init)
{
Lisp_Object val;
diff --git a/src/data.c b/src/data.c
index c1699aeae7..76b1c6ca4c 100644
--- a/src/data.c
+++ b/src/data.c
@@ -3783,6 +3783,25 @@ DEFUN ("bool-vector-count-consecutive", Fbool_vector_count_consecutive,
return make_fixnum (count);
}
+DEFUN ("bool-vector-extract", Fbool_vector_extract, Sbool_vector_extract, 1, 3, 0,
+ doc: /* Return a new bool vector which consists of the bits
+between index FROM (inclusive) and index TO (exclusive) of VECTOR. */)
+ (Lisp_Object vector, Lisp_Object from, Lisp_Object to)
+{
+ Lisp_Object res;
+ ptrdiff_t size, ifrom, ito;
+
+ CHECK_BOOL_VECTOR (vector);
+ size = bool_vector_size (vector);
+ validate_subarray (vector, from, to, size, &ifrom, &ito);
+
+ res = make_uninit_bool_vector (ito - ifrom);
+
+ for (ptrdiff_t i = ifrom; i < ito; i++)
+ bool_vector_set (res, i - ifrom, bool_vector_bitref (vector, i));
+
+ return res;
+}
\f
void
syms_of_data (void)
@@ -4064,6 +4083,7 @@ #define PUT_ERROR(sym, tail, msg) \
defsubr (&Sbool_vector_subsetp);
defsubr (&Sbool_vector_count_consecutive);
defsubr (&Sbool_vector_count_population);
+ defsubr (&Sbool_vector_extract);
set_symbol_function (Qwholenump, XSYMBOL (Qnatnump)->u.s.function);
diff --git a/src/fns.c b/src/fns.c
index fd0c7fc71a..6bf469d1e9 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -1326,6 +1326,9 @@ DEFUN ("substring", Fsubstring, Ssubstring, 1, 3, 0,
Lisp_Object res;
ptrdiff_t size, ifrom, ito;
+ if (BOOL_VECTOR_P (string))
+ return Fbool_vector_extract (string, from, to);
+
size = CHECK_VECTOR_OR_STRING (string);
validate_subarray (string, from, to, size, &ifrom, &ito);
diff --git a/src/image.c b/src/image.c
index 7b648c46ae..79c8ac0df8 100644
--- a/src/image.c
+++ b/src/image.c
@@ -3242,7 +3242,7 @@ xbm_image_p (Lisp_Object object)
}
else if (BOOL_VECTOR_P (data))
{
- if (bool_vector_size (data) / height < width)
+ if (height > 0 && bool_vector_size (data) / height < width)
return 0;
}
else
@@ -3794,6 +3794,16 @@ xbm_load (struct frame *f, struct image *img)
{
USE_SAFE_ALLOCA;
+ if (BOOL_VECTOR_P (data))
+ {
+ Lisp_Object newdata = Fmake_vector (make_fixnum (img->height), Qnil);
+ for (int y = 0; y < img->height; y++)
+ ASET (newdata, y, Fsubstring (data,
+ make_fixnum (y * img->width),
+ make_fixnum ((y + 1) * img->width)));
+ data = newdata;
+ }
+
if (VECTORP (data))
{
int i;
@@ -3813,8 +3823,6 @@ xbm_load (struct frame *f, struct image *img)
}
else if (STRINGP (data))
bits = SSDATA (data);
- else
- bits = (char *) bool_vector_data (data);
#ifdef HAVE_NTGUI
{
--
2.20.1
next prev parent reply other threads:[~2019-06-23 19:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-23 7:15 bug#36337: 26.1; XBM images are sometimes not displayed correctly Markus Triska
2019-06-23 8:05 ` Pip Cet
2019-06-23 8:22 ` Markus Triska
2019-06-23 14:29 ` Eli Zaretskii
2019-06-23 16:26 ` Pip Cet
2019-06-23 16:40 ` Eli Zaretskii
2019-06-23 19:16 ` Pip Cet [this message]
2019-06-28 7:57 ` Eli Zaretskii
2019-06-28 8:29 ` Pip Cet
2019-06-28 12:43 ` Eli Zaretskii
2019-06-29 7:20 ` Pip Cet
2019-06-29 7:56 ` Eli Zaretskii
2019-06-29 8:25 ` Pip Cet
2019-06-29 9:54 ` Eli Zaretskii
2019-06-30 9:48 ` Pip Cet
2019-06-30 14:34 ` Eli Zaretskii
2019-06-30 14:53 ` Pip Cet
2019-06-30 15:15 ` Eli Zaretskii
2019-06-30 15:36 ` Pip Cet
2019-06-30 16:09 ` Eli Zaretskii
2019-06-30 17:12 ` Pip Cet
2019-06-30 17:35 ` Eli Zaretskii
2019-09-24 16:35 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOqdjBdji=k4QnkepWEYuP6eECh2PNrWL2OufvDw4OEaQhOqNw@mail.gmail.com' \
--to=pipcet@gmail.com \
--cc=36337@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=triska@metalevel.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.