Long query bug shows text past line break in query tab

In a query tab I have a very long query (36 kilobytes) however some brief testing is showing this occurs with much shorter strings. It's a generated query by my web platform. I was using EXPLAIN to ensure that the automatically generated query would work without, obviously, executing it.

I've attached an image with two arrows to visually demonstrate this bug. The horizontal yellow arrow points at the keyboard caret which is at the very end of the line, obviously pressing the right arrow key to navigate forward would bring this textarea to the next line. The vertical red arrow points to the bug where text inappropriately appears.

It's not some kind of death-knell of a bug and it might be easy to fix. I just thought it was odd and a bit confusing at first. I'm using the latest stable version of HeidiSQL which is 11.3.0.6295 (obviously checked for updates). Hopefully you can directly reproduce the issue; I've been dealing with a couple client-only-errors myself of late and it's pointlessly frustrating; this bug is not terrible though but we can't let the world know that you're not completely perfect. ;-)

Please use the update check to update to the latest build 6450 (not the last release) and test again. If that still appears buggy, then reset the dark theme to the default "Windows" theme, and test once again. These themes have quite a few painting issues.

With the latest build and the default theme I cannot reproduce that here.

I set both the Windows theme to light, unloaded WindowBlinds 10 and set HeidiSQL's theme to "Light" and the problem still occurs.

I tried to update to the latest build 6450 and received the following error:

[Window Title] Local Server: Error

[Content] Could not open http://www.heidisql.com/builds/heidisql64.r6450.exe ()

[OK]

[Footer] Find some help on this error (=> ecosia.org)

However the absolute URL works fine in my browser. However when running the installer for build 6450 I received the following error:

[Window Title] Error

[Main Instruction] Connection failed

[Content] File does not exist: D:\My Documents\Downloads\libmariadb.dll

Please launch HeidiSQL from the directory where you have installed it. Or just reinstall HeidiSQL.

[OK]

[Footer] Find some help on this error (=> ecosia.org)

Any way after encountering prerequisite errors (meh, good luck with that) I confirmed the bug exists with the blinding-Windows-theme, the HeidiSQL Light theme and WindowBlinds 10 not loaded on a completely different Windows user that did not have any Windows-user specific settings (not sure if the settings are Windows-system or Windows-user based). I've attached a screenshot of the bug still occurring using the same SQL query. The only other thing I can think of is to send you a PM or email with the SQL query (posting it here will look bad for search engines).

Why did you select "Light"? I meant "Windows".

For the other errors - you need to use the update-check dialog, so you get heidisql.exe into the right directory. You have it just downloaded somewhere, where it cannot find dlls.

What is WindowBlinds, and what does that have to do with this issue?

Okay, I just switched to the "Windows" theme and the problem still persists.

Yeah, I copied the portable version and put it in to the install directory to do the testing.

WindowBlinds is what I use to force dark mode on everything or as close to everything as I can manage. There are lots of junky parts of Windows that are still blinding after the "dark mode" feature was added.

To be honest, I don't think this is an issue with themes. I'm happy to ZIP up and provide the files and export any settings if you want to try to help you reproduce the issue.

Ok, probably I am doing something differently, but I can't see what's wrong here:

Note the wordwrap glyph in the left gutter, as I am wrapping a long line here. Is that activated for you too?

No, when I use word wrap (in general) it's only temporary and I have it off by default (if I'm aware of it to begin with). So no, I'm not using word wrap. In fact I looked in the context menu for the SQL query tab and looked in all the tabs for Tools menu / Preferences and did not see the word wrap option - how do I toggle it?

Okay, under the Query menu there is a "Wrap long lines" option though it doesn't seem to do anything for me in the query tab.

Secondly I went to HKEY_CURRENT_USER\Software\HeidiSQL and set ToolbarShowCaptions to 0 and restarted because I looked up word wrap on Duck Duck Go images and didn't see the toolbar item. After restarting pressing that a few times also does not change the text.

Query > Wrap long lines

Without wordwrap it's also normally displayed:

Okay so I press Home and then scrolled horizontally a few pages and then selected everything from that point to the left. I'm not sure what the total length was though word wrap worked then.

Cutting everything from the query field Notepad++ says the total length is 36,259 characters. So there certainly is some sort of hard limit on how long that field accept or works with strings. I do some zany things, often to see the limits. This is actually for a query to rebuild HTTP 301 redirects and I don't have the time to compare what is in the database to what is going back in so I am simply truncating the table and rebuilding it each time hence the extremely long SQL query. I apologize for the confusion, it's not my intention.

