Talk:Lint
Latest comment: 9 August by Lahwaacz in topic Rename this page to "List of …"
Suggest alternative package mangers for linters
(This is also relevant for LSP page).
I see a lot of empty "package" entries here and also many AUR packages which among the other things are sometimes unmaintained. There are many good package managers that specifically focus on developer tools and there is a big chance that one might find the needed Linter/LangServer there, if it's not present in the official repos / AUR.
I don't know if it's OK to do such recommendations on Arch Wiki (i'm pretty new here), but if it's ok i would go ahead and add something similar to what i have written in Formatter page. What do ya think? Pigeon (talk) 22:17, 2 February 2026 (UTC)
- It's fine, but I would skip the last part with Nix and mise. IMO if people already use these, they will get the message from the preceding part, but otherwise it is not a good place to start looking for a linter package. — Lahwaacz (talk) 12:40, 7 February 2026 (UTC)
- This situation sounds like a good case for creating a place to list all package managers beyond pacman available for Arch Linux. Then we could link to that, where appropriate. At this point, we have Linuxbrew, Flatpak, Snap, Guix, Nix, Mise, pkgx, PkgForge's soar. I cannot speak for all of them, but Nix, for instance, certainly has packages of a great quality.
- Though all PMs of those i mentioned specialize on a slightly different goals. Maybe it deserves a sub-categorized section in e.g. List of applications?
- I've recently created a section List_of_applications/Utilities#Language runtime version management, but covers a different niche. For example, Flatpak, Brew and others will certainly not fit such purpose. I don't know how these 2 purposes could be combined together.
- Also there is a division (with both package management for General-purpose applications and Language runtimes) for language-specific and language-agnostic tools. I am pretty sure that listing language-specific tools like NPM package manager and NVM version manager is beyond the scope of such list.
- So the question is:
- is it a reasonable idea in the first place?
- where to put that? Somewhere in the List of applications?
- how to avoid duplication with sections like List_of_applications/Utilities#Language_runtime_version_management that serve similar purpose but cannot replace one another?
- should we also create subsections to list language-specific package mangers like uv, npm, ...
- Pigeon (talk) 17:42, 10 March 2026 (UTC)
Rename this page to "List of …"
I'm not sure if it is a proposal or clarification questions:)
- Why do we have Lint and Formatter instead of "List of linters" (
or "List of linting tools"?(edit: there is List of applications/Utilities#Linters, so "List of linters" sounds good for me) and"List of formatters" ("…formatting tools"?)(edit: we have List of applications/Utilities#Code formatters so "List of code formatters" is my current choice) ? - Why these two pages formatted as tables instead of just lists like List of programming languages?
- Do we really need three separate pages—List of programming languages, Lint, Formatter? What about combining all information from them into List of programming languages?
- I also don't like constructions like "Link_A, Link_B, Link_C, Link_D" — "Package_A, Package_B, Package_C, Package_D" (see e.g. JavaScript in Lint and Clojure in Formatter. I would prefer list of "Link_X — Package_X" instead.
— Andrei Korshikov (talk) 01:20, 24 March 2026 (UTC)
- Forgot to mention LSP—"List of language servers" and DAP—"List of debuggers". — Andrei Korshikov (talk) 01:28, 24 March 2026 (UTC)
- I think it's fine if we just add these pages to Category:Lists_of_software. It's not like we should rename every list page to List of ... — Lahwaacz (talk) 09:21, 26 April 2026 (UTC)
- If I understand you correctly, your suggested layout looks as follows:
- Programming Lang 1 — compiler package1, package2
- linters
- package1
- package2
- formatters
- package1
- ...
- LSPs
- ...
- DAP
- ...
- linters
- Programming Lang 2 — compiler package1, package2
- ...
- Programming Lang 1 — compiler package1, package2
- One of the problems I see here is that the ratio of relevance for most of the people would be something like
- (1. linter ≈ 2. formatter) > 3. LSP >> 4. DAP
- So while 3. and 4. fit naturally here, they will create more noise on the page than give value for many people that have no use for these.
- (But to be fair, there are less LSP and DAP software for almost any given language than linters with formatters, so it's not that bad.)
- The other problem that will be present if we reformat the currently table-form pages into lists (and especially if we then combine them into one huge list as from above) is how much size it takes. Currently, the Python row on the LSP page is 2.5cm in height with my current font size. If we convert that to a list, that would be 5cm+.
- So then that's basically a question of "easy to find software for one specific language" vs "easy to (quickly) scan the whole page". CPP (talk) 07:26, 18 July 2026 (UTC)
- After thinking about that for a second I've come up with a bigger question:
- If we have a list with a structure as was described (1. language, 2. linters, 3. formatters, 4. LSPs, 5. DAP) why then we don't also have a sublist for (standalone) Debuggers for these languages? But then also version managers (like pyenv/rbenv) worth a mention; and then available build systems for that language. And so on and so on.
- So how i could see this be better organized is:
- 1. Every AW page for a programming language will have a section called something like "Developer tools" like Haskell#Development_tools. Currently some pages have such sections and we have duplication and partial overlaps with Lint, LSP, etc. and software in such sections.
- 2. If there's an AW page for the language and we've created the aforementioned section, we move all software for that language from LSP, Lint, etc. into that section.
- 3. Once only the languages that don't have a dedicated AW page left, we combine the aforementioned lists of linters, formatters, debuggers into the "single page for all languages" structure:
- It's like as if we were to create a separate page for every language on the list with just "Development tools" section, but that wouldn't be enough for a separate page. So when that's the case, we add it to such common list. Once someone creates a detailed page with installation instructions, etc. they would just move the lists of software for that language to the newly created page under "Development tools" subsection and add link to that language's page on List of programming languages.
- CPP (talk) 07:42, 18 July 2026 (UTC)
- What about formatters, linters and LSPs for languages that are not programming languages? E.g. CSS, HTML, JSON, YAML, etc. — Lahwaacz (talk) 16:12, 9 August 2026 (UTC)