GNOME Bugzilla – Bug 689896
Unable to save scintilla indentation preferences
Last modified: 2020-11-06 20:22:44 UTC
I am using Anjuta 3.6.0, with the Scintilla Editor plug-in and it is impossible for me to save the scintilla configuration. I want it to always indent with 4 spaces and not with a TAB character. But no matter what I do, when I restart Anjuta, then it has reverted to using the TAB character instead of spaces. Never the less, when I go to Preferences->Scintilla->Basic Indentation, then the option 'Use tabs for indentation' is not checked. To get working tab completion, only the following work around works for me: * Check the checkbox 'Use tabs for indentation' * Click on close * Open the perferences again * Uncheck the checkbox 'Use tabs for indentation' * Click on close again However this work around is only valid for the current session. When I close and remove Anjuta, then I am back to TAB characters for indentation. As a side note, when I look into the folder ~/.config/anjuta/scintilla there is no file being saved. There used to be a file named editor-style.properties which I deleted, because I thought it might be causing my problems. However deleting the file has not changed the bug I have described above. Additionally the file is not being recreated at the moment and the folder always stays empty.
I think the preferences are not restored correctly in Scintilla. If you set the size of a tab in Scintilla preferences the size is changing. But after exiting and re starting Anjuta, the new size is set but not applied in Scintilla.
I have committed a small patch fixing this issue. Could you check if it's working?
Hi, I dont see any recent commits on git.gnome.org: http://git.gnome.org/browse/anjuta/ Where did you commit the patch? I was trying to build anjuta with jhbuild like `jhbuild build anjuta` and it gets stuck at [step 6/44] when configuring yelp-xslt (not sure why its even needed). The error says 'libxslt >= 1.1.8' is required, but I have installed libxslt1 and libxslt1-dev in version 1.1.26 already.
(In reply to comment #3) > I dont see any recent commits on git.gnome.org: > http://git.gnome.org/browse/anjuta/ > Where did you commit the patch? It's an issue with Scintilla which is not in the main anjuta repository but in anjuta-extras here: http://git.gnome.org/browse/anjuta-extras > I was trying to build anjuta with jhbuild like > `jhbuild build anjuta` and it gets stuck at [step 6/44] when configuring > yelp-xslt (not sure why its even needed). > The error says 'libxslt >= 1.1.8' is required, but I have installed libxslt1 > and libxslt1-dev in version 1.1.26 already. Installing libxslt1-dev should have fixed the issue. I think you need libxml2-dev too is it installed too? Else, you can try to build anjuta without using jhbuild. Another solution is to get the anjuta-extras source package from your distribution, apply the change that I have committed in anjuta-extras (it's quite simple) and recompile the whole package.
Strange, libxml2-dev is also installed, maybe the problem is related to this messsage: Required packages: System installed packages which are too old: (none) No matching system package installed: libicu (icu-i18n.pc, required=4) wireless-tools (required=25) jhbuild build: Required system dependencies not installed. Install using the command 'jhbuild sysdeps --install' or to ignore system dependencies use command-line option --nodeps However both libicu and wireless tools are installed including the dev version of libicu: i libicu-dev i A libicu48 i wireless-tools If I cant get it to work, then I will just apply the patch manually.
Hi, I have tested the patch, by downloading the anjuta-extras sources in Ubuntu and applying it manually. The result is the same, I cannot see any difference, with or without the patch applied. I will keep trying to build anjuta with jhbuild and report back if I get it to work.
(In reply to comment #6) > I have tested the patch, by downloading the anjuta-extras sources in Ubuntu and > applying it manually. The result is the same, I cannot see any difference, with > or without the patch applied. I have checked again and I have written another fix, in this commit http://git.gnome.org/browse/anjuta-extras/commit/?id=e156ad6a66a08f20652f4425e8c94e4cebc7639e It's quite small, you can apply it and check again. I have fixed another issue with indentation settings in the following commit, but it needs a change in anjuta too: http://git.gnome.org/browse/anjuta-extras/commit/?id=925c22f5b1a73a8493e844b857e287949c1f8089 http://git.gnome.org/browse/anjuta/commit/?id=9565bd2088c2f2aec707556daf9a8bf60b87065f These two fixes are needed when using the scintilla option "Press Tab insert indentation".
Thanks for the patches, Sebastien. I'll apply and test them tomorrow. I don't know if I'm in a special situation, but for the life of me, I cannnot find any way to make tabs behave 'normally', i.e. in 8 character wide columns. I've set ALL values I could find, both in the editor and in 'Basic Indentation' to 8, and _still_ tabs as only 4 characters. There are no modelines in any of the files. And this happens with both Scintilla and GtkSourceview as editors. I tried to find out where the tabs settings are actually stored. I now suspect this is through dconf. Could this database somehow be corrupted? John
(In reply to comment #8) > I tried to find out where the tabs settings are actually stored. I now > suspect this is through dconf. Could this database somehow be corrupted? I don't think the database is corrupted. If you change the size of the tabulation (Edit->Preferences->Scintilla->Basic Indentation->Size of tabulation in space), all tabulations of the current file should change. This should already work without patches, is it fine for you? Then, after changing the tabulation size, you should see its value using dconf-editor in the key named org.gnome.anjuta.editor.tab-width. If this value does not change it's probably an issue with dconf which is not installed correctly and is using the memory backend as a work around. If this value is right, when you restart anjuta, the value here is ignored. It's a bug fixed in the patch above. Finally, if you have the option "Press Tab insert indent", pressing the Tab key will not insert a tab character but a mixture of tabs and spaces depending on the setting of the indentations and tab size.
Before applying the new patches: > If you change the size of the tabulation (Edit->Preferences->Scintilla->Basic Indentation->Size of tabulation in space), all tabulations of the current file should change. That's just it. No change in configuration, either in "Edit->Preferences->Scintilla->Basic Indentation->Size of tabulation in space" or the equivalent when using GtkSourceView, changes the actual Tab size. org.gnome.anjuta.editor.tab-width is actually set to 8, as is indent-width. After applying the new patches to anjuta and -extras: I cannot see any difference at all. I went to check the dates/times of the executables, as I even thought it wasn't reinstalled correctly. How can I check the value used for tab-widths is the correct one? Set a breakpoint anywhere? John
(In reply to comment #10) > That's just it. No change in configuration, either in > "Edit->Preferences->Scintilla->Basic Indentation->Size of tabulation in space" > or the equivalent when using GtkSourceView, changes the actual Tab size. In this case, I think it's a different issue. Changing these values should change the size of any tabulation in your file and of the org.gnome.anjuta.editor.tab-width key. I think the dconf daemon is automatically started when a program request a key. It uses DBus so it needs to be started too. > After applying the new patches to anjuta and -extras: If there is an issue with dconf, these patches are not really useful. > How can I check the value used for tab-widths is the correct one? Set a > breakpoint anywhere? You can set a breakpoint on the on_notify_tab_size function in plugins/scintilla/text_editor_prefs.c With the latest patch, this function is called in text_editor_prefs_init function. Previously, this function was called only on a change in the preferences dialog.
1) I checked the behaviour of dconf. It does correctly write the tab width values, as monitored with: dconf watch /org/gnome/anjuta/editor/tab-width (a pity dconf doesn't allow monitoring reads) 2) I put a breakpoint at the proposed function (on_notify_tab_size) and can see that it reads the correct values from dconf. In this case, it shows 8 being read, while Scintilla insists on using 4 char wide tabs. 3) I tried to follow what happens with the 8, and traced into Scintilla, where it is assigned to a local variable: pdoc->tabInChars = wParam; (wParam is still 8) Not any nearer, I'm afraid. John
More checking: In the line pdoc->tabInChars = wParam; pdoc->tabInChars had a previous value of 4, before being overwritten by wParam (8). This is strange, as the pdoc constructor initializes to 8, and this is the default value as documented. I cannot find any other assignments to tabInChars at all.
More info: 1) Starting with anjuta -f, I opened a new document (test.c). TabWidth is set in preferences to 8. 2) I put a breakpoint at int Editor::KeyDown(int key, bool shift, bool ctrl, bool alt, bool *consumed) { (In Editor.cxx) and followed the path of the only character I typed (a TAB). 3) in 5589 void Editor::Indent(bool forwards) { I checked the value of pdoc and strangely found: p *pdoc $20 = {<PerLine> = {_vptr.PerLine = 0x7fffd9f8f730 <vtable for Document+16>}, <IDocument> = { _vptr.IDocument = 0x7fffd9f8f828 <vtable for Document+264>}, <ILoader> = { _vptr.ILoader = 0x7fffd9f8f8e0 <vtable for Document+448>}, refCount = 1, cb = {substance = {body = 0x0, size = 0, lengthBody = 0, part1Length = 0, gapLength = 0, growSize = 8}, style = {body = 0x0, size = 0, lengthBody = 0, part1Length = 0, gapLength = 0, growSize = 8}, readOnly = false, collectingUndo = true, uh = {actions = 0x15cbf48, lenActions = 100, maxAction = 8, currentAction = 8, undoSequenceDepth = 1, savePoint = 0}, lv = {starts = {stepPartition = 0, stepLength = 0, body = 0x13e2550}, perLine = 0x14b1f70}}, charClass = {charClass = "\000\000\000\000\000\000\000\000\000\000\001\000\000\001", '\000' <repeats 19 times>, "\003\003\002", '\003' <repeats 12 times>, "\002\002\002\002\002\002\002\002\002\002\003\003\003\003\003\003\003", '\002' <repeats 26 times>, "\003\003\003\003\002\003", '\002' <repeats 26 times>, '\003' <repeats 133 times>}, stylingMask = 127 '\177', endStyled = 0, styleClock = 2, enteredModification = 0, enteredStyling = 0, enteredReadOnlyCount = 0, watchers = 0x1c28960, lenWatchers = 1, perLineData = {0x1b6c0f0, 0x14b21d0, 0x14b2200, 0x1cff7d0, 0x1cff800}, matchesValid = false, regex = 0x0, pli = 0x1593c30, stylingBits = 5, stylingBitsMask = 31, eolMode = 2, dbcsCodePage = 65001, tabInChars = 4, indentInChars = 4, actualIndentInChars = 4, useTabs = true, tabIndents = false, backspaceUnindents = false, decorations = {currentIndicator = 0, currentValue = 1, current = 0x0, lengthDocument = 0, root = 0x0, clickNotified = false}} ====> tabInChars = 4 Could there be a confusion as to which pdoc->tabInChars is set to 8 on receiving the notification (which I checked), and the one used to the actual editing (above)? Or can it be overwritten in between operations? I'm no great C++ programmer (if at all), so I looked up most unknown things as I detected them. 965 return reinterpret_cast<sptr_t>(this); The reinterpret_cast operator seems to be almost generally disadvised. What more can I do to help?
This probably is just too far-fetched, but: There seems to be some disagreement about reinterpret_cast, and there are changes from C++03 to C++11. I'm using gcc-4.7.1.
I think you have done quite a lots of investigation on this issue. I have put here a breakpoint line 7752 in Editor.cxx. I think it's the only place where pdoc->tabInChars is written. The initial value is 8 and in my case it has been overwritten by 4 which is fine. I don't know why the initial value is 4 in your case. Are you sure that you have put the breakpoint before starting the program? Then, it is possible with gdb to put a watchpoint on an address. You can put a break when pdoc->tabInChars is initialized to the right value 8 in your case and put a watchpoint on the address of this variable. gdb should stop as soon as the value is changed. I think it can detect some unexpected write. I don't see how reinterpret_case can lead to such issue but I'm not a specialist neither. Here I'm using gcc 4.6.3. But I have understood that you have the same issue with the GtkSourceView editor which isn't written in C++. If you use GtkSourceView and open a file containing tab character. When you change Edit->Preference->GtkSourceView Editor->Size of Tabs in spaces, do you see the tab size changing? If not, I suppose it's rather an issue with DBus which doesn't warn Anjuta when a settings is changed. I will be traveling this week end, I will not be able to reply.
Just tried GtkSouceView again and behold, it works normally! Tabs are 8 characters, as they should be... I'm happy... So, I guess the problem is not dbus or dconf. It really is in Scintilla. Though it seems I can finally get some work done in Anjuta now, I still offer my humble help if needed. Have a nice trip! John
(In reply to comment #17) > Just tried GtkSouceView again and behold, it works normally! Tabs are 8 > characters, as they should be... I'm happy... Do you have the size of the tab changing in the editor when you change the value in the preference? > So, I guess the problem is not dbus or dconf. It really is in Scintilla. I have looked at Scintilla change log and there are some patches to remove some warning when compiled with gcc 4.7 but I haven't seen something that can explain your issue. Which distribution are you using?
> Do you have the size of the tab changing in the editor when you change the > value in the preference? Well, I'm not entirely happy. 'Real tabs' already present do change size correctly and immediately. But I cannot seem to insert new 'real tabs' \t. They are inserted as spaces. > Which distribution are you using? The distro is almost a clean Slackware 14.0 + GSB (Gnome Slack Build) 3.2. I did update some packages to be able to compile 3.6.1. John
I can confirm that with the above patches the problem is fixed for me.
And thank you very much for your work Sebastien.
(In reply to comment #19) > Well, I'm not entirely happy. 'Real tabs' already present do change size > correctly and immediately. But I cannot seem to insert new 'real tabs' \t. They > are inserted as spaces. Normally, if you select Edit->Preferences->GtkSourceView->Use Tab for indentation, you should be able to insert real tab in GtkSourceView. > The distro is almost a clean Slackware 14.0 + GSB (Gnome Slack Build) 3.2. I > did update some packages to be able to compile 3.6.1. I have used it since years, I'm afraid it can be a bit difficult to set up. Perhaps I can try to send you a patch adding debugging message to try to understand what's happen on your system.
> Normally, if you select Edit->Preferences->GtkSourceView->Use Tab for > indentation, you should be able to insert real tab in GtkSourceView. That puts GtkSourceView in 'intelligent' mode. It uses tabs if possible, but it follows any indentation it can find near. So, most of the time it uses a mixture of tabs and spaces. > I have used it since years, I'm afraid it can be a bit difficult to set up. I've 'grown up' with Slackware (from 1994 or so). I don't really have problems with any programs. Editors, including Geany and Gedit, which are also GtkSourceView based, also seem to work more predictably. I wrote a mini-IDE for Pascal-FC some time ago - I'll upgrade it to GTK-3 and GtkSourceView 3.xx and see how it does. > Perhaps I can try to send you a patch adding debugging message to try to > understand what's happen on your system. I'm interested in any tests... I'd really like to know if what happens here is an installation problem! Thanks, once again. And a very succesful 2013!
Created attachment 232572 [details] [review] Add debugging message Here is a patch adding several printf in Scintilla code. I have tried to track all changes of the variable tabInChars. Could you try to apply it and send me the output of Anjuta? I have use the master version. It would be better to use it but I think it can be applied on Anjuta 3.6. Note that if you use the master version of anjuta-extras, you need the master version of anjuta too because I have added two functions in the editor interface. I don't see anything strange here. Anjuta should output all changes of TabInChars with the address of the owner object to be sure that we use the right one. If you enter a tabulation in one editor, you should have a message displaying the current value of TabInChars.
Created attachment 232573 [details] [review] Display tab size when a tab is entered in the editor The first attachment doesn't display tab size when a tab is entered in the editor.
Created attachment 232574 [details] [review] Improved debugging code Oups I have sent the wrong file. This one should be fine.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/anjuta/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.