Re: [gNewSense-users] PFV mode: partially verify directory

[Bake Timmons]

>> you may have problems.  Possible solutions:
>>
>> 1. Run M-x kfv-toggle-cache to turn off caching of wiki data.
>> 2. Force KFV Mode to ask before opening up old copies of your work in
>>    a directory (section).  This is controlled via the
>>    "kfv-ask-to-open-old-kfv-files-flag" variable, so you can set this
>>    to the value t for true.  M-x set-variable sets it until you quit
>>    Emacs; M-x customize-set-variable sets it permanently.
>> 3. A bug needs fixing. :)  I appreciate your report, Sam, since, of
>>    course, it may indicate either a software or useability glitch.
>>    Let me know what works or leave the section unfinished and tell me
>>    so that I can try my hand at it or at a similar case.  I would love
>>    to nail it!
>>
>> I should emphasize that #1 can be a handy workaround, but it's also
>> good--in the long run, of course--if we can figure out how to maximize
>> the use of cached data to ease the strain on the wiki.
>>
>
> I did a bit more testing. I'm not exactly sure about the effects of
> kfv-toggle-cache, so I'm gonna play some more with that. I did not
> touch kfv-ask-to-open-old-kfv-files-flag.

For anyone unfamiliar with Emacs, the command M-x describe-function
asks for a function to describe and then describes it.  The shortcut
for describe-function is the C-h f key combination.  For
kfv-toggle-cache it says:

"Toggle whether KFV Mode uses local copies of network data."

The status bar at the bottom of the KFV window which says "KFV Mode"
also indicates whether the cache is active.  After the cache is
deactivated, the cache will written to but not read from.

>
> What I did now was take a directory with more than one file (fs/fuse)
> and verify only the first file. After that was uploaded I closed Emacs
> and started it up again. I did kfv-start on the same section and
> continued with the next file. I repeated that for each file, playing
> with different settings. I don't remember which steps I did with each
> file, but I did get these results one or more times:
>
> - After first C-c C-c it asks to upload instead of generating the
> markup. The markup it wants to upload is still that of the previous
> file.

C-c C-c does the next "logical" step.  "Logical" depends on whether
any generated markup is already displayed, so if the generated markup
is very old, for example, then any data files containing that markup
are assumed to be meant for uploading.  Thus, getting rid of all
displayed markup and then doing C-c C-c "resets" everything, including
regenerating data files.

This is not a particularly clever way to do things, and I will try to
improve it in order to solve any particular issues.

> - First C-c C-c generates markup, but with twice 0% instead of 100%
> for the file, although it was marked as GPLv2.
>
> It looks like I do get correct results when I answer the question
> "found existing file, resume it?" with "n". I must add (since you

I have had mixed results using kfv.el to resume "old" files, i.e.,
files that I had worked on in a previous session: most of the time it
seems OK, but there still seem to be some cases where something is not
properly updated, for example.  In all cases of error, however, it
seemed to be minor enough to just manually fix.  If the file
already had markup, I usually just clear and it regenerate it after
any further changes I make to the table, since regeneration is
trivial.

A major class of errors could creep in sometimes when opening an
existing file while the cache were active.  Namely, if the cache
expiry time (which is customizable) had not yet been reached and there
were new updates online in the meantime.  Generally, this is the kind
of error we would wish for. :)

So while resuming is not perfect, it is somewhat workable, and you
should do whatever works for you, including answering "n" as you did
to not resume the old copy.  I will keep an eye on the resuming
feature, but do not anticipate any immediate fixes.

> brought it up) that this has a small usability issue. Upon uploading
> it asks me "Upload blabla.posted again?". I don't really know the
> answer to that question, because I don't know what that file is and
> whether it has changed in such way that it needs to be uploaded
> again. That can be solved somewhat by looking at the file, but for me
> that means going to a terminal and doing 'less
> ~/.gns-kfv/foo/blabla.posted'. Maybe an experienced Emacs user can
> escape from that prompt and open the file from there. Anyway, I just
> answer "y" and that seems to work.

OK.  ".posted" is appended to the name of any file (of markup) that
has already been uploaded so as to minimize redundant uploads when
resuming partially uploaded directories.  Three things I can think of
to make this more usable are: (1) to have extra keystroke options that
would show the already uploaded file's contents and then re-ask the
question; (2) preface the asking of these questions with some kind of
explanation; (3) ask a better, clearer question (such as, "Upload the
markup for blabla again?").  I am curious about whatever people like
here.

Now that I think about, congratulations, you have indeed found a bug!
The question should be "Upload blabla again?" (i.e., the *new* version
of "blabla.posted") because "blabla.posted" has already been
posted. :) I will fix that but will also try to make it more usable
and with any suggestions I get in mind.  (As a technical point, when
files are uploaded, no file named "blabla" will be uploaded if
"blabla.posted" already exists.  Thus, a "y" to the question here
deletes "blabla.posted" so that the uploader sees only "blabla".)

Regarding escaping the question, there is no escape. :) Generally, I
just press C-g to quit.  People should be aware that, except for
one-keystoke interactions such as this, pressing C-x o will switch
among all Emacs "windows" within a frame, including the minibuffer
window (i.e., where questions are asked).

I will certainly correct the question bug, consider how to make it
clearer, and post the revised kfv.el soon on the PFV Mode svn.