You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in exploring (and maybe coding/contributing) an addition that would allow individual source files to identify their own chain of interpreters (somewhat akin to the sha-bang line of shell scripts).
//!FILTER github.com/Osndok/golang-braces/cmd/go-fix-braces
//!FILTER github.com/DAddYE/igo/cmd/indention-instead-of-braces arg1 arg2
//!FILTER /usr/bin/cpp -Dkey=value - -
//!FILTER /usr/bin/sed -E 's/oneThing/another/g'
func main()
{
//the rest of the file is normal (with the above filter chain)
}
As seen in the first two lines, I was thinking that it would not be too hard to call "go build" if needed for the additional ease of go's fetch/build magic.
The idea being... if anyone:
is so terribly bothered by any particular/trivial golang design choice that it might exclude them, and
is a sufficiently advanced programmer to encode the minor difference in a filter
...then the community at large is probably better off having them "in" the golang corner.
What's more... when combined with github, it would provide an easy mechanism for the owners/moderators of golang to gauge what is important to the community (that which they invest time in, and are using) by scanning go repos for an easy-to-match string, and counting/sorting uniques.
There are a few major drawbacks, of course, the biggest of which is probably obvious:
//!FILTER rm -rf /some/important/file
...which could wreck havoc in build servers (don't build as root!).
Therefore, presuming this is not something that is desired in this (the upstream repo), I'd be quite content with this issue being closed for an answer to these questions (to whoever knows):
at a minimum, what points in the source would need the changes/additional code, and
if developed, what conditions (if any) might allow such a change in the official repo?
The text was updated successfully, but these errors were encountered:
Let's move this to the golang-nuts@ community mailing list where more people would see it. This isn't quite how we use the bug tracker for Go, since there's no bug to track.
I'm interested in exploring (and maybe coding/contributing) an addition that would allow individual source files to identify their own chain of interpreters (somewhat akin to the sha-bang line of shell scripts).
As seen in the first two lines, I was thinking that it would not be too hard to call "go build" if needed for the additional ease of go's fetch/build magic.
The idea being... if anyone:
...then the community at large is probably better off having them "in" the golang corner.
What's more... when combined with github, it would provide an easy mechanism for the owners/moderators of golang to gauge what is important to the community (that which they invest time in, and are using) by scanning go repos for an easy-to-match string, and counting/sorting uniques.
There are a few major drawbacks, of course, the biggest of which is probably obvious:
...which could wreck havoc in build servers (don't build as root!).
Therefore, presuming this is not something that is desired in this (the upstream repo), I'd be quite content with this issue being closed for an answer to these questions (to whoever knows):
The text was updated successfully, but these errors were encountered: