Re: [patch] fix another End keypress lockup in the viewer
Hello,
On Sun, 14 Aug 2005, Jindrich Makovicka wrote:
the new viewer has a problem with viewing files with DOS line
separators, which manifests again in a lockup after pressing the End
key. Then, it is impossible to move the view further, except by pressing
the Home key.
It is caused by the code of view_move_up, which moves by one line using
view_coord_to_offset() and then view_offset_to_coord() with offset
decremented by one. In the case of 0d/0a separator, the decremented
offset points to 0d, and view_offset_to_coord() returns the same coords.
The attached patch fixes the issue by decrementing the offset until
something else than 0d appears.
I've also been looking into this issue lately but I haven't got enough
time to write a proper patch and I wanted to discuss this issue with
Roland. Now looking at your patch I think that your approach is not the
best one. Before commiting this patch consider the facts below.
The actual problem does not lie in view_move_up() but in the viewer's
coordinate cache handling. view_ccache_lookup() doesn't do proper handling
for '\r' and as result the same offset in the file is returned for both
'\n' and '\r' thus the code in view_move_up() cannot perform the move in
the case described by Arpad Biro. I think fixing view_ccache_lookup() is
how the problem should be attacked.
Another approach would be to simplify the following code from
view_move_up():
} else if (line = 1) {
view_coord_to_offset (view, linestart, line, 0);
view_offset_to_coord (view, line, col, linestart - 1);
/* if the only thing that would be displayed were a
* single newline character, advance to the previous
* part of the line. */
if (col 0 col % width == 0)
col -= width;
else
col -= col % width;
} else {
It is clear now that the assumption that `linestart - 1' is not always an
offset inside the text on the previous line. Is it safe to assume that if
`line' does exist `line - lines' would also exist (of course if lines is
not greater than line) ? If so why don't we just do :
view_coord_to_offset (view, (view-dpy_topleft), line - line, 0);
I haven't investigated this possibility properly but maybe Roland can
comment.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] interruptible search in the viewer
Hello, On Sun, 14 Aug 2005, Jindrich Makovicka wrote: The attached patch makes the search function interruptible by Ctrl-C. Hehe - I was wondering why the only way to stop a search trough a big file was killing MC :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] interruptible search in the viewer
Jindrich Makovicka wrote: The attached patch makes the search function interruptible by Ctrl-C. Committed. Thanks. I am not sure it it doesn't interfere with get_byte() stuff which can do some I/O, but block_search doesn't disable the interrupts during I/O either. I just fixed the case when using mc_read(). The other cases still need to be checked. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Jindrich Makovicka wrote: Hello, the new viewer has a problem with viewing files with DOS line separators, which manifests again in a lockup after pressing the End key. Then, it is impossible to move the view further, except by pressing the Home key. Can you provide a file where that lockup occurs? As always, I cannot reproduce the bug. But I have found another bug in the coordinate cache code. Opening the attached file and running mc_ccache_dump() results in an endless loop. I will first fix this one, perhaps it fixes your bug, too. Roland 1025 ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Hello, On Mon, 15 Aug 2005, Roland Illig wrote: Jindrich Makovicka wrote: Hello, the new viewer has a problem with viewing files with DOS line separators, which manifests again in a lockup after pressing the End key. Then, it is impossible to move the view further, except by pressing the Home key. I have corrected the view_ccache_lookup() function so that it does not store an entry in the cache when the previous character is a '\r'. Can you please check if this fixes the bug? I still cannot reproduce it. :( Are you kidding ? Have you tried with the file I've sent you ? I've debugged the problem and there is no way that it wont happen. Are you using the correct MC binary ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Pavel Tsekov wrote: Are you kidding ? Have you tried with the file I've sent you ? I've debugged the problem and there is no way that it wont happen. Are you using the correct MC binary ? I am using mc-HEAD with the exception of src/view.c, which I took from yesterday. I extracted the file from your mail, pressed Down until I reached the end of file, then pressed Up until I reached the beginning of the file. And I reached it. Or did I completely miss the point here? Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc editor small changes III - unified diff
Hi Jindrich, thanks for your mehodology hints... I'll keep it in my mind. To your question. I'd prefer to have '' ... '' highlightment mainly for c++ code (nested templates ...). You're right that nowadays C code doesn't require that, but are we sure that for instance function templates feature aren't going to be available in C ? We may think about conditioning this feature, but it requires bigger changes to CoolEdit used in MC. Kind Regards, Frantisek Puvodni zprava Od: Jindrich Novy [EMAIL PROTECTED] Predmet: Re: mc editor small changes III - unified diff Datum: 13.8.2005 12:45:59 Hello Frantisek, On Thu, 2005-08-11 at 09:07 +0200, František Řezníček wrote: here are the changes (just unified diff) : Please send the patch as an attachment for the next time, it makes extraction of it less painful. # Should I use the latest nighbuild and incorporate the changes there or you can # do it? The best is probably to send here a ported patch to one of the latest releases as it's likely that the patch will be applied smoothly to HEAD. # Could I hope to have these minor changes in the official mc? I modified the patch a bit so that it looks bit better now. Please avoid shipping commented-out code within the patch. The question is whether highlighting of '' and '' is desirable in all cases. Highlighting of such characters doesn't make too much sense when editing C source files for instance. mc-devel, what's your opition on this? Yes/No? Attaching the updated patch - applies smoothly to 4.6.1. Best, Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Hello, On Mon, 15 Aug 2005, Roland Illig wrote: Pavel Tsekov wrote: Are you kidding ? Have you tried with the file I've sent you ? I've debugged the problem and there is no way that it wont happen. Are you using the correct MC binary ? I am using mc-HEAD with the exception of src/view.c, which I took from yesterday. I extracted the file from your mail, pressed Down until I reached the end of file, then pressed Up until I reached the beginning of the file. And I reached it. Or did I completely miss the point here? Yes! But it is not your fault. The problem was originally described here: http://mail.gnome.org/archives/mc-devel/2005-July/msg00341.html Follow those instructions. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Pavel Tsekov wrote:
Another approach would be to simplify the following code from
view_move_up():
} else if (line = 1) {
view_coord_to_offset (view, linestart, line, 0);
view_offset_to_coord (view, line, col, linestart - 1);
/* if the only thing that would be displayed were a
* single newline character, advance to the previous
* part of the line. */
if (col 0 col % width == 0)
col -= width;
else
col -= col % width;
} else {
It is clear now that the assumption that `linestart - 1' is not always an
offset inside the text on the previous line.
EPARSE. Did you mean this:?
It is clear now that `linestart - 1' is not always an offset inside
the text on the previous line.
Why? If only because of the buggy coordinate cache, this does not count.
The bug is fixed.
Is it safe to assume that if `line' does exist `line - lines' would
also exist (of course if lines is not greater than line) ? If so why
don't we just do:
view_coord_to_offset (view, (view-dpy_topleft), line - lines, 0);
Because we are in text wrap mode. Internally the viewer stores the
unwrapped coordinates. When you want to go one line up, you have to
distinguish whether you are inside a long line or at the beginning of a
line. This is what the code does.
The code you suggest is used in the !hex_mode !text_wrap_mode case.
To my knowledge, the code cannot be made simpler. I could add some
comments to the code to make understanding it simpler. Shall I?
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Hello, On Mon, 15 Aug 2005, Roland Illig wrote: Because we are in text wrap mode. Internally the viewer stores the unwrapped coordinates. When you want to go one line up, you have to distinguish whether you are inside a long line or at the beginning of a line. This is what the code does. Well, maybe the cache should be changed then. And btw this was idea that I have not investigated fully it just crossed my mind. But what is done now is clearly suboptimal. The code you suggest is used in the !hex_mode !text_wrap_mode case. To my knowledge, the code cannot be made simpler. I could add some comments to the code to make understanding it simpler. Shall I? Roland, are you really thinking that I do not understand that code ? Did you miss the fact that I've determined where the right place to fix this bug is ? Now, after nearly 5 months or working on the viewer - do you understand your code ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Midnight Commander problem
Hello, I have an annoying problem that I have not been able to find any help about on the internet or mention that it is happening to anyone else. However, it happens on both Fedora CORE 3 installations that I have. I use a telnet application from my Windows 2000 client to connect to the Linux hosts. At first I've gotten a garbled screen when typing MC but I figured out that if I change my environment variable from LANG=en_US.UTF-8 to LANG=en_US it looks great in telnet with TERM=vt320, even colors and menus work well. The problem is that when I exit Midnight Commander, it exits normally two or three times, and then it gives me a message about a zero screen dimension. Once I see that, when I go back into MC, the screen goes blank and shows the following message at the bottom: libgpm: zero screen dimension, assuming 80x25. It is completely locked up at this point. If I disconnect and then reconnect I can sign back in but going into MC just locks up the session again. If I reboot the Linux host, MC works fine for another two or three times. If I use VNC or the console to connect and I have TERM=xterm then MC works fine even when it doesn't through telnet. I have tried playing with stty but have not had any luck with that. I would be much happier if I didn't have to reboot the server throughout the day as I use MC quite a bit. My version is below. powermc -V GNU Midnight Commander 4.6.1 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support Any help would be greatly appreciated. Thank you. Kurt Wagner [EMAIL PROTECTED] ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander problem
Hello Kurt, On Mon, 2005-08-15 at 09:10 -0400, Wagner, Kurt wrote: I use a telnet application from my Windows 2000 client to connect to the Linux hosts. Have you tried to use ssh connection instead of the telnet one? Do the same problems occur when you use PuTTY? http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] fix another End keypress lockup in the viewer
Pavel Tsekov wrote: Hello, On Mon, 15 Aug 2005, Roland Illig wrote: Because we are in text wrap mode. Internally the viewer stores the unwrapped coordinates. When you want to go one line up, you have to distinguish whether you are inside a long line or at the beginning of a line. This is what the code does. Well, maybe the cache should be changed then. And btw this was idea that I have not investigated fully it just crossed my mind. But what is done now is clearly suboptimal. If the cache was changed, the code for the non-wrapping text mode would become more complicated, just as the text_wrap_mode code is now. I decided to store the unwrapped coordinates in the cache because the user might change the screen size, which would invalidate the whole cache if it contained the wrapped coordinates. The unwrapped coordinates also make displaying the current position very easy. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
