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
txtar archives frequently form the basis of issue reports, which means they get copy/pasted to GitHub issues and the like. This causes tab characters to be converted to spaces (there may be other lossy conversions).
I've just come across a case where I need a file in a txtar archive input to testscript, shared via a GitHub issue, to include tab characters. i.e. the rewrite to space is not acceptable, because the tab characters form the basis of the issue. Very niche and quite possibly a solid edge case, but I'm raising this for discussion to see whether there would be wider benefit to the following approach.
What I'm thinking is that it would be useful to have a fprintf builtin command (someone please save me on the naming front) which takes a number of file names, reads each in turn, interprets the contents of a file as an interpreted string literal, then writes the result back to a file.
This would therefore allow:
fprintf main.go
go run main.go
-- main.go --
package main
func main() {
\tprintln("Hello\\tworld")
}
Thoughts?
The text was updated successfully, but these errors were encountered:
This raises the somewhat interesting question of what changes (if any) would be made to txtar-c: how would the user of that command indicate that a particular file (or files) should be written to the resulting txtar as an interpreted string literal? Perhaps, given this workflow would be rare, it would be acceptable to accept a flag which can be repeated, a flag that specifies a glob of files that should be encoded in this way?
@rogpeppe has kindly pointed out a flaw in my testing. In that testing, it appeared to me that GitHub did not preserve tabs in code snippets. However, that is not the case, i.e. it does preserve them. What is breaking things in my setup is that xterm's insert-selection writes tabs as spaces. Within Vim, a paste from the clipboard works as expected.
So whilst the GitHub use case is perhaps no longer an issue, I suspect it would probably be a "safe" idea to have something like this feature, in case someone is pasting from somewhere other than GitHub, or their local setup also writes tabs as spaces etc. It helps to remove variables from the equation.
txtar
archives frequently form the basis of issue reports, which means they get copy/pasted to GitHub issues and the like. This causes tab characters to be converted to spaces (there may be other lossy conversions).I've just come across a case where I need a file in a
txtar
archive input totestscript
, shared via a GitHub issue, to include tab characters. i.e. the rewrite to space is not acceptable, because the tab characters form the basis of the issue. Very niche and quite possibly a solid edge case, but I'm raising this for discussion to see whether there would be wider benefit to the following approach.What I'm thinking is that it would be useful to have a
fprintf
builtin command (someone please save me on the naming front) which takes a number of file names, reads each in turn, interprets the contents of a file as an interpreted string literal, then writes the result back to a file.This would therefore allow:
Thoughts?
The text was updated successfully, but these errors were encountered: