Bug 168124 - xdvi - navigation with a space bar does not keep position
Summary: xdvi - navigation with a space bar does not keep position
Alias: None
Product: Fedora
Classification: Fedora
Component: tetex
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-09-12 18:02 UTC by Michal Jaegermann
Modified: 2013-07-02 23:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-11-05 08:19:05 UTC
Type: ---

Attachments (Terms of Use)
Patch to fix this. (879 bytes, patch)
2005-10-31 14:36 UTC, Jindrich Novy
no flags Details | Diff
patch for keeping position both forward and backwards (1.59 KB, patch)
2005-11-03 00:43 UTC, Michal Jaegermann
no flags Details | Diff

Description Michal Jaegermann 2005-09-12 18:02:30 UTC
Description of problem:

'man xdvi' says the following:

       Space key
              [unpause-or-next()]  Moves  down two-thirds of a window-full, or
              to the next page if already at the bottom of the page.

This indeed happens but there is a regression in comparison with older versions
of xdvi.  Namely while doing the above it ignores a 'keep-position' flag when
it was set and shifts a horizontal page position.  The same shows up also with
"Delete key [up-or-previous()]".

Other navigation keys which switch pages (say 'f' and synononyms, or 'b' and
synonyms) do honour the flag in question but they also keep a vertical
position on a page.  So if you are scrolling forward and you were at the
page bottom you will end at the page bottom of the next one and have to
hit, for example, "Home" to get to a text fragment which you really want
to see.

For many years now xdvi users were able to scroll through a document with
a space bar and Delete/Backspace keys without a constant need to reposition
pages left and right.  This is a serious inconvenience.  Yes, -keep flag
is now documented not to be used by up-or-previous() and down-or-next().
What do you propose to use instead to restore a badly needed functionality?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start xdvi with keepPosition flag set (say using '-keep' option) on
   any dvi file with multiple pages in it.
2. Set zoom high enough that a page is wider and taller then a display
   window and center a view of the currently displayed page.
3. Find a reasonable way to scroll through a document without pages jumping
   left and right (and without messing your horizontal position by an accident).
Additional info:

If somebody had a bright idea to re-interpret in a nasty way a long established
meaning of "keepPosition" then maybe a new "keepHorizontalPosition" is needed
for use in up-or-previous() and down-or-next()?  Frankly, holding to a vertical
position when switching pages is hardly ever useful or desired.

