When autocompleting a word, overtype doesn't work as expected about atom-overtype-mode HOT 6 OPEN

sometimes it does not take much to make people happy 8=))

I'm exactly on this.. looks good. It relates to the field of package-to-package conflicts.
Same can be said for the bracket-matcher-issue, you mentioned.
Do you think double-insertions alike () make sense during overwrite-mode ? I'd rather say no, one bracket, the opening one would be enough for me. The second is just one keypress from being overtyped ?
What do you think ?

Regarding the bracket-matcher a quick&dirty-solution is to just let the first character pass. The 'problem' is, that in overtype-mode one typically wants to avoid changes to the surroundings. Example:

+item('Dashboard',     '0')(href='#dashboard')
+item('Profile',        0 )(href='#profile')

Obviously the zero in line-2 needs a pair of single-quotes . If one now selects the 0 and uses bracket-matcher to add the single-quotes, you end up like so :

+item('Dashboard',     '0')(href='#dashboard')
+item('Profile',       '0' )(href='#profile')

The right-side of things has shifted a bit to the right. I can't stop bracket-matcher from doing so. Since it has no idea, that in this case, it would be a good idea to overwrite, instead of doing an insert.
I can do smth. as long as no selection has been created before. Then there will be a Event, which i can identify and intercept - because it contains two characters. Therefore one can act upon this case. What i do now is, cancel the event and make use of the first character - the opening-something. When bracket-matcher sends (), i put a ( on the line and move on.
One could look if there is a term right next to the cursor that wants to be wrapped into brackets, quotes or you name it. The handling of such cases would naturally have to be different, compared to standard-mode/Insert-mode. And that's not really desirable.
Sadly, the same applies to some other strong-features of bracket-matcher. The removal of pairs/brackets will most likely, remove smth. and as a consequence slightly shift the surroundings. Fair enough, at least I can confirm that the go-to-matching-bracket-select actually does work.
Anyhow, your ideas on this issue are welcome.

greets, Andreas

from atom-overtype-mode.

I think that auto-insertion of closing symbols like quotes and brackets makes little sense in overtype mode, more or less by definition (personally I don't like and don't use this feature, finding it more hassle than help).

I don't think any real effort should be expended to support it -- if anything, just overtype the closing symbol and leave it there. Granted the user will then immediately overtype the closing symbol, but what else could they expect?

from atom-overtype-mode.

This is due to the fact that the auto-complete-package works on a atom.selection. That makes it hard to hook into the actual process of text-insertion.
I have a early working version. Needs some testing :

• simple insertion works as overwrite. Expands lines as needed.
• multi-cursor ditto.

Snippets might cause problems. Snippets can be inserted via auto-complete-plus. The tab-triggered- jumps inside snippets might cause glitches... needs investigation & tests

from atom-overtype-mode.

Nice, a reply after 3 years :)

I was just going to report the same issue. So does it mean it's not possible to fix it?

Also, the same issue happens when parentheses/quotes/apostrophes pairs are auto-completed.

from atom-overtype-mode.

Is there any timeline for these outstanding issues to be resolved and the Atom package repo updated?

from atom-overtype-mode.

@lawrence-dol
two 'monkey-patched'-issues need to be resolved, before I'd want to release it. But i'm quite busy right now.
I'd like to release at the end of may... we'll see.

from atom-overtype-mode.