For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.

In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.

The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.

https://github.com/alexpovel/issuedigger

For a tool I’m writing, the tree-sitter query language is a core piece of the puzzle as well. Once you only have JSON of the concrete syntax trees, you’re back to implementing a query language yourself. Not that OP needs it, but ast-grep might?

     cat file.py | srgn --py def --py identifiers 'database' 'db'

An input like

    import database
    import pytest


    @pytest.fixture()
    def test_a(database):
        return database


    def test_b(database):
        return database


    database = "database"


    class database:
        pass

    import database
    import pytest


    @pytest.fixture()
    def test_a(db):
        return db


    def test_b(db):
        return db


    database = "database"


    class database:
        pass

Note: I just wrote this, and version 0.13.2 is required for the above to work.

[0]: https://github.com/alexpovel/srgn

It allows you to grep inside source code, but limit the search to e.g. “only docstrings inside class definitions”, among other things. That is, it allows nesting and is syntax aware. That example is for Python, but the tool speaks more languages (thanks to treesitter).

https://github.com/alexpovel/srgn/blob/main/README.md#multip...

Think of srgn as a blend of rip-grep, tree-sitter and GNU `tr`/`sed`. At its core, it most closely resembles `tr`, but expands on it in two important ways.

First, srgn provides scoping, used to specify what part of an input to work on. This can be literal text, regular expressions, or tree-sitter queries. The latter is the most interesting one. As tree-sitter queries can be tough to construct (although the tool is excellent, with an online playground for testing and more), srgn has pre-defined queries and makes an effort to unify these across languages. For example, across TypeScript, C#, Go, Rust and Python, you can specify to scope all "comments", and it (hopefully) just works as expected, despite these languages having different ideas of how comments work and look like (C# has multi-line and inline, for example, while Python only has a single type, all of which is also reflected in what tree-sitter calls those corresponding nodes).

Secondly, there's actions, which simply perform text manipulation on whatever is in scope from the previous step. One could delete certain parts of all comments, for example, or rewrite all import statements across an entire code base (https://github.com/alexpovel/srgn#mass-import-module-renamin...).

