Error handling and documentation suggestions #17
Conversation
I would find it annoying if I was using *OUT* as a clipboard or something and the contents disappeared. Especially since undo doesn't work after `settext`.
Also doesn't set `editor.error_handler` by default. Which I think is sensible but *maybe* makes the API less discoverable (user will have to rely on documentation or reading the code rather than inspecting what fields `editor` come prepopulated with).
|
You may not want all of these. I think the git commands to selectively apply patches should be: First add my fork to the sources (“remotes”) you can pull commits from. I think you will only have to do this once. The name of the “remote” will be “bjornbm”: Then you should be able to apply individual commits, for example: If you want to merge the entire |
|
Thanks for your commits. And thanks for your patience and the details about cherry-pick! I managed to get the commits I wanted, but it was not straightforward, probably because I did not apply all the commit, and in order, or because I didn't apply the first one, and didn't know what to do in case of merge errors / failure of cherry-pick I am close to clueless regarding git, except the most basic use case: commit my own change at the end of the (only) current branch! Each time I have departed from that, I have fallen "into a maze of twisty little passages, all alike" :-) Regarding your commit "Don't toggle away from OUT on error (clobbers previous buffer), I don't understand the issue. Using ^O from the OUT buffer works ok here. What happens on your side? |
|
The git user experience is a UX disaster. I barely scrape along, too. Try triggering an error (^Xt) in *OUT* and you will see what happens: it swaps to the previous buffer and does a |
Commit f8e0b82 should fix this. |
|
That is indeed a less intrusive fix. |
These commits are related to error handling and documentation. Refer to the commits messages and diffs for details.