Comment 1 Jindrich Novy 2005-09-13 12:09:25 UTC
Yes, I can see the page is moved back to its vertical beginning independently on
whether I call xdvi with -keep option or not (or switching it by `k'). Let me
look into the code in order to try to fix it.

Comment 2 Michal Jaegermann 2005-09-13 15:50:01 UTC
> I can see the page is moved back to its vertical beginning ...

You mean that the next page is positioned again in the left-hand corner to
corner in a display window after you got to it with, say, space bar?
Other ways of switching, say by mouse clicking on a page number or with
"PageDown" will keep a position when asked but both horizontal and vertical.
PITA each way.

I did not dig into the code yet but maybe when switching pages with a "SpaceBar"
(and "Delete") one can do what "PageDown" is doing followed immediately by
"Home" (and analogous for going back).  If that is feasible that this should
be pretty "cheap fix".

Comment 3 Jindrich Novy 2005-10-31 14:36:33 UTC
Created attachment 120567 [details]
Patch to fix this.

xdvi developers forgot to check whether the keep flag was set while setting the
home position on the page before reseting x-scrollbar. This patch fixes it.

Comment 4 Jindrich Novy 2005-10-31 14:42:32 UTC
The fix will hopefully occur in the tomorrow's rawhide teTeX.

Comment 5 Michal Jaegermann 2005-11-01 20:48:09 UTC
This is only a partial fix.  While scrolling forward with a space bar indeed
goes from the bottom of one page to the top of the next _and_ keeps a horizontal
position when asked (thanks!) doing that backwards with <Backspace> keeps
both horizontal and vertical positions so, if not all lines on a page fit
in a window, you are jumping from the top to the top and similar instead of
scrolling backwards in a text.

If you will use a <Delete> key instead then indeed lines are showing up in
a (reverse) succession but switching pages moves a horizontal position as well
so either way you have to reposition - either vertically or horizontally.

Comment 6 Michal Jaegermann 2005-11-01 21:09:07 UTC
BTW - the current xdvi is awfully "chatty" on stdout.  Is this a debugging
output or this is supposed to be of some help?  I think that this is only
annoying to a non-developer.  Yes, I know that it can be make quiet with
.hushStdout but this is not a default.

Comment 7 Jindrich Novy 2005-11-02 11:55:20 UTC
I found out that the documentation of xdvi in its man page needs fixups.
Firstly, the behaviour of "Delete" key is in the right opposite with the action
that it performs (acts like inverse of "space" but performs a similar action to
"Space" as stated in the man page) Despite of this the last sentense in the
"Delete" description says that it ignores the keep flag. So that even if it's an
apparent oddity for an end user, the buggy behaviour of "delete" is in agree
with the documentation.

Maybe xdvi guys should know about this. An action of "Backspace" is not
documented at all in the man page AFAICS so I've got no clue what it should do

Comment 8 Michal Jaegermann 2005-11-02 17:03:47 UTC
I quoted documentation in my original report.  You can find there, close
to the place of the initial quote (but for some reasons in a "Delete key"

                                    By default, the Space key is bound to the
              action unpause-or-next() which does a similar thing; see  there.
              The 'keep' flag is ignored by these actions

Also a description of '-keep' option says:

       -keep  (.keepPosition)  Sets  a  flag  to indicate that xdvi should not
              move to the home position when moving to a new page.   See  also
              the  'k'  keystroke.  This flag is only honoured by the up() and
              down() actions, not by up-or-previous() and down-or-next().

I wrote that, without an explicit quote, in the last paragraph of the
original report.

So the displayed behaviour is exactly as documented although in my take, and
also all xdvi users I talked with, completely unwarranted, wrong, devoid
of sense and breaking long established conventions.  Some comments I heard
were quite a bit stronger than that.  As your partial fix shows it is not even 
something which is hard to do due to layout of internal structures. Who got
that bright idea and why I have not the slightest clue. Documenting bugs does
not make them into any lesser bugs.  

As for "Backspace" it is indeed not explicitely documented.  'man page' says:

       p      [back-page()] Moves to the previous  page  (or  back  n  pages).
              Synonyms are 'b' and Ctrl-h.

and in many circumstances Ctrl-h and "Backspace" are assumed to behave in
a similar way although strictly speaking this is not right.  Older versions
of 'man xdvi' were actually more correct (although Delete is mentioned elsewhere)

       p      Moves to the previous page (or back n pages).­
              Synonyms are `b', control-H, and Delete.

But there is also a precedent with expectations ingrained over many years
and which should not be discarded lightly for gratitous changes in an interface.
Namely in older versions of xdvi both "Backspace" and "Delete" are going back
through a document, NOT jumping from a page to page, and they keep a horizontal
position when 'k' flag is in force,

It looks like that a split of 'back-page()' action into 'back-page()' and
'up-or-previous()', and similar for forward movements, was not very well
thought through - does not matter what got documented.

I will try to find some moment later and to have a peek into sources.

Comment 9 Michal Jaegermann 2005-11-03 00:43:06 UTC
Created attachment 120672 [details]
patch for keeping position both forward and backwards

Ok, as far as "BackSpace" key goes in tetex-src-3.0/texk/xdvik/translations.h
one can find:
    "<Key>Return:	forward-page()\n"
    "<Key>Delete:	up-or-previous()\n"
    "<Key>BackSpace:	back-page()\n"
#ifdef MOTIF
    "<Key>osfDelete:	up-or-previous()\n"
    "<Key>osfBackSpace: back-page()\n"

so even if its use is not clearly documented it is obviously there. Personally
I would vastly prefer "BackSpace" doing 'up-or-previous()' as well, and I do
not see an option to rebind keys without recompiling the whole program but if
you will decide agains it I will silently suffer.  Maybe I am wrong and this
can be rebound via resources?

As for keeping a horizontal position on scroll there are functions 'home()',
which you already patched, and 'home_bottom()' which needs the same.
I also think that for completness in a non-MOTIF branch conditionals
'if (globals.widgets.x_bar != NULL)' should be replaced with
'if (globals.widgets.x_bar != NULL && !resource.keep_flag)', in both functions,

but I will leave that for you to decide.

After applying the attached patch one can scroll forward with a SpaceBar
and backwards with Delete and a horizontal position behaves in a sane manner.

Comment 10 Jindrich Novy 2005-11-05 08:19:05 UTC
Fixed in 3.0-8.

Note You need to log in before you can comment on or make changes to this bug.