bug#4896: DocView: Continuous mode

bug#4896: DocView: Continuous mode

[Juri Linkov]

Most of my attempts to use DocView often end up by resorting to
stand-alone PDF viewers.  The reason is a single missing feature
that would be easy to implement in DocView.

What I mean is the continuous page mode where you can scroll through
document pages without having to use the previous-page and next-page keys.

With smooth scrolling, navigation keys like C-p/<up> and C-n/<down>
on reaching the beginning/end of the current page should advance to the
previous/next page.

Using the mouse in the continuous mode requires advancing to another
page on the page edges.

Any opinions on implementing this?

Also please consider the following comments on the current keys
in DocView:

<C-home> doesn't move to the top the document like `M-<' does.
and <C-end> doesn't move to the bottom the document like `M->' does.
But in normal buffers, <C-home> is equivalent to `M-<', and
<C-end> is equivalent to `M->'.

`M->' doesn't move to the end of the document, it moves to the beginning
of the last page, but not to the end of the last page.  However, as I see
in other PDF viewers, <C-end> moves to the beginning of the last page.
So maybe in DocView it should do the same.

After rebinding <C-home>/<C-end> there will be no keys to move to the
beginning/end of the current page (image).  Maybe logically suitable
keys are: `C-a'/<home> and `C-e'/<end>?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Stefan Monnier]

> What I mean is the continuous page mode where you can scroll through
> document pages without having to use the previous-page and next-page keys.
[...]
> Any opinions on implementing this?

Go for it (tho still supporting the page-by-page mode, of course: I much
prefer it since it makes it possible to browse thorugh the whole
document without wasting screen real estate on its margins).

> Also please consider the following comments on the current keys
> in DocView:

I have no opinion on this.


        Stefan

bug#4896: DocView: Continuous mode

[Juri Linkov]

[Cc'ed DocView's maintainer Tassilo Horn]

>> What I mean is the continuous page mode where you can scroll through
>> document pages without having to use the previous-page and next-page keys.
> [...]
>> Any opinions on implementing this?
>
> Go for it (tho still supporting the page-by-page mode, of course: I much
> prefer it since it makes it possible to browse thorugh the whole
> document without wasting screen real estate on its margins).

Since most stand-alone PDF views don't enable Continuous mode by default,
we could keep the current page-by-page mode in DocView as well.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri!

>>> What I mean is the continuous page mode where you can scroll through
>>> document pages without having to use the previous-page and next-page keys.
>> [...]
>>> Any opinions on implementing this?
>>
>> Go for it (tho still supporting the page-by-page mode, of course: I
>> much prefer it since it makes it possible to browse thorugh the whole
>> document without wasting screen real estate on its margins).
>
> Since most stand-alone PDF views don't enable Continuous mode by
> default, we could keep the current page-by-page mode in DocView as
> well.

What do you exactly mean with Continuous mode?  One big buffer, where
all images are shown each on its own line?  I think that would be nice
sometimes.

There's some "minor continuous mode", i.e. when you scroll with SPC and
DEL, you will finally switch pages and start at the beginning/end
respectively.  But still, there's only one image in the buffer.

Anyway, here you have a "go for it" from my side, too.  I think doc-view
is not too hard-wired to this "one page at a time" style, so it sounds
quite doable.

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Juri Linkov]

> What do you exactly mean with Continuous mode?

I mean a mode to scroll through document pages without having to use the
previous-page and next-page keys like I described in the first message:
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4896

> One big buffer, where all images are shown each on its own line?

Hmm, maybe.  Do you think this will cause problems with a large number
of pages and corresponding images in the same buffer?

> There's some "minor continuous mode", i.e. when you scroll with SPC and
> DEL, you will finally switch pages and start at the beginning/end
> respectively.

Yes, SPC and DEL already scroll continuously.

> But still, there's only one image in the buffer.

In the simplest case, one image is enough, provided that C-n/C-p
and mouse scroll will jump to the next/previous page.  That's what
`evince' and `kpdf' do in non-continuous mode.

Ideally, there could be two images at a time, where you see the tail of
the previous page and the head of the next page.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

>> What do you exactly mean with Continuous mode?
>
> I mean a mode to scroll through document pages without having to use
> the previous-page and next-page keys like I described in the first
> message:
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4896

I'm fine with everything you mentioned there.

I think mouse-4/5 once where bound to
doc-view-scroll-down-or-previous-page and
doc-view-scroll-down-or-previous-page previously, so they scrolled or
switched pages back then.  I don't know why this was changed.  I guess,
because one "press" of mouse-4/5 scrolled a half page, which was a bit
unusual...

>> One big buffer, where all images are shown each on its own line?
>
> Hmm, maybe.  Do you think this will cause problems with a large number
> of pages and corresponding images in the same buffer?

I don't know.  Just try it out by inserting all PNGs of some PDF into a
buffer.

What could be a problem with multiple images in one buffer is the
(re)conversion process on a first load of a document, or if a user wants
to adjust the scaling, or the doc has changed.  Then, one PNG after the
other changes, starting with the current one.  The conversion sentinel
is usually only called, when the whole thing has finished, but when all
PNGs are visible in the buffer, it would be better to refresh the images
as soon as a new one has finished.

The current implementation refreshes the current page, as soon as it is
(re)converted, by converting a list of important pages (the current one
and maybe some more) first so that the sentinel is called several times,
but that only works for PDFs.

>> There's some "minor continuous mode", i.e. when you scroll with SPC
>> and DEL, you will finally switch pages and start at the beginning/end
>> respectively.
>
> Yes, SPC and DEL already scroll continuously.
>
>> But still, there's only one image in the buffer.
>
> In the simplest case, one image is enough, provided that C-n/C-p and
> mouse scroll will jump to the next/previous page.  That's what
> `evince' and `kpdf' do in non-continuous mode.

Agreed.  So C-n/C-p should be bound to new functions that normally call
image-next/prev-line, or switch pages and scroll, just like
doc-view-scroll-down-or-previous-page and
doc-view-scroll-down-or-previous-page do.

> Ideally, there could be two images at a time, where you see the tail of
> the previous page and the head of the next page.

