LEDIT(1)                    General Commands Manual                   LEDIT(1)

NAME
    ledit – weird text editor

SYNOPSIS
    ledit [-c config] [file]

DESCRIPTION
    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’.

ANTI-DESCRIPTION
    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.

OPTIONS
    -c 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.

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

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

MOUSE ACTIONS
    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.

CONFIGURATION
    See leditrc(5).

MISCELLANEOUS
    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.

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

QUIRKS
    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.

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

AUTHORS
    lumidify <[email protected]>

BUGS
    Too many to count.  See TINY SUBSET OF BUGS.

TINY SUBSET OF BUGS
    Well, I guess I'm too lazy to collect bugs right now.

                              September 5, 2024