unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Rah Guzar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 62679@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
Subject: bug#62679: 29.0.60; Bindings on `image-map` cause error on sliced images
Date: Thu, 06 Apr 2023 17:43:55 +0200	[thread overview]
Message-ID: <87pm8hat4s.fsf@zohomail.eu> (raw)
In-Reply-To: <83o7o1qrew.fsf@gnu.org>

Hi Eli,
  I can confirm that the issue is mostly fixed now. One thing I noticed
  was that it is still possible to trigger the error by starting with my
  recipe before, moving the point to somewhere on the image and then
  using right arrow key. Since the image has a single column the point
  is now off image but on the same line. This buffer position still has
  the "image-map" and pressing e.g. "i +" still causes the error.

  I also see the artifacts you mentioned with "i -". I am using
  "insert-sliced-image" to insert image of typeset math in a comint
  derived mode and I have seen visual artifacts at the end of line
  there too and like in this case "describe-char" shows them to be
  control characters. The also seem to disappear on their own if I
  switch buffer and back. I haven't been able to get rid of them and
  can't reproduce them in "emacs -Q" so I might be doing something wrong
  but this makes me think this might be the result of creating the image
  with a ":max-width" property which might cause the equivalent of "i-".

  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. From the perspective of
  scrolling it would nicer to have slices which have a fixed length and
  width so that number of slices changes when "i +" and "i -" are used.

Thanks a lot!
Rah Guzar

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 05 Apr 2023 17:23:11 +0200
>> From:  Rah Guzar via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> (let* ((image (create-image path-to-png 'png nil :mask 'heuristic))
>>        (rows (max 1 (1- (cdr (image-size image))))))
>>   (goto-char (point-max))
>>   (insert "\n")
>>   (insert-sliced-image image " " nil rows))
>> ```
>> This inserts the image specified at the end of the buffer. The image
>> has a `keymap` text property which include binding for various
>> operations on images but moving point to the image and trying to use
>> any of these (e.g. `i +` to increase image size) results in the error,
>>
>> Error running timer ‘image--change-size’: (error "No image under point")
>
> This should be fixed now on the emacs-29 branch.
>
> It isn't perfect: "i -" leaves display artifacts (which I think are
> unrelated to this bug report per se), and "i r" doesn't really work,
> except when you type 'r' 4 times in a row.  But I'm not sure I
> understand the conceptual meaning of rotating a sliced image, and even
> resizing it doesn't necessarily have a clear-cut meaning IMO.
>
> Perhaps we should decide we don't support these operations for sliced
> images, and simply show a different error message specifically about
> that non-support?
>
> Lars, any comments and/or ideas?





  reply	other threads:[~2023-04-06 15:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 15:23 bug#62679: 29.0.60; Bindings on `image-map` cause error on sliced images Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-06  9:41 ` Eli Zaretskii
2023-04-06 15:43   ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-04-06 16:24     ` Eli Zaretskii
2023-04-06 18:30       ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-08  9:46         ` Eli Zaretskii
2023-04-08 18:29           ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-08 18:58             ` Eli Zaretskii

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pm8hat4s.fsf@zohomail.eu \
    --to=bug-gnu-emacs@gnu.org \
    --cc=62679@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rahguzar@zohomail.eu \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).