- This topic has 43 replies, 12 voices, and was last updated Jan 21-9:06 pm by Brian Masinick.
-
Posts
-
Brian Masinick
The only question I have regarding leafpad is support. Sid doesn’t include leafpad. Is a Debian version still built or do we have to build it ourselves? Otherwise leafpad is fine for a simple graphical interface editor.
ne is a light alternative. Haven’t used it much recently. If light rather than easy is a criteria levee is the smallest full feature editor I’ve ever used; VERY FAST and efficient, very vi in function! Not everyone will know how to use it but vi fans, especially PRE vim vi fans will love the efficiency.
Nano is a simpler editor than either ne or levee but it uses a little more memory than levee and neither are true GUI editors.
--
Brian MasinickBrian Masinick
Another editor I didn’t think of as a GUI editor because it’s usually run from the command line is joe and it’s counterpart jupp. Joe and jupp have multiple modes; it can use wordstar bindings, emacs bindings, vi bindings, nano bindings and Joe’s own bindings; jupp is a refactored implementation; all of these show up in the antiX menu in Accessories and they also show up in Programming when you install joe or jupp – I installed jupp and it does work in a GUI (it’s own window).
--
Brian MasinickBobC
I did try nano, levee, joe and jupp. I also tried mfe, eon, and xfte. For base, I think we will be looking to replace larger apps with lighter replacements to stay under the max CD size limit. People will always have the option to load a different app and assign it as their default.
A possible solution would be to use a default terminal session with MCEdit as the default editor in base, and in the control panel where we open a list of files, open them with MCEdit and then use xdotool to do F9 (menu bar), W (window), L (list) to bring up the list of files opened so the user can just point and Enter to choose the one they want to View/Edit.
Another possible solution would be to use e3 (in your favorite mode), and open a default terminal session for each file in e3 in a tab (if possible), or some equivalent solution using a light editor we already include. There is no reason we couldn’t add a desktop entry for whatever terminal based editor we choose to allow it to be selected as the default editor.
Given the micro-size of Leafpad, if an old version of Leafpad would work from an antiX repo, that isn’t a bad idea.
- This reply was modified 5 months ago by BobC.
Brian Masinick
@BobC:
Good ideas. If leafpad continues to work, that makes sense. Otherwise at least there are many choices to consider.
--
Brian Masinick
mrpieceofwork
Difficult as in it does not respond to key input when invoked in RoxTern lol (I will look online for solutions if I ever want to try it, I was just wondering if it was installed)
Difficult as in it does not respond to key input when invoked in RoxTern lol (I will look online for solutions if I ever want to try it, I was just wondering if it was installed)
@mrpieceofwork: Which “light editor” is that? Also, I’m guessing you meant RoxTerm?
Xunzi_23
Seems Leafpad was removed due problems with small files on network saves with samba o.a. being lost/failing.
Never seen the issue but I only use it localy, the rework, now mousepad has more functionality but is by no
means as light. As long as leafpad works I will continue using it.On sid, up to now, it is still doing all I need.
BTW, Since he hasn’t chimed in, I know BitJam uses Vi or one of its clones that is installed by default, and when this came up a few years ago, and the discussion was on removing packages to save space, he asked that the Vi packages included be left alone. There are others used to it too, I know.
Brian Masinick
BTW, Since he hasn’t chimed in, I know BitJam uses Vi or one of its clones that is installed by default, and when this came up a few years ago, and the discussion was on removing packages to save space, he asked that the Vi packages included be left alone. There are others used to it too, I know.
Regarding vi, vin, or another clone, on one hand to keep things as small and light as possible, whatever is chosen is fine. Veterans will be fine and are capable of installing the tools they need. Some “purists” will look for a vi style editor. Ever since vi was created, though it was created in the BSD community, both BSD, UNIX System V adherents and a large percentage of Linux users will have some familiarity with vi. Only absolute beginners won’t know it, yet basic vi is taught in almost all books about Linux. I’d only omit it in space conserving versions, otherwise the space savings are inconsequential.
--
Brian MasinickBrian Masinick
Personally I can use whatever we provide.
I think it’s really important to decide what criteria we use to decide which default tools to include. On our smallest images size is very important. On our full version efficiency is still important; vi and a variety of editors are reasonably efficient.--
Brian MasinickColonel Panic
Some good posts here. I’m a big vim fan although I use at most 10% of its features, but both it and vi (on which it is of course based) have a very steep learning curve for the average newbie. Beaver used to be a good one too though I haven’t seen it for a while.
Would Pluma be too heavy for including in AntiX?
mrpieceofwork
This is what pops up when invoked with “vim” in terminal… also, it’s just a RTFM issue for me, and I doubt I’ll ever use it, as I mostly just need/use the GUI editors (Geany and Leafpad)
VIM – Vi IMproved
version 8.2.2434
Brian Masinick
This is what pops up when invoked with “vim” in terminal… also, it’s just a RTFM issue for me, and I doubt I’ll ever use it, as I mostly just need/use the GUI editors (Geany and Leafpad)
VIM – Vi IMproved
version 8.2.2434
The vast majority of vi implementations for Linux are actually “vim” implementations (and there are multiple ways to configure vim). There are actually several replacements for a Linux vi – one of the first was called “Elvis”. I don’t see it around much, but early versions of Slackware often included it.
I’ve mentioned levee before. It’s a VERY small editor, and it comes with little, if any, documentation, but except for that, it’s a pretty faithful implementation of the original vi and it it is very fast and small.https://www.tecmint.com/vi-vim-inspired-code-editors-for-linux/ provides a description of several editors that provide some degree of “vi compatibility”.
History and explanation of vi:
https://en.wikipedia.org/wiki/Vi
History and explanation of vim:
https://en.wikipedia.org/wiki/Vim_(text_editor)--
Brian MasinickBrian Masinick
Some good posts here. I’m a big vim fan although I use at most 10% of its features, but both it and vi (on which it is of course based) have a very steep learning curve for the average newbie. Beaver used to be a good one too though I haven’t seen it for a while.
Would Pluma be too heavy for including in AntiX?
I’m not 100% positive, but the history of this editor dates back to a rework of gedit, which was a core editor for the GNOME project and Pluma has been a core editor of the Mate project. Both of them are capable editors, but without bringing them in and examining exactly what occurs, my suspicion is that when you include them in GNOME or Mate, they are pretty efficient, but if you install them on a minimal system, they are very likely to pull in a fairly significant set of libraries to support their integration with their respective desktop environments.
Individuals are certainly welcome to install whatever they wish. As far as including this at a default, some detailed analysis is appropriate before making the decision.
--
Brian Masinick
- You must be logged in to reply to this topic.
