Unicode bug in characters that move to the previous glyph

[David263]

"Please search existing issues to avoid creating duplicates." There are too many bugs for me to do an accurate search. sorry.

I tested with the standard product only. I am busy,. sorry.

• VSCode Version:1.39.2
• OS Version:Windows 10 Home

Steps to Reproduce:

1.Enter the string "nūta॑nairu॒ta" into a new VSC file 2.See that garbage is displayed (more than 11 characters)

3. See that the cursor does not move through the garbage characters one character at a time.

Note that this bug reporting system can display the above string correctly. Also, the UTF-8 validator tool https://onlineutf8tools.com/validate-utf8 displays the string correctly.

Unless you disagree that this is a bug, please fix it. I can't use VSC until the worst of the bugs are fixed. Thanks!

Does this issue occur when all extensions are disabled?: Yes I do not use any extensions, since I'm evaluating VSC to be my new editor. (I can't use it until the autoindentation disabling bug is fixed and until it handles Unicode correctly.)

[gjsjohnmurray]

/findDuplicates

[vscodebot[bot]]

Potential duplicates:

• [Feature Request]: if we can support paste file or folder which copied from Desktop (#17791)
• On Mac, if VSC is hidden, then opening it from Terminal opens new window in background (#48441)
• Selection length of 4 byte Unicode characters is incorrectly calculated (#62286)
• Option to disable Unicode point count in the Col section of status bar (#84336)
• missing character (#81869)

[David263]

The first "possible duplicate" in your list has nothing to do with Unicode at all.

My bug report stands and I do want it fixed, not ignored as a duplicate.

[gjsjohnmurray]

Please update to the current release and retest. If the problem remains please attach your test file.

[gjsjohnmurray]

/confirm I am able to reproduce this in 1.40.2 and 1.41.0-insider by copying the test string from GH report and pasting.

[David263]

You first say, "Please update to the current release and retest." But then you say, "I am able to reproduce this." Do you still need me to update and retest? I am confused by your posts.

[gjsjohnmurray]

Sorry for the confusion. I don't think you need to do anything more at the moment. But I am not a member of the VSCode team.

From the extra research I did I learned your sample string includes two nonspacing mark characters, U+0951 and U+0952. It seems VSCode doesn't handle these correctly. Thanks for reporting.

[David263]

Thank you. As a further clarification, another of the hidden complexities of our "keep adding complications" standard, Unicode, is 'grapheme extenders'. Please see https://stackoverflow.com/questions/21722729/what-is-the-difference-between-combining-characters-and-grapheme-extenders-i for the difference. Although I haven't tested VSC for correctness in rendering grapheme extenders, I am busy currently and anyway I bet it can't do them either, so consider this bug report to be extended (in a graphemic way) to include grapheme extenders in addition to combining characters. My subject line already conveniently covers both.

(But please note that Astral characters, such as 🍵🍶🍷🍸, do seem to be correctly rendered. And, unexpectedly, মৌ is correctly rendered, which shows yet another Unicode feature.)

Also, VSC can't handle the combining grapheme joiner (CGJ), U+034F. Here is an example: הֽ͏ַ . This is displayed correctly by github but not by VSC.

While I'm at it, I'll include in this bug report the code point U+fdfd, which is one character that is supposed to be rendered roughly 12 characters wide, but in VSC is rendered in one character width. Github also can't render it properly; here it is: ﷽ . You can't even see this.

I think VSC needs an expert in Unicode who can research all the horrible corners of this wonderful standard and document them all so they can be fixed. I just am too busy to keep working at this task, sorry.

Thanks to all who read this, and particular thanks to anyone daring to try to fix VSC Unicode rendering. At least it is partially working, which is nice.

[gjsjohnmurray]

Might still be worth you updating to 1.40 because the release notes mention better handling for Unicode combining characters.

[David263]

I have updated to 1.40. Wow, an impressive number of Issues were closed.

As to the Unicode errors reported here:

1. The "nūta॑nairu॒ta" error still happens.
2. The "הֽ͏ַ" grapheme is now correctly rendered, but cannot be copied and pasted. Also, the caret doesn't move correctly either forward or backward, and the mouse doesn't work right either.
3. The "﷽" phrase is still displayed as one character.

I hope you will excuse me if I move on to some other work I need to get done. Best of luck.

I would like my text editor to adhere to the Unicode standard, so I can implement Unicode programming using it. VSC does not seem ready for that challenge as yet, sorry. But other editors seem equally broken, even some that cost money, and even good old Notepad. As I said, I think VSC needs an expert, or at least someone with the time to really research all of Unicode. It is a remarkable and wonderful standard.

<flame>Unfortunately, any software tool that renders standard UTF-8 text must adhere to it. The future seems to belong to increasingly complex standards, making ordinary software tools increasingly difficult to implement and maintain.</flame>

[mcswell]

@David263, I'm not on the VS Code team either, but I do a lot of editing with Unicode. I tried to reproduce your report:

1.Enter the string "nūta॑nairu॒ta" into a new VSC file 2.See that garbage is displayed (more than 11 characters)

3. See that the cursor does not move through the garbage characters one character at a time.

   I am wondering what the "garbage" characters are that you're seeing. In my case (VS Code v.1.40.2), I see two empty boxes in addition to the alphabetic chars and the over-bar on the first 'u': one box corresponds to the Devanagari stress sign udatta (0x951) over the first 'a', and the other o is the underbar under the second 'u' (another Devanagari stress sign anudatta, 0x952).

If that's what you're seeing (you might be seeing a box in place of the over-bar, too), that's a font issue, not an editor issue. When a font doesn't contain the glyph for a particular Unicode character, it substitutes some symbol, typically an empty box--which is what I'm seeing here. And apparently the font that VS Code is using in your setup doesn't contain 0x951 or 0x952.

The only way you're going to see those characters as anything but boxes is if you tell VS Code to use a font that covers both the Basic Latin (equivalent to ASCII characters) and the Devanagari block, and probably even then you'll need to order that Devanagari font before any other fonts in VS Code's list of fonts, because I suspect it renders each character using the first font it finds that contains that character. I don't know of any such fonts, but there might be some. It is in any case very strange to want a Devanagari character to appear atop a Latin character--the Devanagari combining characters are intended to combine with Devanagari base characters, not Latin Base characters. If you want the general shape of those combining characters atop Latin characters, I would suggest "combining vertical line above" (0x030D) or possibly 0x02C8, and "combining macron below (0x331), or possibly 0x0332.

I haven't tried your #2 and #3 issues, but I suspect they're similar.

In sum, I suspect VS Code is adhering to the Unicode standard; it's a font issue, not an issue with VS Code.

[David263]

Concerning bug #1: this string is copied from a Sanskrit font that uses the IAST (Roman/Latin) character set, not the Devanagari character set. I certainly don't expect you or a VSC team member to be an expert in character sets! That is why I phrased the bug report as I did: I simply compared with other products that render or recognize this string correctly, then point out that VSC shows it as

Yes, it is true that the character set must support whatever Unicode characters are being tested. The font I have selected in the Settings > Text Editor > Font is Consolas. When I try with Arial, I see the same thing, except it is in Arial font. Can you suggest a fixed-width font name that would work?

Yes, of course I order the preferred font first, before the default font families (Courier New and Monospace). That is the way CSS works.

[mcswell]

Confused. Afaict, IAST is a transliteration standard which predates computing. But in any case, either the original app you copied it from was using some Devanagari characters, or something strange happened when you copy-pasted it in from some other application, because the two characters that show up as boxes really are in the Devanagari range of Unicode (U+0951 and U+0952); they are not code points in any Latin character set. I've verified that in a couple different ways.

I'm also not clear what you mean when you say you copied it from a font--I guess there are ways of extracting characters from a font (like FontForge), but you'd need to have done that one character at a time, which seems painful. Perhaps you mean you copied the string of characters from some application like Word or LibreOffice, where the application was using a Sanskrit Latin font? (BTW, if it was Word, Word automatically uses font substitution where it needs to, so you can't rely on the font it says it's using actually being the font it uses on any particular character.)

I'm also not sure where this is: Settings > Text Editor > Font is Consolas I don't see that chain of settings in VS Code anywhere; the File > Preferences> Settings sequence takes me to a page with lots of controls, the relevant one in this case (I think) being "Editor: Font Family."

Unfortunately I don't know any fixed-width font that covers both Latin and Devanagari Unicode code ranges.

About: ordering the preferred font first, I was referring to the settings inside VS Code (the settings page), not CSS.

Here's the text I think you're trying to get, using only Latin range characters (specifically, 0x30D and 0x331 in place of 0x951 and 0x952): nūta̍nairu̱ta Try copy-pasting that into VS Code and see what it looks like.

[David263]

"Confused."

That is why I just said that I avoided the issues you raised: to avoid confusing anyone. I suffices that VSC doesn't implement all of Unicode, and I'm reporting the problems I've found.

"Afaict, IAST is a transliteration standard which predates computing."

Quite true, as far as that goes. However, ISO 15919 "Transliteration of Devanagari and related Indic scripts into Latin characters" is a modern standard (https://en.wikipedia.org/wiki/ISO_15919). Unicode complies with it (see the Unicode standard for details).

"the two characters that show up as boxes really are in the Devanagari range of Unicode (U+0951 and U+0952)"

Yes, and so what? All the ranges of Unicode are part of the Unicode standard and are implemented in the standard tools I've mentioned above. My complaint is that VSC doesn't support all of Unicode.

"they are not code points in any Latin character set"

Again, so what? Unicode was invented to support all character sets, not just Latin. Specifically, we are allowed to mix the alphabets of different languages together in the same string. I'm surprised you didn't know that.

The special characters that keep the position from being incremented are very much a part of the Unicode standard and are implemented by other tools, as I've already said.

If you are arguing against Unicode (are you?), you are in the wrong forum.

"I'm also not clear what you mean when you say you copied it from a font"

I simply mean that I copied them from their source (typically Firefox) to the Windows clipboard. Both Firefox and the clipboard implement enough of Unicode to make such copying successful, as verified by the Unicode validation tool I mentioned above.

"I guess there are ways of extracting characters from a font (like FontForge)"

Windows comes with a Character Map utility that lets you copy individual Unicode characters to the clipboard. This issue is irrelevant to my report.

"Perhaps you mean you copied the string of characters from some application like Word or LibreOffice...Word automatically uses font substitution"

I am a retired professional Web and software engineer. I understand such issues. These all seem to be attempts to argue with the bug report. First, before looking for problems with the report, you should say whether you were able to replicate the bugs or not. Assuming I did things wrong is not helpful at this point, as it wastes our time and github storage space. If you can't replicate the bug, then you should start criticizing. Did you even try to replicate it? You don't say.

"I'm also not sure where this"

Anyone very familiar with VSC will know how to change the default font. Do I really have to give you a list of steps for doing this in a bug report? You can do a Web search to learn how to change the default VSC font (I would tell you to read the manual, but there isn't one; you can read the Help file).

"Unfortunately I don't know any fixed-width font that covers both Latin and Devanagari Unicode code ranges."

Yes, I doubt there is one. I apologize for mentioning "fixed font". There are many fonts that include the Devanagari range, and that is sufficient to replicate the bug. People who write in Hindi, Sansrkit, and about a dozen other languages need all of Unicode working. If you want to help, experiment with fonts and find one or two that implement the Indic/Devanagari range.

"About: ordering the preferred font first, I was referring to the settings inside VS Code (the settings page), not CSS."

VSC uses CSS in some of its settings, unless I'm confusing it with Atom.

"Here's the text...using only Latin range characters"

That is an interesting test, and it is successful. That gives more insight into the bug, but doesn't relieve VSC of the responsibility of rendering the Sanskrit range of characters correctly, along with Latin ranges, even if a font doesn't include the actual glyphs, in my opinion.

In point of fact, I copied the Sanskrit example from a website that offers English transliterations of Sanskrit texts. Clearly, the authors wrote their texts using a keyboard that inserted Sanskrit accent marks into a Latin string. You can criticize such a keyboard, but it is what they chose to use and their strings are correct according to the Unicode standard.

As a programmer's text editor, I expect VSC to adhere to the Unicode standard, not just a part of it.

This kind of discussion, where my report is picked apart and I must keep defending, is very tiring and time-consuming, since I already provided enough information to allow replication of these three bugs.

What is relevant at this point is whether the VSCode team can replicate them or not. Perhaps we could wait until an actual "member of the VSCode team" shows up, please? I have other work to get to.

Thanks.

[alexdima]

@David263

VS Code is built with Electron, which is built with Chromium. The current Chromium version shipping with VS Code is 76.0.3809.146. The current Chrome stable version is 78.0.3904.108.

1. Enter the string "nūta॑nairu॒ta" into a new VSC file
2. See that garbage is displayed (more than 11 characters)

The editor portion of VS Code uses Chromium for text rendering. I can reproduce the issue you have identified around the rendering of nūta॑nairu॒ta in the latest Chrome Canary, 80.0.3983.2. I personally cannot explain what is going on, since text rendering is implemented in Chromium, but I do know they have some of the best text rendering on the planet, so I have therefore reported the issue upstream at https://bugs.chromium.org/p/chromium/issues/detail?id=1029992 .

3. See that the cursor does not move through the garbage characters one character at a time.

What a great coincidence! I have just recently implemented Unicode's grapheme cluster boundary rules for cursor navigation via https://github.com/microsoft/vscode/commit/3f1a2f690ae5b0dc192ef1a233a7c1c9cb8360ff so I can say I have made myself familiar with those rules. That commit has only made it to the insiders channel at this point, so you would need to install VS Code Insiders side-by-side to get the fix right now, or you can simply wait until the next stable release.

According to Unicode's Grapheme Cluster Boundary Rules, the code point U+0951 is classified with the Grapheme Break Property Extend. See line 113 of GraphemeBreakProperty-13.0.0d4.txt

0951..0957    ; Extend # Mn   [7] DEVANAGARI STRESS SIGN UDATTA..DEVANAGARI VOWEL SIGN UUE

According to rule GB9 of the Grapheme Cluster Boundary Rules, a Grapheme Break cannot be introduced before such a character:

I therefore find VS Code's cursor navigation around these specific graphemes spec compliant.

---

Regarding the rendering of 🍵🍶🍷🍸, মৌ , הֽ͏ַ , ﷽ . I think it is best that you report these issues directly to Chromium. I can do it on your behalf, but I feel that you know a lot more about their peculiarities than me and might be more qualified for a discussion with them.

[mcswell]

Alexandru-- David and I have been going around in circles on this. I'm virtually certain that the problem is that the font he and I are using simply doesn't contain the characters in question, so they show up as boxes. There are basically two behaviors I've seen in programs when the chosen font doesn't have a glyph for a particular character. Either the program displays a box, or some similar indication that the character is not supported in the chosen font (see https://stackoverflow.com/questions/18760943/character-code-of-unknown-character-character-e-g-square-or-question-mark-romb); or the program silently substitutes some other font that happens to contain that particular character. Firefox and Microsoft Word (and from your bug report, Edge) behave in the latter way; almost every other program I've ever used behaves the other way, apparently including Chrome. I don't consider either behavior wrong.

The only other thing a program could do (I've never actually seen one do this) would be to display the Unicode code point, e.g. as a hex digit. Not sure that would be very helpful, but I suppose it could be done.

[David263]

I found the following interesting statement on the Microsoft typography website:

Arial Unicode MS was originally commissioned by Microsoft Office as an extended version of the Arial typeface to support a large set of international characters. The font was included with Office but not Windows. Over time the Unicode standard grew to the point where it was not possible to include all encoded characters in a single font file, so today most applications rely on font linking or font fallback to provide appropriate language support when a selected font doesn’t include the characters you need. We stopped servicing and updating Arial Unicode and no longer install it as part of Office. However, updated versions of the font are available from Monotype.

Website http://luc.devroye.org/indic.html lists many fonts that include the Indic characters.

Alexandru, I am glad that you are familiar with some of the internals of Unicode. If I can help by reporting these problems elsewhere, I'm happy to do so. Just give me the URL of the bug report website. Thank you.

[David263]

I have just tried to show nūta॑nairu॒ta in the DejaVu Sans and Segoe UI fonts, where it is supposed to be supported, and it still displays with rectangles, as shown above. Perhaps I am not doing this correctly, as I am not a VSC user. I go to Settings Icon > search bar > Editor: font family. enter "Segoe UI, Consolas, 'Courier New', monospace", press Enter, then choose the test text buffer tab.

[mcswell]

The two characters in question, U+0951 and U+0952, are in the Unicode Devanagari block. According to these web pages https://en.wikipedia.org/wiki/DejaVu_fonts#Unicode_coverage https://en.wikipedia.org/wiki/Segoe (see under section labeled "mono") neither the DejaVu Sans nor the Segoe UI fonts covers the Devanagari range. That would explain why the characters don't show up with those fonts.

[David263]

Sorry about that. The table at page https://en.wikipedia.org/wiki/Unicode_font indicates that 'GNU Unifont' and 'GNU FreeFont' include the Devanagari block (0900–097F), and that the same two fonts also include the very short Devanagari Extended block (A8E0–A8FF). The Devanagari/transliteration website that I got that string from used the uncommon font 'Shobhika' throughout. This font is available for free from page https://ctan.org/tex-archive/fonts/shobhika?lang=en (as .otf files, which, like .ttf files, can be installed locally by copying into the C:\windows\fonts directory).

Good news! When I installed the font and changed the VSCode font setting to Shobhika or 'Shobhika', pressed Enter, then selected the test file tab, the word was displayed correctly. Not only that, but the caret moved correctly both under mouse and keyboard control.

Thank you everyone for patience with my learning about Unicode. It has so many features that it is clear I will never have the time to understand all of its internal details.

I tested the Hebrew "הֽ͏ַ" again with the font set to Arial (which supports Hebrew), and it still looks correct, but setting the caret at the end of the letter (the left side) using the mouse is impossible, and moving from beginning to end of the character (from right to left) using the keyboard skips the character following the "הֽ͏ַ". There are other keyboard character movement problems as well.

I tested the Arabic phrase "﷽" again, and it still is displayed in highly compressed form, so that bug appears to remain. Here is how it should be displayed (from my clipboard monitor):

And, finally, VSCode fails to display files containing multiple fonts (so it does not seem possible to display files that require the use of uncommon disjoint Unicode blocks covering which requires the use of two or more fonts). If I were creating a Unicode-compliant text editor, I would have a default font selection in my settings, but this could be overridden by selecting some text and the using mouse or keyboard to select a desired font and font size (and probably other characteristics) from a menu or context menu. This would support the Unicode goal of showing any human language character in a single string.

Should I create a new Issue for each of these problems, since this Issue is so cluttered?

[alexdima]

The upstream issue I have reported to Chromium regarding the rendering of nūta॑nairu॒ta at https://bugs.chromium.org/p/chromium/issues/detail?id=1029992 has been closed as won't fix. Since this issue was a tracking issue for their issue, I will close it now.

@David263

Editor text rendering is delegated to Chromium. If you find text rendering to be flawed in any way, please create a fiddle at https://jsfiddle.net/ and report it directly to Chromium at their issue tracker -- https://bugs.chromium.org/p/chromium/issues/list

Editor text editing is implemented in VS Code. If there is any further issue with editing the text, like cursor placement, editing operations, then please do not hesitate to open new issues here with clear steps.

[David263]

Alexandru, Thank you for your help.

Two things:

1. How do I create a fiddle that changes the font used by VSC, and runs VSC?

2. Please answer the question I asked at the end of my previous posting.

Thanks, David

On 12/3/2019 12:21 PM, Alexandru Dima wrote:

The upstream issue I have reported to Chromium regarding the rendering of |nūta॑nairu॒ta| at https://bugs.chromium.org/p/chromium/issues/detail?id=1029992 has been closed as won't fix. Since this issue was a tracking issue for their issue, I will close it now.

@David263 https://github.com/David263

Editor text rendering is delegated to Chromium. If you find text rendering to be flawed in any way, please create a fiddle at https://jsfiddle.net/ and report it directly to Chromium at their issue tracker -- https://bugs.chromium.org/p/chromium/issues/list

Editor text editing is implemented in VS Code. If there is any further issue with editing the text, like cursor placement, editing operations, then please do not hesitate to open new issues here with clear steps.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/85853?email_source=notifications&email_token=AA5I2NXFKLMAU2FDBTOF4OTQW2IRFA5CNFSM4JTHBZOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF2EXPI#issuecomment-561269693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5I2NT4SBB7J6N4I6ITXWDQW2IRFANCNFSM4JTHBZOA.

[David263]

In other words, do I create one or three Chromium bug reports?

[alexdima]

@David263 I would like to try to understand what are the 3 other issues that you mention.

1. Regarding the Hebrew "הֽ͏ַ"

Can you share the code fragment that was problematic? We have a number of known issues around RTL, perhaps one of the existing issues already contains the exact issue you are experiencing?

• https://github.com/microsoft/vscode/issues/11770
• https://github.com/microsoft/vscode/issues/14019
• https://github.com/microsoft/vscode/issues/65648
• https://github.com/microsoft/vscode/issues/65855
• https://github.com/microsoft/vscode/issues/83365

2. Regarding "﷽"

This appears to be rendered correctly only when enabling ligatures. VS Code is a code editor and has ligatures disabled by default. Enabling them via "editor.fontLigatures": true will allow this string to be rendered as I think you expect:

3. Regarding having multiple fonts in the same file

This has already been asked in https://github.com/microsoft/vscode/issues/30925 . You can simply upvote that issue

[David263]

@alexandrudima, I agree that the caret moving problems would undoubtedly be fixed if RTL languages were supported. My intuition, based on previous experience with RTL strings embedded in LTR pages in other programs, would support this idea.

I looked at just #11770, and it does not list specific problems, just asks for RTL to be implemented. It has been CLOSED multiple times, which is astonishing since the comments make it clear that the feature (a standard one) is still only partially implemented. Why do these Issues get Closed before they are ready to be closed? Strange. And weird.

I would upvote suggestions if I could see how. Please give me instructions for upvoting (I haven't ever done it before at Github).

Regarding bug 3 and ligatures, I haven't experimented with it, but English ligatures are undesirable in a text editor as a global option, since one usually wants to see clearly where character boundaries are. An additional reason is that it messes with column screen locations when fixed-width fonts are used.

So, if bug 3 is fixed by enabling ligatures, then this behavior should be decoupled, so that bug 3 is fixed even when ligatures are disabled.

In general, a text editor should have multiple levels of some options: global (meaning: by default), per-file (meaning, applies to this file only), and per-string (meaning, applies to a selected substring only). The more specific options override the more general. I would have thought this makes common sense. An example of such a three-level option is boldface. Others include font (actually typeface), ligatures, and color (the latter of course also interacting with syntax coloring). Such options relate to specific characters. Other, two-level options include whether newlines are CRLF or LF and file encoding.

And returning to bug 1, I consider it still unsolved, since you only allow changing a font (in this case to obtain the Devanagari glyphs) globally. So, to include IAST in a program source or plain text file, one would have to change the global font used for all files!

So, in summary: bug 1 unsolved, bug 2 unsolved, bug 3 unsolved. This Issue should remain Open.

I still don't know how to create a VSC fiddle for Chromium issues (I asked this above).

By the way, I love your intelligent replies to Issues. VSCode is lucky to have you here.

[alexdima]

The issue #11770 has never been closed, it is still open:

But there are a lot of linked issues that are closed, e.g. #45180 , #59843:

It is possible to upvote issues by going to the first comment and clicking on the plus-smiley icon in the top right corner:

---

Back on topic, our goal is to be a very good code editor and if it so happens to be a good text editor, then so be it. But we need to focus our time on providing a great coding experience, so our focus will always be to address real-life situations that occur when programming.

---

It is possible to configure VS Code to have different editor settings per language, e.g. settings.json:

"editor.fontFamily": "Consolas",
"editor.fontLigatures": false,
"[plaintext]": {
  "editor.fontFamily": "Arial",
  "editor.fontLigatures": true,
}

---

Having multiple fonts in a single file (with respective font settings like font ligatures) is a feature request. We currently don't support that, but that has been already asked at #30925 .

[mcswell]

@createdbyjurand: "our goal is to be a very good code editor and if it so happens to be a good text editor, then so be it." This is just an FYI: I'm sure I'm a tiny minority, but FWIW, I deal nearly every day with coding in multiple scripts, most recently Devanagari (for Hindi) and Arabic (for Urdu), along with Latin/ English. I do most of the coding in XML, which gets converted to sfst, xfst and lexc (finite state transducer programming languages), and I sometimes have to edit the latter when something goes wrong. Also mixed-script Python. While I could be a minority of 1, I suppose there might be other people in similar boats, who program NLP (Natural Language Processing) applications that involve multiple scripts.

[alexdima]

@mcswell I am sorry, maybe that came across the wrong way. We do want to include your use case, even if you are in the minority, and I think editing different scripts is a use-case we want to support!

I was just trying to say that IMHO our core competency is to be a code editor. That is where I think VS Code can offer the most value. That is why we wrote VS Code and that is probably why you installed it. There are many associated tasks that involve editing that are close to programming: editing binary data, viewing logs of 100GB, tailing output from a running process, etc. In other words, there are very many things people want to do in their code editor besides writing code.

But it might be that not all of those work great today. If you want to get them improved, the easiest way to make that happen is to implement it and submit a PR, since we are an open source project.

[mcswell]

No problem, I understand your constraints--I subscribed to this feed because of a different bug (https://github.com/microsoft/vscode-remote-release/issues/1087), and I've been astounded by how many bug reports you have to deal with. I just wanted to point out that the boundary between a code editor and a text editor is a fuzzy one.

As for implementing a fix myself, I've worked with a lot of programming languages in my life, but I do have limitations...

[David263]

Me, too. I've been a professional software engineer for 40 years (retired now), but I absolutely cannot understand the required Open Software Github documentation process in spite of having taken courses in it. Nor can I figure out how to do builds under Windows of products written for Linux. (This is a general comment, not specific to VSC.) I've tried to do a simple documentation-only fix for a product and then failed to be able to update the actual product in Github. Github is amazingly idiosyncratic and difficult for such simple functionality. Programming languages is the least of the problems, for me.