Re: Re: mcedit bug
- From: Matthias Urban <murban cs uni-magdeburg de>
- To: mc-devel gnome org
- Subject: Re: Re: mcedit bug
- Date: Mon, 17 Dec 2001 00:09:51 +0100
[TO THE MODERATOR: Dear Pavel, as a matter of fact the mail to Bjoern
wasn't meant to be sent to the list. It was a carelessness of me. I'm
sorry.]
--------------------
Hi Steef,
> Well, indeed, I know what you mean and for these cases I usually hold a
> shift button and grab for the mouse to fall back to the good old X/gpm
> cut&paste.
Oh, this works? I never tried to hold down the shift key. (how
embarrassing :-)))
> not be able to deal with the <SHIFT-INS>. The only reason may be that
> <CTRL-INS> can store multiple lines, whereas the entry fields would
> normally close when they receive a newline. These normally need to be
Yes, that's true. But gpm`s copy mechanism can store multiple lines too.
You see, the problem is already there. Moreover, gpm running on the
virtual consoles isn't a matter of course, though it should be. For
instance the Linux distribution I'm using (SuSE) was configured to not
start gpm if xdm is also started! I don't know the reason for this
behavior (and I've changed it the day I became aware of it ;-), but that
might be not a rarity I guess.
Best regards,
Matthias
PS: Did you read the mail about the problem I had with `c.syntax'? There
I forgot to mention that I had this problem not only with the new
Midnight Commander (4.5.99a). At the moment the Commander I use doesn't
try again reading a character if there was an interrupt ('if (errno =
EINTR) continue;' commented out). This can only be a work around since I
also know that it is explicitly allowed and recommended to try a system
call again if it was interrupted. But, is it a good idea to try it
endlessly? I've no idea who is interrupting the read process, so I'm
also not able to estimate the problem :-(
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]