Warning message in logs and an error 6.7
Brought to you by:
err
Menu
▾
▴
#95 Warning message in logs and an error 6.7
WARNING [org.netbeans.editor.BaseDocument]: org.netbeans.modules.jvi.NbBuffer uses deprecated, slow and dangerous method BaseDocument.atomicLock ().
SEVERE [com.raelity.jvi.ViManager]: column 2, limit 0
at com.raelity.jvi.ViManager.dumpStack(ViManager.java:947)
at com.raelity.jvi.swing.DefaultBuffer$Mark.setMark(DefaultBuffer.java:384)
at com.raelity.jvi.Edit.stop_insert(Edit.java:1115)
at com.raelity.jvi.Edit.start_arrow(Edit.java:1076)
at com.raelity.jvi.Edit.ins_right(Edit.java:1964)
at com.raelity.jvi.Edit.edit(Edit.java:372)
at com.raelity.jvi.Normal.processInputChar(Normal.java:139)
at com.raelity.jvi.GetChar.gotc(GetChar.java:75)
at com.raelity.jvi.ViManager.keyStroke(ViManager.java:656)
at com.raelity.jvi.swing.DefaultViFactory$EnqueKeyAction.actionPerformed(DefaultViFactory.java:597)
> WARNING [org.netbeans.editor.BaseDocument]: ... uses deprecated ...
Yeah, NB made a change and the corresponding change to jVi (stop using document locks) is going to take a lot of work.
Can you reproduce the "SEVERE [com.raelity.jvi.ViManager]: column 2, limit 0"?
Other than the stacktrace, was there anything unusual that happend on the screen or with the edit session? Do you remember stuff about what you were doing at the time?
Thanks very much for the reports.
I get this and another stack trace quite frequently (blinking error indicator on NB). I am not too sure what combination of moves causes this, but the error itself is benign. As far as I can see, it has no effect on my work or what I was trying to do. I am expecting only standard vi behaviour, so if there is anything over and beyond that that is being attempted by your plugin (fancy NB UI updates or whatever), I would not notice it :-)
If you have an opportunity to post the "other stack trace", I'd like to see it.
In this case, since exception came through "ViManager.dumpStack", jVi is reporting an unexpected condition and not actually getting an exception. A quick look at the stack track indicates that the right arrow key was pressed in insert mode and the condition is arising when jVi is setting up the mark for the start of operation to where an insert started, the '[ named mark. Its all standard vi/vim stuff.
I was reading the stack trace wrong. The other trace is exactly the same. You are right in your analysis, that was indeed what I was doing. I had got used to using the right arrow key after auto completion to go to end of line, enclosing method call etc in IntelliJ/vim. Is that something that I should not be doing, and stick to using ESC, $ to go to end of line?
I was reading the stack trace wrong. The other trace is exactly the same. You are right in your analysis, that was indeed what I was doing. I had got used to using the right arrow key after auto completion to go to end of line, enclosing method call etc in IntelliJ/vim. Is that something that I should not be doing, and stick to using ESC, $ to go to end of line?
Forgot to attach the full trace.java.lang.IllegalStateException
at com.raelity.jvi.ViManager.dumpStack(ViManager.java:947)
at com.raelity.jvi.swing.DefaultBuffer$Mark.setMark(DefaultBuffer.java:384)
at com.raelity.jvi.Edit.stop_insert(Edit.java:1115)
at com.raelity.jvi.Edit.start_arrow(Edit.java:1076)
at com.raelity.jvi.Edit.ins_right(Edit.java:1964)
at com.raelity.jvi.Edit.edit(Edit.java:372)
at com.raelity.jvi.Normal.processInputChar(Normal.java:139)
at com.raelity.jvi.GetChar.gotc(GetChar.java:75)
at com.raelity.jvi.ViManager.keyStroke(ViManager.java:656)
at com.raelity.jvi.swing.DefaultViFactory$EnqueKeyAction.actionPerformed(DefaultViFactory.java:597)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1576)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2772)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2807)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2735)
at java.awt.Component.processEvent(Component.java:5379)
at java.awt.Container.processEvent(Container.java:2010)
at java.awt.Component.dispatchEventImpl(Component.java:4068)
at java.awt.Container.dispatchEventImpl(Container.java:2068)
at java.awt.Component.dispatchEvent(Component.java:3903)
at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1826)
at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:681)
at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:938)
at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:810)
at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:645)
at java.awt.Component.dispatchEventImpl(Component.java:3941)
at java.awt.Container.dispatchEventImpl(Container.java:2068)
at java.awt.Window.dispatchEventImpl(Window.java:1801)
at java.awt.Component.dispatchEvent(Component.java:3903)
[catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
> using the right arrow key after auto completion to go to end of line
That should work fine, even with the stacktrace being printed.
With your description I may be able to reproduce it; thanks.
The stacktrace represents a real longstanding bug, though pretty benign. The bug was exposed by a recent fix for setting the '[ and '] marks correctly after insert ended. The simplest way to create the problem is with "o" command that does auto indent followed by esc. The fix was adding a couple lines of code which was left out from the port from vim. Fixed in 1.2.6.x7 or later.
Available in nbvi-1.2.6.beta1