What is your favorite text editor?

astyle said:
This thread did not have a poll..
Click to expand...
Tuesday, after
Cthulhux said:
I love how this thread has entirely lost its track.

(Unsubscribing.)
Click to expand...
wrote I thought, I could start a new thread with this topic - with a poll.
Because Cthulhux is right insofar, because the topic is really a vast field (page 16!) 🤓
And if you want to discuss textdeditors, review them, not only to list their names, the field is way to vast to keep it within "which texteditors are available, and who likes who" - especially if one doesn't want to fuel the Editor war again. 🤪

Many years ago I realized: For my targets in computers I'll need to do much editing, so chose the right editor.
And I've already learned, it's fewer the choice what editor you use, as more to learn to use an editor really good.
So pick a particluar one - chose well - and then really learn it.
Of course, if you are willing to make the effort in teaching yourself a real powerful, complex editor like emacs or vi you want to be sure chosen the right one.
So I started an evaluation process for myself:
1. Which editors there are?
2. Test them a while
3. Pick one and learn it.

Even if you limit point 1 just to free editors only, you'll quickly get a list of 20...30 editors - even more (/usr/ports/editors alone provides way more than 50)
And then you only have the famous, most used ones. Since there is not just vi, emacs, geany, Kate,...
Each editor brought up derivatives and many copys such as "like XYZ, but more/less/slightly other functions/features...."

That's why I recommend first to chose between the basic concepts of vi or emacs.
Even if they are named completely else most today's editors orient themselves at emacs as a kind of role model.
vi provides a complete other, but also extremely powerful concept of textediting.
There are more concepts as those both, but you may run into additional challenges like getting a copy for your OS.

So, to actually being correct you really need to say:
"First find and pick your concept of texteditoring, then pick an editor within this concept and learn it well."

Long story short:
I agree with either of you as with the presumed origin idea of this thread, as it would be useful to
1. summerize, what editors there are
2. discuss advantages, disadvantages, attributes, features...

