|Summary:||xdvi - navigation with a space bar does not keep position|
|Product:||[Fedora] Fedora||Reporter:||Michal Jaegermann <michal>|
|Component:||tetex||Assignee:||Jindrich Novy <jnovy>|
|Status:||CLOSED RAWHIDE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-11-05 08:19:05 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): tetex-xdvi-3.0-4 How reproducible: always 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 actually.
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" section): 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.