[PATCH] xnc.hlp converted to mandoc format
Hello, I converted binary xnc.hlp to mandoc format and merged it with mc.1.in. Here are the patches to src/man2hlp.c, doc/mc.1.in (English version), and doc/Makefile.am. You can do $ diff mc.hlp.old mc.hlp to see that nothing was broken by the patch... Of course, there are some minor differences in the output, but they occur *only* with preformatted text that was in xnc.hlp. Let me describe the patch to man2hlp: 1) New commands: .ti - Temporary indent .ce - Center lines .ex - Used to exclude from the man page the text from xnc.hlp .\BOOKMARK With the .\BOOKMARK command you can place a 'bookmark' inside the node, and reference it with a link (this is used in 'NO WARRANTY' link, I already posted about this on the maillist). 2) Small change in handling .TP label to be compatible with new .ti command. The old implementation assumed that the next input line following .TP command is a paragraph label. This assumption is wrong: the next line could be a comment or another troff's command. So I did a small change - I moved that code out of the main reading loop to a better place. This also allowed to simplify the logic a bit: 'tp_flag' was triple-state (0,1,2), now it has only two states (0,1). 3) Added support of troff commands in no-fill mode. When handling .nf (no-fill command) man2hlp used a simple solution: the input was copied to output verbatim, and troff commands were ignored in that mode. For example, for the following input: .nf .B Sample text the output was .B Sample text. My patch emulates no-fill mode more closely to groff: for the input shown above the output will be Sample text in bold font. mc.1.in now takes advantage of that feature. 4) New function - unescaperise(), to remove backslash-quoting. The old implementation did it by pasting the same piece of code in 4 various parts of the program. 5) Modified string_len() function: a) Added handling of TAB character: it is assumed 8 chars in length. b) Removed that mysterious code: /* Ugly hack to prevent loss of one space */ len++; I really don't understand what this 'ugly hack' is used for. I tried to find an answer in ChangeLogs and original version of man2hlp.c from mc-4.1.35... No success. Anyway, this code is never used because printing of node headers is done directly via fprintf(), and not via print_string(). Since it has never been actually used I decided to remove it to prevent confusion. Regards, Grigory mc-xnc_hlp_gone.patch.gz Description: application/gzip ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: On Tue, 2007-01-09 at 19:08, Grigory Trenin wrote: Pavel Tsekov wrote: I am not quite satisfied with that simple solution too. What do you think if I convert xnc.hlp to mandoc format and patch man2hlp respectively? I think it will be sufficient to add to man2hlp support of these two troff commands: 1) '.ce' (to center lines) 2) '.ti' (temporary indent - to support right indention of the first line of the paragraph). Sound nice. Do you have a patch already ? :) Not yet :) I'm about to make it. Btw. after those changes do you think that xnc.hlp will still be necessary ? xnc.hlp contains information that is not included in the manual page (help's welcome screen, GNU GPL). If we merge xnc.hlp with mc.1.in, that information will be there. This is probably not what desired, so we need some means to exclude it from the manual page. We could put troff's .ex command in the appropriate place of mc.1.in, it will tell troff to stop processing. But it sometimes emits a broken pipe message. Or we could put some magic comment, and at a build time, when mc.1 is generated from mc.1.in, rip everything that follows that magic comment. P.S. Your help is much appreciated Thanks! Wish my help is useful. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: Well, we can go with the simple solution for now - but it should be documented somewhere to prevent further confusion. As to whether it is worth the effort - think about this: Me and you together spent a considerable amount of time on a simple issue - was it worth it ? I think making the things right will allow the developer to spend his time on more pressing issues. I am not quite satisfied with that simple solution too. What do you think if I convert xnc.hlp to mandoc format and patch man2hlp respectively? I think it will be sufficient to add to man2hlp support of these two troff commands: 1) '.ce' (to center lines) 2) '.ti' (temporary indent - to support right indention of the first line of the paragraph). Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: Implementing either solution would not remove the necessity of this: [...] need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. [...] To fix this there should be no preformatted pages involved, IMO. But I may be wrong. Well, sometimes preformatting is useful. Of course, it shouldn't be used for regular text, as it is used now. But in some nodes config files samples (like mc.menu) are given, and it is necessary to preserve indents and avoid line wraping for them. Besides, man2hlp handles a limited number of groff commands, it doesn't handle .ce command for example, so it is not possible to center lines with man2hlp. It is done by preformatting now. If we decide to eliminate all preformatting, it is necessary to patch man2hlp to center lines. I don't know whether the result will cover the efforts. May be it is easier just to leave that space on the right as is, and make it mouse-clickable? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: I had this idea now. How about fixing the code that captures mouse events from xterm instead ? I.e. when it receives a mouse down event it will record which key was pressed and it will copy this information to the mouse up event ? This will be not always reliable. Suppose such situation: a user presses left mouse button, then (without releasing it) presses right mouse button, and finally, he releases one of these buttons. How do we know which button (left or right) was released? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) So, there are two ways to get rid of that empty space on the right: 1) Shrink the window from 63 chars to HELP_TEXT_WIDTH (58 chars). This will cause some difficulties due to the usage of preformatted text - need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. 2) Expand HELP_TEXT_WIDTH to the effective window width (63 chars). IMHO this is better. Besides, I think it would be nice to leave a margin in one column between a text and a frame. Should I try and do it? What do you think? Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] Help Viewer - mouse issues
Hello,
Here are 3 patches to the mouse issues in the Help Viewer.
1) mouse-rightbutton.patch
Returning to a previous node by pressing right mouse button
doesn't work in xterm. It works only in Linux console with GPM.
The problem is that help_event() catches only GPM_UP event,
and it seems that xterm doesn't report which mouse button
was released. Handling GPM_DOWN instead of GPM_UP will fix it.
2) mouse-offbytwo.patch
Last two lines of the help window (the bottom line and a frame)
are not mouse-clickable. So the user will not be able to follow
a link with a mouse, if it is situated at the bottom line.
And the frame needs to be clickable because it serves a special
purpose - page scrolling.
3) mouse-linkfollow.patch
When following a link with a mouse, an extra '\n' is insterted
at the top of the window (just follow any link with a keyboard,
then return back, and follow the same link with a mouse,
and you should see the difference).
P.S.
And finally, it would be nice to add mouse auto-repeating and
wheel-scrolling. I don't provide such a patch because I think
it's better to do it after dealing with above issues.
Regards,
Grigory
--- help.c.orig 2006-12-31 02:03:48.0 +0300
+++ help.c 2007-01-03 18:38:51.0 +0300
@@ -474,7 +474,7 @@ help_event (Gpm_Event *event, void *vp)
Widget *w = vp;
Link_Area *current_area;
-if (! (event-type GPM_UP))
+if (! (event-type GPM_DOWN))
return 0;
/* The event is relative to the dialog window, adjust it: */
--- help.c.orig 2006-12-31 02:03:48.0 +0300
+++ help.c 2007-01-03 18:47:50.0 +0300
@@ -840,7 +840,7 @@ interactive_display (const char *filenam
((Widget *) help_bar)-y -= whelp-y;
((Widget *) help_bar)-x -= whelp-x;
-md = mousedispatch_new (1, 1, help_lines, HELP_WINDOW_WIDTH - 2);
+md = mousedispatch_new (1, 1, help_lines + 2, HELP_WINDOW_WIDTH - 2);
add_widget (whelp, md);
add_widget (whelp, help_bar);
--- help.c.orig 2006-12-31 02:03:48.0 +0300
+++ help.c 2007-01-03 18:55:56.0 +0300
@@ -520,7 +520,7 @@ help_event (Gpm_Event *event, void *vp)
history_ptr = (history_ptr+1) % HISTORY_SIZE;
history [history_ptr].page = currentpoint;
history [history_ptr].link = current_area-link_name;
- currentpoint = help_follow_link (currentpoint, current_area-link_name);
+ currentpoint = help_follow_link (currentpoint, current_area-link_name)
+ 1;
selected_item = NULL;
} else{
if (event-y 0)
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. Good point! Certainly, this would be better. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? It is man2hlp.c who always puts newline after the node header: fprintf (f_out, \004[Contents]\n); ... fprintf (f_out, %c[%s], CHAR_NODE_END, buffer); col++; newline (); Besides, newlines are also present in the template - xnc.hlp file. It is interesting, however, that move_backward2(), which is called when the up key is pressed, assumes '\n' as a part of the node header, but move_to_top(), which is called when the home key is pressed - doesn't. As for me, I don't like that leading '\n', but it is probably a matter of taste. IMHO it is better to fix help_follow_link(), move_to_top(), and documentation... But I remember (it was 2 months ago, I guess) you suggested to rip line wrapping code out of man2hlp and to put it in the Help Viewer... If you still plan to do it, may be it would be better to patch man2hlp.c also not to insert '\n' after the node header... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) There is some preformatted stuff that is not generated by man2hlp - nodes GNU GENERAL PUBLIC LICENSE, How to use help... I guess that is the problem - it doesn't fit after removing that + 4 part. However, that problem can be solved if we increase the mouse area: -md = mousedispatch_new (1, 1, help_lines, HELP_WINDOW_WIDTH - 2); +md = mousedispatch_new (1, 1, help_lines + 2, HELP_WINDOW_WIDTH + 1); ^^ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. In some nodes (eg, Menu File Edit) preformatted text is used (it is marked by .nf tag). In that case man2hlp will output the text as is, without trying to wrap lines, even if it exceeds HELP_TEXT_WIDTH. I think it would be nice for man2hlp to issue a warning if that happens. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc, ftp and filmview (fwd)
OK, but can you tell me a hotkey in mc to copy a full address of file in command line? Try Ctrl+Shift+Enter. It may not work on some terminals, but it works for me. It will copy the full pathname to the command line, eg: /#ftp:ftp.server.local/films/verygoodfilm.avi However, you have to edit it a bit (replace /#ftp to ftp://) so that mplayer could understant it. Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Pavel Tsekov wrote: I am not convinced that this patch is better than your first one. Its basically the same and removes a valid check - it doesn't fix the issue. It does fix the _original_ issue. And that one you are talking about is quite a different thing (see below). It isn't related to the original issue. Anyway, saving/restoring 'startpoint' in history won't fix it either. Try the following: COLS = 126 LINES = 60 1) F1 (Help) 2) Select contents and hit Enter 3) Press Page Down You should end up on Executing operating systems commands 4) Press Up You should notice that the marker doesn't select the previous link as it should. Why do you expect it? Why pressing Up should scroll _two_ lines up? It is documented that Up key scrolls only _one_ line up. From MC's help: down Move to the next item or scroll a line down. upMove to the previous item or scroll a line up. You need to press Up one more time. That's right. Because the previous link is two lines up, you have to press Up two times to scroll two lines up. By the way, Down key works the same way. So Up/Down keys work the way they are documented: - If prev/next link is visible, jump to it. - Otherwise, scroll one line up or down. If we modify it to always jump to the prev/next link even if the link is not visible, it would be easier to navigate in the contents. But it may bring confusion while navigating inside the node. IMHO, scrolling _always_ one line up is more natural and predictable behaviour. But let me return to the original issue and the patch. Of course I am not saying that it is the best, but I thoroughly analyzed the source and came to conclusion that the check and 'startpoint' are not needed. Really. Waiting for your decision. P.S. Sorry for the late reply but I have some problems which I need to take care of. If I am annoying you with such a simple issue, just say it :) Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Hello Pavel,
Pavel Tsekov wrote:
I think the correct solution would be to keep both
'startpoint' and 'currentpoint' in the history but I am
open to suggestions.
Yes, I thought about it too. This is a good and safe fix.
But I have a suggestion.
Actually, 'startpoint' is used only once at line 315 of help.c:
p = current_link - 1;
if (p = start)
return 0;
p = search_char_node (p, CHAR_LINK_START, -1);
return p;
Here 'current_link' is the pointer to the currently
selected (highlighted) link, and 'start' == 'startpoint'.
Since there can be no situation when currently selected link
is outside of the current topic, (p = start) expression
becomes true only in one rare case - when the first text in the node
is a link, for example:
^D[Topic name]^ASome link^BSome link^C
In that case 'p' will point to ']' character, and 'start_point' will
point to ^A, so (p = start) condition will be true. But
this check for (p = start) condition is not really necessary,
because search_char_node() will not search beyond the topic
boundaries, it will stop at ^D character and return NULL.
So, if that check and the 'startpoint' variable itself are not
really necessary and can be eliminated, why should we mess with
saving/restoring 'startpoint' in the history?
Please look at a new patch - what do you think?
There I removed 'startpoint' as well as the first argument of
select_prev_link() function. And after calling it there is no sense to
check if (selected_item = last_shown) - this will never happen,
so I removed it also.
Regards,
Grigory.
--- help.c.orig 2005-07-22 13:29:50.0 +0400
+++ help.c 2006-12-02 16:35:18.0 +0300
@@ -72,7 +72,7 @@
static const char *main_node; /* The main node */
static const char *last_shown = NULL; /* Last byte shown in a screen */
static int end_of_node = 0;/* Flag: the last character of the node shown?
*/
-static const char *currentpoint, *startpoint;
+static const char *currentpoint;
static const char *selected_item;
/* The widget variables */
@@ -305,19 +305,11 @@
return p - 1;
}
-static const char *select_prev_link (const char *start, const char
*current_link)
+static const char *select_prev_link (const char *current_link)
{
-const char *p;
-
if (!current_link)
return 0;
-
-p = current_link - 1;
-if (p = start)
- return 0;
-
-p = search_char_node (p, CHAR_LINK_START, -1);
-return p;
+return search_char_node (current_link - 1, CHAR_LINK_START, -1);
}
static void start_link_area (int x, int y, const char *link_name)
@@ -489,7 +481,7 @@
event-y -= 2;
if (event-buttons GPM_B_RIGHT){
- currentpoint = startpoint = history [history_ptr].page;
+ currentpoint = history [history_ptr].page;
selected_item = history [history_ptr].link;
history_ptr--;
if (history_ptr 0)
@@ -527,7 +519,7 @@
history_ptr = (history_ptr+1) % HISTORY_SIZE;
history [history_ptr].page = currentpoint;
history [history_ptr].link = current_area-link_name;
- currentpoint = startpoint = help_follow_link (currentpoint,
current_area-link_name);
+ currentpoint = help_follow_link (currentpoint, current_area-link_name);
selected_item = NULL;
} else{
if (event-y 0)
@@ -561,7 +553,7 @@
if (p == NULL)
return;
-currentpoint = startpoint = p + 1;
+currentpoint = p + 1;
selected_item = NULL;
help_callback (h, DLG_DRAW, 0);
}
@@ -582,7 +574,7 @@
history[history_ptr].page = currentpoint;
history[history_ptr].link = selected_item;
-currentpoint = startpoint = new_item + 1;
+currentpoint = new_item + 1;
selected_item = NULL;
help_callback (h, DLG_DRAW, 0);
}
@@ -595,7 +587,7 @@
static void prev_node_cmd (void *vp)
{
Dlg_head *h = vp;
-currentpoint = startpoint = history [history_ptr].page;
+currentpoint = history [history_ptr].page;
selected_item = history [history_ptr].link;
history_ptr--;
if (history_ptr 0)
@@ -672,14 +664,14 @@
if (history_ptr 0)
history_ptr = HISTORY_SIZE-1;
- currentpoint = startpoint = history [history_ptr].page;
+ currentpoint = history [history_ptr].page;
selected_item = history [history_ptr].link;
#endif
} else {
history_ptr = (history_ptr+1) % HISTORY_SIZE;
history [history_ptr].page = currentpoint;
history [history_ptr].link = selected_item;
- currentpoint = startpoint = help_follow_link (currentpoint,
selected_item) + 1;
+ currentpoint = help_follow_link (currentpoint, selected_item) + 1;
}
selected_item = NULL;
break;
@@ -704,9 +696,8 @@
case KEY_UP:
case ALT ('\t'):
/* select previous link */
- new_item = select_prev_link (startpoint, selected_item);
- selected_item = new_item;
- if (selected_item
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
Pavel Tsekov wrote: I won't apply this patch yet. I want to investigate further. Oh, now I see that I had hurried over to make that patch. I'll check everything and make another one. Without haste. Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] Help Viewer - incorrect behaviour of up arrrow key
Hello all,
While browsing MC's help, I've noticed a strange behaviour of up arrow
key. After I visit some topic and return back (using right arrow key),
the behaviour of up arrow key weirdly changes: instead of selecting
the previous link, it jumps to the top of the window!
Here is a detailed description how to reproduce it:
1) Open the Help Contents (press F1, Tab, Enter)
2) Navigate some lines forward (press End or PageDown several times)
3) Enter the selected topic (press Enter)
4) Return back (press right arrow)
5) Move to the top of Contents (press Home)
6) Now try navigating the Contents using the up and down arrow keys.
(for example, press down arrow for 5 times, then press up arrow).
You will notice that when you press up arrow key the selection
jumps to the top of window.
The problem is in the help_handle_key() function:
case KEY_UP:
case ALT ('\t'):
/* select previous link */
new_item = select_prev_link (startpoint, selected_item);
The 'startpoint' variable should be a pointer to the first byte
displayed in the Help window. But here it has a wrong value - that's
the problem. That's why select_prev_link() cannot find the link and
returns NULL, and the selection moves to the first link in the window.
I tried to find out what's wrong with the 'startpoint' variable.
I came to the conclusion that 'startpoint' is used here erroneously
instead of 'currentpoint' variable.
'currentpoint' always contains a pointer to the first byte displayed,
and it should be used here. And by the way, 'startpoint' variable
seems to be totally useless.
So in my patch I replaced 'startpoint' with 'currentpoint' and
removed the 'startpoint' variable completely.
Regards,
Grigory Trenin
--- help.c.orig 2006-11-29 18:06:27.0 +0300
+++ help.c 2006-11-29 18:09:20.0 +0300
@@ -72,7 +72,7 @@
static const char *main_node; /* The main node */
static const char *last_shown = NULL; /* Last byte shown in a screen */
static int end_of_node = 0;/* Flag: the last character of the node shown?
*/
-static const char *currentpoint, *startpoint;
+static const char *currentpoint;
static const char *selected_item;
/* The widget variables */
@@ -489,7 +489,7 @@
event-y -= 2;
if (event-buttons GPM_B_RIGHT){
- currentpoint = startpoint = history [history_ptr].page;
+ currentpoint = history [history_ptr].page;
selected_item = history [history_ptr].link;
history_ptr--;
if (history_ptr 0)
@@ -527,7 +527,7 @@
history_ptr = (history_ptr+1) % HISTORY_SIZE;
history [history_ptr].page = currentpoint;
history [history_ptr].link = current_area-link_name;
- currentpoint = startpoint = help_follow_link (currentpoint,
current_area-link_name);
+ currentpoint = help_follow_link (currentpoint, current_area-link_name);
selected_item = NULL;
} else{
if (event-y 0)
@@ -561,7 +561,7 @@
if (p == NULL)
return;
-currentpoint = startpoint = p + 1;
+currentpoint = p + 1;
selected_item = NULL;
help_callback (h, DLG_DRAW, 0);
}
@@ -582,7 +582,7 @@
history[history_ptr].page = currentpoint;
history[history_ptr].link = selected_item;
-currentpoint = startpoint = new_item + 1;
+currentpoint = new_item + 1;
selected_item = NULL;
help_callback (h, DLG_DRAW, 0);
}
@@ -595,7 +595,7 @@
static void prev_node_cmd (void *vp)
{
Dlg_head *h = vp;
-currentpoint = startpoint = history [history_ptr].page;
+currentpoint = history [history_ptr].page;
selected_item = history [history_ptr].link;
history_ptr--;
if (history_ptr 0)
@@ -672,14 +672,14 @@
if (history_ptr 0)
history_ptr = HISTORY_SIZE-1;
- currentpoint = startpoint = history [history_ptr].page;
+ currentpoint = history [history_ptr].page;
selected_item = history [history_ptr].link;
#endif
} else {
history_ptr = (history_ptr+1) % HISTORY_SIZE;
history [history_ptr].page = currentpoint;
history [history_ptr].link = selected_item;
- currentpoint = startpoint = help_follow_link (currentpoint,
selected_item) + 1;
+ currentpoint = help_follow_link (currentpoint, selected_item) + 1;
}
selected_item = NULL;
break;
@@ -704,7 +704,7 @@
case KEY_UP:
case ALT ('\t'):
/* select previous link */
- new_item = select_prev_link (startpoint, selected_item);
+ new_item = select_prev_link (currentpoint, selected_item);
selected_item = new_item;
if (selected_item currentpoint || selected_item = last_shown){
if (c == KEY_UP)
@@ -835,7 +835,7 @@
DLG_TRYUP | DLG_CENTER | DLG_WANT_TAB);
selected_item = search_string_node (main_node, STRING_LINK_START) - 1;
-currentpoint = startpoint = main_node + 1;
+currentpoint = main_node + 1
Re: [PATCH] Help Viewer - incorrect behaviour of up arrrow key
s/right arrow/left arrow/g Of course I meant left arrow key when I was talking about going back to the previous topic. Sorry for that. -- Grigory. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
