sidju / add-ed Goto Github PK

Inspired by the old "qed" editor, adding support for multiple buffers via the 'b' and 'B' commands could be nice. In a terminal UI this would add little, but for a vi style UI or a multi window GUI it adds some flexibility.

As always, I'd love to hear some feedback before I commit on this feature.

Internal error! Save and quit, and please report at `https://github.com/sidju/add-ed/issues`
debug data: UnreachableCode { file: "/home/solofs12/.cargo/registry/src/index.crates.io-6f17d22bba15001f/add-ed-0.13.0/src/cmd/parsing/selection.rs", line: 245, column: 7 }

At least it doesn't crash :)

When moving selection 'x,'y forward the tag x was duplicated and left on the line immediately following the selection. Furthermore the line that the selection was moved to ended up being placed where the selection was before.

Very strange....

The differences are sufficient in how it affects the handling of current filepath to warrant a separate handler. Current implementation has some errors causing the filepath to be changed unduly if there is no explicit selection given to W, which has now caused me some minor data loss....

Selection validation errors on saving an empty file. Until someone requests support for this I'll leave it as is, since one usually doesn't open a text editor to save an empty file (the touch command does it well enough) and it can prevent accidents.

in hired, trying to reference a local clone of add-ed results in there being no feature named vecbuffer.

steps to reproduce error:

1. clone hired
2. clone add-ed
3. set add-ed in hired's Cargo.toml to local add-ed e.g.: path="../add-ed"
4. cargo build

I tried removing the feature from hired in Cargo.toml and explicitly setting it in add-ed but still cant find VecBuffer in hired. patch notes suggest feature is implicit but it cannot be found when removing the feature flag despite versioning being the same in remote and local add-ed.

Also try to improve the clarity of the documentation. It is cryptic to those not expecting man style example commands, and quite confusing even to those who do.

When I use /bin/ed comes with macOS Ventura (which I'm not sure how standard this is), I can do such thing as below.

ed
i
insert these
lines
.
,p
insert these
lines

and i allows me to insert right away.

But hired complains with No prior selection exists. when I wish it just works.

(as a side note)
On the other hand, ed doesn't print whole body with just , - as it require it to be ,p - but hired does print all lines which is very convenient 👍🏼.

There is some groundwork done and could be nice to add inserting/prepending variant commands for the commands that append. On the other hand there is support for basic arithmetic in all index parsing, so the functionality would be heavily redundant.

My current plan is to leave the variants out of the coming release but leave the internal code for their implementation (unreachable), unless someone expresses opinions for or against them.

The current code interprets selection before it knows which command is relevant (https://github.com/sidju/add-ed/blob/main/src/cmd/editing_commands/input.rs#L80). If done after matching on commands we could give a more correct default than state.selection (such as (state.selection.1, state.selection.1) in the case of a), giving more intuitive behaviour.

The History struct should add support for having a message describing the action that creates a snapshot. This would enable undoing/redoing to return a string similar to "Undid ,a" or "Redid ,a", which would greatly help navigating the undo/redo history.

As different representations of the same visible string should match in regex operations it would probably be good to normalise both buffer contents and commands.

Details exist in here: https://tonsky.me/blog/unicode/

There is some debate over undo behaviours. The options (I currently know of) are:

• "simple" undo, where all redo potential is lost when you perform an action
• "tree" redo, where every action after you have undone creates a new branch
• "revert" undo, where the undo is an undoable action (see here)

Aside from simple (which is currently imlemented) the behaviours enable accessing every state the application has been in during this session.

I don't have strong opinions, if someone is gifted with such please opine and/or share PRs here.

Due to History using a single matched field per line, nested interactions that affect that field cause unpredictable behaviour.

Potential fixes are either blocking nested interaction, making the matched flag a list of bools pushed and popped by operations on it, or backing to use find_matching to just find nearest line matching after index each execution (not dealing with any changed selections or moves by commands).