|
I do use suckless terminal though, it’s good and I build it via nix with my config patched in
|
#
?
Apr 2, 2024 13:51
|
|
|
|
| # ? Jun 3, 2024 22:21 |
|
|
tbh the moment you step away from human-editable (and this to some extent goes for assuming tool support to do xml) just do sqlite for everything.
|
|
#
?
Apr 2, 2024 14:10
|
|
|
plists aren't xml. there's an xml serialization of plists but that's not the native format and the xml serialization is very weird
|
|
#
?
Apr 2, 2024 16:17
|
|
|
leper khan posted:
i've only seen this once in the wild at a former employer: the perforce vs plugin used to(?) have a dialog box for some thing or another that would trigger quasi-randomly including while you were in the middle of editing code. the default selected option in that box was to just clobber your local changes and replace them with a fresh copy from the repo. predictably, this design choice was rather unpopular with devs, to the point that someone just straight up hex-edited the dll to flip the buttons around and started distributing it internally so basically what i'm saying is this is the correct answer to the issue of config formats
|
|
#
?
Apr 2, 2024 17:01
|
|
if they care enough they can binary patch it. no need for recompiling, providing source, or using the registry.
|
Plorkyeran posted:plists aren't xml. there's an xml serialization of plists but that's not the native format and the xml serialization is very weird right. ascii with undocumented pbxproj extensions ftw
|
|
#
?
Apr 2, 2024 18:23
|
|
|
Xml is s-expressions Enterprise Edition
|
|
#
?
Apr 2, 2024 19:50
|
|
|
Can someone sell me on LSP? Because I feel like I don't entirely get the point. Maybe that's a bad way of phrasing it, but people seem to make a huge deal out of LSP these days, e.g., languages and/or tools (editors, IDEs, REPLs, etc.) having or not having LSP support, or even more on the extreme (to me) end, refusing to use languages without LSP and I don't get it.
|
|
#
?
Apr 3, 2024 00:11
|
|
|
what if we could write one plugin per language instead of one plugin per editor per language
|
|
#
?
Apr 3, 2024 00:15
|
|
|
i like kotlin enough that i deal with it not having a maintained LSP (last i checked) because the kotlin company is also the intellij company and that's a pretty drat good IDE i'm happy enough to use, but if your language is not also made by a company that makes a top-tier IDE, it probably should have an LSP so people can use it with w/e
|
|
#
?
Apr 3, 2024 00:18
|
|
|
also everyones in one of three buckets 1) only uses vscode, which supports 2) uses some editor like vim or emacs which both support LSP because no one wants to write a vim or emacs plugin for a language anymore 3) is using some integrated language-and-IDE like visual studio/.net, xcode/swift, or kotlin/intellij, and thus the point is moot i think a big thing is that if your "language support" in an editor is just syntax highlighting then lmao you need to be using a different language, and one plugins get more complicated than syntax highlighting it becomes hard to maintain them across multiple editors
|
|
#
?
Apr 3, 2024 00:24
|
|
|
pokeyman posted:what if we could write one plugin per language instead of one plugin per editor per language and what if the developers of the language could provide that LSP plugin instead of fifteen different hobby users creating bespoke parsers everywhere. not that this currently happens - but I think it’s the ideal of LSP. And since it’s a “server protocol” languages could even ship their LSP with the language and editors can then “just use it”
|
|
#
?
Apr 3, 2024 02:24
|
|
|
necrotic posted:and what if the developers of the language could provide that LSP plugin instead of fifteen different hobby users creating bespoke parsers everywhere.
|
|
#
?
Apr 3, 2024 02:38
|
|
|
Ralith posted:this does happen sometimes, e.g. rust-analyzer coordinates closely/is distributed with rustc yeah, fair. I should have said “frequently happens”. overall LSP is relatively new, and so many languages already have bespoke support in many editors. I think we’ll be seeing more and more LSP over the years, and hopefully more from the actual language (or closely supported by, like rust-analyzer).
|
|
#
?
Apr 3, 2024 03:20
|
|
|
it’s been a while since I posted here but the feature I designed, prototyped, and wrote tests for has finally matured and will be in the next major erlang version. first version was drafted in 2018, prototypes were done 3+ years ago, and it matured for a couple years but it’ll be in for good.
|
|
#
?
Apr 3, 2024 03:58
|
|
|
As an emacs guy LSPs have been a revelation after what felt like years of stagnation
|
|
#
?
Apr 3, 2024 04:11
|
|
|
MononcQc posted:it’s been a while since I posted here but the feature I designed, prototyped, and wrote tests for has finally matured and will be in the next major erlang version. badass, congrats
|
|
#
?
Apr 3, 2024 04:33
|
|
|
MononcQc posted:it’s been a while since I posted here but the feature I designed, prototyped, and wrote tests for has finally matured and will be in the next major erlang version. 
|
|
#
?
Apr 3, 2024 05:21
|
|
|
necrotic posted:and what if the developers of the language could provide that LSP plugin instead of fifteen different hobby users creating bespoke parsers everywhere. isn’t thus exactly why Microsoft created LSP for TypeScript? like the language + IDE vendor actually does provide the LSP support, because LSP is how they provide the TypeScript language support to VS Code
|
|
#
?
Apr 3, 2024 12:08
|
|
|
Fortaleza posted:As an emacs guy LSPs have been a revelation after what felt like years of stagnation the thing is, emacs could have had this, but Stellman was paranoid about possibly making something that helped “proprietary software” too that and he had little exposure to decent implementations of emacs before he scrawled his name on and bolted a lovely lisp to gosmacs; all the real “fancy code editor” action was all happening in Zmacs on TI and Symbolics, and in InterLISP-D and Smalltalk on Xerox, all of which were p-p-p-proprietary!
|
|
#
?
Apr 3, 2024 12:16
|
|
|
eschaton posted:the thing is, emacs could have had this, but Stellman was paranoid about possibly making something that helped “proprietary software” too most advances in IDE features were in proprietary s/w back in the day ergo IDE features are inherently suspect
|
|
#
?
Apr 3, 2024 14:03
|
|
|
prisoner of waffles posted:most advances in IDE features were in proprietary s/w back in the day huh, just learned that VS Code is MIT licensed
|
|
#
?
Apr 3, 2024 14:39
|
|
|
leper khan posted:huh, just learned that VS Code is MIT licensed
|
|
#
?
Apr 3, 2024 14:41
|
|
|
mystes posted:But some of Microsoft's extensions, like the current python one, are licensed in a way that says you can only use them in the official version of vs code lol
|
|
#
?
Apr 3, 2024 14:45
|
|
|
prisoner of waffles posted:most advances in IDE features were in proprietary s/w back in the day An IDE without sin would only crash, never save.
|
|
#
?
Apr 3, 2024 14:49
|
|
|
ynohtna posted:An IDE without sin would only crash, never save. Immediate Deletion Engine
|
|
#
?
Apr 3, 2024 14:57
|
|
|
eschaton posted:isn’t thus exactly why Microsoft created LSP for TypeScript? like the language + IDE vendor actually does provide the LSP support, because LSP is how they provide the TypeScript language support to VS Code yes, I should have said “rarely” - rust-analyzer was also pointed out above.
|
|
#
?
Apr 3, 2024 15:17
|
|
|
Internet Janitor posted:Immediate Deletion Engine sounds like decker should get on that, good luck
|
|
#
?
Apr 3, 2024 17:12
|
|
|
FlapYoJacks posted:Apple should license the IDE work out to Jetbrains and have them make Xcode.  appcode
|
|
#
?
Apr 3, 2024 17:17
|
|
|
vscode is very much in the tradition of emacs. just better at it, to no small part because emacs has largely rotted for decades.
|
|
#
?
Apr 3, 2024 17:18
|
|
|
eschaton posted:the thing is, emacs could have had this, but Stellman was paranoid about possibly making something that helped “proprietary software” too Oh yeah I know, I've been an emacs guy for nearly twenty years. We've all heard that story, probably multiple times, but now things are better and there's nothing the goobers can do about it
|
|
#
?
Apr 3, 2024 17:20
|
|
|
as a vim sicko, I am curious to know if neovim and its scripting situation are good/bad/okay/atrocious I really should just take a day and try out neovim
|
|
#
?
Apr 3, 2024 17:20
|
|
|
Cybernetic Vermin posted:vscode is very much in the tradition of emacs. just better at it, to no small part because emacs has largely rotted for decades. propped up upon the rotting corpse of the fsf
|
|
#
?
Apr 3, 2024 17:20
|
|
|
prisoner of waffles posted:as a vim sicko, I am curious to know if neovim and its scripting situation are good/bad/okay/atrocious I don't know vimscript, but Lua is nice. The problem I have with it is that I switched to nvim because I didn't like how "magically just works" stuff was with VSC, but documentation to actually set stuff up from scratch in nvim is very poor. so you'll get told to use plugins, which put you back in the "magically just works" category i recently rewrote a chunk of my config because Mason was loving up one of my LSPs (mostly the LSP's fault tbh) and this was a nice walkthrough of all the stuff that lspconfig was abstracting away: https://vonheikemen.github.io/devlog/tools/neovim-lsp-client-guide/
|
|
#
?
Apr 3, 2024 17:41
|
|
|
prisoner of waffles posted:as a vim sicko, I am curious to know if neovim and its scripting situation are good/bad/okay/atrocious modern actual vim is better than neovim
|
|
#
?
Apr 3, 2024 19:19
|
|
|
Cybernetic Vermin posted:vscode is very much in the tradition of emacs. just better at it, to no small part because emacs has largely rotted for decades. yeah, vscode is in many ways what emacs could have been if it had continued to be developed with the intention of advancing the state of text editing rather than being an ideological art piece leper khan posted:modern actual vim is better than neovim i agree, but i do wonder how long it'll stay true with bram gone
|
|
#
?
Apr 3, 2024 19:25
|
|
|
Do people actually do things in vscode beyond editing files? Emacs turned into more of a unified application platform, and while it's fine not to like its style of interface, I don't really see vscode being better at it.
|
|
#
?
Apr 3, 2024 19:36
|
|
|
Athas posted:Do people actually do things in vscode beyond editing files? Emacs turned into more of a unified application platform, and while it's fine not to like its style of interface, I don't really see vscode being better at it. click menu botan vs cmd shift pgdn
|
|
#
?
Apr 3, 2024 19:37
|
|
|
Athas posted:Do people actually do things in vscode beyond editing files? Emacs turned into more of a unified application platform, and while it's fine not to like its style of interface, I don't really see vscode being better at it.
|
|
#
?
Apr 3, 2024 19:37
|
|
|
Athas posted:Do people actually do things in vscode beyond editing files? Emacs turned into more of a unified application platform, and while it's fine not to like its style of interface, I don't really see vscode being better at it. vscode is in a wierd spot where its too bloated to be a text editor and its not good enough to be an IDE. still better than vim or emacs tho
|
|
#
?
Apr 3, 2024 19:45
|
|
|
|
| # ? Jun 3, 2024 22:21 |
|
|
Shaggar posted:vscode is in a wierd spot where its too bloated to be a text editor and its not good enough to be an IDE. still better than vim or emacs tho it's good enough for web dev.
|
|
#
?
Apr 3, 2024 19:52
|
|