6 ms·
>* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before acce
by Sir_Cmpwn 8y ago
>* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
We use pygments, so patches to pygments would make it to sr.ht's syntax highlighting.
>* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
Planned. Also planned to let you sync between both.
>* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
Eventually users will be able to add custom base images, which will permit the use of Windows (if you can get an sshd running there, at least). As for multi-arch, experimental support for aarch64 is there, and by the end of the year I expect to have RISC-V builds backed by HiFive hardware.
- greglindahl 8y ago> We use pygments, so patches to pygments would make it to sr.ht's syntax highlighting. I really appreciate this response! That encourages improvements that benefit everyone, not just sr.ht users.
- jancsika 8y ago> Eventually users will be able to add custom base images, which will permit the use of Windows (if you can get an sshd running there, at least). msys2 has an sshd. I use it on a Windows VM runner with Gitlab CI. It's not easy to set up but it can be done.
- mikepurvis 8y agoNonetheless, it'd be nice to have some way of plugging in more of this kind of functionality at the instance, user, and possibly repo levels. Obviously syntax highlighting is one use case, but some others: - Sophisticated cross-referencing tools like Kythe and SourceGraph - Linking stdlib functions and imports to public documentation, like cppreference.com, python.org, etc. - Linking ticket/user names to my non-srht bug tracking tool (especially JIRA, but there are lots of possibilities). - Linking to public or self-hosted generated API docs (doxygen, swagger, sphinx, etc). - Linking to info pages generated from metadata-type files such a PKG-INFO (for example containing dependency tree information). - Propagating back information gathered from build or test runs, for example highlighting areas missing test coverage, or which are "hot" from a perf point of view. Only some of these would be appropriate to go into the mainline version of the tool, which is why it's important to support plugging in these capabilities for the users which need/want them.
- Sir_Cmpwn 8y agoI think a lot of what you're looking for is going to be possible through generic interfaces I plan on writing. It's not going to take the shape of "you can write code which executes on sr.ht's servers just for your repo in particular", but rather things like "you can POST to an API endpoint on git.sr.ht to annotate the sources in your tree for a specific commit sha with links to pydoc et al". builds.sr.ht would then be the place where you could run arbitrary code to automate this.
- sqs 8y agoSourcegraph CEO here. We would love to help integrate Sourcegraph into sr.ht for code intelligence (hovers, go-to-definition, etc.). We’re kicking this off with GitLab next month.
- Sir_Cmpwn 8y agoGreat! My email is sir@cmpwn.com. I can't guarantee a lot of cycles right now, but get in touch and I'll keep it on my radar.