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

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

[Mark Oteiza]

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.

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

[Stefan Monnier]

> 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

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

[Mark Oteiza]

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

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

[Stefan Monnier]

> 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

I can't remember the reason, but my guess is that having it be t let me
catch some programming errors earlier.  Then again, maybe it's just
a historical accident.


        Stefan