What is your favorite text editor?

For quick script and config editing - vi and micro (with a little helpfrom tmux). Most editing is C/C++/C# where jucipp and monodevelop take over.
 
drhowarddrfine said:
I'm pretty sure every editor has been mentioned by now, and multiple times, as is always true of all such threads everywhere in the universe that asks this exact same question. So can we close this one now until the next same question gets asked later today?
Click to expand...
Editors evolve. So it's not bad to ask the same question on regular intervals
 
Nailing the lid of the coffin shut...
SOP.jpg
 
I would change the question to: what qualities should the editor have?

(1) Reliable, it should not spoil my file.

(2) lightweight, it should run also in old computers without time lag.

(3) powerful search and replace functions, regexps across lines.

In scripts I use ed. For elementary things I use (n)vi, but I suspect it does not fulfill 3.
Normaly I use emacs, but condition 2 is not really fulfilled.

Perhaps sam is the right editor, but I do not like the background colours when using it with gui.
 
hruodr said:
(3) powerful search and replace functions, regexps across lines.
Click to expand...
Not by default but using '!' to pass into specific filters for the task (awk is pretty useful for this), you potentially have a vastly superior solution to a lot of off-the-shelf IDEs.

I have one that looks in headers, including previous versions of headers (from svn, git) for a specific function. Very useful when porting codebases to newer middleware. Yet so niche, that most IDEs will never bother including such a feature.
 
kpedersen said:
awk is pretty useful for this
Click to expand...
But it works line by line. How do I search across lines?

I think the main function of a text editor is that, reading text, recognizing parts, and altering them.
One could say ed is a regular expressions engine, and it is a powerful text editor, but not enough
and not comfortable.
 
hruodr said:
But it works line by line. How do I search across lines?
Click to expand...
Typically it is used that way but Awk is surprisingly large as a language.

If you do a search in the awk manpage for "getline" you will see a function that allows you to read from file (or pipe) and thus store the entire contents in a string (just like most other languages really). From here you can do any string searching.

Awk is basically similar to Perl or Python without the ability to import external libraries.
 
sidetone said:

Reddit - Dive into anything

www.reddit.com www.reddit.com
Supposedly, vim pulled in dependency hell. I wasn't able to confirm it, because my desktop already had many of those packages.

Also, they had the suggestion of using vim-console and other lightweight packages.
Click to expand...
To me that is a fundamental problem with software. Unless you write it yourself or have the ability to completely customize it, you are stuck with someone else's "vision of perfect".
Take email. To me, email is text. You want to send pictures? Attachements, but email is not "html".

Text Editors: use drives desired features.
Writing code? language-specific awareness and ability to customize the layout is often desired. Color syntax stuff, auto indentation, spaces vs tabs, etc. Not "necessary" but "nice to have because it makes your life easier".

Writing technical documents? WSYWIG is useful, but not needed. Markup languages like roff and others have been used for text processing for a long long time.

All editors:
I agree with the lightest weight possible for the desired functionality, ease of use/intuitive interface, minimal system requirements.

One of these days a text editor is going to pull in systemd/homed as a dependency.
 
Why would VIM install Wayland? When a window manager or desktop doesn't even install Xorg or Wayland. Their vision of perfect is quite the opposite. Pango is a Linuxism, and has been associated with dependency hell on FreeBSD.

If the package is meant for Wayland, it needs to be vim-wayland. vim-console should be the default install as just vim.
 
Personally I would recommend editors/vim-tiny anyway so you don't need to spend ages disabling all the dumb auto-format / highlighting clutter that it defaults to these days.

Then for the few plugins you might need, just put them in the respective ~/.vim folder. Easy and fuss free.
 
They need to keep things simple, and replace many dependencies with simple messages, that say: if you want this additional functionality or for this set of bloat for those inclined to unnecessary bloat, install these packages/ports.

What happened to KISS?
 
Keep It Simple, not rock band depicted on a That 70's Show t-shirt.

They may as well have an install that calls on every single port library and many suites of ports. And takes 5 days to compile. Then, to get sound, another set of ports needs to be installed that takes another 5 days to compile. That was an exaggeration, it has never been that bad, but it feels like this what was some aim for.
 
sidetone said:
Keep It Simple, not rock band depicted on a That 70's Show t-shirt.
Click to expand...
Apologies for trying to inject a bit of levity on a Monday.
For the record, I know what KISS is, as my previous sentence says, levity was intended. Obviously I fell far far short.
 
I use vi() for short edits and devel/geany for longer edits and projects.

The latter I find terrific thanks to:

* Lightweight
* Good customisation
* No learning curve
* Save buffer
* Multiple languages and syntax support

But yes, presenting an IDE may be straining the TS a bit but hey.
 
I use vi out of habit. I probably wouldn't have taken the time to learn it if it hadn't been necessary way back when, but now that I know how, I kind of prefer it.

Once I have a system up and running, I install vim, mainly for the colorized syntax checking features. Since I don't like the auto-indenting features (also because of old habits), I put this in my ~/.vimrc --
Code: 
set noai inde=
For searching and editing headers, include files, and other project-related needs, I just write my own shell scripts using grep and/or sed for those purposes. To avoid re-typing long filenames, I use terse lower-case shell environment variables, which I export via the ~/.shrc file and edit frequently according to my immediate needs.
 
You must log in or register to reply here.
Back
Top