[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On image-mode-winprops and using image-mode elsewhere
From: |
Mark Oteiza |
Subject: |
Re: On image-mode-winprops and using image-mode elsewhere |
Date: |
Wed, 14 Dec 2016 10:09:59 -0500 |
User-agent: |
Mutt/1.7.2+4 (df1d1e379477) (2016-11-26) |
On 14/12/16 at 08:37am, Stefan Monnier wrote:
> > 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.
Ah, adding that does make everything work, but it appears that it simply
sets the alist to nil anyways if it's not #'consp. Further, after
reading a little more carefully I can't find anything that actually
checks if image-mode-winprops-alist is t, as opposed to an object within
that can be '(t . ALIST). That (image-mode-winprops t) is invariably an
error makes me think that the alist always gets set to nil and possibly has
elements added to it before a call to image-mode-winprops happens. But
perhaps there is a reason for it!
In any case, looks like I don't need to touch it by taking care of the
window configuration hook. Thanks