Any thoughts on cleaning up the JS files and running through a linter/formatter for a consistent formatting?
1. There are some .js files that have hard coded CP437 characters in
them, these should be changed to use at least escape codes instead of
the characters directly (octal or hex). By doing this, the files should
be able to be read with UTF8 editors without issue.
2. Would be nice to agree upon a standard format and linting for formatting... most likely eslint with either prettier, standard, airbnb, and/or other format options. I would suggest 2 spaces for indentation,
as this is what the broader JS community has adopted in most libraries.
3. Would be a followup to address linting issues that don't meet auto-formatting.
On 10/29/2020 8:45 PM, Tracker1 wrote:
Any thoughts on cleaning up the JS files and running through a linter/formatter for a consistent formatting?
1. There are some .js files that have hard coded CP437 characters in
them, these should be changed to use at least escape codes instead of
the characters directly (octal or hex). By doing this, the files should be able to be read with UTF8 editors without issue.
2. Would be nice to agree upon a standard format and linting for formatting... most likely eslint with either prettier, standard, airbnb, and/or other format options. I would suggest 2 spaces for indentation,
as this is what the broader JS community has adopted in most libraries.
3. Would be a followup to address linting issues that don't meet auto-formatting.
Any thoughts on cleaning up the JS files and running through a
linter/formatter for a consistent formatting?
linting and formatting are 2 very different things.
1. There are some .js files that have hard coded CP437 characters in
them, these should be changed to use at least escape codes instead of
the characters directly (octal or hex). By doing this, the files should
be able to be read with UTF8 editors without issue.
Definitely not octal. I don't doubt this, but can you cite specific examples? Feel free to submit a merge request which addresses this (one specific thing).
2. Would be nice to agree upon a standard format and linting for
formatting... most likely eslint with either prettier, standard, airbnb,
and/or other format options. I would suggest 2 spaces for indentation,
as this is what the broader JS community has adopted in most libraries.
Defintely not 2 spaces. I don't care what "the broader JS community" has adopted. I prefer to keep the style similar to the prevailing C/C++ style
in sbbs that that is very unlikely to align with "the broader JS community".
3. Would be a followup to address linting issues that don't meet
auto-formatting.
White space changes should not affect linting.
On 11/5/2020 5:32 PM, Digital Man wrote:
Any thoughts on cleaning up the JS files and running through a
linter/formatter for a consistent formatting?
linting and formatting are 2 very different things.
Most JS linters I am aware of also do formatting rules as well as
integrate an auto-formatter.
1. There are some .js files that have hard coded CP437 characters in
them, these should be changed to use at least escape codes instead of
the characters directly (octal or hex). By doing this, the files should >> be able to be read with UTF8 editors without issue.
Definitely not octal. I don't doubt this, but can you cite specific examples? Feel free to submit a merge request which addresses this (one specific thing).
Was going to do this... how does JS handle CP437 output for UTF8
character sets for CP437/drawing characters?
Thinking of just writing a script that loads all the .js files and for
any character < 32 or > 127 it assumes CP437 and escapes either the character as-is or converts to UTF8 value(s) and escapes that sequence.
Does spidermonkey 1.8.5 support \u escapes?
Running writeln("\uD83D\uDE00"); from jsexec.exe seems to output "="
in Windows Terminal ... so it looks like unicode escapes are handled,
and that it does some CP437 translation/mapping (character seems roughly equivolent to the "unknown" character .. which is what I saw from UTF8>nntp>qwk>vert>qwk>nntp for a message.
Okay, ran the following as a test, and definitely didn't go as
expected... first are the upper left corner line drawing characters,
second is the upper-right.
writeln("\u250C\u250D\u250E\u250F");
writeln("\u2510\u2511\u2512\u2513");
Also garbled... So probably best to do the CP437 escapes for the
characters, but not try to map to utf values... but should put a note to maybe add character translation for unicode/ucs16/utf8 to CP437 output,
or as-is for unicode terminals.
2. Would be nice to agree upon a standard format and linting for
formatting... most likely eslint with either prettier, standard, airbnb, >> and/or other format options. I would suggest 2 spaces for indentation, >> as this is what the broader JS community has adopted in most libraries.
Defintely not 2 spaces. I don't care what "the broader JS community" has adopted. I prefer to keep the style similar to the prevailing C/C++ style in sbbs that that is very unlikely to align with "the broader JS community".
tabs it is then... would still suggest eslint or prettier for formatting configured as desired for tabs and strings.
3. Would be a followup to address linting issues that don't meet
auto-formatting.
White space changes should not affect linting.
Would you be willing to create an eslint config file that matches your rules? Also, if an auto-format is available, does it really matter?
writeln("\u250C\u250D\u250E\u250F");
writeln("\u2510\u2511\u2512\u2513");
Also garbled... So probably best to do the CP437 escapes for the
characters, but not try to map to utf values... but should put a note to
maybe add character translation for unicode/ucs16/utf8 to CP437 output,
or as-is for unicode terminals.
There's no such thing as "CP437 escape", so I'm not really sure what
you're saying. Have you actually looked at existing Synchronet .js
modules to see how extended ASCII chars are sent?
tabs it is then... would still suggest eslint or prettier for formatting
configured as desired for tabs and strings.
Okay.
Would you be willing to create an eslint config file that matches your
rules? Also, if an auto-format is available, does it really matter?
Yes, it matters.
On 11/6/2020 5:49 PM, Digital Man wrote:
writeln("\u250C\u250D\u250E\u250F");
writeln("\u2510\u2511\u2512\u2513");
Also garbled... So probably best to do the CP437 escapes for the
characters, but not try to map to utf values... but should put a note to >> maybe add character translation for unicode/ucs16/utf8 to CP437 output, >> or as-is for unicode terminals.
There's no such thing as "CP437 escape", so I'm not really sure what you're saying. Have you actually looked at existing Synchronet .js
modules to see how extended ASCII chars are sent?
s/escape/translation/
I'm saying my expectation for the above code would be to see the line drawing characters with jsexec in a utf-8 terminal...
I would expect to
similarly see line drawing characters in a utf-8 connected client if console.writeln was used. I might expect to see CP437 line characters
in a terminal that wasn't utf-8.
tabs it is then... would still suggest eslint or prettier for formatting >> configured as desired for tabs and strings.
Okay.
Would you be willing to create an eslint config file that matches your
rules? Also, if an auto-format is available, does it really matter?
Yes, it matters.
Was the "yes" part to the first question, or the second, or both?
Aside: if you want me to just go away, please say so.
| Sysop: | Ree |
|---|---|
| Location: | Toronto, ON |
| Users: | 2 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 107:33:41 |
| Calls: | 374 |
| Calls today: | 1 |
| Files: | 2 |
| Messages: | 38,873 |