Script Moe with NimScript

[uninhm]

I think that should like vim too, the configuration file should be a script. And the EX mode should execute nim script commands.

[uninhm]

So, the configuration should be with procs. Example:

~/.config/moe/moerc.nims

theme dark
tab on
synatx on
tabstop 2
paren on
indent on
linenum off
statusbar off
realtimesearch on
deleteparen off
smoothscroll on

[uninhm]

And all we have in the config file, we should be able to execute in the EX mode.

[juancarlospaco]

I dont know, maybe I dont feel too attracted to TOML, but maybe have you considered just using NimScript instead of TOML ?.

https://github.com/juancarlospaco/nimscript4python/blob/master/src/nimscript4python.nim

Can also be the base for Plugins in Moe, keep a tiny core and let anyone make Moe plugins. :thinking:

[fox0430]

@juancarlospaco

I have never used NimScript. But that sounds good. I try to use NimScript. Thank you.

[juancarlospaco]

Maybe it can start as few tiny proc of 1 argument, with primitive argument types, like int, bool, string, then you dont have to fight serializations and code is simple and also fast, because can be memoized.

Imagine simple procs like:

• goToLine(line: int).
• goToColumn(colum: int).
• insertChar(chara: int) (use this in a for loop to insert a string).

Plugin can be (Pseudocode):

goToLine buffer.countLines
gotoColumn buffer.splitLines[^1].len
for chara in "Hello World": insertChar chara

Build a complex functionality from simple pieces. :thinking:

[tobimensch]

