It’s All Text!

Posted on by

Have you ever had to fill in a form on a web page and wished you could open it in an editor? If you use lots of blogs, post lots of comments or file many bugs then you probably get annoyed at the lack of true editor commands.

I’ve seen some solutions that embed a JavaScript editor into a textarea on demand. Generally, I don’t like them. They are re-inventing a wheel. Especially since I like my particular flavor of wheel, Emacs, though I have no problem with other flavors.

So when I discovered the Firefox extension MozEx I was a very happy hacker indeed. But as time went on I didn’t like the way the extension was going. It was trying to solve a problem I didn’t have; it wanted to add handlers for things like ssh://, etc. and I didn’t need that. I needed an external editor!

When Firefox 2.0 came out, I MozEx didn’t work. I waited for an update and it didn’t come out. Since my new job used a lot of editing stuff via web forms, I really really needed an editor. So I reached for External Editor. It seems to have gone since then, replaced with Editus Externus which seems to be an improved version by someone else.

External Editor had a huge problem. When you edited a file it would freeze up all of firefox till the editor quit. Yikes! However, it let me do things that I needed to do, so I use it.

I started poking around in MozEx to figure out why it wasn’t working in Firefox 2.0 and discovered that in an effort to support pre-1.5 versions of Firefox, it did a lot of work in JavaScript that could now be done in Firefox (md5sums) and it did these sums way too many times for my liking.

It also had some potential security flaws where the browser could be tricked into fetching the contents of a file from one site into their site. Even more annoying, if a second user used MozEx and edited the same site, the files would collide.

So I started thinking… how hard could it be to write an extension?

So I did. :-)

It’s called It’s All Text! and is available for download today.

If you have any suggestions, feel free to post here. I’ll keep this open until I get to version 1, at which point I start a new post someplace…

My current todo list:

  • [idea] dropdown list for charsets (utf-8, western-iso, default)?
  • [low] getDocumentIdentifier should sort arguments and append the post data.
  • [security] Detect collisions using the raw key.
  • [idea] Pass in the line number to the editor, arbitrary command?
  • [high] On edit, let user pick the file extension.
  • [idea] allow the user to pick an alternative editor?
  • [med] Profiling and optimization.
  • [med] If the textarea is focused, we should refresh it.
  • [low] When the editor quits, we should refresh the textarea.
  • [idea] support for input elements as well?
  • [high] Confirm that we find textareas inside iframes and frames.
  • [med] Have gumdrop fade in and out on mouseover

Things marked as ideas, may or may not happen. Everything else will either happen or the issue will be addressed in some other way.

And yes, I edited this blog post with it. :-)

Ciao!

Download: It’s All Text!

