in reply to One button text processing

Various comments.

  1. You are synchronizing two parts of your code with numerical codes. These will become problematic to keep in sync. It is better to build one data structure with all of the necessary information and then loop through it a couple of times to produce both data structures, thereby keeping like stuff together. For instance have an array with elements like 
      ['To Mixed Case', sub {
    tr/A-Z/a-z/;
    s/\b(.)/uc($1)/ge;
  }],

    [download]
    and then use the first field as the text, and build up a function lookup hash used in the run() function instead of your current case. (Pass the text to the run() function and then there is no synchronization needed.)
  2. Note that above I used $_. Since you are likely to write many cases, and commands default to $_, for this special purpose program I think that $_ makes sense.
  3. You are limiting the user to only the commands that you have thought of and pre-built. I would recommend adding in commands where the execution of the command depends on a text field where the user can enter something more sophisticated - for instance their own substitution, arbitrary code, the name of a file to save the clipboard in and so on. Note that this will make your Tk display necessarily more complex, and complicates the first suggestion that I made. Solving that is left as an exercise to the reader...
  4. You will eventually run across the fact that Win32::Clipboard leaves line endings as \r\n. It is convenient to convert \r\n into \n on the way into the run() function, and convert \n back into \r\n on the way out.
  5. Your assumption that this can be modified for other operating systems is only partially correct. The *nix model of having selecting text be the same as putting it into the clipboard makes using a tool like the above be inconvenient for in place editing. You select text, edit the clipboard, then you have to go back and paste it, then reselect, and then delete the original. Ugh. You would be better advised to use hooks in your editor.
  6. In fact my final suggestion is to just learn your editor better. I say this because a clipboard editor (command line, but on the same principle as the above) was the first useful program that I wrote for myself in Perl. I learned this program, with the result that for a long time I used my homegrown tool rather than learning my editor better. But long-term, I think that learning the editor is likely to be more productive.
I hope that this feedback proves useful to you.

Replies are listed 'Best First'.
Re: Re: One button text processing
by nysus (Parson) on Jul 15, 2003 at 07:24 UTC
    Tilly,

    Thanks for the tips, bro. I especially like the first one, if I understand you correctly. Instead of using arbitrary numbers to match code, just use a hash. Very neat. I'll try that out.

    As far as learn my editor better, well, one of the major reasons I wrote this program is because I do web design with Dreamweaver which does not have change of case functionality. Also, I use UltraEdit in Windows which also has limited text processing capabilities. It's no Vim or Emacs as far as shortcut keys go. However, UE works very well as a cheap IDE, allowing me to run test code and debug Perl programs very quickly. I tried using Vim (which I used fairly extensively when I used Linux) in Windows the other night but found it a huge pain to use just to test some simple code compared to UE. And I don't really do enough programming to be able to take full advantage of a Vim or Emacs. I've written maybe 6 to 10 small Perl programs in the last year. So by the time it's time for me to write another program, I've all but forgotten what what the shortcut keys are. It gets very frustrating having to look up the simplest keystrokes over and over. But I'm certainly open to suggestions for a better IDE/editor for Perl on Windows if you can recommend one.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff";
    $nysus = $PM . $MCF;
    Click here if you love Perl Monks

[reply]
      Also, I use UltraEdit in Windows which also has limited text processing capabilities

      I beg to differ on that one...I am using version 10 and I find it to be as feature rich as I need. No Emacs sure but still a professional editor...what can't you automate?

    • Upper case: Alt F5
    • Capitalise: F5
    • Advanced->configuration->key mapping
    • ...

      Having said that, I like your utility.. :-)

[reply]
        I'm not knocking UE. It's all a part-time programmer like me needs. But I highly doubt a power programmer would use it. That being said, UE has shortcomings. For example, I don't see a way to do sentence case. And it's RE engine isn't capable of knocking out any heavy duty search and replace functions.

        $PM = "Perl Monk's";
        $MCF = "Most Clueless Friar Abbot Bishop Pontiff";
        $nysus = $PM . $MCF;
        Click here if you love Perl Monks

[reply]
      For more editor choices than you can shake a stick at, see Code Editors and Development Environments. But still I think that bm underscored the value in learning your existing editor better.

      However you're right that this will not help you with Dreamweaver. And from experience I can tell you that editing your text with a small Perl utility will work, and gives you lots of opportunity to learn Perl better. Whether or not this is more useful to you than learning editors in general is a judgement call.

[reply]
      nysus,

      UltraEdit looks very much like http://www.chami.com/html-kit/

      May be that you should try it (FREE). It has some macro stuff that looks like JavaScript and there is a lot of modules to extend functionality as much as you want.

      Anyway, I am fond of Xemacs. But HTML-KIT has also a module that helps editing Perl scripts, checks syntax and runs perl scripts...

[reply]

In Section Cool Uses for Perl