Many of you are most likely familiar with Microsoft Visual Studio. When I move focus, my changes are already there (or I just need to hit the “Yes to All” button in the reload confirmation dialog) and I am getting the best of both worlds.īefore I go into greater detail, I’d like to explain a bit about Visual Studio Code. Some things I do in Qt Creator, while others I do in Visual Studio Code. I have configured both to auto-save and auto-reload so that I can switch seamlessly between the two. My current work setup uses both in parallel. I am not advocating to ditch Qt Creator altogether. Also, I am doing a lot of my development on macOS, and Qt Creator does not always have the same level of stability there as it does on Linux and Windows. The first question you want to ask is probably, “Why use another editor or IDE at all if we have Qt Creator, which is a perfectly good and, in particular, Qt-specific IDE, ready at our disposal?” And, of course, that’s a very valid question to ask.įor me, the main reason is that Visual Studio Code simply does some things better than Qt Creator – and other things worse, which I’ll discuss later. Motivation of using Visual Studio Code instead of Qt Creator So in this blog post, I am going to share with you some of the experiences some of us here at KDAB have had using Visual Studio Code for Qt development.
After making changes to a file and reopening it, the detected encoding is suddenly different and characters cannot be displayed anymore.Software developers like tools, and in particular tools that make them more productive. If the names are not matching, the check for encodingExists would fail.įinally I am running into some issues when testing this and I think this exposes a problem with encoding auto detection in general. If jschardet is returning an encoding with a specific name, we have to ensure that this is the same name used in iconv-lite (see here for a list of supported encodings in iconv-lite).
I would then also suggest to rename the flag from autoDetectEncoding to autoGuessEncoding.Īs you probably already figured out, we are using iconv-lite to convert to and from encodings. Since we already have jschardet in the system, this functionality could be added quite easily I guess.Īs for the setting, maybe it would be better to rename it to autoGuessEncoding and have the wording be When enabled, will attempt to guess the character set encoding when opening files.
Yes, this would be an optional thing to "guess" the encoding from the picker in case the user does not want to opt in to the setting for all files.
0 kommentar(er)
