Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to specifiy a custom config #411

Closed
gene-pavlovsky opened this issue Mar 21, 2019 · 5 comments · Fixed by #412
Closed

Add option to specifiy a custom config #411

gene-pavlovsky opened this issue Mar 21, 2019 · 5 comments · Fixed by #412

Comments

@gene-pavlovsky
Copy link

gene-pavlovsky commented Mar 21, 2019

I'd like to have an option to manually tell the formatter which config file to use (overriding the default "closest parent directory" algorithm).

Use case:
I've implemented a Macro for FlashDevelop that adds automatic formatting when saving a file (similar to the VS Code integration's feature).
To retain Undo history (as VS Code does), I can't modify the file in place then tell FD, instead I have to create a temporary file with the same contents, run the formatter on that file, then load the contents and replace the editor's text itself with them - this retains the Undo. The limitation is that I have to create the temporary file in the same directory as the original file, to be sure it gets formatted with the current config. This is not very nice for multiple reasons (e.g. if something goes wrong and the file doesn't get deleted, it might accidentally be committed, also in same rare case it may crash FD), so I'd like to create the temporary file in a temp dir, determine which config is correct by performing the same "closest-parent" lookup as haxe-formatter does, and then tell haxe-formatter to format the temp file using that proper config.
If someone is interested, here it is (rename to HXFormat.cs):
HXFormat.txt

@Gama11
Copy link
Member

Gama11 commented Mar 21, 2019

I have an easy fix: use VSCode instead. :D

On a more serious note, it sounds like the ideal solution would be to have a flag that prints the formatted file to stdout, rather than replacing the file. Then you don't have to get the formatter's config semantics right.

@gene-pavlovsky
Copy link
Author

gene-pavlovsky commented Mar 21, 2019

I'll respond to your serious note first:
As a UNIX lover, I do agree that input from stdin and output to stdout is a very important feature to have. The code would have to be reviewed to make sure no other output is going to stdout (errors, stats report when formatting is done). In case of input from stdin the option to specify which config to use would be a MUST.

As for VSCode:
For the last couple of months, I am trying to give VS Code a chance when working on personal projects (not using the formatter in that case). I find it great in many respects. The thing that really suffers compared to FlashDevelop is code completion. The compiler completion works very well - when it works. But if I have any serious error (e.g. an extra or missing { somewhere) in my code when I start/restart VS Code, the language server doesn't work until I fix those error(s). This is a real downer... When I do some refactoring, I often break a lot of things all at once, and then I fix them up. I expect completion to continue working while I'm doing that, and with VS Code it's often not the case. The biggest problem is that it loses all completion for everything - won't even complete library code (which is valid and has no issues). FlashDevelop's built-in completion keeps working, and I personally consider it one of the strongest advantages FD still holds over VS Code. If that would be fixed, I'd probably fully switch to VS Code. Personally I think that compiler-provided completion should supplement, not attempt to replace, built-in IDE completion. Especially considering that if I heard correctly, the compiler developers have no plans to implement every possible completion/refactoring feature in the compiler - meaning that if VS Code is to provide those features in the future, it will have to do a lot of work to parse/understand the code, anyway.

@AlexHaxe
Copy link
Member

AlexHaxe commented Mar 21, 2019

I'm not sure how feasible it is to actually embed formatter in your macro, but with the recent API changes it would be possible to get a correct config file and use it on some code you have in memory or in a file somewhere else.
Theoretically it should be possible to compile formatter to C# and call API functions directly, but I haven't tried it and I don't use HaxeDevelop (mostly because Linux).

stdin / stdout is probably doable, but as you say there needs to be absolutely no other output (stderr should be fine). I am not sure stdin will fully work, since we need the full file before we can start parsing and formatting, so anything other than cat file.hx | formatter or echo "code" | formatter might pose a problem.

@Gama11
Copy link
Member

Gama11 commented Mar 21, 2019

One issue with compiling to C# is that you need to update each time the formatter updates, and then you probably always lag behind a bit.

@gene-pavlovsky
Copy link
Author

gene-pavlovsky commented Mar 21, 2019

Reading from stdin - if it's necessary to read the entire input until EOF, then format and emit it, then so be it, I don't think there's a need to do streaming-style formatting.

FYI: cat file.hx | formatter is useless, formatter <file.hx is always preferred (unless you give cat multiple files in which case it does something useful).

As @Gama11 mentioned - embedding the formatter in the C# macro would be not so feasible. I will setup the macro for every developer in our team who uses FlashDevelop - and do it only once, the hxformat.json config and haxe_libraries/formatter.json (we're using lix) are committed to source control, this will make sure that when there's an update, everyone will get the updated version of the formatter / config. Also, the macro is executed using CSScript, I have no idea how slow that is (could it possibly be faster than neko?)

AlexHaxe added a commit to AlexHaxe/haxe-formatter that referenced this issue Mar 21, 2019


added CLI option --stdin to switch to stdin/stdout mode, fixes HaxeCheckstyle#411
AlexHaxe added a commit that referenced this issue Mar 21, 2019
* fixed sameline of anon type with wrapping keep, fixes #301
* added CLI option --stdin to switch to stdin/stdout mode, fixes #411
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants