Description of problem:
'man xdvi' says the following:
[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
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):
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).
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.
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.
> 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".
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.
The fix will hopefully occur in the tomorrow's rawhide teTeX.
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.
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.
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
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
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.
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:
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.
Fixed in 3.0-8.