moe icon indicating copy to clipboard operation
moe copied to clipboard

Proactive correction of common mistakes and typos

Open tobimensch opened this issue 3 years ago • 1 comments

Say I type in these two lines:

if isGood()
  doSomething()

Obviously a final semicolon is missing at the end of the ifline.

Next example:

proc myProcNameIsLong() =
  echo "test"

myProcNameIsLng()

I think it's clear that myProcNameIsLng misses an O. However this isn't always easy to decide programmatically, because it's not impossible that the typo is not a typo, and there exists indeed a myProcNameIsLng() for example in an imported module. However with LSP and other means of checking that there's indeed no symbol named myProcNameIsLng, it should become rather easy to deduce that changing it to myProcNameIsLong() is safe to do.

Next example:

var b = False

This is something that could happen to somebody that switches between Nim and Python, and gets confused. False should be false.

Next example:

if foobar == barfoo:
 echo "hello"
  echo "world"

Here for whatever reason the indentation of the echo "hello" line is not like expected.

Next example:

type
  Person = object
    name*: string
    *age: int

Here the asterisk for the member age needs to come after the identifier not before it.

Next example:

import stringutils

They probably want strutils instead. You have to be careful here, as the possibility of a stringutils module existing is real. Therefore first check for the existence of stringutils, and if it doesn't exist change it to strutils.

Next example:

type
  BadError* = object Exception

Here the of is missing between object and Exception.

I could go on and on and on, but there are so many possible ways this could aid the programmer who makes typing errors from time to time, or who forgets some trivial but important thing (like the of being needed after object or where the * needs to be for exporting symbols).

Much of this is Nim specific, but there will at least be some common ground between Nim/Python.

By proactive correction I mean that with this feature enabled the editor should correct these trivially visible mistakes as soon as possible, without asking the user for permission for each change (optionally it could also ask first).

To go back to this example:

type
  BadError* = object Exception

Proactive here would mean that when the user types the E of Exception, moe notices that it makes no sense, since of must always come right after the object keyword here. It would then insert of between the E the user just typed and the object. So the user can continue to type Exception without having to worry about the of he forgot, with the end result being correct Nim code

The types of mistakes that could be corrected with such a feature are many. But for a first implementation it would certainly be enough to concentrate only on the most common ones and I think you'd already get a lot of utility from that.

More examples:

echo "hello
test()

" is not a multiline string, so it must be closed on the same line. It's easy to reason, that a closing " should be inserted after the user inserts a linebreak. In this case after the hello.

tobimensch avatar Jul 29 '20 03:07 tobimensch

That's a work for the LSP, not the editor, all that must be implemented as code actions.

uninhm avatar Aug 17 '21 02:08 uninhm