On Thu, 21 Jan 2021, Sebastian Gniazdowski wrote:
> I have made the wish list on the ticket system:
> http://midnight-commander.org/ticket/4177
>
> Are there any interesting entries? Or: is the direction in them
> compliant with the maintainer vision?
Sorry, I've used up the time that I can make for mc for the coming months,
but to make it short, I'd rather side with Andrew.
I'm pretty averse to overloading mcedit with small hardly discoverable
functions (however useful they are), and bolting on a questionable
scripting engine on top of that.
There are two arguments in the paragraph:
1. Small hardly discoverable features:
2. Questionable scripting engine.
Ad. 1.
I think/I'm hoping that it's just a first impression that the wishlist has made, mostly because of how long it is. I think that the entries in it are of the following categories:
A. Small bugfixes.
Like the whitespace leaving on the divided line by the typewriter wrapping, or the pasting onto an input's initial, faded text, or the find definition goto-line instead of replacing the file with the same file, or the fix of ParagraphFormat action, etc.
Such changes are fine as they are rather bugfixes than microchanges, and bugs can be as small as they can get, because they're bugs that should be just fixed.
B. New features that are narrow, but sensible.
Like the line joining (vim's J command), character swapping (Ctrl-t in readline), centering of view (vim's zz command), CapitalizeWord (vim's gUiw command), LowercaseWord/Letter, ReloadFile action (vim's :edit), or the to-open-paren indenting, etc.
I think that such changes are yes – narrow – however they're have a good history in other editors, so it's fine to implement them. All of them require only small coding.
C. Features by the big F – with big coding required by them.
Like the (30) alternate/updated WindowList command merging (but with a separation) the entries of the open file list and the editor history, or the clipboard history, (61) showing of current function in the window bar, or the (10) word-delimited block paren-like matching (i.e.: MatchBracket action), MultiSearch listbox filtering, etc.
Such changes are IMO little heavy and require acceptance of the maintainer, however I strongly believe in them (not sure if all such wishes from the list, however the above – yes) and I hope that I'll win maintainers blessing on them.
D. Annoyance resolving changes.
Like the (52) WordRight to jump to the end of word, not to the beginning of next word, or (41) repeating of Complete to move the selection in the list to next item, or (46) opening of file without adding it to editor history, or (53) explicit jumps to previous locations in the file, (56) saving and restoring of the replaced buffer's undo history.
I think that such changes may be most difficult to convey to the maintainer. On the other hand, SearchOppositeContinue has found its way to mcview, and it is from this category – a narrow change to resolve an annoying problem, so maybe there's hope.
E. Fancy changes.
Like (13) completion of file paths in buffer, (39) go-to filename under the cursor, (40) repeating of all characters and commands from the last save, (57) peek of the declaration of the function under the cursor, or the terminal window support, or (18) bookmark listbox, (32) search results listbox, etc.
Such changes can be perceived as controversial because of the fanciness and size of the patches. I think that they need to be "pulled off", which makes them open for a simple rejection.
F. Creative, eccentric changes.
Like the (17) preview of ExternalCommand, (14) tray with a set of Unicode symbols, (16) git support, (58) a tags aware window list.
Such changes are rather doomed for a fork fate. 17 and 14 – yes, maybe, but the git support or 58 – no, rather no chances of acceptance of the maintainer.
G. Long awaited changes.
Like (5) file browse widget for Edit/SaveFile,(15) "other file" .c ↔ .h support, (11) CK_WindowCascade / CK_WindowTile, (29) scroll left/right.
Such changes are IMO problematic, because they're known for the maintainer and fossilized. I however still have hopes for all of the above, especially the last three.
H. Weird changes
Such changes might be the ones that you and Andrew have biggest objections to, like 45, 36, 31, 4, 24, 47, etc. I've included them in the wishlist just to stimulate the grey cells and new ideas. They and the ones from F. may have caused the allergic reaction of Andrew… And also D., contributing to the microchanges aura.
Ad.2. Questionable scripting.
Slang is a good language. It e.g.: allows inheritance of structures via, e.g.:
car = struct {x, y, z}; truck = struct {@car, t};
Slirp is a very reliable tool. Did maybe the kitchensink example scare you off? Because it's the standard syntax used in such tools, it's virtually identical to Swig, the main scripting integration utility, I know this because I was first embedding Python in mcedit with it. Uh, good that I dropped the idea, Python and Swig would be too big.
There are enough fundamental problems with mc codebase, and my vision for
it would have been to clean up the core, cover it with tests, and expose
its API to an external engine, which provides a high level memory managed
language. Everything beyond core could be pushed into this layer and left
up to users and distributions...
What cleanup is needed?
This was pretty much what mc^2 was a prototype for, but very unfortunately
we didn't have the capacity to integrate it :-(
I wonder how is mc^2 coded, is it a good code or just a rapid iterations result, like it is little with my slang support currently, maybe… Also I think that the author should cooperate more from the beginning, not just provide a full, but external result… That's why I'm planning to draw people in soon, when only a part of the API will be available from S-Lang. I hope that you will like S-Lang, it integrates very lightly even compared to the Lua support, which now appears to me as a big, foreign thing to throw in…
--
Sincerely yours,
Yury V. Zaytsev