88 thoughts on “It’s All Text!”

  1. docwhat says:

    Shift, alt or something similar clicking on the edit button would copy the path to the file for the text area. The idea being you could copy this path, then type something like:

    cp /etc/hosts [paste]

    And that’d update the textarea quickly. How cool is that?

    Similar in concept to jeroenvrp’s idea:
    It would be great if you could choose an alternative editor, with clicking shift, alt or ctrl when clicking the blue edit button.

    But I think more generically useful.

    Ciao!

  2. .jon says:

    Hi! Would it be possible for you to create a spin-off that evaluates the $EDITOR environment-variable and only gives the button, or a text-area popup-menu in order to strip down the size of this add-on. While ca.20k might look small, as more extensions I install, the more I add ;-) And I really only need my $EDITOR (or %EDITOR% on Win32) (since that is, obviously, the editor I use all times).

  3. docwhat says:

    I like the idea of using $EDITOR or percent-EDITOR-percent in Windows. It won’t make the extension smaller. It’ll probably make it bigger, actually.

    I can make the extension smaller on disk. It currently takes 112k. If I put the chrome/contents directory in a jar, then that’ll reduce it further to 68k on disk. 24k is just the size of the extension downloaded.

    However, I don’t want to write a build optimization phase into my makefile until I’m done testing. I’ll add it to my todo list.

    Are you working on an embedded platform that you are counting kilobytes?

    Ciao!

  4. Daikon says:

    Excellent work! I can say for certain that using your add-on combined with Dreamweaver has saved me at least two days of manual find & replace work.
    You might want to think about setting up a little PayPal link so that grateful people like myself might donate something ^_^

  5. Matt says:

    [FF 2.0.0.1, Mac OSX 10.4.8]

    No matter what text editor I select (e.g., TextEdit, TextWrangler, BBEdit), I get the pref box that says it can’t run it.

    Trying another is a pain because the pref box does not dismiss. I have to quit and relaunch FF.

    You may also want to correct the language in the pref box:

    “You the browse button…”

  6. docwhat says:

    Matt:

    Thanks for taking the time to report the problem (and the text typo).

    I suspect that you are trying to run the .app file from the Application directory. On MacOSX, you need to use the binary that the editor placed in /usr/bin. Alternatively, you can look in the /Application/<name>.app/Contents/MacOS/ for an executable. Usually the name of the executable is <name>, matching the .app directory name. However, not always.

    This is one of the really annoying parts of MacOSX. I haven’t come up with a good solution. I think I’ll update the text to include this information for the next version.

    If that doesn’t fix your problems, then I’ll have to borrow a Mac and see if I can reproduce the problem.

    In general, I’d appreciate anyone’s help on this, since I don’t use Macs.

    Thanks again!

    Ciao!

  7. Hans says:

    It’s a very usefull extension for Wikipedia, so you can easy edit articles in an external editor. A textarea on Wikipedia however has the full width of the screen, so the edit button felt for the half outside the screen and caused a horizontal scrollbar.

    I have changed the margin of the button in itsalltext.js, so the right margin of the button is equal to the right margin of the textarea and the button doesn’t cover partly the textarea.
    It is row 639, I have changed it to:
    gumdrop.style.margin = ['0 -',width,'px'].join(”);

    Before: http://xs311.xs.to/xs311/07041.....Change.png
    After: http://xs311.xs.to/xs311/07041.....Change.png

    Maybe you can make this optional.

    Hans.

  8. Christian says:

    Hi,

    I like your plugin very much (I use MozEx at the moment).
    Thanks for offering it.
    It works fine, but your plugin does not
    support special characters f.e. german umlaute (üöä) or the euro sign (€).
    (FF 2.0, WinXP Professional)
    With my preferred editor Boxer I get strange characters instead of Umlaute,
    with Notepad.exe I get the Umlaute but not the newline.

    Beste regards
    Christian

  9. docwhat says:

    Hello Christian! Nice name. :-)

    The plugin does indeed save the output as UTF-8 (as in the preferences). However, I don’t write a Byte-Order Mark to the beginning of the file. I don’t do that because a lot of editors don’t know what to do with it.

    Try asking Boxer to read the file as UTF-8 instead of the Windows Default UTF-16 (little endian).

    The fact that Notepad can read it implies that it is written correctly. If that doesn’t work, then zip up and email one of the files that Boxer cannot read correctly to me. I’ll double check that it is being written correctly.

    My last name (Höltje) has an umlaut in it and I use it with
    It’s All Text! all the time.

    Ciao!

  10. Christian says:

    Thanks Christian,

    I found the problem: my editor (Boxer) does not support Unicode.
    But I like Boxer so much, that I have to live with it.
    MozEx has an option to not use UTF-8. Disabling UTF-8
    works fine for Boxer (€ does not work, but Umlaute are fine).
    With UTF-8 enabled the behaviour is identical to “It’s all text”
    Could you provide ANSI-encoding?

    Best regards
    Christian

  11. docwhat says:

    Christian:

    Go to Tools->Add Ons Select It’s All Text! Then click Preferences. Where it says ‘UTF-8′, change it to ‘windows-1252′. That should fix the problem.

    It’s a shame that Boxer doesn’t recognize UTF-8.

    Ciao!

  13. Peter says:

    Could this add a couple of options:

    1) To put emacs into wiki-mode, it’d be nice to have an association of sites to extensions (maybe this is asking for a lot?).
    1a) alternatively, could the right-click menu for it’s all text bring up the option to add an extension or have a pre-configured profile or something that’s selectable?

    2) Is it posslbe to add flags to the editor? Somtimes I like to use emacsclient with a failback to running emacs in case I don’t have an emacs server running yet.

    Otherwise, this is fantastic! Thanks,

    -Peter

  14. Lulu says:

    What does it do?
    When I change the font to a different colour or effect, it doesn’t show up in the original text box; instead it shows up with the html commands…. Why?

  15. isaac says:

    as vim and mac user, wondering if there’s way not to open multiple instance of the application(gvim in mac os x), but just keep editing in a single gui window? thanks

    greatjob! – wish one day we could one editor that can right edit within the textarea with different choice of editors

  16. Lulu says:

    Here is the problem: My text editor previews the HTML correctly but when I save
    and close the editor only code is placed in the text box. What am I doing wrong?
    I am going to enlarge this text and color it green so you can see. Thank you.

  19. docwhat says:

    firefox_fan: I don’t know anything about BBCodeWriter, but it looks like it isn’t a normal editor. I’m guessing that it doesn’t accept a filename as the first argument when run.

    Try creating a text file and then running BBCodeWriter with the argument being that text file from a cmd.com command line.

    Ciao!

  20. docwhat says:

    Lulu:

    If you create a non-text file, then you’ll get non-text loaded to the web page. These text boxes only handle “text”. If you try setting the fonts and colors, it won’t work. That is the nature of HTML and the web.

    There are ways to work around this, but they depend on the authors of the *site* to do it. A generic plug cannot do that, unless someone comes up with a standard.

    I hope I’m clear.

    Ciao!

  22. Peter says:

    Reliability…

    It seems that the plug-in does a pretty good job of checking for file updates, but I have had many times where the edited file did not update the textearea when I’ve quite my editor.

    Is there anything equivelant to waitpid() in the firefox plug-in API that could make this more reliable?

    -Peter

  23. docwhat says:

    Alas, there isn’t a waitpid or anything similar that I can find in Mozilla. Very sad. If there is one. PLEASE tell me! nsIProccess doesn’t even have the exitValue and pid attributes working. *sigh*

    It checks regularly, every few moments (modulo the browser being busy somewhere else, it’s only single threaded). You can control the refresh rate via the preferences.

    The next version (0.4.x due out very soon) also refreshes when you mouse over the text area. And it should update better, too.

    Ciao!

  24. Peter says:

    Can you add, at the same time, a mutex? If there’s already a running editor on a textarea, and the edit button is hit, could it confirm the desired action?

    Also, what is the interaction with itsjusttext and something like the moinmoin preview button?

    Let me describe what just happened to me, which is I was foolish about both of the above things

    1) Edited document (moinmoin wiki page)
    2) After many hours of editing, left the editor open, came back (lots of fact finding).
    3) Saved multiple times, but accidentally opened a new editor.
    4) Closed the new editor, felt an idiot, kept going. Documents saved in editor1 still caused updates.
    5) Saved the document, closed up, and hit “preview”
    6) Moin had timed out my session and told me to click the editor again or something silly. 1 day of work down the drain (fortunately only about an hour of editing to recover it, but how do I avoid it?)

    Thanks,

    -Peter

  25. Peter says:

    I just answered my own question about moin previews – it doesn’t work. By this I mean that if I click preview while editing a form, the form gets rendered but future edits within the (still open) editor aren’t refleted by the form in the preview page.

    This would be a very useful feature.

    Thanks,

    -Peter

  26. docwhat says:

    Hi Peter!

    I don’t have much experience with moinmoin and cannot think of an installation I could play with. If you have one, post it.

    This feature is there, sort of… It’s hard to make it as nice as I would like because I cannot tell when the editor returns. :-/

    Here is the use case:
    You visit a page with your typical compose->preview->edit->submit pattern. It sounds like moinmoin is like that.

    1) You edit it via “It’s All Text!” starting your editor of choice.
    2) You compose your message and hit save, but leave the editor open.
    3) You hit “preview” on the web page.
    4) You examine it and the press the “It’s All Text!” button. If you now have two editors open to the same file, then close one of them.
    5) You make changes in your editor based on the preview and save.
    6) The changes should be reflected in the textarea.

    Step 5) is needed because the textarea is not monitored for changes until you edit at least once. This behavior is changing because it’s hard to make it maximally useful and keep it from being too confusing to normal users at the same time. Especially since I cannot tell when the editor quits.

    Actually, it would be useful if there was a menu item to let you start the monitoring, instead of step 5). Or actually to pick the file to load into it.

    Hmm….

    Re: loosing your work.

    As soon as you see that message about a session time out, *stop using your browser*. The file you submitted is still in your FireFox profile directory! It’s in a subdirectory called ‘itsalltext’ and will be named something like ‘docwhat.gerf.org.1j2t2z2t1z.txt’ (the example for this site) or if it is an older version of It’s All Text! then it may only have the garbage letters.

    The old copy of the file isn’t deleted until you quit FireFox *or* you re-visit the page.

    Ciao!

  27. Lieven says:

    Docwhat:
    I cannot try your suggestion to point It’s All Text to /Application/.app/Contents/MacOS/ because the Editor field in Preferences is not editable (and you can’t peak into packages with Browse). SI’ve found the file with the defaults prefs for It’s All Text, but I cannot find the file with the current setting. Can you please tell the location of the prefs file?

    Thanks
    Lieven

  28. docwhat says:

    Lieven:
    Sorry. I don’t have a Mac, so I couldn’t check it out the advice with regards to the file picker. All browser preferences are kept in prefs.js in your firefox profile directory. They are not kept in the extension directory (which is what you found, I think).

    Most editors now days include an executable in /usr/bin/ for running the editor externally. What editor are you using that doesn’t have this?

    Ciao!

  29. Peter says:

    moinmoin and preview, redux

    Docwhat, I don’t think that the same filename gets generated when moinmoin generates a preview.

    I’m going to see if there’s a workflow I can glom onto, like forcing myself to use emacserver, that makes this easier, but for now I’d have to open a new emacs instance (and close the old one) every time I want to preview.

    I’ll think about this and see if there’s any way to improve this.

    Thanks,

    -Peter

  30. Sue says:

    I’m on Mac OSX and have had the same issues described above. I use BBEdit, and in /usr/bin/ there IS an executable for BBEdit.

    If you choose that, the dialog box will not go away, and you have to quit FF. When you relaunch, however, the system seems to work, bringing up BBedit when you click the Edit button.

    Would be nice to fix this, or at least make a note to that effect on the plugin page where you download the thing so other OSX users won’t waste their time. Also, the default editor is something I’ve never heard of – would be nice to choose something most Mac users are likely to have.

  31. docwhat says:

    Hi Sue!

    The dialog box sounds like a bug. I think I might have solved in the
    latest version, but I can’t be sure since I don’t have easy access to
    Mac OS X. I’ll see if my wife will let me borrow her laptop to try
    this out. :-/

    As I said, I don’t have a Mac. I’ll spend a little time playing with
    it this weekend, depending on how things go.

    Ciao!

  32. Martin Polley says:

    Hi!

    Nice extension!

    Couple of things:

    * It does not seem work with Flock (http://flock.com).

    * I can’t get jEdit to work with it. To run it, you need to run something like this:

    C:\j2sdk1.4.2_09\bin\javaw.exe -jar “C:\Program Files\jEdit\jedit.jar”

    And you can’t select this from a file chooser…

    Thanks,

    Martin Polley

  33. marc says:

    I repost here what the same thing that I submitted on the mozilla home page:

    MacOSX: Works with all editors…it’s just a little bit tricky. First, in the Finder, click with right mouse button on Application icon, choose “Show Package Contents”, then navigate through Contents to MacOS. Second, in the preference of this add-on, click on the browse button and then drag&drop the executable within the folder MacOS from before into this “Choose your Editor” window. Third, in the drop-down menu of the “Choose your Editor” go up one level to “Contents” and then navigate to the executable in the “MacOS” folder. Finally, you have chosen your editor! This might look like “/Applications/Smultron.app/Contents/MacOS/Smultron”. If the developer would just make the “Editor” field manually editable we could just add the paths ourself or copy&paste paths from the Terminal.app.

    And there is the problem of opening multiple instances of the same program. I wonder if we should have an interim shell or applescript that checks if the preferred editor is already running or not…

  34. docwhat says:

    Thank you for the feed back. :-D I can’t act on everything, in part because I’ve been busy. I know that’s frustrating if you like the extension and there is just *one* little thing that you want fixed… On the other hand, maybe it’s the excuse you need to learn Javascript. :-D

    @Martin Polley

    re: flock – Yeah, that won’t work because I hadn’t heard of it before now. I’ll take a look.

    re: JEdit – Since I don’t allow setting arguments to the executable at the moment (because it is so hard to do cross-platform safely), you’ll have to create a .cmd file to run those commands for you.

    @marc

    I’m planning on making the editor box editable again. I have to verify that the file picker won’t get interfere.

    re: multiple instances of the same program.

    Is that a problem? I only had TextEdit on my wifes Mac this morning and it works fine with multiple runnings. I suspect that this is something beyond the scope of this extension. :-/

    Thanks again for all your feedback. :-)

    Ciao!

  35. Marc says:

    Having multiple instances open of the same program is not a good thing. On slower computers it takes too long to start the application all the time. And each instance use memory. There is a nice UNIX command available on MacOSX which takes care of starting a program only once: “open”. So theoretically, we could have a small shell script like the one below which takes care of the preferred editor as well as only having the editor open once. The only problem is that I don’t know how to pass the file “~/Library/Application Support/Firefox/Profiles/default.ju5/itsalltext/1j1i23382p2r1w2.txt” to the “open” command as e.g. parameter $FILE.

    #!/bin/sh
