This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
(Fascinating, I hadn't run into BaseDocument_PropertyHandler before... But I digress.) I've started hooking up vim's ":set [no]wrap" (in addition to ":set [no]list" and ":set [no]lbr") Bottom line is that there does not seem to be a preferences listener that responds to prefs.put(SimpleValueNames.TEXT_LINE_WRAP, s); DocumentView listens to *document* changes to pick up changes for LINE_WRAP. (For NON_PRINTABLE_CHAR_VIS DocumentView listens to the preferences.) In FormattingPanelController.applyChanges it spins through the EditorRegistry. For line-wrap jVi currently does doc.putProperty after doing String s = !w_p_wrap ? "none" : w_p_lbr ? "words" : "chars"; prefs.put(SimpleValueNames.TEXT_LINE_WRAP, s); (Actually, the current behavior is interesting. It allows jVi to support separate settings per window-buffer. It does the prefs.put and doc.putProperty when a window becomes current and that doesn't affect other windows.)
In general, TEXT_LINE_WRAP is a formatting setting while NON_PRINTABLE_CHAR_VIS is an ordinary non-mimetype-specific setting. As such TEXT_LINE_WRAP can either be set in Tools-Options or in a project Properties dialog. For the moment TEXT_LINE_WRAP and TAB_SIZE (the two formatting setting needed for rendering documents on screen) are wired through document properties. I think that your jVi code is ok. I'm not sure what instance 'prefs' actually is (the one from MimeLookup or the on from the project owning the document), but as long as you get it from CodeStylePreferences it should work consistently with the rest of the formatting settings. Regarding the per-document line-wrap setting, it's probably possible, but inconsistent with other editor settings and obviously not persistent (unless jVi stores it somehow on its own). I have a mild preference for using the same algorithm as in FormattingPanelController, but I'm not that familiar with jVi and its integration. Maybe what you have now suites jVi's users best. So, what actually is here to be fixed? :-)
> what instance 'prefs' actually is (the one from > MimeLookup or the on from the project owning the document) I used MimeLookup, now that I know about CodeStylePref I'll use that. That's part of the problem looking at code, miss these "proper" interfaces. ;-) That bring up the question, what options is CodeStylePref good for. I think everything I use is in SimpleValueNames.*, so I should be OK > per-document line-wrap setting, it's probably possible, but > inconsistent with other editor settings and obviously not persistent I'm actually hoping nothing is changed at this time. In the future if NB wanted to support per document (or event per window) settings, then jVi would adapt. > (unless jVi stores it somehow on its own) jVi supports the vim modeline (for a few options, now including wrap), so the user can embed some jVi commands in the file being edited (typically as a comment). SiftWidth is another example. In addition when a user does ":set wrap" from the command-line that only affect the current document though vim supports it per window. When an editor becomes current (for example TopComponent activated) the NB options are set as needed for that particular editor. So from the user's perspective they have per document settings dynamically and have a way to persist them per document. line-wrap is different since there is a visual component, and a lot of new-view-hier CPU (i guess) when it is changed. Something like changing shift-width doesn't require any rendering update. So have to be careful with something like line-wrap to avoid a lot of CPU when the option is changed. The current behavior of only affecting the current document and not everything is perfect for jVi, though internally in NB things are a bit inconsistent. > So, what actually is here to be fixed? :-) Well, yes, that is the question. Since other occasions where jVi changes options with prefs.put() work without additional code. This seemed like a bug no matter how much I prefer the behavior. Perhaps the distinction between wrap and shift-width is that wrap changes what you currently see. And current NB behavior is "expected". But since no one is quite as intrusive (perhaps intimate is a better word) with the NB editor, I'm happy if this is closed as INVALID. And of course I understand there are no guarantees about the future, jVi is used to things changing under it.
Discovered something interesting about non-print-char-vis option. This is global: > NON_PRINTABLE_CHAR_VIS > is an ordinary non-mimetype-specific setting I was doing prefs.put(...) where prefs was based on mime type. And this *did* something. Further experimentation showed that I could get different settings for plain and x-java. I changed jVi code to do CodeStylePreferences.get((Document)null).getPreferences().putBoolean( SimpleValueNames.NON_PRINTABLE_CHARACTERS_VISIBLE, w_p_list); and it started behaving globally. I guess there's a bug in how it is accessed by the View. It must be using mime-type and not global.
The view uses the following (DocumentView.java): ... prefs = MimeLookup.getLookup(mimeType).lookup(Preferences.class); ... prefs.getBoolean(SimpleValueNames.NON_PRINTABLE_CHARACTERS_VISIBLE, false); So from the view's point of view the setting is per mime-type. The action in the main menu changes the setting for mime type "" which effectively mean changing the option for all files opened in the IDE. I think this is Ok or do you suggest to change the implementation somehow? I am closing as works for me but please feel to reopen with suggestion (or even patch) how this should work in your opinion. Thanks a lot.