Maybe.  But the other changes are a first and simple step in the right
direction.

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Stefan Monnier]

> I think mouse-4/5 once where bound to
> doc-view-scroll-down-or-previous-page and
> doc-view-scroll-down-or-previous-page previously, so they scrolled or
> switched pages back then.  I don't know why this was changed.  I guess,
> because one "press" of mouse-4/5 scrolled a half page, which was a bit
> unusual...

I can't remember why it was changed either, but I for one would dislike
it if scrolling the image with the wheel would suddenly switch to the
next/previous page: when I scroll it's usually because I want to center
the image differently.
So I do think that we need 2 modes: a continuous mode and the current mode.

>> Hmm, maybe.  Do you think this will cause problems with a large number
>> of pages and corresponding images in the same buffer?

I can't think of any reason why that would be a problem.  OTOH the
scrolling commands will need to be changed, and that may prove
more difficult.

> What could be a problem with multiple images in one buffer is the
> (re)conversion process on a first load of a document, or if a user wants
> to adjust the scaling, or the doc has changed.

At least for PDFs, it should be fairly easy to adjust the current code
to DTRT.


        Stefan

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Hmm, maybe.  Do you think this will cause problems with a large
>>> number of pages and corresponding images in the same buffer?
>
> I can't think of any reason why that would be a problem.  OTOH the
> scrolling commands will need to be changed, and that may prove more
> difficult.

Ah, right.  All scrolling is done with the relevant image-* functions,
and AFAIK, they only work for buffers containing exactly one image and
nothing else, but I might be wrong here.

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Juri Linkov]

> > I think mouse-4/5 once where bound to
> > doc-view-scroll-down-or-previous-page and
> > doc-view-scroll-down-or-previous-page previously, so they scrolled or
> > switched pages back then.  I don't know why this was changed.  I guess,
> > because one "press" of mouse-4/5 scrolled a half page, which was a bit
> > unusual...
>
> I can't remember why it was changed either, but I for one would dislike
> it if scrolling the image with the wheel would suddenly switch to the
> next/previous page: when I scroll it's usually because I want to center
> the image differently.
>
> So I do think that we need 2 modes: a continuous mode and the current mode.

The following patch adds a new variable `doc-view-continuous-mode'
and uses it in two new commands `doc-view-next-line-or-next-page'
and `doc-view-previous-line-or-previous-page'.  However, I still
have no idea how make the mouse-wheel to jump to the next/previous
page depending on the value of `doc-view-continuous-mode'.

Index: lisp/doc-view.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/doc-view.el,v
retrieving revision 1.88
diff -c -r1.88 doc-view.el
*** lisp/doc-view.el	17 Jul 2009 19:43:53 -0000	1.88
--- lisp/doc-view.el	23 Nov 2009 09:45:37 -0000
***************
*** 222,227 ****
--- 222,236 ----
    :type 'integer
    :group 'doc-view)
  
