d0a8dc2584
I explained in the comments on BufferType why I'm doing this, but the nutshell version is that I anticipate having bigger files to deal with at some point we won't want to keep in memory. Otherwise we could just use bytearrays. The way this is meant to be used (which admittedly isn't clear--would someone like to submit a patch that improves the docs to clarify?) is that this is intended to be used as a context. In other words, using Python's with statement. This isn't all that different for a ByteBuffer, but it would be for a FileBuffer (which doesn't exist yet and won't for awhile.) Implementation hint for FileBuffer when I get there: If the file is not explicitly opened read-only, I intend for read-modify-write to be standard practice from the start. That'll mean duplicating a file to a temporary one we can manipulate safely and then at flush time, copying the changes over the original. That way you'd always be able to undo your changes by quitting without saving. This seems important as blocksfree is likely to serve a lot of archival duty and you may only get one shot at trying to save an image from a damaged floppy. It would be awful if that image were then destroyed by an accidental exception somewhere in the middle of other operations. So let's not go there. |
||
|---|---|---|
| blocksfree | ||
| doc | ||
| .editorconfig | ||
| .gitignore | ||
| COPYING.txt | ||
| cppo | ||
| HISTORY.md | ||
| README.md | ||
BlocksFree and cppo-ng
This project began as cppo-ng, an attempt to begin evolving cppo, a script written by Ivan Drucker, to be more pythonic. It's growing into something a bit bigger than that, however. See <HISTORY.md> if you want details about where it started and how it's gotten here.
The goal is no longer simply to clean up the cppo script!
What we actually want
TL;DR:
- A scriptable AppleCommander-ac-like tool
cppowith all of its present external interface.- The features of CiderPress from the command line
- Native feel on Windows, Mac, and Linux at the minimum
- Future: A GUI tool that can display characters natively
It should be quite doable to build a tool like AppleCommander-ac with the ability to read, write, convert, dump, and other things that one currently does with AppleCommander. Moreover, it should be no major thing to have it be able to output data in a mechanical format that can be processed by shell scripts or JSON that can be processed by anything more functionally complete. That will resolve the issues of the thing being written in Python if you need something else for the majority of cases. It's not a perfect solution for Windows outside of development tools, but development tools are the primary application for this.
We have tools that need cppo and we cannot assume that we're the only ones
who do. We could maintain the existing script, but it has both bugs and
limitations. Better to emulate the old cppo using a new interface. You can do
this with a runner that provides the old interface alongside the modern one.
That's the plan.
The possibility of using urwid exists to provide a textual interface. It's probably desirable for any GUI to be abstract enough to have multiple implementations, but the idea that you might want a textual interface should be considered.
Documentation
If you'd like to write some. :)
Contributions
Yes please!