I like the idea of adding a configuration mode to moe (Add Configuration mode #205), and this would definitely more easily be implemented, if the predictability of the TOML formatted configuration is kept instead of being replaced by NimScript. Since NimScript is turing complete, it will be very difficult to make the configuration mode UI understand how it should or shouldn't manipulate it. The advantage of toml is exactly that of not being a turing complete language.

On top of that I think that moe should pack many features in its main executable, and not rely on plugins/extensions for becoming useful. My experience with vim/nvim/emacs and the like is that you always spend unreasonable amounts of time with comparing different plugins/extensions, finding them, installing them, configuring them, updating them, so I'd rather see moe become a kind of swiss army knife, that packs every feature that 95% of people would ever need in an editor, and more. Maybe the final 5% could be provided by plugins. For example, @fox0430 has just now added a QuickRun mode, something for which you need a plugin/extension in vim. Native code is also faster than NimScript to my knowledge (because it runs in a VM), but this could be wrong, and it could also change in the future.

Apart from this, yes I think adding NimScript support makes sense.

But I think that the TOML config format should be kept, because it is the easiest way to make changes for new people that have no experience with Nim or NimScript. And toml's INI file like format is really as simple as it can get. I wish for moe not to become a second vim, because my experience is that the learning curve is very steep and it took years for me to acclimate to it, and I still haven't completely. There are countless stories online of people who had the same experience with Vim like I did. So while scripting is a great thing for an advanced experienced pro user, in my humble opinion, it should not be a requirement for new users to come in contact with scripting, and even pro users should be able to configure the vast majority of features without any scripting needing to done.

What I would do is to add NimScript hooks to the toml config, for example:

[Script]
OnConfigLoadedScript = ~/.config/moe/onConfigLoaded.nim
OnProgramExitScript = ~/.config/moe/onExit.nim
OnBufferChangedScript = ~/.config/moe/onBufferChanged.nim

With those hooks you could script moe's configuration/behavior when certain events occur, but you would still have one central configuration file, where no surprises (like loops) are to be expected.

[uninhm]

https://github.com/unihernandez22/nimscripttests

[uninhm]

@fox0430 Check this

[uninhm]

@tobimensch Ok, but I prefer have a config file with NimScript, like VimScript in Vim

[tobimensch]

@unihernandez22 With my suggested solution you could have your way, by simply using the onConfigLoaded hook. And everyone who prefers to use a simple configuration mode (that will hopefully be added) can use that. And I don't really think that "Vim does it, too" is the best argument, since vim is a tool that has always had huge a problem to gain a wider share of users due to its enormous complexity, I think there are areas where you can vastly improve on Vim.

Example: Fedora just decided to remove vim from their default installation, because it is too difficult for most users, and I can attest to that, because I needed years to get comfortable with it, and I'm still not. They deciced that nano is easier to use, and thus should be the default. And sadly I have to agree with them. So, if moe wants to copy everything vim does, and the whole philosophy of it 1:1 it'll end up where vim just ended up in Fedora (there were other distributions that did the same thing), as a total niche pro user tool. So I think it's better to make the defaults as easy to tune as possible, nobody can tell me that an INI file is too difficult for them to manage, and building a configuration mode for it is very realistic.

I know multiple people that aren't programmers at all, or don't like programming/scripting, but maybe they still like to administrate a machine or they have to do it. And I would like to be able to recommend moe to them.

[tobimensch]

https://fedoraproject.org/wiki/Changes/UseNanoByDefault

Quote:

Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.

https://www.phoronix.com/forums/forum/software/distributions/1193105-fedora-approves-of-making-nano-the-default-terminal-text-editor-other-features-accepted

In the discussion thread above there are differing opinions of course, but you can see many comments about vim requiring too much specialist knowledge. And I wholeheartedly agree with them, you shouldn't need to have programming skills to configure your editor. In the best case your editor has a configuration dialog.

And if somebody has the skills they should be able to use them, and for this we could implement something like the idea of hooks, that I put forward in the other comment.

Also see the issue I opened about adding an Easy mode #772 . It would make moe into a replacement for those simpler editors like nano, and vim at the same time. Distributions wouldn't have to make a choice between either installing nano or vim, with moe they would give the user both a simple tool and a power tool.

[juancarlospaco]

OnConfigLoadedScript = ~/.config/moe/onConfigLoaded.nim

Thats by all means a hardcoded callback, thats duplicating Nims include all over again, DRY.

You are contradicting yourself, first say you want to make an "swiss army knife" editor, then say you want to make a "Nano" clone, literally the opposite. :neutral_face:

[tobimensch]

OnConfigLoadedScript = ~/.config/moe/onConfigLoaded.nim

Is by all means a hardcoded callback, thats duplicating Nims include all over again, DRY.

It's not the same thing. One is a turing complete language, that you can't expect all users to like or want to know. The other is a decades old (TOML is basically like INI) configuration format, that even very inexperienced computer users will understand.

For one, I don't know why you classify it as hardcoded, since you could change the path to the script file. And if you don't like the name OnConfigLoadedScript we can find a better one. But the point is that this script would get loaded/run everytime the config is loaded or reloaded.

Your downvote to my other comment wasn't really convincing since I've not seen any argument, just a downvote. I didn't downvote the request for NimScript support, I'd just like to keep the default mode of configuration user friendly. User friendlyness is something that is severely lacking from vim, you have to read whole books in order to get proficient in it. There's definitely a payoff if you go through all of that, but not all people who're casual users of an editor should have to do this.

[tobimensch]

You are contradicting yourself, first say you want to make an "swiss army knife" editor, then say you want to make a "Nano" clone, literally the opposite.

First of all you're currently not arguing in a fair way. I didn't say that moe should become a nano clone. If you can point to where I said such a thing, then I will be surprised. The idea for an easy mode #772, which I had long before this issue #840 was opened, is not about cloning nano, it's about giving users who are not willing to go through the steep learning curve of vim another option, some simply don't have the time. But here's the key to why I think you're unfair here and not representing my words in context, nowhere did I imply or mean or say or write, that moe's features should be limited, taken away, or that they should only match nano. I previously opened a lot of issues requesting new features, if you can believe it. But, probably because of some emotions getting in the way, you're making very little effort to represent my thoughts correctly. I don't know why that's necessary, but please stop that.

So, a swiss army knife when it comes to the number of features and flexibility is not contradictory to offering new users (that don't fall into the advanced programmer category (or ex vim user category)) very user friendly configuration options and an easy mode.

[fox0430]

First of all, I will not delete toml support if add to support for NimScript.

I think need a config file like a script in the future. But I want the default config file to be toml. Because I want moe to be used by users who are don't know Nim or who are not good at programming. Scripts are certainly very good, but difficult for beginners to master. So I adopted toml at first. It should be able to adopt multiple types of configuration files. I want to add support EditorConfig besides toml.

I haven't thought about how to do it, but it should be able to make it available only to users who also want to use scripts such as NimScript.

[uninhm]

I think Lua is a good option for Moe's scripting. It's a language easy to embed.

[fox0430]

@unihernandez22

I have never used Lua. Do you think Lua is a good choice more than NimScript?

[juancarlospaco]

This project seems interesting, I have not tried it tho: https://forum.nim-lang.org/t/6971#43663

Besides Lua 1-indexed collections, tables-as-types, I think that Lua GC may get in the way of Moe ?, because from 1.4+ Nim should not use a traditional GC anymore with ARC/ORC, I dont know.

[uninhm]

Do you think Lua is a good choice more than NimScript? @fox0430

NimScript is more complex, so it's more difficult to embed.

[juancarlospaco]

Nim ↔️ NimScript easy data sharing with Nim native types is used on this project: https://github.com/beef331/nimscripter/blob/master/src/marshalns.nim

[beef331]

Was scrolling through the issues and seen this one, so just wanted to drop in and say that embedding Nimscript is very easy with atleast 1.4.0 onward and with my library is very quick to use/setup. You could ship a minimal stdlib with your editor so it doesnt pad the size too much, but if you implement it and are missing features or want changes feel free to reach out, it's only really been toyed around with by me, so happy to hear what others think.

[fox0430]

@beef331

Thank you for your advice. I will try using NimScript.

[beef331]

As I seen you want help with this I've started a fork to implement it, if you want to check it out build it using nimble dscript, copy the stdlib to ~/.config/moe/ and make a moe.nims in the config folder. Screenshot of current progress:

[fox0430]

@beef331

Amazing!!! I will try it!

[beef331]

Further progression, although with how some of your data is layed out Color specifically it's being a little big of a pain to work with, the macro ontop of color means I cannot directly expose colours atm.

[beef331]

The current state is, no more manual procs, all exposed code is generated using macros, this gives full control(atleast mostly full, some things arent exposed yet) of EditorSettings and ColorTheme through proc calls so it can read like the suggested code. It also outputs a name : Type for all exported procs to a nimscript.docs inside the moe config directory.