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

Suggestion: #d, #t and #s #2

Open
Kynde opened this issue Dec 16, 2019 · 5 comments
Open

Suggestion: #d, #t and #s #2

Kynde opened this issue Dec 16, 2019 · 5 comments

Comments

@Kynde
Copy link

Kynde commented Dec 16, 2019

How about few more:

  • #d to def it to something suitable for easy access ?
  • #t to print it with some timing information ?
  • #s to spit it to /tmp ?
@weavejester
Copy link
Owner

I think #s is a little too specific, and while #d and #t both sound useful, I'd need to think about it.

Of course you're always welcome to use hashp as a base for writing your own; I wrote hashp because Spyscope wasn't quite what I wanted.

@Kynde
Copy link
Author

Kynde commented Dec 16, 2019

True, #s is also a little unnecessary if #d were available.

I like the no b.s. approach with this hashp. I just might investigate into adding them, but just in case some one with more free time available is anxious to add them here as PR or to another project, knowing how much I have free time at my disposal, I'd be cool with that, too.

@sparkofreason
Copy link

In a similar vein what if there were an option to send via tap>, with some known map format? Then the tap listener could do whatever, like spit to /tmp, stuff in an atom for later processing, etc. Don't think you could cover timing with that, though.

@sparkofreason
Copy link

Took a crack at generalizing this, see https://github.com/sparkofreason/hashtag. Feedback welcome and appreciated.

@sparkofreason
Copy link

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

No branches or pull requests

3 participants