Re: yet another utf8 patch: fix completion
Hi Egmont, On Tue, 2007-01-02 at 18:14 +0100, Egmont Koblinger wrote: Hi, Especially to the maintainers of the UTF-8 patches: I've created another patch, this time to fix Alt+Tab (or Escape then TAB) completion when the command line or filename or whatever you type already contains some accented characters. The problem is caused by the UI widget telling the cursor position in characters, while the functions in complete.c expect them to refer to bytes. This new patch can be found at the usual places: https://svn.uhulinux.hu/packages/2.0/mc/patches/ https://svn.uhulinux.hu/packages/dev/mc/patches/ and is called 00-84-utf8-complete.patch. As usual, unfortunately, length and width are not clearly distinguished, so it's unlikely to work correctly with double-width characters. To be applied on the top of the previous utf8 patches in numerical order (though it doesn't depend on all of them). Just a question related to 00-84-utf8-complete.patch. Why do you replace if (SLsmg_Is_Unicode) with if (1) in the implementation of mbstrnlen() ? Will it work when mc is compiled with UTF-8 patches and ran with non-UTF-8 locale? Thanks, Jindrich ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: yet another utf8 patch: fix completion
Hi, Just a question related to 00-84-utf8-complete.patch. Why do you replace if (SLsmg_Is_Unicode) with if (1) in the implementation of mbstrnlen() ? I just applied the previous patches and then cloned mbstrnlen() from mbstrlen(). This modification comes from patch nr. 00-75. As far as I remember, mc processes the --help switch before initializing slang, but we already need a properly working mbstrlen() here to have the 2nd column of the row +number displayed in the right place, if the translation of the string +number contains accents. (The least important issue any of these utf8 patches addresses :-)) Since mbstrnlen() is not used at this time, it's perfectly okay to have if (SLsmg_Is_Unicode) there. Probably a better approach would be to initialize slang at the very start and have both functions begin with if (SLsmg_Is_Unicode). Will it work when mc is compiled with UTF-8 patches and ran with non-UTF-8 locale? I guess it will, but I haven't tested. IIRC I once tested it with --help and it worked. I think mbrtowc() and friends work correctly when converting between arbitrary non-UTF-8 locale and wchar. ... OK, now I did a quick test of tab completion in latin2 and it seems to work correctly. Please note that I also modify mbstrlen() in patch nr. 00-82, and this one also affects my implementation of mbstrnlen(). By the way, it seemed to me that we wouldn't need mbstrnlen(), since when we call it, we actually always pass it the actual length of the string. If it is the case, a simple mbstrlen() would have done it; but I just couldn't get sure this is the case; and I didn't want to use a different approach than the original code did. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
No MC snapshot since 2006-12-28
Would you check why the snapshot is not being generated ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: 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. 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 ? I'm CC-ing to the xterm developer just in case he can give some insight. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18689] Config checkboxes not acting on mouse click
URL: http://savannah.gnu.org/bugs/?18689 Summary: Config checkboxes not acting on mouse click Project: GNU Midnight Commander Submitted by: egmont Submitted on: Thursday 01/04/2007 at 18:52 Category: None Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Release: current (CVS or snapshot) Operating System: GNU/Linux ___ Details: Under Options/Configuration and Options/Layout, checkbox or radiobutton options that precede the currently focused widget are not clickable with mouse, these mouse clicks are simply ignored. Example: open the Options/Configuration dialog, click on the checkbox of the last option (safe deLete), then click on any other option with your mouse, this second click will have no effect. You have to use the keyboard or close this dialog and open again to change these options. Tested with 4.6.1 and with 2007-01-04-16 snapshot, both on Linux console (gpm) and in gnome-terminal. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18689 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. -- Regards, Pavel Roskin ___ 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: No MC snapshot since 2006-12-28
On Thu, 2007-01-04 at 21:07, Pavel Roskin wrote: On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. I see. I thought the snapshot was generated manually. At least it seemed to me that new versions appear after changes were commited :) Perhaps the process can be automated ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Thu, 2007-01-04 at 22:33, Grigory Trenin wrote: 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? Well, we don't :) But who will do this anyway ? I mean it's pointless :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: No MC snapshot since 2006-12-28
On Thu, 2007-01-04 at 23:07 +0200, Pavel Tsekov wrote: On Thu, 2007-01-04 at 21:07, Pavel Roskin wrote: On Thu, 2007-01-04 at 17:51 +0200, Pavel Tsekov wrote: Would you check why the snapshot is not being generated ? No problems this time. I run the snapshot generator manually from time to time. The new snapshot is available now. I see. I thought the snapshot was generated manually. At least it seemed to me that new versions appear after changes were commited :) Perhaps the process can be automated ? The script will need to find out if there are any updates in CVS. We don't want to post a snapshot without actual changes in CVS. Unfortunately, there is no single commit ID in CVS, so I'll need to implement an algorithm to calculate it (I think it could be SHA1 of the sorted list of all files with revisions). I'm placing the issue on my TODO list. -- Regards, Pavel Roskin ___ 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
