Re: Bugs should be reported to mc-devel@gnome.org
Pavel Tsekov wrote: On Tue, 10 Apr 2007, Jeremy Dawson wrote: Pavel Tsekov wrote: On Tue, 3 Apr 2007, Jeremy Dawson wrote: I don't understand how what you describe qualifies as a problem or a bug ? A program which grabs my window, from which I can't tell how to quit? You must be joking. You must have been living under a rock if you have no idea how to use a Norton Commander clone. It would be nice if the device between the computer moniter and the chair could actually think. I don't tolerate ignorant people. Where ignorant means not familiar with Norton Commander. This is why you're not suited to being a software developer. None of us knows everything that everybody else knows. Most of us have the sense to realise this. I'll tell you something you don't know - if you want to learn about software which is usable by someone who hasn't been taught how, or hasn't previously used a clone of that software, try any of pine mutt lynx Jeremy Dawson ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bugs should be reported to mc-devel@gnome.org
On Wed, Apr 11, 2007 at 09:02:44AM +1000, Jeremy Dawson wrote: A program which grabs my window, from which I can't tell how to quit? You must be joking. sleep 1 = it's just another program you can't tell how to quit, right? It doesn't have docs for that. Do you think you should report that to the coreutils folks? In mc, the bottom right corner shows how to quit, or how to pull down the menu where you can find the quit option, too. You can also invoke the menu with the mouse. There's also a built-in help that documents these. As you wrote, you had looked up this e-mail address in mc's manual page. So you know what man pages are and how to read them. Haven't you found the info on how to quit mc there? Surprisingly it _is_ written there, too. I'll tell you something you don't know - if you want to learn about software which is usable by someone who hasn't been taught how pine, mutt or lynx as user-friendly, and even more, newbie-friendly software??? You really must be joking... What's your goal with your bug report? Do you want to _use_ mc, become familiar with it? Or just complain that you were unable to quit and don't want to see it any more? (It seems to me that no-one around here cares about the latter one.) Doesn't your window have an X button in the upper-right corner that closes this window? Perfect way for beginners to quit any application - usually they find it on their own. Ps. I'm not a developer, just a guy who uses mc regularly and send some minor patches sometimes. But I strangely stare at your mails and can't understand them... I just have a feeling that if 1 out of 1 users (who actually has a university's domain name in his e-mail address) have no clue how to use it then it's probably not the software's fault. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
mc and utf8
Hello, I would like to help with support utf-8 in mc, because I have chosen update or rewrite the utf-8 patch as my bachelor's (student's) work. My work leader is author of the original utf-8 patch for mc. I have read some old posts about this theme and source codes of mc, too. I would known what is needed to do or how can I help you with that? My suggestion is that I could first make a few example implementations to find out the best way. Or I can do something else. So if you have something to do on mc and utf-8, I will do it. Rostislav Benes ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc and utf8
Hi, I'm very glad to hear that there's going to be some work on it! My work leader is author of the original utf-8 patch for mc. Oh my God... Who is he? (Just for curiosity.) There were lots of names: Jakub Jelinek, Vladimir Nadvornik, Jindrich Novy - AFAIK they're all involved in the current UTF-8 patches. I have read some old posts about this theme and source codes of mc, too. I recommend reading the following two threads. Especially because I also wrote my detailed opinion in both threads and I don't want to re-type them :-))) so imagine they're #included here. Proposal for simplification (2005 Sep-Oct) is (amongst others) about possibly dropping support for one of ncurses and slang. If, after some investigations, you think that dropping these would make your work much easier than probably this is the way to go. Request for discussion - how to make MC unicode capable (2007 Feb-Mar) contains lots of useful ideas. Please also see my UTF-8 related patches at https://svn.uhulinux.hu/packages/dev/mc/patches/ The most important goal I think is to get work accepted in mainstream mc. This means we need clean code that is well-designed, modularized, easy to understand, easy to verify, easy to modify/improve/fix. And of course that works correctly :) I think the first step should be to decide which scripts to support (or plan future support for). This should probably include testing commonly used terminal emulators what they do at certain circumstances. Here's what I mean: - Handling single-width characters is trivial. - Handling double-width (CJK) shouldn't be hard, but there are some tricky questions arising. E.g. what to do if only the left half of a double-width character is visible in the rightmost column during editing a file? What if wordwrap mode is on and it should continue in the next row? I don't think terminal emulators support wrapping CJK characters (and it would make no sense actually) so probably some special symbol (e.g. ») should be displayed at the end of the line if word wrapping is off, and if word wrapping is enabled then probably the whole new character should be wrapped to the next line. What if some CJK text (maybe a filename) needs to be printed in a smaller box, probably with a ~ in the middle, probably by cutting at its end...? I guess you'll need several helper functions similar to (but more complex than) my 00-70-utf8-common.patch. - What to do with zero-width characters, including combining characters? Very few terminal emulators support them correctly (e.g. plain old xterm). Should we address supporting them on these terminals? (Or at least design mc now so that it can be added easily later, without a complete rewrite?) - What to do with BIDI issues (Right-To-Left writing)? I don't know if there are terminal emulators out there at all that support RTL. But maybe mc could reverse these strings on its own and send them out without sending LTR or RTL marks so that eventually the user sees them correctly. Needless to say, this would make editing a line or a file much trickier. Maybe you should study emacs/vim whether they support BIDI... - How much support does ncurses or slang give to make these complicated things easier? The current version of mc with utf8 patches works well with single-width characters, but behaves quite bad with CJK. According to my experiences so far, most of the terminal emulators and applications handle double-width correctly, but other issues (zero-width, combining, bidi) still suffer from plenty of bugs. So for me it would seem to be a wise decision to address single and double wide characters, but not yet support other tricks. (Of course by not supporting them I mean that mc still does something reasonable in these cases, e.g. prints the Unicode value within signs or similar. It's not affordable if the screen gets completely damaged or something out of mc's control happens.) Some more random pieces of ideas you might found useful: There's a stuff called gnulib. I have absolutely no info on it, except that once I sent a bugreport to the findutils folks that case insensitive UTF-8 matching didn't work, and later they reported they were able to fix it due to an upgraded gnulib. MC with utf8 patches also suffer from such problem, case insensitive search in the viewer only works for non-accented letters. Probably gnulib provides a nice function that could solve it. In order to be able to view or edit half-text half-binary files and fully work on them, you'll need string searching and regexp matching functions that perfectly tolerate invalid byte sequences, but still find matches within the valid parts. Maybe you should take a look whether there's an already existing solution that you can use. (Maybe glibc's regex stuff, maybe pcre... I don't know whether these work correctly on mixed text/binary strings.) Currently mc with utf8 patches has a nasty bug that if a filename is invalid utf8 and you
Re: mc and utf8
Hi Egmont, Rostislav, mc-devel, On Wed, 2007-04-11 at 18:22 +0200, Egmont Koblinger wrote: Hi, I'm very glad to hear that there's going to be some work on it! My work leader is author of the original utf-8 patch for mc. Oh my God... Who is he? (Just for curiosity.) There were lots of names: Jakub Jelinek, Vladimir Nadvornik, Jindrich Novy - AFAIK they're all involved in the current UTF-8 patches. Yes of course, Rostislav came to me with a great interest in UTF8ization of mc and wanted me to supervise his bachelor's thesis in this field and I'm very happy because of that. I have never claimed I'm the only original author of the UTF-8 patch. The misunderstanding most likely came from our discussion about downstream patches in the Red Hat mc branch, where we have more of UTF-8 related patches, some of them written by me in addition to the main UTF-8 patch where many people were involved. Thanks for good pointers for Rostislav and I'm also joining wishing good luck in his upcoming work! Jindrich ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc and utf8
On Wed, Apr 11, 2007 at 07:03:44PM +0200, Jindrich Novy wrote: Hi, I have never claimed I'm the only original author of the UTF-8 patch. The misunderstanding [...] No, that was clear to me, there's no misunderstanding. I knew the UTF-8 patch was a work of several people. I was just curious who Rostislav referred to, because he (i.e. you) could also write to this list and so I knew that yeah, _he_ is his supervisor :) bye, Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
