- It’s not clear if user prompts should be attempted before configuration settings, or
vice-versa. - Perhaps we also should always ask the user for an encoding as a last resort, irre-
spective of configuration settings. - For saves, we could also try to guess an encoding to apply to the str content (e.g.,
try UTF-8, Latin-1, and other common types), but our guess may not be what the
user has in mind. - It’s likely that users will wish to save a file in the same encoding with which it was
first opened, or initially saved if started from scratch. PyEdit provides support to
do so, or else the GUI might ask for a given file’s encoding more than once. How-
ever, because some users might also want to use Save again to overwrite the same
file with a different encoding, this can be disabled in the configuration module.
The latter role might sound like a Save As, but the next bullet explains why it may
not. - Similarly, it’s not obvious if Save As should also reuse the encoding used when the
file was first opened or initially saved or ask for a new one—is this a new file entirely,
or a copy of the prior text with its known encoding under a new name? Because of
such ambiguities, we allow the known-encoding memory feature to be disabled for
Save As, or for both Save and Save As in the configuration module. As shipped, it
is enabled for Save only, not Save As. In all cases, save encoding prompt dialogs
are prefilled with a known encoding name as a default. - The ordering of choice seems debatable in general. For instance, perhaps Save As
should fall back on the known encoding if not asking the user; as is, if configured
to not ask and not use a known encoding, this operation will fall back on saving
per an encoding in the configuration file or the platform default (e.g., UTF-8),
which may be less than ideal for email parts of known encodings.
And so on. Because such user interface choices require wider use to resolve well, the
general and partly heuristic policy here is to support every option for illustration pur-
poses in this book, and rely on user configuration settings to resolve choices. In practice,
though, such wide flexibility may turn out to be overkill; most users probably just
require one of the policies supported here.
It may also prove better to allow Unicode policies to be selected in the GUI itself, instead
of coded in a configuration module. For instance, perhaps every Open, Save, and Save
As should allow a Unicode encoding selection, which defaults to the last known en-
coding, if any. Implementing this as a pull-down encoding list or entry field in the Save
and Open dialogs would avoid an extra pop up and achieve much the same flexibility.
In PyEdit’s current implementation, enabling user prompts in the configuration file for
both opens and saves will have much the same effect, and at least based upon use cases
I’ve encountered to date, that is probably the best policy to adopt for most contexts.
PyEdit: A Text Editor Program/Object | 691