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

  Re: Re: JS script cleanup/formatting
  By: Tracker1 to Digital Man on 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.

We have a jslinter in Synchronet (exec/syncjslint.js) - it does not reformat anything.

 > >> 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?

You wouldn't use UTF-8 but rather the exact CP437 character value, e.g. in hexadecimal.

 > 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.

No, definitely do not do that.

 >   Does spidermonkey 1.8.5 support \u escapes?

Yes.

 > 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.

The "\u" escapes for UNICODE codepoints, not UTF-8 sequences or CP437.

 > 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.

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?

 > >> 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.

Okay.

 > >> 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?

Yes, it matters.
-- 
                                            digital man

Rush quote #74:
A modern-day warrior mean, mean stride, today's Tom Sawyer, mean, mean pride
Norco, CA WX: 66.0øF, 69.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs

---
 þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

.