[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62679: 29.0.60; Bindings on `image-map` cause error on sliced images
From: |
Eli Zaretskii |
Subject: |
bug#62679: 29.0.60; Bindings on `image-map` cause error on sliced images |
Date: |
Sat, 08 Apr 2023 12:46:55 +0300 |
> From: Rah Guzar <rahguzar@zohomail.eu>
> Cc: larsi@gnus.org, 62679@debbugs.gnu.org
> Date: Thu, 06 Apr 2023 20:30:19 +0200
>
> > I cannot reproduce this. On my system, if I move point with the right
> > arrow key, "M-x describe-text-properties" doesn't show the keymap
> > property.
>
> You are right there is no keymap property there but somehow "image-map"
> is still active. I can press "i +" there and see the error while after or
> before the image pressing "i +" will insert the two characters.
Thanks, I fixed this now on the emacs-29 branch.
> >> According to the info manual, the advantage of using sliced images is
> >> to get a more intuitive scrolling behavior and that is the reason I am
> >> using them. I think for everything else the image should behave as a
> >> single image. For that reason the behavior of "i r" seems correct to
> >> me. It rotates the image and then slices.
> >
> > If this is what you see, I guess you have Emacs built with
> > ImageMagick? I don't see "rotation followed by slicing", because the
> > code doesn't do that, at least not with rotation that is implemented
> > natively in Emacs on my system. But, as I said, rotation of sliced
> > image is not well defined, so my opinion is that people should not
> > depend on it doing something sensible.
>
> Evaluating "(image-type-available-p 'imagemagick)" returns nil so I
> think Emacs is built without imagemagick support. The sequence of
> command I ran to build it were
> ./configure --with-pgtk
> make
> make bootstrap
> where the first make failed due to some org issue.
>
> But to the broader point about rotation not being sensible I think it
> might be a good idea to put a different keymap on sliced images in that
> case. Maybe "sliced-image-map" which should be the parent of
> "image-map". I don't see any misbehavior though.
I added a new map, in which some commands that have no meaning for
sliced images are absent.
And with that, I'm closing this bug.