Re: [PATCH] Editor locking update



On Thu, 25 Mar 2004, Adam Byrtek / alpha wrote:

> Hi. I'm attaching a patch to the editor locking scheme. First of all
> it adds the most useful option to "Lock encountered" dialog called
> 'Abort'. It allows user to cancel editing keypress and rewind any
> changes. Unfortunately it required a new flag in the edit widget,
> which I called rewind.

What is rewind?  How it's different from "undo"?  Why is it needed?  Maybe
it's better to check the lock before executing the action instead of
undoing it?

> Moreover the patch forces mc to check validity of it lock before any
> save operation, so it can react if the lock was grabbed by sb else.

Please avoid abbreviations like "sb" in ChangeLog.  Also, entries for
every function start with a new line.  It's a little detail, but such
details take time to fix.  Technical documentation shouldn't look like SMS
messages.

> I tested it in a few different scenarios, but of course any feedback
> is appreciated. Andrew please could you review and apply this patch,
> if Pavel is unavaliable?

I've tested the patch.  If I try to edit a file in two processes I get a
dialog that suggests following:

File "remove_proc_entry.diff" is already being edited
User: proski localhost
Process ID: 15745
[ Grab lock ]  [ Proceed ]  [ Abort ]

I'm afraid most users won't know the difference between "Grab lock" and
"Proceed".  Even those who are fluent in English.  Why do we want users to
make this choice?  Are there any meaningful reasons why we expose all these
technical details about locking?

Can you suggest a situation when "Grab lock" is what the user wants, and
both "Proceed" and "Abort" would be unacceptable?

Conversely, can you suggest a situation when "Proceed" is what the user
wants, and both "Grab lock" and "Abort" would be unacceptable?

Also, "Abort" sounds wrong.  Support I press an editing key by accident.
My options are two things I don't quite understand plus "Abort".  Abort
what?  The editor?  The mc process?  Will it dump the core?

I think "Stay read-only" or something like that would be better (if I
understand your intention correctly, of course).  Aslo, I believe this
question should be asked only once per file.

-- 
Regards,
Pavel Roskin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]