Re: [Bug-zile] File change on disk

[Garnaik Sumeet]

Hi Gary,

        I will do that and regarding the tests in specl I will try to figure that asap and get back to you if I need any help. As soon as this bug is fixed I hope to start working on the unicode support.

On Sun, Apr 6, 2014 at 3:21 PM, Gary V. Vaughan <address@hidden> wrote:

Hi Garnaik,

On Apr 6, 2014, at 4:01 PM, Garnaik Sumeet <address@hidden> wrote:

> Hi,
>    What do I do when file changes on disk?
> Here are the possible paths:
> 1) Overwrite all the changes in the disk by allowing save_buffer function to perform its actions as usual (in ./lib/zile/file.lua) and only give an error message.
> 2) Load the file again into the buffer.
> 3) Ask for the user to take the decision.

As I outlined in my review comments on github, zemacs is a clone of Emacs and so
must behave precisely same way that Emacs does for all of the features that it
implements.

Observe and replicate the exact words and behavior of Emacs when you perform the
following:

  1a. echo foo > bar
  1b. emacs bar
  1c. (in another terminal) echo baz >> bar
  1d. back in emacs, press a key to change the contents of the buffer

(note that emacs complains a bit, and asks what to do)

And continuing, some more behavior to replicate:

  2. in emacs, C-x C-s to save the buffer

Also, there is another behavior we need to clone:

  3a. echo foo > bar
  3b. emacs bar
  3c. still in emacs, press a key to change the contents of the buffer
  3d. (in another terminal) echo baz >> bar

(note that the emacs buffer and file have diverged now, but Emacs ignores the
changes to the file after editing the buffer...) until you try to save.

  4. in emacs, C-x C-s to save the buffer.

What follows is more or less textbook TDD/BDD style practices, with details
of my Zile development process mixed in :)

Ideally, you would try to capture each of the above behaviors in (a series of)
specl examples, and ensure that if you link lib/zemacs/zemacs to /usr/bin/emacs
those test cases all pass (i.e. that you successfully specified the actual
behavior of Emacs), and that when you regenerate lib/zemacs/zemacs as a wrapper
for bin/zemacs those same test cases fail (i.e. you have written useful tests
that will not succeed if a future zemacs commit changes the specified behaviors).

I would tackle these in four chunks, first specifying behaviors for 1a-1d,
ensuring that they pass for emacs and fail for zemacs, and then writing just
enough code to get the tests to pass.  At that point, make a local commit, and
perform any tidy ups and refactors you think improve the code ensuring the
new specl checks continue to pass at each stage, and secure in that you can
always revert back to the check pointed local commit if a refactor gets out of
hand and breaks something.  After the refactors, all the changes you made beyond
what is in the upstream master repo are one changeset.

Then move on to 2, follow the same process etc etc.  Unless you are very
confident everything is in excellent shape already, you should probably solicit
a review by submitting a pull-request at any point you get stuck, need some
clarification, or just validation everything is going in the right direction,
before moving on to the next thing.

Even if you get stuck right from the outset (figuring out how to write the
Specl example code for instance), please go ahead and ask for help on this list!

=)O|

Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)

Thanks,

--

Garnaik