emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On image-mode-winprops and using image-mode elsewhere


From: Stefan Monnier
Subject: Re: On image-mode-winprops and using image-mode elsewhere
Date: Wed, 14 Dec 2016 08:37:12 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

> I've been poking image-dired lately and wanted to use the navigation
> commands implemented in image-mode in image-dired-display-image-mode.
> This should be as simple as setting a keymap parent, but I am greeted
> with

>   (wrong-type-argument listp t)

> which appears to me to be due to 83600dc. In particular, the line

>   (defvar-local image-mode-winprops-alist t)

> but I think this should be nil.  Thought I'd ask before I change it.

I'm pretty sure there was a good reason why I put t in there.

I can't remember the details, but here's what I can tell you:

- the main source of complexity in that code is the desire to be able to
  move within the image differently in each window when the buffer is
  displayed in several windows.  And also to try and "remember where we
  were" if you temporarily switch to some other buffer and come back.
  IOW, the desire to reproduce what usually happens with `point` but in
  the context of images where `point` can't play its role.

- this is also used in doc-view-mode (where it's even more important,
  since it lets you see different pages of the document at the same time
  in different windows).

- I seem to remember that the code is picky for good reasons: if you're
  not careful earlier, you end up with a problem later which is rather
  difficult/painful to understand.

- the code needs window-configuration-change-hook (and that's probably
  why just setting a keymap parent isn't good enough).  Maybe we could
  make the "just set the keymap parent" work by making the commands
  ensure the hook is in place.

- I'm not very happy with this code, because it was a pain to make it
  work and is fiddly.


        Stefan



reply via email to

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