Closed JdeH closed 7 years ago
i like the idea to customize js output to personal prefs - but I would not add yet another CLI switch but rather a config dir pointing to my personal .config/transcrypt.py or .ini and where I can declare all such customizations, there will be more in the future than 'just' the space, I could think of (with 5 seconds thinkgin):
(....)
more to follow. Trying to say: Lots of reasons for personal config file ;-)
btw: I rarely use the closure compiler on the hosts I deploy transcrypt to. Its on many hosts now (around 30) and only on my local laptop I have it. Because compared to the static off the shelf js libs which are minified anyway and I never look into them the cleartext transcrypt file size does not matter at all (or do I overlook a benefit here) - but throwing a full jdk on the nodes "just" for this is not worth it.
The config file is a good idea, will put it in the queue as an enhancement. No harm in adding the CLI switch as well, I think.
sure, your decision. but don't overdo it, like they:
1.siptrunk_axc.DEV.NB01:/# uwsgi --help |grep '--' | wc -l 889
with nearly 900 options on the cli it makes things a little bit hard to handle (where are the 1% important ones which 95% nead all the time versus all the rest). A good thing with many options on the cli is to give up on single letter switches but put into functional groups which one can grep at, like transcrypt -h | grep fmt. Well you know that stuff, why do I say that, sorry, little boss syndrom, too many juniors around me recently :-)
The nice thing about command line switches is that you can use them ad-hoc rather than editing a file, and you can switch between multiple alternatives within one 'batch'.
But indeed it shouldn't be overdone. Config files are much more readable (but I sometimes have a hard time finding them, especially if there's a hierarchy of them, one overriding the other). Have to think a bit more about this one.
Main thing for now is that the 'mainstream formatting' gets in. Many people are very attached to it.
got it, you know the prios better.
still: think twice, at least about the single letter, (Transcrypt's entering into phase2): A cli switch is here to stay, you may never change later, it will cause a lot of hate when builds break due to version updates. speaking of my own crimes here (contradicting what I said yesterday "maybe ditch the time module" ...). Ups, I did it again.
Config files are much more readable (but I sometimes have a hard time finding them, especially if there's a hierarchy of them, one overriding the other).
let me guess: ipython incl. the notebook ;-)
Unfortunately the notebook is still a closed book for me...
But many tools work in this way. And then the joke about CSS applies:
Two stylesheets walk into a bar. In a totally different bar a glass of beer falls over...
Indeed, Transcrypt is entering phase 2. I spend quite some time contemplating the consequences. The IT world is changing too fast to only focus upon compatibility. A code formatting switch won't break anything. Things like -i c.q. --iconv etc. are at a different level of holyness, they should preferably be left alone.
Since the alphabet has only 26 chars, for less important features or groups of features the CLI resorts to letter combinations. E.g. all debugging switches currently start with d. And probably all layout options will start with an l. That would break the --license switch, but I bet users aren't too interested in that. Furthermore the letter x will be reserved, meaning extended, and so recursively. So -x<anything>
will open a whole new alphabet, not to speak of '-xx
hehe, the recursive extension switch is neat. and the css joke... scoped css does help a bit, though.
Thought a lot about config machineries in my life but that Idea with the recursive x unfortunately bypassed my brain, on its way to the Netherlands. I invested recently a lot of time to make a really good tab completer for long cli options, directly from source code statements, also nested and where you always in the completion process can hit TAB twice and get help from the docstrings - and also it detects options in function signatures so that it can auto complete values as well. But thats no option here since it depends on bash and transcrypt must run in windows as well.
Oh and the notebook should be ONE of the server sided components to be able to sync with transcypt components. They released this widgets, which users can extend, based on very very awkward js to write. Absolutely full match for Transcrypt, believe me. And its a lot used in a community which you personally also seem to have a lot of stakes in still (I left it long ago getting my physics degree, sad sad)
O well, once again I get pressed with my nose upon the fact that I really, really should dive into the IPython notebook. Indeed, I still have stakes in the physics world, due to the cardiology research I am involved in. We're also looking for a way to make the results of non-invasive diagnostics available over the Internet. I am almost certain Transcrypt will play a role there, it's one of my private reasons to embark on it.
This issue is postponed since Google Closure currently can't prettify without leaving out the comments, thus making the code less readable... Have posted a feature request. Can't use just any prettyfier, because of the sourcemaps.
Add a compiler switch to generate e.g.
aFunction( param1, param2 )
rather than
aFunction (param1, param2)
since it will enhance readability of the generated JS to many used to such formatting. The actual formatting job can be delegated to the Closure compiler.