EDITOR="/Applications/Text/Smultron.app"
open -a $EDITOR $FILE

    Any hints about passing parameters to an externals shell script?

    Regards, Marc

  36. Marc says:

    Very nice. Works like a charm. This is what I was looking for and I can perfectly live with this external script.

  37. docwhat says:

    @marc

    I know about open. However, ‘open’ isn’t a UNIX command, it’s only a MacOSX command. :-( I couldn’t figure out how to deal with it portably or even how to reliably detect MacOSX.

    Anyway, you want your shell script to look like so:

    #!/bin/sh
EDITOR="/Applications/Text/Smultron.app"
open -a "${EDITOR}" "$@"

    Ciao!

  38. vikas says:

    Works well with Firefox!
    Is it possible to make it work with thunderbird too. I do a lot more editing there.
    There is an external editor extension for thunderbird, but it does work with 1.5+.

  39. codemac says:

    I can’t seem to get this working with the following script:

    #!/bin/sh
urxvt -e zsh -c "vim $@"

    All that happens is vim tries to edit a “visible-stats” buffer and an “on” buffer. What do you pass as parameters to the program? It seems to me you are sending “visible-stats on” at some point, which is bizarre. Any ideas?

  40. docwhat says:

    @vikas: You’re the second person to ask. I honestly don’t know what’s needed to make it work in Thunderbird. I think I want to make this work as well as possible in Firefox first.

    @codemac:
    It’s All Text! only sends the filename. I definitely don’t send the words “visible-stats on”. Is it possible that you have a weird alias, or some sort of setting in your .vimrc? Otherwise, I’m not sure what it could be, since it works for everyone else.

    I guess I’d suggest starting with basic principles, like
    echo "$@" > /tmp/testing and work your way up. I assume you tried running your script directly…

    Ciao!

  41. Shufla says:

    Hello,

    There are little problems with rendering edit button on trac (http://trac.edgewall.org/). Edit button is sometimes to low. I know, that more info are needed for good bug report – please contact me directly.

  42. Brad says:

    Please make it so the “Edit” button doesn’t show for a textarea with the readOnly property set to true (which can be initially set via the readonly HTML attribute).

    Thanks.

  43. Brad says:

    It would also be awesome if there were an option to disable the “Edit” button and have an option on the browser context menu instead (right click a textarea > Edit in external editor).

  44. Terry Lee says:

    Maybe it’s me, but I can’t seem to get “It’s All Text” to work. I see the grey’d out Edit button, but when I click on it, I get the following message: “I was unable to run your editor, ‘usr/bin/gedit’ You the browse button to choose another editor and try again.” Could you tell me how I might fix my problem? Also, You might want to change the word “You” in the error message to “Use.”

  45. docwhat says:

    @Shufla: I’m trying to collect test cases where the button doesn’t appear correctly. I currently have trac, wordpress, and wikipedia (I think).

    @Brad: I’ve added your bug and idea to my todo list. :-) Thanks for the feedback.

    @Terry Lee: The “You the browse button” typo was fixed in newer versions (0.4+). I can’t figure out what is going on from your description, I’ll email you and if there is any generally useful info, I’ll post it back here.

  47. Scott says:

    Cool plugin. works well with TextWrangler on OS X. One odd behavior, though, is that the edit button shows up about an inch below the textarea in Trac. Any idea what might be causing that?

    Thanks!
    Scott

  48. Hans says:

    I have installed the new version (4.2). However the button is displayed far away from the textarea when using it in Wikipedia.

    I discovered what causes the problem: the button is positioned on an absolulte place from the top and left depending on the width and height of the window. However the real position is not related to the top-left corner of the window, but the top-left position of the div where it is wrapped in. That div is placed 2.8em from the top and 12.2em from the left, so the edit-button is also placed at that distance from the textarea.

  49. docwhat says:

    @Hans:
    Thanks for pointing that out. I don’t know *why* I was trying to position it from the page edge instead of the parent node edge. I think I just got into this zone of frustration where I went nuts. *sigh* It’ll be fixed in the next version.

    To all those who pointed out the gumdrop edit button was in the wrong place:
    Thanks reporting the edit button being off. It’s fixed currently and should be fixed in any version > 0.4.2

  50. Doug Hellmann says:

    Hi, Christian,

    If you need someone with a Mac to test new releases for you, let me
    know. I’d be happy to test a prelease version with the edit button
    position fix. :-)

    Doug

Comments are closed.