Hi Tassilo, Tassilo Horn <[EMAIL PROTECTED]> writes:
> Bill Clementson <[EMAIL PROTECTED]> writes: >> There are a few ways that it could probably be made better though: >> >> 1. It is slow: It would probably be better to provide an async mode >> option. In other words, instead of waiting for the convert process to >> complete, let the user view the pages that have been generated and >> periodically, have doc-view automatically update the >> doc-view-current-files variable with the updated list of pages. > > I don't think that would help much. The generation of the pictures is > about the last 5-10% of the transformation. Darn. That's the major hassle with using doc-view and I thought having async functionality would make it less painful. >> 2. Cancel key: There should be a key binding to cancel the convert >> process and (optionally) view what has been generated so far. > > I've done that yesterday. Get the current version. Just did a git pull and it said I had the most up-to-date version already. I didn't see anything in the source - maybe you haven't checked it into your git repository yet? >> 3. Page count: It would be useful to have a running update of how many >> pages have been converted so far in the minibuffer (or maybe the mode >> line so that the minibuffer isn't being continually updated and can be >> used for other commands). > > See my answer to point 1. ok. >> 4. Batch mode: It would be nice to have an option to kick off a batch >> background process to do the conversion. For big documents, it isn't >> really practical to wait till it's been converted. > > Well, why do you think you have to wait? Go on with your work and > eventually the *DocView* buffer pops up. (That's much better in the > current version now.) The convert process seems very resource hungry as my Powerbook G4 slows to a crawl (and is basically unusable) when I'm converting a large (2MB) PDF file. On small PDF's, it's still usable (but slow). I thought that a batch option would provide an alternative that might not be as intrusive. >> 5. Dired key: It would be nice to have a defcustom value that would >> specify a dired map key that would call doc-view on a file (with a new >> doc-view function that doesn't prompt for the file name). This would >> make it easier to "browse" pdf files in dired. > > Good idea. I'll add that. Do you have a good suggestion what key could > be used and is free? How about "b" (for browse) or "V" (for View)? >> Did I mention that doc-view is way cool? :-) > > And think of how cool it will be in 5 or ten years when we all have > 64-core 50 GHz computers with 512 GB RAM!!! At the moment, I would be happy to just replace my Powerbook with a dual core computer with 4GB of RAM! - Bill _______________________________________________ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources