LEDIT(1) General Commands Manual LEDIT(1)

ledit — weird text editor

ledit [-c config] [file]

ledit is a vi-like text editor for people who switch between keyboard layouts frequently and/or work with languages that require complex text layout. It combines the drawbacks of vi-like terminal editors with the drawbacks of graphical editors.

Additionally, it allows multiple views on a text buffer so that different parts of a file can be shown at the same time.

It is assumed that readers of this manual page are already familiar with vi(1).

Most documentation is actually included in leditrc(5) because that's where all the key and command bindings are discussed. It would be nice to show the default key bindings in a nice format here, but that would require too much work, so you'll just have to look at the descriptions in leditrc(5) and the default bindings in leditrc.example.

WARNING: All input data is assumed to be utf8!

Input lines are split at ‘\n’, ‘\r’, ‘\n\r’, or ‘\r\n’, while lines written to output files only ever use ‘\n’.

ledit is not a code editor. Features for code editing may be added in the future, but the main purpose is currently to edit other text.

ledit is not a general-purpose text editor. It is content to be useful for some tasks and does not feel insulted when other editors are used for other tasks.

ledit is not a minimalistic text editor. It probably counts as reasonably minimalistic in the modern world, but that is not the main goal.

ledit is not a good text editor.

config
Load the configuration file given by config. If this option is not specified, ledit will attempt to read the configuration file .leditrc in the user's home directory before using the defaults.

See the descriptions given in leditrc(5) and the default bindings in leditrc.example.

See the descriptions given in leditrc(5) and the default bindings in leditrc.example.

There currently are not many mouse actions. Clicking and dragging with the left mouse button enters visual mode and selects text, which is always copied into the X11 primary selection.

Note that text selection currently does not work in the line editor because the author is too lazy to implement that.

Middle click in insert mode pastes the current X11 primary clipboard. Note that the text is pasted at the current cursor position, not the position of the mouse cursor. The author prefers this way.

See leditrc(5).

ledit includes a fair number of sanity checks (asserts) to make sure some illegal conditions never occur. If one of these checks fails, ledit will write the error to stderr and abort. In order to avoid losing work, it will attempt to write out the entire contents of the buffer to a new file whose name is based on the current filename, but with “-emergency-dump-” and a random string of characters appended. Perhaps this functionality will be removed once ledit is perfect and all bugs have been removed.

The ledit utility exits 0 on success, and >0 if an error occurs.

The cursor movement commands try to move left/right visually instead of moving through the text logically. This causes weird cursor jumps when working with bidirectional text in normal mode. This may be fixed in the future, but it currently is not clear how to make the behavior more logical.

Due to the way undo is implemented, when text is typed in one view in insert mode, then in another view, and then again in the first one, the last two inserts will be undone in one go since both views were in insert already. I'm not sure how to make this more logical, though. Maybe it could be “improved” by also saving the view in the undo stack, but that would cause problems because views can be added and removed, and it would maybe not even be more logical.

Scroll offset is stored as a pixel value, so a view may scroll when text is added or deleted in another view. Additionally, when a new view is created, the scroll offset from the old view is taken, which may be weird if the window of the new view is a different size.

Spaces at the ends of lines are weird because they have to be drawn manually instead of highlighting them and letting Pango take care of it because the Pango developers decided to hide spaces at the end of a line.

ed(1), vi(1), vim(1), leditrc(5)

lumidify <nobody@lumidify.org>

Too many to count. See TINY SUBSET OF BUGS.

Well, I guess I'm too lazy to collect bugs right now.

September 5, 2024