I fully agree that would be very helpful for anybody who has not found his texteditor yet.
But from my experience I know this cannot be done fully considered by a list of editors only, neither with a forum's thread.
Just to make a list of all editors would need some effort (and I promise, you'll be beaten up immediatly, if you only forget a single particular one! 😜) and a list would only be the very start.
To make it right, you'll need to describe and compare them, better naming and dividing concepts of textediting, then building family trees... and then you only have one personal flavour of seeing it.....
That's something more for a research project, really. Ending up in a book: "Which editors there are and which I should try"

Otherwise, you end up in what's the most favorite one, only. And this ain't no satisfactory help for someone who already knew the most favorite stuff seldom fits (so one would not use FreeBSD but something more famous 😁

So, bottom line:
Everybody is at his own to find the best solution for himself, anyway. After all he/she needs to make the decision alone for him/herself.
All others can do about is list what there is, name alternatives, give input about things to think of...
And that's exactly what this thread does.

I agree, it's grown convoluted. But so is the subject.
 
blind0ne said:
Why nano is not the choice?
Click to expand...
It depends on what you're mostly doing with an editor, obviously. And you've got to take a look at the roots of nano: Pico.

The Pico editor is part of the Pine mail program. Pico was made for doing one job: writing emails, so having a small and easily understandable console editor, because Pine was supposed to be an easy understable MUA. Back in the good old days the competition Pine had was Elm, which had a much much steeper learning curve. This is what Pico has been designed for, as it was shipped aside Pine.

Nano is a re-implementation of Pico under the GNU license, so written from scratch but it mimicks Picos's UI and behaviour. Since then many features have been added which are not in Pico.

So Nano originally is mostly being around writing emails. Of course it can be used for other tasks. But if you are e.g. serious about programming, well, then there are for sure more suitable editors around for that than Nano.
 
1650954718532.png
the standard shortcut for paste is misinterpreted by vi as a command that is not a vi command and there is no mention of the word paste in the man page for vi man oh man what could possibly go wrong
 
grahamperrin said:
the standard shortcut for paste
Click to expand...
Who's standard? Microsoft's from 1995? In X11, the standard for middle click to paste a buffer will work fine.

Otherwise have you tried 'p' for "paste". Seems fairly intuitive and user-friendly to me. ;)

You can find more about this in the manpage. Search term: "commands to copy text"
Presumably you got that far to learn how to yank text in to a buffer in the first place?
 
In the UNIX Text Processing by O' Reilly, he refers to the 'p' as 'put' command. But I like to think of that, as 'print'. Why?

* In ed(1), 'p' prints the current address -- the implicit '(.,.)' address.
* In sed(1), 'p' prints the 'pattern space' -- the 'pattern space' can loosely be considered as some type of buffer.
* In vi(1), 'p' puts text from buffer -- which implies some sort of non-streaming printing, after all.
* In grep(1), although there's no 'p' option, but the 'p' letter in the name 'grep', comes from sed(1)'s 'g/re/p' -- and, still printing!

To sum-up: take 'p' as 'print', and everything will make sense.
 
Mark text with the mouse and just put it elsewhere with middle mousebutton works fine with vi.
For me that's standard copy-paste.../put/print under FreeBSD. Cannot have it more easy.

It does not work if within a GUI windows the already existing text is automatically marked, which of course overwrites the buffer, and what in my eyes is bad habits derived from Windows.
Point is, MS copied many things from UNIX/unixlike (MS DOS was nothing but an attempt to copy unix' shell but way much lighter), just changed them a bit, to be different (ls -> dir, cp -> copy, etc.) and often worsen them.
Thus bringing many bad habits into computer's world though it all was invented already mostly at its best or at least better.

Now many people reinventing the wheel we already had. Round. Not square, not polygon, but circular, running smoothly.
unix -> windows copies unix -> unixlike OS copies windows - that's tremendous cattle fieces!
better: unix -> unixlike,
not to say:
simply unix period :cool:

Or in other words:
Try to get Windows out of your heads. Or at least try to switch your reference.
Windows is not the role model.
Unix is.
Always was. Always will be.

Mostly it's just the question what you're used to.
If you can open your mind to become used of something else, you may experience:
There are so many "old" things, already and still existing under unix you figure out quickly:
"It's easy. It's quick. It's logical. It's intuitive. It's elegant. It's intelligent. It's smart. It's powerful. It's cool."
Well of course, somebody gave it a good thought. But coming from Windows you're simply not used to it.

I also used Windows for many years before I switched to FreeBSD.
But, okay, maybe it was easy for me because before Windows I had Amiga OS and got a better idea of how well things can be done before I faced my first Windows (95) and hated it from the start. Because there were so many things changed worse or done completely cuckoo without any comprehensible reasons.

short:
Don't compare unix with Windows.
Compare Windows with unix!
Else you're putting the cart before the horse. 😁
 
Alain De Vos said:
Oneone knows what are the advantages of nvi2 ?
Click to expand...

nex/nvi(1) is the the bug-for-bug replacements of 4BSD ex/vi utilities. But nex/nvi(1) was removed from OpenBSD 2.0 and was replace with vim. Then, OpenBSD 2.2 switched backed to nex/nvi(1), i.e. the current version in the base: nex/nvi 1.79, and they keep patching and cleaning-up the 1.79 version. Thus, it's far beyond the old nex/nvi. For example, they're using mkstemp(3) and pledge(2) to make it more secure.

There are two problems: first, it doesn't support wchar_t. Second, it's not compatible with systems which don't support pledge(2) syscall for example. That's why there's also an OpenVi, the portable fork of OpenBSD's nex/nvi(1) which works perfectly on FreeBSD too. For wchar_t support, there's a reimplementation of nex/nvi, which's known as 'nvi2', that is, the 2.2.0 version of nex/nvi, the one that's available in the OpenBSD ports tree.

Right now, I don't have access to a FreeBSD machine, so I'm not sure which is which on FreeBSD. But in OpenBSD you can have them both installed -- beside the vim, and use them separately: using 'vi' command for the 1.79 version in the base, and 'nvi' for the 2.2.0 (nvi2) version from ports.
 
a6h said:
Right now, I don't have access to a FreeBSD machine, so I'm not sure which is which on FreeBSD.
Click to expand...
commit f0957ccae4f402b93cf27b125542343d28b53109
Merge: ebe2785690e3 be3e4646eef6
Author: Peter Wemm <peter@FreeBSD.org>
Date: Sun Aug 11 20:03:12 2013 +0000

Update nvi-1.79 to 2.1.1-4334a8297f

This is the gsoc-2011 project to clean up and backport multibyte support
from other nvi forks in a form we can use.
 
  • Thanks
Reactions: a6h
In the late 90s there was FTE 0.49 editor written by Marko Macek. Very good editor.
I used it on Solaris 2.6 and early Linuxes (such as Red Hat 4.2) before I met vim...
Code: 
lanin@debian2:~/tmp/fte-0.49.7$ head -n 29 README 

                           FTE Kit, Version 0.49.3

                     Copyright 1994-1998 by Marko Macek.
                All rights reserved.

    This program is free software; you can redistribute it and/or modify
    it under the terms of either:

    a) the GNU General Public License as published by the Free
    Software Foundation; either version 2, or (at your option) any
    later version, or

    b) the "Artistic License" which comes with this Kit.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See either
    the GNU General Public License or the Artistic License for more details.

    You should have received a copy of the Artistic License with this
    Kit, in the file named "Artistic".  If not, I'll be glad to provide one.

    You should also have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

-----------------------------------------------------------------------
 
You must log in or register to reply here.
Back
Top