John Levon wrote:
On Thu, Sep 14, 2006 at 02:13:43PM +0200, Helge Hafting wrote:
Perhaps "store" is a better word than "save", but I can't
see how you can claim that the operation itself isn't useful.
How else would you want to preserve a document for the future?
Why on earth would the computer not do this for you?
Well, it can be automatic of course. Still, there are times when
it is useful *not* to save. The cat walked across my keyboard,
but it doesn't matter for I wasn't going to save this.
Well, we could remove "save" and keep "revert", or even rely on
"undo" for this sort of thing.
There is still the case of "I want to save *now* so I can mail
a copy somewhere. But I don't want to close the document
for I'm also going to work on the next revision.
This seems hard to do as long as:
* Lyx don't have its own "mail/scp/ftp/... this document" functionality
* Updating the disk on each and every editing operation is too slow.
Well, I guess it _can_ be done with decent performance. Writing the
entire document will be too slow, but it sure is possible to log actions
like "mark from here to there, cut, mark from here to there, apply
character style, insert 5 lines of text, start enumeration style...."
A proper lyx file could be rewritten now and then, so the document don't
grow enormous with time.
The disk is faster than the keyboard, after all. If the file is copied
in such a state, then the LyX instance loading it performs all the
stored edits at load time.
Is it something like this you have in mind? It'd sure help establishing
lyx as the "word processor that does things differently".
Complaints about "Not two spaces in a row" might stop after this. ;-)
They are correct in this. Disk storage is a kind of (magnetic) memory.
No they're not, in any meaningful sense.
Computer memory is devices where you can store stuff and later
recall it. RAM is a very fast kind, but needs continous power.
Disk is slow but persistent. Both are memory. Look up
"memory hierarchies", calling disk memory is common.
but it is far from the only kind. It doesn't matter much if users
don't understand about RAM. They need to know that what's
Hah, yes it does! The File->Save paradigm forces them to know about RAM.
Not really, they just need to know that the stuff in the window
isn't persistent.
Good. You're making it harder by not explaining what
you want instead of "save". I'll read the book,
You're assuming it makes sense to have something that's "instead of
Save".
If we don't have "save", then we need "something instead of save".
It might be "something automatic" so the user won't need to
interface with it. We obviously don't want to loose everything on
power-off.
Users tend to do this:
1. Start a new document, or bring an existing document up on the screen.
2. write & edit
3. Do something else than work with lyx or the computer
4. Go back to (1) and work with existing documents.
Seen isolated, no save is needed here. Lyx can "save" on close,
as well as after 5s of inaction to be on the safe side.
But I have thought some more about this, and I see problems.
If I send the document somewhere (mail, ftp, scp, copy it
to another folder) then I want to know what I get. Most other
software will indeed grab a "file" and send it off somehow.
The email program may be up and running, the message written
already. I put some finishing touches on the document and may
be able to attach the file and send it faster than the above mentioned 5s
autosave. After all, I am good at sending attachments. So, did I send the
document with the latest changes or not? "Save" is one way of
synchronizing this. A file with stored edit operations might be another,
_if_ that can be done faster than the user switch between apps.
Lyx can change, getting rid of another menu entry. It still have to
interoperate well with other software.
Helge Hafting
