I don't understand what is the point of releasing an IDE via #flatpak, when that flatpak doesn't include all the necessary dev tools, and it can't access the ones outside its sandboxing. Honestly. What's the point? I'm looking at you, #Geany.
Personally, I can't stand flatpaks or #snap. #Appimage is nicer just because it's just one delete away from within the file manager and doesn't leave crumbs everywhere. But overall, I prefer #apt, and #dnf.
@alxlg@vwbusguy@eugenialoli
Containers & bring-your-own-dependencies may have some use cases, but that should not be for normal Linux apps. One containerized program I used last year required a full 4GB, as it only ran on Ubuntu.
So yes, I'm talking about making native packaging easier for devs. I'm also looking for a healthy collaborative culture where code is updated as needed rather just punting and allowing old code to rot in an isolated container.
@wickedsmoke@alxlg@eugenialoli That's less of an issue for flatpak since the shared runtimes get updated, but it's very much an issue for toolbox and distrobox environments. There's not currently a great way to keep them all updated or upgrade them if you use them longterm.
I think, for me, much like EDLIN, it's pretty much always been a matter of knowing that it was the default editor available in every incarnation of #UNIX and #Linux since, ... I dunno, ... 4.2BSD or so?
Perhaps I should say vi, and in DOS I don't really recall when EDIT.COM supplanted #EDLIN, but do feel free to checkout my friend's more modern #FREDLIN in the link above. h/t to @dheadshot for creating a POSIX interpretation of that classic utility from the days when disk drives talked to you and diskettes shimmied...
Also, These #Vim memes are some of the funnest elbows to the ribs of the person sitting next to you we can all enjoy together... unless, unless, Oh my gawd am I on Drugs?
Here's another one for folks to add to their collections, for foshizzles and giggles, of course, and we all can haz #Cheezburgerz! 🍔
Kindest regards, and thank you for some of the very best cookbook style #tuts, #HowTo's, and introspectives for the UNIX / Linux / FOSS world on the Internet :)
Learned about #geany yesterday and installed it today to take a look. Looks like fun so far. Has its own css file for look and feel. Can't say I'll use it over #NotepadPlusPlus - the interface is a little sluggish by comparison, which is only to be expected with GTK, but hey - that's never the point with me. :-)
First order of business, figuring out how to force it to single-instance mode..
I like #vim, I use it when I work remotely through ssh or on my computers to edit config files (I never use root on GUI).
But to develop software, essentially PHP, CSS and JS files, I prefer #Geany. It is between a text editor and a full IDE. I find it is easier than vim to navigate in source code.
I wonder if I should have a look to #Emacs
Learning lots of new shortcuts/commands scares me.
Thanks @hajovonta that sounds like a good place to start.
However, the description of Doom shows just how complicated emacs is to set up. In fact, not sure that I'm ready to spend all the necessary time to discover it. And I'm not si young ^^
Emacs is not Doom, you cannot conclude from one to the other. Dom uses Emacs.
Emacs itself is usable right away, on its own.
It however has many internal and external modules that often can interact with one another. If you decide to use them, then Emacs becomes a bit more complicated. In pure Emacs you however often do this one after the other. It is however always more complicated than Geany (since it's more powerful).
Doom comes preconfigured with lots of modules. Many more than you ever will need. And so it has its own method of allowing you to select what you want. Quite un-emacsy, if we're honest. However, they added code to make the resulting Emacs load slick and that is driven by their packages.el and "bin/doom sync" logic that you won't find in Emacs.
BTW, saying that Python, Perl, JavaScript are complex because there are TONS of external modules available for them... a weird thought. But for Emacs people do that. A logic that allows you to install a select list of modules that are known to work together (like numpy and scipy) complex? Still a weird thought for me. Having a file where you can influence the list of installed modules perceived as conpiexity, not as freedom? We think differently :-)
In the end, if you see Emacs itself as overly complex, then maybe Emacs isn't for you. Nothing wrong with that.
#Geany 2.0, une mise à jour majeure de l'#IDE open source #GTK est sortie. Elle offre un support expérimental pour Meson, une nouvelle fonction "Historique des changements", des améliorations de l'interface, une prise en charge de nouveaux types de fichiers et bien plus encore. Téléchargez-la sur GitHub ou via Flatpak. #Programmation