So, what is your policy on 36K+ query lengths? 🤣︀

I don't think SynEdit has a hardcoded maximum line length. Can you please again post a screenshot and say what's wrong.

So I decided to see if there were any special characters that were causing the issue. I stripped out a-z, A-Z, 0-9 and a few other common characters. I have the length down to about 915 characters which is much more manageable.

As it turns out there are some characters or, I think more likely, combination of characters that mess with the editor's ability to comprehend the keyboard caret position.

Since the text I'm about to post might be lost in some sort of unrelated third party conversation I'll copy the text I post and test to it if it has the same effect and confirm either way. I'm still trying to narrow it down a bit to be actually helpful here though I want to give you something to work with too.

(' ~~ '), ('?='), ('&='), ('以获得更详细的“当前已知”列表，特定于&'), ('以获得更详细的“当前已知”列表，特定于&'), ('', '+'), ('?='), ('?='), ('?='), ('?='), ('?='), ('?='), ('?='), ('', '++'), ('?='), ('?='), ('?='), (';'), (',', ':'), ('?='), ('', ''), ('?'), ('?'), ('?,'), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?'), ('?'), ('?'), ('?'), ('?=&=', '?='), ('?=&=&=&=&=&=&=&=', '?='), ('?=&=', '?='), ('?='), ('?'), ('?:'), ('?:'), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), ('?=&='), (','), ('?='), ('?='), ('?='), ('?='), ('?=&='), ('?=&=&='), ('?='), ('?=&='), ('?='), ('?=&='), ('', ''), ('', ''), ('', ''), ('?='), ('?='), ('?=', '?='), ('?='), ('', ':'), ('', ':'), ('&=&=&=&='), ('&=&=&=&='), ('&=&=&=&='), ('&=&=&=&='), ('&=&=&=&='), ('&=&=&=&='), ('&=&=&=&='), ('&=&=&=&='), ('', '#'), ('', '#'), ('', ':'), ('');

Okay, copying the left-over code from above the website reduces the error character count down to two spaces to the left than what it should be. Here is a screenshot of what the Control + End caret position appears to be:

Okay, I've attached the file hex.txt to this message with the characters that you can use to load in to an online hex editor. Removing the clear binary data reduced the issue though it's still present by six characters. The hex file contains 39 characters. I don't know if you want to do anything about binary / invalid / whatever characters, it's up to you. This stuff is generated with minimal human interaction and I likely did not see the binary data when I created whatever relevant redirects likely now years ago. It's one more task that I'm not sure I have the time for. Maybe there is something easy to reproduce that can be filtered out or have a warning message appear for? I hope this helps, sorry for the mess.

I see the issue now, with your sample text. I cannot move the cursor to the actual end of the text, just 2 or 3 characters before the very last character.

I have no clue how to solve that. This is an upstream bug in SynEdit. Not sure if it was already reported in their tracker.

Is this the correct page for SynEdit? I'm just verifying since I'm not familiar with the project. If so I will take a few minutes to post a report with a reference link to this thread?

Yes, that's the SynEdit repository. But please explain the issue more exact and shorter than you did here. It might also not be helpful to link to a long thread where developers must dive into, just to understand an issue.

I've been catching up on a lot of things and finally was able to knock this off my to-do list. This is a link to the error report at GitHub: https://github.com/SynEdit/SynEdit/issues/191.

Someone posted that there was a Unicode update earlier this year that may resolve the Unicode issue. However I'm not familiar with compiled software (just interpreted/web) so it's all you Ansgar.

https://en.delphipraxis.net/topic/6277-synedit-just-got-a-major-uplift/

If that was the case then you should see this fixed in the latest nightly builds of HeidiSQL, which have an updated SynEdit component from a few weeks ago. But I really doubt your specific issue was fixed by these updates.

Indeed the above mentioned article talks about the TurboPack version of SynEdit, while HeidiSQL uses the original SynEdit code.

Again this is all your area of expertise and I have none other than this forum thread.

I can say that cPanel screwed up Apache and PHP by integrating LiteSpeed which caused numerous issues with Apache for me. So based on that and similar screw-ups by others I've been directly effected by I both encourage trying new things out though testing for compatibility and stability. Who knows? Maybe the TurboPack version of SynEdit will fix those weird bugs that occur when typing an the keys act as commands?

Don't know. But I see some issues in TurboPack/SynEdit which were already fixed in the original SynEdit project. For example double minus comments which require a trailing space are broken in TurboPack.