Fake sender for context menu
This provides a late hook for once every thing is set-up and the user may want to mess with the display. You shouldn't use this hook for setting modes as this will likely confuse the minor mode magic we are using.
A pull request to fix up focusing of the new frame on MacOS lead me to re-factor this code so all the frame raising logic is common for the new-frame and re-use frame options. Also: * Clean up tabs * Clean up doc string
* made package.json as minimal as possible * add .gitignore for npm installed stuff
In edit-server-accept, set-buffer-multibyte is called, but it's applied to whatever buffer was previously active because the call is not wrapped with `with-current-buffer`. This makes edit-server fail if that previously active buffer is an indirect buffer (set-buffer-multibyte is illegal in an indirect buffer). Rather than add with-current-buffer, though, just remove the call altogether. It is not necessary for the process buffer to be multibyte.
This is not a fix but will make it obvious in the console log when we have hidden a text area. Unfortunately when the Blogger text area comes into focus it doesn't seem to trigger a DOM update. Maybe we should just skip adding buttons but still allow event mapping.
If we don't clear the kill-buffer-hook we'll end up doing it all over again!
I had to move the background scripts back to a background page as it was needed for a temporary place to store clipboard contents. I've also added a bunch of explanation for the set-up to the help text.
By using command keys which we can define we can have a definitive keystroke to active a foreground Emacs shell without messing about with failed connections to the content scripts. This is much cleaner.
Add a window.onkeydown handler to handle keypresses when no text area is in focus. This allows me to trigger the editor with a foreground message on the Chromebook.
It's looking fairly minimal so far but at least one user bugs seems to have been cleaned up.
For starters the CSS wasn't being applied at all because I'd used an id instead of class descriptor. Having done that I found the behaviour of divs and textareas where different so I split the css rules into two. I then experimented with Gmail's interface in an attempt to get the edit button inside the sibling element. Unfortunately all the guides I could find on CSS positioning said these things are done with reference to the parent node, not the sibling. It might be for divs we need to place the image inside the div to have enough control but this then raises issues of how to clean up the contents before the application does something with it. We after all are only meant to put the users text in the box, not random html :-/ Also: * removed the tabs that snuck into that function
This is mainly so I can have a fancy status graphic in the README for the Travis tests.
…rame we create as a result of a foreground request.
The previous method using the persistent tab connection has a few problems. The principle failure was when there was no content script to talk to. As the call is asynchronus we need to check for failure in the callback which is only possible using sendMessage(). Also some clean-up of the tabs that seem to have sneaked into the code.