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.
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.
| Sysop: | Karloch |
|---|---|
| Location: | Madrid, Spain |
| Users: | 54 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 128:42:41 |
| Calls: | 700 |
| Files: | 17,895 |
| D/L today: |
128 files (60,769K bytes) |
| Messages: | 66,010 |