RE: midnight bug - feature request

[BARTHAZI Andras <andras barthazi hu>]

Hi!

Well, I've tested it more. There are 3 mode:

 1. i'm "boogie"
 2. i'm "boogie / su / i'm "root"
 3. i'm "boogie / su - / i'm "root"

If I do the 2, just that way I have no problem. When I do like 1 and
like 3 the problem exists.

> > I'm using the latest snapshot, the bug is the same in the
> last days.
> > As I can remember, the same bug happened to me a long time
> ago, but I
> > can't remember clearly. The system is a Debian 3.0, the program was
> > builded from source. I use it remotely, from a PUTTY client 
> (it's on a
> > server). The version in the Debian distribution works well, without
> > any problem. If you have any other questions about my 
> configuration,
> > please tell me.
>
> I have never seen anything like that.  It's almost certainly
http://www.wish.hu/mcbug.jpg - a picture about it... :)

> a bug in putty.  I need the version of putty, the value of 
Why I don't think so, is that no problem when i'm a root user, but
problem, when i'm "boogie". And putty don't know, who I am. The other
reason is why I think that not putty is buggy, that MC that in the
Debian release works well. 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.

> the TERM environment variable (echo $TERM) and the output of
It's the same as root and as an user: xterm.
 
> "mc -V", so that I don't spend time guessing.  It would be 
GNU Midnight Commander 2002-11-17-07
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish
With builtin Editor
Using included S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support

> great if you test other terminal programs and compare 
> results.  If you are using a custom terminfo entry, I'd like 
> to see the output of infocmp (you can compress and attach it, 
> as it can be long).
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'm just using xterm. Anyway, you can get my infocmp output here:
http://www.wish.hu/xterm.out

I tried to compare environment settings as I'm root and as I'm a normal
user, I did'nt find anything useful. If you ask about something, please
do it.

> > And the feature request: I miss some (i think) easy to implement 
> > feature from the editor. First of all, the most important 
> for me is to 
> > save the position of the cursor when I leave a file, and when I go 
> > back, start at the same position.
>
> Please give more details.  Should it be a separate command 
> (save cursor
> position) or you envision it as an option for all files?  
> Should every mc process have its own remembered positions or 
> they should be shared between processes?

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.
 
> > The other is a small modification on "bracket matching". Currently, 
> > when I'm on a bracket, it shows the other bracket. My 
> request is, that 
> > I'm after (maybe before) a bracket, show the other.
>
> This functionality is already present.  If you could not find 
> it, please explain where you where looking, so that this 
> feature can be made more visible.
I did it. :) Again:

Why I ask it is that when i'm typing a program, I close and close
brackets, and _after_ when I'm closed the last one (as i think), i would
like to see, where is the opening bracket for the last one I put there.
At this time, I'm (my cursor is) not _on_ the bracket, I'm (my cursor
is) _after_ it, so I have to move back to check for it.

So: I know it is working. I ask for a small modification. Now, when I'm
_on_ a bracket, it shows the opposite one. It's okay, I like this way.
What I'm ask for to extend the feature, so when I'm after a closing
bracket, show the opposite, too (except if I'm on a bracket, this time
show that's opposite). FAR Manager, Visual Basic's IDE (as I can
remember it was a long time ago) works this way.
 
> If you are not satisfied with the existing functionality, 
> then please explain the reasons.
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.

> Just because somebody said so in the list, it doesn't mean 
> that it's true, myself included.
I still think, that it would be a nice feature for midnight. If I'm
editing a program, that has 2-3 files, and I have to make modifications,
then it's time to move to positions again-and-again to the line I want
to. It would be nice to remember it - I think it's not so convenience
and a lot of time.
 
> There is one thing that can stand in the way if you want to 
> do position saving across different instances of mc.  We need 
> locking for configuration files.  Also the configuration file 
> should be written to a temporary file and then copied to the 
> permanent location.  This is important, but not really 
> simple, and will require serious testing.
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?
 
> The great thing about open source is that we don't have to 
> keep the API stable.  It can evolve together with the 
> plugins.  The plugins can be updated when the API is updated.
>
> I'm not so optimistic about volunteers.  I'm doing some code 
> cleanup to make it easier to make extensive changes to the 
> codebase, but I haven't seen much interest in doing such 
> changes from those who actually can.
OK, I accept your opinion about it. It is just a not so important future
feature request. :)
 
Bye,
  Andras