Improve the capabilities for launching editors for text.
Review Request #10668 — Created Aug. 28, 2019 and submitted — Latest diff uploaded
RBTools sometimes needs to invoke editors (to create commit messages,
for instance). The code we had before failed on Python 3, due to string
type mismatches when reading in the resulting edited file content, but
even with that fixed, the editing experience was error-prone and far
For instance, if things went wrong during
edit_text(), we'd get some
generic exception, like
OSError. We now have a dedicated error for
Another limitation was that we had no control over the filename of the
edited file. This meant we couldn't influence the editor -- no syntax
highlighting or other editor settings would apply, creating a subpar
experience. This is currently most important for editing commit
To address this, we needed to provide a filename during the editing
process, but it wasn't as simple as just a standard filename. We needed
to support two different ways of doing this: The Git way (using a fixed
filename for the file), and the Mercurial way (using a generated temp
filename with a prefix and a suffix).
edit_text()has been updated to make the Git approach easier. It now
takes a filename, which will be passed to
a specific filename for the content. It will also immediately delete
that file once it's been read back in, just to keep the filesystem a bit
To support the Mercurial approach, a new method was added:
edit_file(). This contains the core logic of
operates on an existing filename. This means that for more advanced
cases, like with Mercurial commit messages, we can generate a commit
filename elsewhere and then pass it to
These new editing capabilities have one additional benefit: The
configured editor can now be specified as
RBTOOLS_EDITOR, letting us
define an editor that isn't dependent on the
environment variables. This is mostly useful for testing for now, but
can be useful if someone wants an explicit editor to be used for RBTools
(or a wrapper script that processes text in some way).
A dummy editor has been added inside
testing purposes, allowing us to have full test coverage of these
methods. It simply uppercases the whole file.
Unit tests pass.
Manually tested the new editor errors and capabilities alongside an
upcoming change to leverage all this in Git.