Re: No MC snapshot since 2006-12-28
On Fri, 2007-01-05 at 01:27, Pavel Roskin wrote: 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). Isn't it possible to use the CVS output to see if there were updated files ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18695] tab completion vs. spaces and escaping
URL: http://savannah.gnu.org/bugs/?18695 Summary: tab completion vs. spaces and escaping Project: GNU Midnight Commander Submitted by: egmont Submitted on: Friday 01/05/2007 at 13:07 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: Tab completion (Alt+Tab or Escape+Tab, I'll refer to these simply as Tab) works exactly the same way in the command line and in dialog boxes (such as copy/move file). The function complete() in src/complete.c only takes a widget as its input and performs the completion. This approach is wrong, since the dialog boxes and the command line have different word splitting and escaping rules, they cannot be treated the same way. Currently they both have bugs. (I found these while trying to tidy up my mp3s, where lots of file and directory names contain spaces.) In the file copy and similar dialogs, filenames are typed as pure strings without any kind of escaping, and a text entry only takes one filename. However, splitting at spaces is still performed. Suppose I have a directory named /tmp/a bcde. I press F5/F6 on a file, and type /tmp/a and then Tab, it completes to /tmp/a bcde. This is okay. But if I type /tmp/a bc and press Tab now, it completes to the files in the current directory whose name begins with bc, due to the splitting at the space. Similarly, if I already have /tmp/a bcde/ in the edit field, it won't complete to subdirectories or files of this directory. In this case the whole content of the field should be treated as one, not being split at spaces. In the command line, splitting at spaces is okay, however, we would need some escaping and unescaping too, which doesn't happen. (Note: Esc followed by Enter correctly escapes the filename when it puts it into the cmdline.) Example: type ls /tmp/a and then Tab, you'll have ls /tmp/a bcdefgh/ in the command line, which clearly won't list the contents of that directory due to the unescaped space character. Another example: type ls /tmp/a\ b and hit Tab, it won't complete to ls /tmp/a\ bcde/, but it should. I understand that it is beyond the scope of mc to perform a full shell syntax parsing (single and double quotes, nesting them etc.). This doesn't even happen when Esc Enter is pressed: backslashes are inserted even between quotes, but I'm fine with that. However, mc should produce proper escaping when inserting spaces or other special chars as a result of completion, and should be able to parse the backslash escaping it created (or the user typed) when doing further completion. Obviously the current design of the complete() function to take only a widget is not okay (unless there's some room in the widget to store splitting and escaping rules). There are two main possible solutions I can see, but probably they'd eventually lead to basically the same code. 1) modify complete() so that it receives information on word splitting and escaping, so that it becomes more complex and probably more buggy and harder to maintain, but solves everything we need. 2) remove the word splitting code from complete(), so that it becomes simpler and perfect for the file copy/move widgets. Slightly modify its interface to take and return string and cursor positions instead of widget. Then make the command line editor split at unescaped spaces, unescape the resulted word, call complete() on this temporary string, escape the result of completion and put back in the command line. Finally, we should check how the internal cd command handles its arguments. Currently it seems to do a lot of heuristics. For example, if I type cd ab (four backslashes) then it tries to change to the directory called ab (four backslashes) but if there's no such directory, it changes to a\\b (two backslashes). This seems to be terrible, and leads to bugs, e.g. if the cursor is on a\\b and I type cd followed by a Tab, I get the command cd ab and hence it'll change to ab which is not the desired directory. I'd remove all the heuristics and perform the usual command line unescaping, just as if it was an external command. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18695 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #18689] Config checkboxes not acting on mouse click
Update of bug #18689 (project mc): Status:None = Confirmed ___ Follow-up Comment #1: Oh, well. The mouse event is directed to the groupbox (the frame holding other widgets inside it). The bad thing is that the groupbox is rather simplistic widget and it doesn't know anything about the widgets that are displayed inside it :( IMO, the real solution to this problem should involve teaching the groupbox that it holds other widgets (i.e. making it a real container widget). A simplistic solution would be to skip groupboxes when dispatching mouse events. ___ 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
[bug #18695] tab completion vs. spaces and escaping
Follow-up Comment #1, bug #18695 (project mc): Sounds familiar... http://savannah.gnu.org/bugs/?16176 ___ Reply to this item at: http://savannah.gnu.org/bugs/?18695 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Fri, 2007-01-05 at 02:32, Grigory Trenin wrote: 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? 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. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Follow-up Comment #6, bug #3836 (project mc): Some time ago dpkg had a bug: when it removed a package that contained a symlink to /dev/null, it chmod'ed /dev/null to 000. The problem was that it did a chmod() instead of lchmod(), or stat() instead of lstat() or something like that on the file to be removed. Obviously if mc changed /dev/null to 600 for everyone, we would all know about it and it would be already fixed. On the other hand I have no reason to doubt the reporter. So I guess that the bug might be that mc (or maybe its wrapper script) chmod's something to 600, and this something (a temp file maybe) happens to be a symlink to /dev/null on the reporter's system due to some special setup or env var or special wrapper script or something like that... ___ Reply to this item at: http://savannah.gnu.org/bugs/?3836 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Update of bug #3836 (project mc): Status: Need Info = Works For Me Open/Closed:Open = Closed ___ Follow-up Comment #7: Issue mentioned comment #4 was caused by a history file being symlinked to /dev/null. Closing WORKSFORME. The use of lchmod() might be useful but cannot be implemented without proper configure tests for the existence of the function. ___ Reply to this item at: http://savannah.gnu.org/bugs/?3836 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !
Update of bug #3836 (project mc): Status:Works For Me = None Open/Closed: Closed = Open ___ Follow-up Comment #8: Based the closing of this bug on http://mail.gnome.org/archives/mc/2007-January/msg1.html , overseeing Egmont's remark. We could just as well have the general discussion whether to use lchmod() where appropriate (and available) here, so I'm reopening. I would suggest fixing the issue of chmodding targets of links throughout the code, not just for this specific case. ___ Reply to this item at: http://savannah.gnu.org/bugs/?3836 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ 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
