Created attachment 174006 [details] Wrong code coloring during input Open https://bugs.documentfoundation.org/attachment.cgi?id=174003. Start Query → Create Query in Design View Choose the table "Person" and close the dialog for choosing a table Double-click on * in the table. Switch Design view off. Type at he end of the code WHERE "Name" LIKE '%*' WHERE will be colored like the table name before. When typing '"' the whole following content will be shown bold and black. The whole code, which is typed when design view is off will be shown wrong colored. This bug appears in Version: 7.2.0.2 / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded with OpenSUSE 15.2 64 bit rpm Linux. Note: Color in Tools → SQL has same buggy behavior. There won't be shown any color. Only the text after a " will be shown bold while input code.
Created attachment 174007 [details] Right code coloring after reopening
This buggy behavior doesn't appear in LO 7.1.5.1 on the same machine. It hasn't appeared in any version before, so a regression.
On pc Debian x86-64 with master sources updated today, I got the wrong code coloring too but differently. All of these have the same color ""Person" WHERE "Name" LIKE '%*'" (orange/light brown).
On pc Debian x86-64 with master sources updated today, I don't reproduce this anymore. I'm quite sure it's thanks Caolán's patch, https://cgit.freedesktop.org/libreoffice/core/commit/?id=5b98dd53c7dc101d3a5ff693d3f0520ec1abd3d1 tdf#143657 'execute' button doesn't get enabled when contents changedHEADmaster since... commit 73c9ef661d9ef6237d3fd3c259fd040a545b44cf "Date: Tue Jul 6 18:51:38 2021 +0200 tdf#132740 don't broadcast if modified status has not changed now we only get a notification on transition from unmodified to modified. So continue to launch a timer on transition but clear modification on firing so we will get notified on the next change and move the modify callback to the timer. modifications are now deferred until the timer fires, so reduce the timer to make it smoother "
yeah, that lack of broadcast of a change would explain this too, lets mark as a duplicate to keep things simple *** This bug has been marked as a duplicate of bug 132740 ***