bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]