Re: [PATCH] Editor locking update

On Fri, Mar 26, 2004 at 01:01:42PM -0500, Pavel Roskin wrote:
> 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?

Let me explain. Rewind flag tells editor to do standard undo at the
end of sequence of edits caused by a single keypress. AFAIK it is
essential, because one keypress could generate hundreds of edit_insert
actions each calling edit_modification.

The structure is:

 edit_callback                  edit_push_key_press
       |                    .-- (to indicate beginning of sequence)
 edit_execute_key_command --|
       |                    `-- do_undo (to rewind the stack if needed)
       | | |
 edit_insert / edit_delete / others (maybe multiple times)
 edit_modification (maybe multiple times)

So only at the leaves we know that the keypress has caused buffer
modification. But they can be called multiple times during the same
keypress, so we can:

1. Turn some flag on on abort and modify every function which calls
edit_modification to abort output on this flag. Check this flag in
edit_modification to ask the question only *once* for example after F8
keypress which calls multiple edit_delete.

2. Turn some flag on on abort. After the keypress is handled (in
edit_execute_key_command) do_undo if the flag is set.

Hope I'm elaborate enough. I've choosen the second approach which is
IMO less intrusive. If you see some other way, let me know.

> 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?

The locking scheme is based on Emacs and JED. Let me quote

jed has:
/foofile is locked by alpha mentat 1907   (S)teal, (P)roceed, (A)bort?

emacs has:
/foofile locked by alpha mentat (pid 1907): (s, q, p, ?)?

Help shows:

It has been detected that you want to modify a file that someone else
has already started modifying in EMACS.

You can <s>teal the file; The other user becomes the
  intruder if (s)he ever unmodifies the file and then changes it again.
You can <p>roceed; you edit at your own (and the other user's) risk.
You can <q>uit; don't modify this file.

Yes, it could be hard to understand. But in fact after this patch
(which only updates existing locking scheme) this will be easier for
the user, because he can "Abort" when he feels lost, rewinding the

> 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?

Maybe the Emacs help above clarifies something.

Yes, it would be best to have it documented on F1. But currently
query_dialog has "[QueryBox]" help context hardcoded :(

> 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 am not a native English speaker, so fell free to modify it as you

> understand your intention correctly, of course).  Aslo, I believe this
> question should be asked only once per file.

It is asked only the first time the user modifies the file, and before
save. It is already in the sources, but I will quote it once more:

   The basic idea here is quite simple.  Whenever a buffer is attached
   a file, and that buffer is modified, then attempt to lock the
   file. Moreover, before writing to a file for any reason, lock the  
   file. The lock is really a protocol respected and not a real lock.   
   The protocol is this: If in the directory of the file is a   
   symbolic link with name ".#FILE", the FILE is considered to be
   by the process specified by the link.


  __ _
 / _` |   Adam Byrtek -*- jid -*- pgp 0xB25952C0
 \__,_|   "Każdy ideał w ciele jest trywialny" - prawdy algebraiczne

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