Slashdot Mirror

← Back to Stories (view on slashdot.org)

Programming Contest: Efficient Editor Usage

Posted by timothy on from the colon-w-colon-q dept.

Fred (a.k.a. The POTM-MASTER) writes "Anyone can write editors, but it's surprisingly hard to write a program to USE an editor. This latest Programming challenge asks you to write a program that will change one block of text into another using a simple set of 'vim-like' editor commands." (Find the details here.) "Deadline is May 31, 2005 so you've got plenty of time. The POTM is the 'Programmer Of The Month' contest - newly revived and active with about 1000 folks registered for the forums. It is completely for fun - unsponsored and prize-less except for the fame!"

7 of 33 comments (clear)

  1. vim-like? by keesh · · Score: 5, Interesting

    Hardly vim-like... It's missing all the useful stuff like f F t T, all text objects and motions and all the modal stuff. These're the things that make vim so much more powerful than anything else.

    But then, I guess "using a few simple manipulation commands" doesn't sound as sexy, eh?

    1. Re:vim-like? by zonx+lebaam · · Score: 3, Interesting
      Perhaps they should have said TECO-like (to give us the idea without raising vi-religious hackles), but, of course, that wouldn't address your actual point that the problem rules aren't targetted at as rich a command space as vi (or ed or TECO either (by a long shot)).

      In that regard, I think the problem is quite cleverly designed, as the choice of commands is small yet sufficient to invite complex solutions (beyond just finding the smallest diff between the inputs).

  2. Contest to find most effienct keystrokes by Mycroft_514 · · Score: 3, Interesting

    should be changed to a contest to find the most efficient way to do the job. I wrote such a job finisher years ago, and it is used by myself and others to check Project Gutenberg texts.

    And my method is capable of learning.

  3. Re:pff... by AuMatar · · Score: 3, Interesting

    For fun.

    Its also a non-trivial algorithm. Basicly a bunch of partial line diffs and trying to find as much commonality as you can. RCS systems use this type of functionality. The better you make them, the better they can do. ALthough a real RCS system would need to be able to analyze over y as well as x, this seems to have a very limited y.

    --
    I still have more fans than freaks. WTF is wrong with you people?
  4. Re:Brute Force solution by duggy_92127 · · Score: 2, Interesting

    Tied for 6th place!

    Doug

  5. Re:Edit distance with traces by Karma+Farmer · · Score: 3, Interesting

    The problem involves transforming multiple, independent lines of text. Finding a shortest edit on any one of those lines would be trivial. Finding the shortest edit on all of the lines simultaneously would be interesting.

    For example, change a couple of characters on the first line (which moves the cursor left or right); go down a line; change a couple of characters (again moving the cursor left or right); return to the first line and perform some more edits...

    So, there are two problems -- solving the problem in the minimum number of moves (which should be doable with a small amount of thought), and solving the problem in the minimum amount of time (which will be more difficult, because the standard diff algorithms aren't sufficient).

  6. Re:Edit distance with traces by Anonymous Coward · · Score: 1, Interesting

    I think there you have actually hit the crux of the issue. There is a ton of work, some of which half-way solves the issue. This means that you have to
    a) work out which part of the ton does actually half solve the problem, and
    b) work out how to extend it to do the other half of the work.
    The fact the scoring is based upon all commands including cursor movements means that it isn't the case of just finding the smallest number of changes for each line.

    Mole125