Subj : Re: JS script cleanup/formatting
To   : Digital Man
From : Tracker1
Date : Fri Nov 06 2020 12:51 pm

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?

-- 
Michael J. Ryan
tracker1 +o Roughneck BBS
---
 þ Synchronet þ Roughneck BBS - roughneckbbs.com

.