I had looked around a bunch for similar tools (https://github.com/alexpovel/srgn#similar-tools), but couldn't find any that quite did what srgn does.

The CLI is a rather thin wrapper around the Rust library, which is usable in the usual way.

By the way, the name srgn stands for surgeon, in the sense of a code surgeon: precise manipulation of text. Regular expressions and tree-sitter queries can be combined, which turns out to be much more powerful than either of these by itself, and also fills a different niche than LSP-powered Rename all-like features. It can also be used in CI, as a simple custom linter ("fail if you find any 'TODO' strings in comments").

A lot of the use cases can be covered by just regex, and then fixing mistakes manually; srgn mainly inches the precision of these operations closer to 100%, for when it's needed (like large refactors, where srgn offers full parallelization as well).

Comments URL: https://news.ycombinator.com/item?id=39160149

Points: 2

# Comments: 1

Caught me.

> And how is it less tedious to have to select previously typed text all the time?

This is tedious, but I have that automated (AutoHotKey). So a single, AHK-managed hotkey does the equivalent of:

    CTRL + SHIFT + HOME
    CTRL + C
    feed into tool, paste back
    CTRL + V

[0]: https://github.com/alexpovel/srgn/blob/0008cce1c71f0d83f6a31...

It grew out of a niche, almost historical need: using a QWERTY keyboard, but needing access to German Umlauts (ä, ö, ü, as well as ß). Switching keyboard layouts is possible but exhausting (it's much more pleasant sticking to one); using modifier keys is similarly tedious, and custom setups break and aren't portable.

So this tool can do:

    $ echo 'Gruess Gott, Poeten und Abenteuergruetze!' | srgn --german
    Grüß Gott, Poeten und Abenteuergrütze!

A niche need I haven't yet come across someone else having as well! (just the amount of text explaining what it's all about is saying a lot in terms of specificity...)

The tool now grew into a tree-sitter based (== language grammar-aware) text manipulation thing, mostly for fun. The bizarre German core is still there however.

[0]: https://github.com/alexpovel/betterletter/blob/c19245bf90589...

Thank you for the feedback! That sounds good, I'll add that.

I've spent a lot of time trying to find similar tools, and even list them in the README, but `AST-grep` did not come up! I was a bit confused, as I was sure such a thing must exist already. AST-grep looks much more capable and dynamic, great work, especially around the variable syntax.

Idea: renders your resume as pretty terminal output. Others can view it in their own terminals:

    curl -L ancv.io/heyho

I provide a GCP-hosted server that works off GitHub gists (where your resume can live in JSONResume form). However, self-hosting is a first-class citizen and easy to use as well.

Comments URL: https://news.ycombinator.com/item?id=33684987

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=32801769

Points: 3

# Comments: 0

Yeah, I had looked into these but for some reason that didn't work. Don't remember why.

> Looking through the repo I wondered why you would commit the complete German dictionary weighing in at over 30 MB, whereas you only need a small fraction, the words containing the umlauts (or their false matches). Surely this would be a huge performance boost?

Yes! It would be performance boost. In fact, I had a "caching" sort of functionality in the tool before. The whole dictionary is shipped (because that makes it much easier and there's almost no risk of wrong-doing just copy-pasting a word list, plus it compresses well enough), but then a list containing only special characters will be generated on first use if it doesn't exist yet.

As you noted, a lot of words do contain special letters, so the "complexity" wasn't worth it to me and I removed that. Could be brought back anytime, but it's fine for now.

    ` [ ] \ / { }

Anyway, both Linux and Windows offer fast switching between installed keyboard layouts/languages using SUPER+SPACE. This is needed in e.g. emails, where I still need Umlauts. It's just much easier to read that way. However, switching back and forth constantly is completely overwhelming and not viable. However, in German, there are perfectly and officially (?) acceptable alternative spellings for our special "Unicode"-characters. They can be typed using plain ASCII, aka a QWERTY keyboard.

So, I wrote a script to read in any text, combined it with AutoHotkey on Windows and now have a tool that, at the touch of a button, replaces selected text using alternative spellings (gruen, Duebel, Faehre) with their correct versions (grün, Dübel, Fähre). The tool could be extended for other languages rather easily. I've been using it for over a year now and recently got to release it properly on the cheese shop:

    pip install betterletter

Before putting this together, I had looked around for an existing tool. To my surprise (there's always something!), I found nothing. I guess this scratches a too specific itch: using QWERTY but wanting proper spelling quickly, while remaining on QWERTY as to not have a mental breakdown and stay at full typing speed.

After writing, select everything (CTRL+SHIFT+HOME works well), hit shortcut, text will be replaced. This takes about 2 seconds, much faster than switching keyboard layouts back and forth. If this ran as a daemon with the dictionary loaded into RAM already, the script could run almost instantaneously (most of the 2 seconds is IO, reading from disk), in linear time according to the text input size.

That is only because their templates are years behind the curve and they are slow to update. It is not an argument for the advantages of pdftex, aside from its stability, gained over many decades.

LuaTeX has been nothing but stable for me, so from a technical standpoint, there is no reason not to switch.

As far as scientific papers go, the publishers and editors probably value stability and backward-compatibility (I would).

This is simply an artefact of times past and has no technical relevance nowadays. LuaTeX allows dynamic allocation, with the available system RAM as the upper limit (so effectively, no limitations in everyday usage).

Now, I could not find a mention of memory handling in the XeTeX reference manual [4]. People are using tricks like `tikzexternalize` with xelatex [5, 6]. Especially the first point makes me think XeLaTeX inherits base TeX memory handling/limits, but I cannot confirm this.

I just know that all my problems disappeared when switching from XeLaTeX to LuaLaTeX.

Lastly, see here [7] for a comprehensive (albeit somewhat anecdotal) list of advantages of LuaTeX over XeTeX. Of that list, `microtype` is another significant functionality I rely on.

[0]: http://www.tug.org/texlive//devsrc/Master/texmf-dist/doc/con...

[1]: https://tex.stackexchange.com/q/7953/

[2]: https://tex.stackexchange.com/search?q=tex+capacity+exceeded

[3]: https://tex.stackexchange.com/a/482560/

[4]: http://mirrors.ctan.org/info/xetexref/xetex-reference.pdf

[5]: https://tex.stackexchange.com/q/438131/

[6]: https://tex.stackexchange.com/q/334250/

[7]: https://tex.stackexchange.com/q/126206/