ladyboonami / wsedit Goto Github PK

I just figured I'd let you know that I no longer get rekt Unicode after using wsedit on xterm. The issue is mentioned in the readme, so if you can confirm that the problem is resolved then you might as well remove that part from the readme. 🙂

As it stands now, wsedit's documentation is a complete mess. You'll have to piece your information together from:

• the very brief -h
• the even briefer -hk
• the main README.md
• ...

It could use a restructured -h* infrastructure, as well as an improved README.md.

working on it...

It could look like a traditional scroll bar on the right edge of the screen.

1. Open a symlink that points to a file. Atomic saves must be enabled.
2. Save.
3. Behold: the symlink is now a file with the new contents, the original file is unchanged.

goddamn it

Ctrl-P currently works on the entire file, no matter if text is selected or not. Processing only part of the file would be nice.

Naively glancing through the code, it looks like it's the /usr/local part that's tripping it up in this case. /usr/local is where a lot of package managers (e.g. Homebrew and FreeBSD's Ports Collection) like to install things, so looking there as well as ~/.config and /etc would be ideal, I think.

This is a combination of two different issues:

• The WRI check takes jump marks into account and therefore fails.
• A failing WRI check calls emergencySave which in turn calls save again, creating a mutual recursion. This fails on an already opened file, crashing the editor.

Especially the second issue is bad since it's a crash in the emergency handling system.

Proposal:

• -eC: automatic detection, current default behaviour.
• -ecx: use xclip or xsel, error message if neither is installed.
• -ecF: use the default clipboard file ~/.wsedit-clipboard
• -ecf <fname>: use the specified file as clipboard buffer

File permission management:

• If the file doesn't exist, perform chown go-rw on it.
• If the file already exists, do not touch its permissions.

Internal representation:

data ClipboardMode
    = CAuto
    | CUseX
    | CUseFile (Maybe File)
    deriving (Eq, Read, Show)

This would allow for fancy stuff such as sharing clipboard contents with remote machines via nfs and stuff while also enabling the user to "fight back" if the somewhat hacky checkClipboardSupport function returns a wrong result.

Something along the lines of

type WSEdit = RWST EdConfig () EdState IO
type WSPure = RWS EdConfig () EdState

All functions that do not perform direct I/O should live in this Monad instead, so they can be reliably tested with HUnit. Might run into some problems with the type sigs of alterBuffer et al. though (solution: either two separate functions (sucks), or maybe a (possibly weird) polymorphic signature), pending further investigation.

It would be great if you'd be willing to create releases on GitHub that coincide with the versioning you're already using. I'd be interesting in making a Homebrew formula for wsedit but having a tagged release makes that a lot easier.

Nice work on this, by the way!

90% of the code is already there, we only need an option to read an EdDesign from a specified file and plug it into EdConfig before starting up.

I recently upgraded the macOS Homebrew formula to 1.2.1 then recompiled, and I found that the resulting binary is wsed rather than the usual wsedit. Is this expected? The readme still refers to the executable as wsedit.

When given a parameter like -fs+foo, wsedit should highlight all occurences of foo in the entire document, overriding any existing formatting.

• Explicit specification for the file extensions used for autocompletion, since e.g. C uses .h and .c files (-d0e~hs?)
• Maybe even let the user explicitly specify a list of files (-d0f~WSEdit/Data.hs?)
• Some files (e.g. Haskell data statements) may have relevant declarations at multiple indentation levels (-d0 -d1 -d2?)
• Possibly integrate the comment detection with the -flcparameter?

A recent CRASH-DUMP reached 500MB size, filled to a significant part with repeating dictionary definitions for every step in the undo history. Reduce this by

1. chopping off more undo steps (reduce to ~10?),
2. unsetting the dictionary for the entire undo history upon dumping. The read process should be able to restore it from the current dictionary.

To test the Lisp highlighter, I opened https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm in wsedit. Initially loading the file took several seconds, and once it was open, any cursor movement within the editor was extremely slow and laggy. This is a pretty big file (over 2100 lines as of this writing), but opening it in other editors such as Vim poses no problem at all. For reference, loading smaller files is instantaneous and the scrolling is smooth.

I don't pretend to know how wsedit works internally, but perhaps you could buffer only a portion of the input file at a time and load more of it as needed when scrolling? ¯\_(ツ)_/¯

This is rather trivial to implement, and would be very helpful for e.g. LaTeX files.

Security implications: Worst case scenario: echo '*: --on-save adduser -G wheel evil' >.local.wsconf, a world-writable directory could be exploited to gain root access if a sufficiently priviledged user trips over the config file. While this is no problem on single-user machines, I wouldn't want such a ticking time bomb running on my server. Going the ghci / openssl route of only loading config files if their permissions are narrow enough is overly restrictive, and only requiring it for files containing hooks is unfeasible because of the way config files are handled. Putting hooks in extra config files (like .on-save.wsedit) with tight security requirements doesn't allow for hooks to be specified as call parameters, which is orthogonal to how wsedit has been operating thus far and therefore unacceptable. Maybe this can be solved via compile flag?

(A)Synchronous?: Probably we need both approaches, one silent, asynchronous hook and a synchronous one where the output gets displayed somehow and the editor resumes after the hook terminates.

I'm adding a test to the wsedit Homebrew formula in hopes of submitting it to Homebrew-core, and I'm running into an issue. My idea for a test was to capture the output of wsed -hv and do a simple regex match check. However,

==> /usr/local/Cellar/wsedit/1.2.2/bin/wsed -hv
wsed: user error (Terminal does not define required capability "cup")
Error: ararslan/pints/wsedit: failed

When I run wsed -hv manually in the terminal, the terminal flashes but then it outputs normally.

I'm sure this is due to how the Homebrew Ruby function shell_output is set up, and it might not be compatible with the terminal libraries used here, so there may not be anything we can do here. But if you have a better idea for a simple test case, that would be fantastic. (Existing code here.)

E.g.

• Press Ctrl-M to toggle a mark in the current line
• Pass -m+<xxx> to create a mark in line xxx
• The mark shows up in the scroll bar as a red dot
• Press Ctrl-N to jump forward to the next mark
• Press Ctrl-Shift-N to jump backwards to the previous mark

And maybe even integrate the jumping with -fh, so that you can jump from search term to search term.