+ (defcustom doc-view-continuous-mode nil
+   "In Continuous mode reaching the page edge advances to the next/previous page.
+ When non-nil, scrolling a line upward at the bottom edge of the page
+ moves to the next page, and scrolling a line downward at the top edge
+ of the page moves to the previous page."
+   :type 'boolean
+   :group 'doc-view
+   :version "23.2")
+ 
  ;;;; Internal Variables
  
  (defun doc-view-new-window-function (winprops)
***************
*** 286,291 ****
--- 295,304 ----
      (define-key map [remap backward-page] 'doc-view-previous-page)
      (define-key map (kbd "SPC")       'doc-view-scroll-up-or-next-page)
      (define-key map (kbd "DEL")       'doc-view-scroll-down-or-previous-page)
+     (define-key map (kbd "C-n")       'doc-view-next-line-or-next-page)
+     (define-key map (kbd "<down>")    'doc-view-next-line-or-next-page)
+     (define-key map (kbd "C-p")       'doc-view-previous-line-or-previous-page)
+     (define-key map (kbd "<up>")      'doc-view-previous-line-or-previous-page)
      (define-key map (kbd "M-<")       'doc-view-first-page)
      (define-key map (kbd "M->")       'doc-view-last-page)
      (define-key map [remap goto-line] 'doc-view-goto-page)
***************
*** 442,447 ****
--- 455,492 ----
  	(image-bol 1))
        (set-window-hscroll (selected-window) hscroll))))
  
+ (defun doc-view-next-line-or-next-page (&optional n)
+   "Scroll upward by N lines if possible, else goto next page.
+ When `doc-view-continuous-mode' is non-nil, scrolling a line upward at
+ the bottom edge of the page moves to the next page."
+   (interactive "p")
+   (if doc-view-continuous-mode
+       (let ((hscroll (window-hscroll))
+ 	    (cur-page (doc-view-current-page)))
+ 	(when (= (window-vscroll) (image-next-line n))
+ 	  (doc-view-next-page)
+ 	  (when (/= cur-page (doc-view-current-page))
+ 	    (image-bob)
+ 	    (image-bol 1))
+ 	  (set-window-hscroll (selected-window) hscroll)))
+     (image-next-line 1)))
+ 
+ (defun doc-view-previous-line-or-previous-page (&optional n)
+   "Scroll downward by N lines if possible, else goto previous page.
+ When `doc-view-continuous-mode' is non-nil, scrolling a line downward
+ at the top edge of the page moves to the previous page."
+   (interactive "p")
+   (if doc-view-continuous-mode
+       (let ((hscroll (window-hscroll))
+ 	    (cur-page (doc-view-current-page)))
+ 	(when (= (window-vscroll) (image-previous-line n))
+ 	  (doc-view-previous-page)
+ 	  (when (/= cur-page (doc-view-current-page))
+ 	    (image-eob)
+ 	    (image-bol 1))
+ 	  (set-window-hscroll (selected-window) hscroll)))
+     (image-previous-line n)))
+ 
  ;;;; Utility Functions
  
  (defun doc-view-kill-proc ()

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

> The following patch adds a new variable `doc-view-continuous-mode' and
> uses it in two new commands `doc-view-next-line-or-next-page' and
> `doc-view-previous-line-or-previous-page'.

Looks good to me, except that I have the feeling that this whole "check
if scolling happened" thingy could be refactored into its own functions
and used from doc-view-scroll-up-or-next-page and
doc-view-next-line-or-next-page (and the other two).

> However, I still have no idea how make the mouse-wheel to jump to the
> next/previous page depending on the value of
> `doc-view-continuous-mode'.

Can't you simply bind mouse-4/5 to the two new functions?

Bye,
Tassilo

> Index: lisp/doc-view.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/doc-view.el,v
> retrieving revision 1.88
> diff -c -r1.88 doc-view.el
> *** lisp/doc-view.el	17 Jul 2009 19:43:53 -0000	1.88
> --- lisp/doc-view.el	23 Nov 2009 09:45:37 -0000
> ***************
> *** 222,227 ****
> --- 222,236 ----
>     :type 'integer
>     :group 'doc-view)
>   
> + (defcustom doc-view-continuous-mode nil
> +   "In Continuous mode reaching the page edge advances to the next/previous page.
> + When non-nil, scrolling a line upward at the bottom edge of the page
> + moves to the next page, and scrolling a line downward at the top edge
> + of the page moves to the previous page."
> +   :type 'boolean
> +   :group 'doc-view
> +   :version "23.2")
> + 
>   ;;;; Internal Variables
>   
>   (defun doc-view-new-window-function (winprops)
> ***************
> *** 286,291 ****
> --- 295,304 ----
>       (define-key map [remap backward-page] 'doc-view-previous-page)
>       (define-key map (kbd "SPC")       'doc-view-scroll-up-or-next-page)
>       (define-key map (kbd "DEL")       'doc-view-scroll-down-or-previous-page)
> +     (define-key map (kbd "C-n")       'doc-view-next-line-or-next-page)
> +     (define-key map (kbd "<down>")    'doc-view-next-line-or-next-page)
> +     (define-key map (kbd "C-p")       'doc-view-previous-line-or-previous-page)
> +     (define-key map (kbd "<up>")      'doc-view-previous-line-or-previous-page)
>       (define-key map (kbd "M-<")       'doc-view-first-page)
>       (define-key map (kbd "M->")       'doc-view-last-page)
>       (define-key map [remap goto-line] 'doc-view-goto-page)
> ***************
> *** 442,447 ****
> --- 455,492 ----
>   	(image-bol 1))
>         (set-window-hscroll (selected-window) hscroll))))
>   
> + (defun doc-view-next-line-or-next-page (&optional n)
> +   "Scroll upward by N lines if possible, else goto next page.
> + When `doc-view-continuous-mode' is non-nil, scrolling a line upward at
> + the bottom edge of the page moves to the next page."
> +   (interactive "p")
> +   (if doc-view-continuous-mode
> +       (let ((hscroll (window-hscroll))
> + 	    (cur-page (doc-view-current-page)))
> + 	(when (= (window-vscroll) (image-next-line n))
> + 	  (doc-view-next-page)
> + 	  (when (/= cur-page (doc-view-current-page))
> + 	    (image-bob)
> + 	    (image-bol 1))
> + 	  (set-window-hscroll (selected-window) hscroll)))
> +     (image-next-line 1)))
> + 
> + (defun doc-view-previous-line-or-previous-page (&optional n)
> +   "Scroll downward by N lines if possible, else goto previous page.
> + When `doc-view-continuous-mode' is non-nil, scrolling a line downward
> + at the top edge of the page moves to the previous page."
> +   (interactive "p")
> +   (if doc-view-continuous-mode
> +       (let ((hscroll (window-hscroll))
> + 	    (cur-page (doc-view-current-page)))
> + 	(when (= (window-vscroll) (image-previous-line n))
> + 	  (doc-view-previous-page)
> + 	  (when (/= cur-page (doc-view-current-page))
> + 	    (image-eob)
> + 	    (image-bol 1))
> + 	  (set-window-hscroll (selected-window) hscroll)))
> +     (image-previous-line n)))
> + 
>   ;;;; Utility Functions
>   
>   (defun doc-view-kill-proc ()

bug#4896: DocView: Continuous mode

[Juri Linkov]

>> The following patch adds a new variable `doc-view-continuous-mode' and
>> uses it in two new commands `doc-view-next-line-or-next-page' and
>> `doc-view-previous-line-or-previous-page'.
>
> Looks good to me, except that I have the feeling that this whole "check
> if scolling happened" thingy could be refactored into its own functions
> and used from doc-view-scroll-up-or-next-page and
> doc-view-next-line-or-next-page (and the other two).

Yes, this could be refactored after we reach a more/less final
implementation.

>> However, I still have no idea how make the mouse-wheel to jump to the
>> next/previous page depending on the value of
>> `doc-view-continuous-mode'.
>
> Can't you simply bind mouse-4/5 to the two new functions?

mwheel.el provides many useful settings like `mouse-wheel-scroll-amount'
that we should respect in DocView.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Juri Linkov]

>>> However, I still have no idea how make the mouse-wheel to jump to the
>>> next/previous page depending on the value of
>>> `doc-view-continuous-mode'.
>>
>> Can't you simply bind mouse-4/5 to the two new functions?
>
> mwheel.el provides many useful settings like `mouse-wheel-scroll-amount'
> that we should respect in DocView.

`mwheel-scroll' relies on `scroll-up' and `scroll-down' to do its job with
the specified values of `mouse-wheel-scroll-amount'.  It would be good
if it was able to use doc-view scrolling.

Below is a proof of concept, not the final patch.  It provides the
correct behavior of the mouse wheel scrolling in continuous mode.

Any ideas how to specify doc-view scrolling functions for mwheel.el
in doc-view continuous mode?

Index: lisp/mwheel.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/mwheel.el,v
retrieving revision 1.56
diff -u -r1.56 mwheel.el
--- lisp/mwheel.el	12 Sep 2009 19:03:52 -0000	1.56
+++ lisp/mwheel.el	24 Nov 2009 17:07:28 -0000
@@ -206,7 +206,10 @@
     (unwind-protect
 	(let ((button (mwheel-event-button event)))
 	  (cond ((eq button mouse-wheel-down-event)
-                 (condition-case nil (scroll-down amt)
+                 (condition-case nil
+		     (if (eq major-mode 'doc-view-mode)
+			 (doc-view-scroll-down-or-previous-page amt)
+		       (scroll-down amt))
                    ;; Make sure we do indeed scroll to the beginning of
                    ;; the buffer.
                    (beginning-of-buffer
@@ -221,7 +224,10 @@
                       ;; to only affect scroll-down.  --Stef
                       (set-window-start (selected-window) (point-min))))))
 		((eq button mouse-wheel-up-event)
-                 (condition-case nil (scroll-up amt)
+                 (condition-case nil
+		     (if (eq major-mode 'doc-view-mode)
+			 (doc-view-scroll-up-or-next-page amt)
+		       (scroll-up amt))
                    ;; Make sure we do indeed scroll to the end of the buffer.
                    (end-of-buffer (while t (scroll-up)))))
 		(t (error "Bad binding in mwheel-scroll"))))

Index: lisp/doc-view.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/doc-view.el,v
retrieving revision 1.90
diff -u -r1.90 doc-view.el
--- lisp/doc-view.el	24 Nov 2009 07:47:49 -0000	1.90
+++ lisp/doc-view.el	24 Nov 2009 17:07:00 -0000
@@ -431,24 +431,24 @@
   (interactive)
   (doc-view-goto-page (length doc-view-current-files)))
 
-(defun doc-view-scroll-up-or-next-page ()
+(defun doc-view-scroll-up-or-next-page (&optional n)
   "Scroll page up if possible, else goto next page."
-  (interactive)
+  (interactive "^P")
   (let ((hscroll (window-hscroll))
 	(cur-page (doc-view-current-page)))
-    (when (= (window-vscroll) (image-scroll-up nil))
+    (when (= (window-vscroll) (image-scroll-up n))
       (doc-view-next-page)
       (when (/= cur-page (doc-view-current-page))
 	(image-bob)
 	(image-bol 1))
       (set-window-hscroll (selected-window) hscroll))))
 
-(defun doc-view-scroll-down-or-previous-page ()
+(defun doc-view-scroll-down-or-previous-page (&optional n)
   "Scroll page down if possible, else goto previous page."
-  (interactive)
+  (interactive "^P")
   (let ((hscroll (window-hscroll))
 	(cur-page (doc-view-current-page)))
-    (when (= (window-vscroll) (image-scroll-down nil))
+    (when (= (window-vscroll) (image-scroll-down n))
       (doc-view-previous-page)
       (when (/= cur-page (doc-view-current-page))
 	(image-eob)

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Stefan Monnier]

> Any ideas how to specify doc-view scrolling functions for mwheel.el
> in doc-view continuous mode?

mwheel could introduce mwheel-scroll-up-function and
mwheel-scroll-up-function (with global defaults of scroll-up and
scroll-down, obviously) which doc-view could set buffer-locally.

Or we could rename scroll-up/down to scroll-up/down-internal and let
scroll-up/down obey new scroll-up/down-function hooks.

I guess starting with mwheel-scroll-up/down-function is less invasive.


        Stefan


> Index: lisp/mwheel.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/mwheel.el,v
> retrieving revision 1.56
> diff -u -r1.56 mwheel.el
> --- lisp/mwheel.el	12 Sep 2009 19:03:52 -0000	1.56
> +++ lisp/mwheel.el	24 Nov 2009 17:07:28 -0000
> @@ -206,7 +206,10 @@
>      (unwind-protect
>  	(let ((button (mwheel-event-button event)))
>  	  (cond ((eq button mouse-wheel-down-event)
> -                 (condition-case nil (scroll-down amt)
> +                 (condition-case nil
> +		     (if (eq major-mode 'doc-view-mode)
> +			 (doc-view-scroll-down-or-previous-page amt)
> +		       (scroll-down amt))
>                     ;; Make sure we do indeed scroll to the beginning of
>                     ;; the buffer.
>                     (beginning-of-buffer
> @@ -221,7 +224,10 @@
>                        ;; to only affect scroll-down.  --Stef
>                        (set-window-start (selected-window) (point-min))))))
>  		((eq button mouse-wheel-up-event)
> -                 (condition-case nil (scroll-up amt)
> +                 (condition-case nil
> +		     (if (eq major-mode 'doc-view-mode)
> +			 (doc-view-scroll-up-or-next-page amt)
> +		       (scroll-up amt))
>                     ;; Make sure we do indeed scroll to the end of the buffer.
>                     (end-of-buffer (while t (scroll-up)))))
>  		(t (error "Bad binding in mwheel-scroll"))))

> Index: lisp/doc-view.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/doc-view.el,v
> retrieving revision 1.90
> diff -u -r1.90 doc-view.el
> --- lisp/doc-view.el	24 Nov 2009 07:47:49 -0000	1.90
> +++ lisp/doc-view.el	24 Nov 2009 17:07:00 -0000
> @@ -431,24 +431,24 @@
>    (interactive)
>    (doc-view-goto-page (length doc-view-current-files)))
 
> -(defun doc-view-scroll-up-or-next-page ()
> +(defun doc-view-scroll-up-or-next-page (&optional n)
>    "Scroll page up if possible, else goto next page."
> -  (interactive)
> +  (interactive "^P")
>    (let ((hscroll (window-hscroll))
>  	(cur-page (doc-view-current-page)))
> -    (when (= (window-vscroll) (image-scroll-up nil))
> +    (when (= (window-vscroll) (image-scroll-up n))
>        (doc-view-next-page)
>        (when (/= cur-page (doc-view-current-page))
>  	(image-bob)
>  	(image-bol 1))
>        (set-window-hscroll (selected-window) hscroll))))
 
> -(defun doc-view-scroll-down-or-previous-page ()
> +(defun doc-view-scroll-down-or-previous-page (&optional n)
>    "Scroll page down if possible, else goto previous page."
> -  (interactive)
> +  (interactive "^P")
>    (let ((hscroll (window-hscroll))
>  	(cur-page (doc-view-current-page)))
> -    (when (= (window-vscroll) (image-scroll-down nil))
> +    (when (= (window-vscroll) (image-scroll-down n))
>        (doc-view-previous-page)
>        (when (/= cur-page (doc-view-current-page))
>  	(image-eob)

> -- 
> Juri Linkov
> http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Juri Linkov]

> I guess starting with mwheel-scroll-up/down-function is less invasive.

Done.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Juri Linkov]

I tried to add a menu item for `doc-view-continuous-mode' with
the following patch, but it doesn't look nice since currently
`doc-view-continuous-mode' is a variable.

If there are problems with that, maybe we should create a minor mode?
However, Continuous mode as a minor mode would complicate interactions
with another minor mode `doc-view-minor-mode' with questions like
should `C-c C-c' disable `doc-view-continuous-mode' and should another
`C-c C-c' re-enable it, and so on?

Index: lisp/doc-view.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/doc-view.el,v
retrieving revision 1.92
diff -u -r1.92 doc-view.el
--- lisp/doc-view.el	25 Nov 2009 17:21:15 -0000	1.92
+++ lisp/doc-view.el	28 Nov 2009 22:51:02 -0000
@@ -332,13 +332,18 @@
 (easy-menu-define doc-view-menu doc-view-mode-map
   "Menu for Doc View mode."
   '("DocView"
+    ["Toggle display"		doc-view-toggle-display]
+    ["Continuous mode"		(setq doc-view-continuous-mode
+				      (not doc-view-continuous-mode))
+     :style toggle
+     :selected doc-view-continuous-mode]
+    "---"
     ["Set Slice"		doc-view-set-slice-using-mouse]
     ["Set Slice (manual)"	doc-view-set-slice]
     ["Reset Slice"		doc-view-reset-slice]
     "---"
     ["Search"			doc-view-search]
     ["Search Backwards"         doc-view-search-backward]
-    ["Toggle display"		doc-view-toggle-display]
     ))
 
 (defvar doc-view-minor-mode-map

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

> If there are problems with that, maybe we should create a minor mode?

I tried it out, and I'd prefer to have a minor mode, because although I
like the continuous mode, sometimes I have to switch it off.  With a
minor mode and the command bound to some key that would be more
convenient that M-: (setq doc-view-continuous-mode nil) RET.

> However, Continuous mode as a minor mode would complicate interactions
> with another minor mode `doc-view-minor-mode' with questions like
> should `C-c C-c' disable `doc-view-continuous-mode' and should another
> `C-c C-c' re-enable it, and so on?

doc-view minor mode should always be off in doc-view buffers.  Its
intention is to be active when editing a PDF/PS/DVI document in
fundamental or ps-mode.  There, it only provides the key binding C-c C-c
to switch to doc-view quickly.

So I don't see how both minor modes would interfer with each other,
except that the C-c C-c key is already used.

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Juri Linkov]

>> If there are problems with that, maybe we should create a minor mode?
>
> I tried it out, and I'd prefer to have a minor mode, because although
> I like the continuous mode, sometimes I have to switch it off.
> With a minor mode and the command bound to some key that would be more
> convenient that M-: (setq doc-view-continuous-mode nil) RET.

After implementing more smooth scrolling, we could later add
a third value (e.g. `smooth') to the customizable variable
`doc-view-continuous-mode'.  But with a minor mode this would not
be possible.  Or when somebody will request to not allow SPC and DEL
to scroll to the next/previous page, we could add a fourth value.
IOW, with defcustom we have more degrees of freedom.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>> I tried it out, and I'd prefer to have a minor mode, because although
>> I like the continuous mode, sometimes I have to switch it off.  With
>> a minor mode and the command bound to some key that would be more
>> convenient that M-: (setq doc-view-continuous-mode nil) RET.
>
> After implementing more smooth scrolling, we could later add a third
> value (e.g. `smooth') to the customizable variable
> `doc-view-continuous-mode'.  But with a minor mode this would not be
> possible.

We could have a variable `doc-view-continuous-kind' and a minor mode
`doc-view-continuous-mode'.  To me the current behavior, smooth
scrolling or even auto-scrolling are all different kinds of continuous
mode.

This would allow the flexibility you are striving for while still make
it easy for user to toggle to non-continuous mode.

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Juri Linkov]

>> After implementing more smooth scrolling, we could later add a third
>> value (e.g. `smooth') to the customizable variable
>> `doc-view-continuous-mode'.  But with a minor mode this would not be
>> possible.
>
> We could have a variable `doc-view-continuous-kind' and a minor mode
> `doc-view-continuous-mode'.  To me the current behavior, smooth
> scrolling or even auto-scrolling are all different kinds of continuous
> mode.
>
> This would allow the flexibility you are striving for while still make
> it easy for user to toggle to non-continuous mode.

But this means that continuous mode should be enabled by default,
because the current default behavior is a kind of continuous mode
that allows only SPC and DEL to jump to the next/previous page.

This means that users will be interested only in changing the value of
`doc-view-continuous-kind' (interactively from the menu or with a command
bound to some key).  Thus the minor mode `doc-view-continuous-mode'
will be useless.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>> We could have a variable `doc-view-continuous-kind' and a minor mode
>> `doc-view-continuous-mode'.  To me the current behavior, smooth
>> scrolling or even auto-scrolling are all different kinds of
>> continuous mode.
>>
>> This would allow the flexibility you are striving for while still
>> make it easy for user to toggle to non-continuous mode.
>
> But this means that continuous mode should be enabled by default,
> because the current default behavior is a kind of continuous mode that
> allows only SPC and DEL to jump to the next/previous page.
>
> This means that users will be interested only in changing the value of
> `doc-view-continuous-kind' (interactively from the menu or with a
> command bound to some key).  Thus the minor mode
> `doc-view-continuous-mode' will be useless.

If doc-view-continuous-kind has a value `none' and there's an interface
for changing the value quickly, I'm also satisfied without having a
minor mode. :-)

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Juri Linkov]

>>> We could have a variable `doc-view-continuous-kind' and a minor mode
>>> `doc-view-continuous-mode'.  To me the current behavior, smooth
>>> scrolling or even auto-scrolling are all different kinds of
>>> continuous mode.
>>>
>>> This would allow the flexibility you are striving for while still
>>> make it easy for user to toggle to non-continuous mode.
>>
>> But this means that continuous mode should be enabled by default,
>> because the current default behavior is a kind of continuous mode that
>> allows only SPC and DEL to jump to the next/previous page.
>>
>> This means that users will be interested only in changing the value of
>> `doc-view-continuous-kind' (interactively from the menu or with a
>> command bound to some key).  Thus the minor mode
>> `doc-view-continuous-mode' will be useless.
>
> If doc-view-continuous-kind has a value `none' and there's an interface
> for changing the value quickly, I'm also satisfied without having a
> minor mode. :-)

But currently `doc-view-continuous-mode' has the same purpose with
a different name :-)

Generally, what I what to achieve is to do the same as in stand-alone
PDF viewers - there is only one menu item "Continuous mode".  However,
continuous mode is implemented differently: some PDF viewers use
smooth scrolling, other PDF viewers display only one image at a time.
With a variable like `doc-view-continuous-kind', we could make this
difference customizable.  We should to find a way to do this cleanly.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>> If doc-view-continuous-kind has a value `none' and there's an interface
>> for changing the value quickly, I'm also satisfied without having a
>> minor mode. :-)
>
> But currently `doc-view-continuous-mode' has the same purpose with a
> different name :-)

I totally agree with everything you say, and I don't want to argue about
the name.  -mode is not my favourite, because it sounds like a minor
mode variable.  How about doc-view-continuous-style?

What's important to me is that the default style can be customized,
*and* that there's an interface command to switch to another style when
viewing a document.

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Juri Linkov]

>>> If doc-view-continuous-kind has a value `none' and there's an interface
>>> for changing the value quickly, I'm also satisfied without having a
>>> minor mode. :-)
>>
>> But currently `doc-view-continuous-mode' has the same purpose with a
>> different name :-)
>
> I totally agree with everything you say, and I don't want to argue about
> the name.  -mode is not my favourite, because it sounds like a minor
> mode variable.

That's is good that we've identified the problem.  The suffix -mode
suggests that it's a mode while it is not.

> How about doc-view-continuous-style?

In one of my intermediate versions I named this variable
doc-view-continuous-level that I think is an equally bad name :-)

So I installed a patch that simply removes the suffix -mode
to use a simpler name `doc-view-continuous'.

> What's important to me is that the default style can be customized,
> *and* that there's an interface command to switch to another style when
> viewing a document.

Yes, now `doc-view-continuous' can be customized and also its value
can be selected from the menu and saved as the default value.
Later we could add more values such as "Smooth" for smooth scrolling
and "Restrictive" to not jump to the next/previous page on SPC/DEL.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Juri Linkov]

>>> One big buffer, where all images are shown each on its own line?
>>
>> Hmm, maybe.  Do you think this will cause problems with a large number
>> of pages and corresponding images in the same buffer?
>
> I don't know.  Just try it out by inserting all PNGs of some PDF
> into a buffer.

Later we could try to implement more smooth scrolling
similar to Google Books powered book previews like e.g.
http://oreilly.com/catalog/9780596153618/preview
It fills the page with placeholders for all images
that display the initial text "Loading..." and loads
an image only when you scroll to it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Juri Linkov]

> There's some "minor continuous mode", i.e. when you scroll with SPC and
> DEL, you will finally switch pages and start at the beginning/end
> respectively.  But still, there's only one image in the buffer.

Multi-page scolling doesn't always work even with SPC and DEL.
Visiting a PDF file puts it to read-only mode, that puts it to view-mode
(when `view-read-only' is t).  And view-mode overrides DocView's SPC and
DEL bindings with its own SPC and DEL bindings (`View-scroll-page-forward'
and `View-scroll-page-backward') that are incompatible with image scrolling.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>> There's some "minor continuous mode", i.e. when you scroll with SPC
>> and DEL, you will finally switch pages and start at the beginning/end
>> respectively.  But still, there's only one image in the buffer.
>
> Multi-page scolling doesn't always work even with SPC and DEL.
> Visiting a PDF file puts it to read-only mode, that puts it to
> view-mode (when `view-read-only' is t).

Hm, at least, that's not the default value.

> And view-mode overrides DocView's SPC and DEL bindings with its own
> SPC and DEL bindings (`View-scroll-page-forward' and
> `View-scroll-page-backward') that are incompatible with image
> scrolling.

Maybe we should switch off view-mode in doc-view-mode explicitly?  IMO
doc-view-mode is THE view-mode for PDF/DVI/PS files...

Bye,
Tassilo

bug#4896: DocView: Continuous mode

[Stefan Monnier]

> Maybe we should switch off view-mode in doc-view-mode explicitly?  IMO
> doc-view-mode is THE view-mode for PDF/DVI/PS files...

Yes, we should,


        Stefan

bug#4896: DocView: Continuous mode

[Juri Linkov]

>> Multi-page scolling doesn't always work even with SPC and DEL.
>> Visiting a PDF file puts it to read-only mode, that puts it to
>> view-mode (when `view-read-only' is t).
>
> Hm, at least, that's not the default value.
>
>> And view-mode overrides DocView's SPC and DEL bindings with its own
>> SPC and DEL bindings (`View-scroll-page-forward' and
>> `View-scroll-page-backward') that are incompatible with image
>> scrolling.
>
> Maybe we should switch off view-mode in doc-view-mode explicitly?  IMO
> doc-view-mode is THE view-mode for PDF/DVI/PS files...

Thanks.  It seems your fix doesn't work.  The reason is that
`after-find-file' calls `view-mode-enter' *after* calling
`doc-view-mode' via `normal-mode'.

However, adding the following line to the end of `doc-view-mode'
seems to work (because `after-find-file' checks for `view-read-only'
before calling `view-mode-enter'):

    (set (make-local-variable 'view-read-only) nil)

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: DocView: Continuous mode

[Juri Linkov]

>> Maybe we should switch off view-mode in doc-view-mode explicitly?  IMO
>> doc-view-mode is THE view-mode for PDF/DVI/PS files...
>
> Thanks.  It seems your fix doesn't work.  The reason is that
> `after-find-file' calls `view-mode-enter' *after* calling
> `doc-view-mode' via `normal-mode'.
>
> However, adding the following line to the end of `doc-view-mode'
> seems to work (because `after-find-file' checks for `view-read-only'
> before calling `view-mode-enter'):
>
>     (set (make-local-variable 'view-read-only) nil)

This still doesn't work in all cases.  Typing `v' on a PDF file in Dired
activates View-mode (I type RET in Dired when the intention is to *edit*
the file, and type `v' when the intention is to *view* the file).

Doc-view-mode has no chance to disable view-mode, because view-file
(called from dired-view-file) at first visits the file with
find-file-noselect that enables doc-view-mode, and after that
view-file enables view-mode.

View-file doesn't enable view-mode only when the property `mode-class' is
`special'.  Actually lisp/doc-view.el already contains the necessary line,
but it is commented out:

;; (put 'doc-view-mode 'mode-class 'special)

I wonder what was the reason for commenting this out?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: Doc-view-mode with View-mode

[Juri Linkov]

>>     (set (make-local-variable 'view-read-only) nil)
>
> This still doesn't work in all cases.  Typing `v' on a PDF file in Dired
> activates View-mode (I type RET in Dired when the intention is to *edit*
> the file, and type `v' when the intention is to *view* the file).
>
> Doc-view-mode has no chance to disable view-mode, because view-file
> (called from dired-view-file) at first visits the file with
> find-file-noselect that enables doc-view-mode, and after that
> view-file enables view-mode.
>
> View-file doesn't enable view-mode only when the property `mode-class' is
> `special'.  Actually lisp/doc-view.el already contains the necessary line,
> but it is commented out:
>
> ;; (put 'doc-view-mode 'mode-class 'special)
>
> I wonder what was the reason for commenting this out?

Stefan, do you remember why you commented out this line?

When `doc-view-mode' has this `mode-class' property, then
viewing a PDF file from Dired doesn't activates View-mode.
(And setting `view-read-only' to nil is not necessary anymore.)

Also I discovered another case: visiting a PDF file from a tar archive
activates View-mode, because `tar-extract' tries to mimic `view-file'
but ignores the `mode-class' property.  The patch below fixes this bug
for tar-mode.el by duplicating more code from `view-file'.

After feature freeze this duplicate code could be moved
from `view-file' to `view-buffer'.

=== modified file 'lisp/doc-view.el'
--- lisp/doc-view.el	2010-02-01 18:25:47 +0000
+++ lisp/doc-view.el	2010-02-01 23:01:10 +0000
@@ -1124,7 +1124,7 @@ (defun doc-view-search-previous-match (a
 
 ;;;; User interface commands and the mode
 
-;; (put 'doc-view-mode 'mode-class 'special)
+(put 'doc-view-mode 'mode-class 'special)
 
 (defun doc-view-already-converted-p ()
   "Return non-nil if the current doc was already converted."
@@ -1302,7 +1302,7 @@ (defun doc-view-mode ()
     ;; canonical view mode for PDF/PS/DVI files.  This could be
     ;; switched on automatically depending on the value of
     ;; `view-read-only'.
-    (set (make-local-variable 'view-read-only) nil)
+    ;; (set (make-local-variable 'view-read-only) nil)
     (run-mode-hooks 'doc-view-mode-hook)))
 
 ;;;###autoload

=== modified file 'lisp/tar-mode.el'
--- lisp/tar-mode.el	2010-01-13 08:35:10 +0000
+++ lisp/tar-mode.el	2010-02-01 23:01:10 +0000
@@ -852,14 +852,23 @@ (defun tar-extract (&optional other-wind
           (set (make-local-variable 'tar-superior-descriptor) descriptor)
           (setq buffer-read-only read-only-p)
           (tar-subfile-mode 1)))
-      (if view-p
-	  (view-buffer
-	   buffer (and just-created 'kill-buffer-if-not-modified))
-	(if (eq other-window-p 'display)
-	    (display-buffer buffer)
-	  (if other-window-p
-	      (switch-to-buffer-other-window buffer)
-	    (switch-to-buffer buffer)))))))
+      (cond
+       (view-p
+	;; FIXME: code duplicated from `view-file', perhaps the test for special
+	;; mode-class should be moved from `view-file' to `view-buffer'.  (Bug#4896)
+	(if (eq (with-current-buffer buffer
+		  (get major-mode 'mode-class))
+		'special)
+	    (progn
+	      (switch-to-buffer buffer)
+	      (message "Not using View mode because the major mode is special"))
+	  (view-buffer buffer (and just-created 'kill-buffer-if-not-modified))))
+       ((eq other-window-p 'display)
+	(display-buffer buffer))
+       (other-window-p
+	(switch-to-buffer-other-window buffer))
+       (t
+	(switch-to-buffer buffer))))))
 
 
 (defun tar-extract-other-window ()

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: Doc-view-mode with View-mode

[Stefan Monnier]

>>> (set (make-local-variable 'view-read-only) nil)
>> This still doesn't work in all cases.

No, but it's still a correct setting.

> Stefan, do you remember why you commented out this line?
> When `doc-view-mode' has this `mode-class' property, then
> viewing a PDF file from Dired doesn't activates View-mode.

Because I think that mode-class is for buffers whose content is
generated from a process or something like that, not from files.
Things like dired, pcl-cvs, ibuffer, shell-mode, compilation-mode, ...

> (And setting `view-read-only' to nil is not necessary anymore.)

Why not?

> Also I discovered another case: visiting a PDF file from a tar archive
> activates View-mode, because `tar-extract' tries to mimic `view-file'
> but ignores the `mode-class' property.  The patch below fixes this bug
> for tar-mode.el by duplicating more code from `view-file'.

> After feature freeze this duplicate code could be moved
> from `view-file' to `view-buffer'.

I think the right solution should be to let the major mode say
explicitly that it is mutually-exclusive with view-mode.  And it should
be a dynamic property: it should only apply when the ps/pdf/dvi document
is displayed as an image, not when it's displayed as text.


        Stefan

bug#4896: Doc-view-mode with View-mode

[Juri Linkov]

>> Stefan, do you remember why you commented out this line?
>> When `doc-view-mode' has this `mode-class' property, then
>> viewing a PDF file from Dired doesn't activates View-mode.
>
> Because I think that mode-class is for buffers whose content is
> generated from a process or something like that, not from files.
> Things like dired, pcl-cvs, ibuffer, shell-mode, compilation-mode, ...
>
>> (And setting `view-read-only' to nil is not necessary anymore.)
>
> Why not?

Because its value is inessential with (put 'doc-view-mode 'mode-class 'special).
Functions `after-find-file', `view-file', `toggle-read-only' check for
`mode-class' to not activate view-mode when major mode is special.

Do you think we should add another similar property applicable only to
disabling view-mode?

>> Also I discovered another case: visiting a PDF file from a tar archive
>> activates View-mode, because `tar-extract' tries to mimic `view-file'
>> but ignores the `mode-class' property.  The patch below fixes this bug
>> for tar-mode.el by duplicating more code from `view-file'.
>
>> After feature freeze this duplicate code could be moved
>> from `view-file' to `view-buffer'.
>
> I think the right solution should be to let the major mode say
> explicitly that it is mutually-exclusive with view-mode.

mode-class=special already says that it is mutually-exclusive with
view-mode, and a new similar property could do the same.

> And it should be a dynamic property: it should only apply when the
> ps/pdf/dvi document is displayed as an image, not when it's displayed
> as text.

mode-class=special already doesn't disable view-mode when the ps/pdf/dvi
document is visited as text because in this case the major mode is not
doc-view-mode.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: Doc-view-mode with View-mode

[Stefan Monnier]

> mode-class=special already doesn't disable view-mode when the ps/pdf/dvi
> document is visited as text because in this case the major mode is not
> doc-view-mode.

Fair enough, go for it,


        Stefan

bug#4896: Doc-view-mode with View-mode

[Juri Linkov]

>> mode-class=special already doesn't disable view-mode when the ps/pdf/dvi
>> document is visited as text because in this case the major mode is not
>> doc-view-mode.
>
> Fair enough, go for it,

Do you mean putting mode-class=special on `doc-view-mode'?

=== modified file 'lisp/doc-view.el'
--- lisp/doc-view.el	2010-02-01 18:25:47 +0000
+++ lisp/doc-view.el	2010-02-03 23:57:08 +0000
@@ -1124,7 +1124,7 @@ (defun doc-view-search-previous-match (a
 
 ;;;; User interface commands and the mode
 
-;; (put 'doc-view-mode 'mode-class 'special)
+(put 'doc-view-mode 'mode-class 'special)
 
 (defun doc-view-already-converted-p ()
   "Return non-nil if the current doc was already converted."

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: Doc-view-mode with View-mode

[Stefan Monnier]

>>> mode-class=special already doesn't disable view-mode when the ps/pdf/dvi
>>> document is visited as text because in this case the major mode is not
>>> doc-view-mode.
>> Fair enough, go for it,
> Do you mean putting mode-class=special on `doc-view-mode'?

Yes.


        Stefan

bug#4896: Doc-view-mode with View-mode

[Juri Linkov]

>>>> mode-class=special already doesn't disable view-mode when the ps/pdf/dvi
>>>> document is visited as text because in this case the major mode is not
>>>> doc-view-mode.
>>> Fair enough, go for it,
>> Do you mean putting mode-class=special on `doc-view-mode'?
>
> Yes.

Actually the same problem exists also for `image-mode'.  Visiting an image
from an archive activates `view-mode'.  This causes incorrect image browsing
that uses view-mode scrolling commands instead of image scrolling commands.

Maybe `image-mode' should have the property mode-class=special as well?

=== modified file 'lisp/image-mode.el'
--- lisp/image-mode.el	2010-01-13 08:35:10 +0000
+++ lisp/image-mode.el	2010-02-04 19:44:42 +0000
@@ -317,6 +317,8 @@ (defvar image-minor-mode-map
 
 (defvar bookmark-make-record-function)
 
+(put 'image-mode 'mode-class 'special)
+
 ;;;###autoload
 (defun image-mode ()
   "Major mode for image files.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#4896: Doc-view-mode with View-mode

[Stefan Monnier]

> Maybe `image-mode' should have the property mode-class=special as well?

Yes.  As a rule, most things that apply to image-mode also apply to
doc-view-mode and vice versa.  For this reason, we should try and
increase the sharing between these two modes.


        Stefan

bug#4896: DocView: Continuous mode

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> With smooth scrolling, navigation keys like C-p/<up> and C-n/<down>
> on reaching the beginning/end of the current page should advance to the
> previous/next page.
>
> Using the mouse in the continuous mode requires advancing to another
> page on the page edges.
>
> Any opinions on implementing this?

It seems like Juri implemented this at the time, and it seems to work
well for me.  The discussion then went on to whether it should be a
minor mode (I don't think that's necessary) and various other
improvements in doc-view and image-mode, but I think that basically
everything concrete was covered, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#4896: DocView: Continuous mode

[Juri Linkov]

>> With smooth scrolling, navigation keys like C-p/<up> and C-n/<down>
>> on reaching the beginning/end of the current page should advance to the
>> previous/next page.
>>
>> Using the mouse in the continuous mode requires advancing to another
>> page on the page edges.
>>
>> Any opinions on implementing this?
>
> It seems like Juri implemented this at the time, and it seems to work
> well for me.  The discussion then went on to whether it should be a
> minor mode (I don't think that's necessary) and various other
> improvements in doc-view and image-mode, but I think that basically
> everything concrete was covered, so I'm closing this bug report.

I implemented only a simple version that doesn't scroll smoothly.
Fortunately, now dalanicolai is making progress on the complete
implementation of this feature.  And development is going on
on emacs-devel, so this request doesn't need to be kept open indeed.