• Re: JS script cleanup/formatting

    From Tracker1@TRN to Tracker1 on Thursday, November 05, 2020 10:59:29
    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.



    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Digital Man to Tracker1 on Thursday, November 05, 2020 16:32:04
    Re: Re: JS script cleanup/formatting
    By: Tracker1 to Tracker1 on Thu Nov 05 2020 10:59 am

    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?

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

    Sling Blade quote #4:
    Doyle: wimpy-ass kids or mental retards.. she got one of each livin' with her. Norco, CA WX: 66.0°F, 69.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
  • From Tracker1@TRN to Digital Man on Friday, November 06, 2020 12:51:10
    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
  • From Digital Man to Tracker1 on Friday, November 06, 2020 16:49:21
    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
  • From Tracker1@TRN to Digital Man on Saturday, November 07, 2020 09:44:32
    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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Digital Man to Tracker1 on Sunday, November 08, 2020 13:10:51
    Re: Re: JS script cleanup/formatting
    By: Tracker1 to Digital Man on Sat Nov 07 2020 09:44 am

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

    Yeah, that's not expected to work. Also, I don't recall there being any scripts in Synchronet which both print line drawing characters and support execution via jsexec (uifc scripts being the exception). Do you have a specific script in mind you're referring to?

    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.

    Not for Unicode characters. Synchronet assumes CP437 content by default. Other character sets (e.g. PETSCII, UNICODE) are the exception and require explicit translation steps or mode flags to be specified when using the Synchronet JS string/display methods.

    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?

    The second.

    Aside: if you want me to just go away, please say so.

    I'd prefer you stick around, but maybe go easy on the "suggestions".
    --
    digital man

    Synchronet/BBS Terminology Definition #29:
    FOSSIL = Fido/Opus/SEAdog Standard Interface Layer
    Norco, CA WX: 66.0°F, 69.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs