On Thu, 21 Jan 2021 at 12:51, Yury V. Zaytsev <y...@shurup.com> wrote:

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

-- 
Sebastian Gniazdowski
_______________________________________________
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Reply via email to