Hi! Thanks for your help, it seems that I solved the problem. Anyway I answer your letter. :)
> Either you have two different mc executables, or they are run You are right. The working midnight commander is version 4.5.99a. The snapshot versions have the bug. > > The other reason is why I think that not putty is buggy, > that MC that > > in the Debian release works well. > > Sorry, I'm not familiar with Debian. This sentence makes no > sense to me. > Maybe 3.0 is not a release? Or you mean mc from the release? Yes, the mc from the Debian 3.0 release. > mc recently switched the internal S-Lang to version 1.4.5 - > that can be the reason. I don't understand it. > > Anyway, of course it possible that still putty is the > problem. If you > > can tell me another ssh client for windows, please do, I > will test it > > under that, too. > > Teraterm Pro. It uses vt220. It seems to works well, except the colors are totally different (red background - no blue, etc). > > > the TERM environment variable (echo $TERM) and the output of > > It's the same as root and as an user: xterm. > > I don't know any other xterm emulator for Windows except > xterm from Cygwin. It requires XFree86 for Cygwin. It may > be too heavy for you, but you can try it. Cygwin comes with OpenSSH. Putty can work as an xterm emulator, you can set it at it's configuration settings. > > The version of my PUTTY is the today's snapshot: 2002-11-08. I have > > tested it with 2002-10-26 snapshot, and with the stabil release: > > release 0.53b. You can download them from > > http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. > > I could not reproduce the problem under today's snapshot of Wine with > putty 0.53b. Hmm. > > I'm just using xterm. Anyway, you can get my infocmp output here: > > http://www.wish.hu/xterm.out > > I installed it and I still cannot reproduce the problem. I > put my screenshot here: http://www.red-bean.com/~proski/putty.png It seems that the problem was really with PUTTY, my ssh client. I don't know what's really, but after I created a new connection for testing for the same server, everything works well. Strange "feature". Thanks for your help. I tried to do the same as you: create a new connection without settings for the screen size, font and other things, and it worked. :) Sorry for it, I thought that the problem somewhere about the configuration files or the rights. ------- > > It works like the command history is working now. When you leave a > > file, mcedit will store your position. The last 20 position will be > > saved in a file. It's okay that way as the command history > is working. > > I think that stores the commands, when I'm exit from > midnight. I think > > it's okay to store the positions in memory, and when I > leave, store in > > on the disk for the next time. If you don't store it on the > disk, just > > in the memory then that will be still okay for me, but > maybe better to > > store/restore to/from disk as the command history. > > Interesting that I never liked this approach (the last mc to > exit saves the history), but users have never complained, so > it's probably OK for other users. Well, bash works the same way with it's history. I don't think this way is the bad way. :) > I often exit and enter a large file as a shortcut to go to > the beginning of the file. It's faster than Alt-L 0 Enter. > Perhaps we should make Ctrl-PgUp and Ctrl-PgDown work at > least on some terminals out-of-box before adding the feature > to store the last position. It would be a great thing. My problem is the opposite: going to the end of a large file... Of course I think storing last position should be a feature, that you can turn on, or turn off globally. It can be strange for the first time, that it stores the last position. > > For example I am writing a program. I write > x=((a+b)-(c+d)). My cursor > > is after the last closing bracket. The inconvenience is > that I have to > > go back one position to see, which opening bracket belongs > to my last > > closing bracket. I ask for that I wouldn't have to go back > one, just > > show the opposite bracket this time, too. > > Now, what should happen if your cursor is on the last > bracket? Like this: > > x=(a-(c+d)) > ^ > > Should both opening parentheses be highlighted? Should > different colors > be used for them? Should this rule apply to the cursor after opening > brackets? Like this: > > x=((a+b)-(c+d)) > ^ I think you misunderstood me. Here's another example. I checked how FAR works, this example explains that: 01234567890123456789 x=((a)-(b)) When I'm position A, let the position B highlighted. A B 0 - 1 - 2 2,10 3 3,5 4 3,5 5 3,5 6 3,5 7 7,9 8 7,9 9 7,9 10 2,10 11 2,10 12 - So it highlights both bracket. If i'm on a bracket, then the pair is evident. There is another rule: when I am after a closing bracket (and i'm not a bracket again), then the pair is the closing bracket and the other belongs to it. I don't think it's confusing, because it's totally evident which to brackets are currently shown. The difference between the current working of mc and this is just that it highlights brackets when you are after a closing bracket, too. I think it help you, when you are currently typing a difficult expression, and would like to know, if you closed all brackets, or not? How do you know it now? You have to go back to the last bracket to check, if the opening bracket that belongs to it is the first or not? > I think it would be too confusing. I don't need this > feature. If you need it, make a patch and post it to > [EMAIL PROTECTED] Don't forget to comment your patch. > Maybe some of the developers will be interested. I don't speak C well. :( > > The way I described the working of it (storing in memory, > then save it > > to disk when you close midnight) is solved now, the command history > > working the same way, isn't it? > > There have been reports that the learned keys are lost. The > command history is lost too. I've seen it myself. Adding > more things to save won't make the situation any better. But it won't be wronger, too. If you solve that problem, it won't be a problem... :) > mc is full of patches based on the principle "if I do it just > like the other guy, it should be OK". At some point the > answer becomes "no". Well, these are just a few things are I _really_ miss. I don't like emacs, vim, because they are too difficult, and not thinks the same way I am. MC do it well... That's why I ask it from you: there is no other solution for me. Bye, Andras _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
