add presets scaffold; enhance lucky word functions in welcome panel; prepare for custom shells functions

[ltaoist]

Add a scaffold for read and use users custom presets.

For the welcome panel, I have test the lucky word would work; however it may not a good typograph, so it may need a further consider or design.

I don't yet have a clear idea how should multiple shells customized. I thinks users can write some indexed preset in the preset file, and pass some name in editing, for guiding how to run multiple shells.

Maybe it will good for a discussion a more manner way to setup presets; for example, a helping window that gen presets file and recover.

[tomlin7]

@ltaoist this sounded like a mix of extensions and a startup/init file (like vimrc in case of vim). But having it this way sounds kinda redundant, since extension manager is already there, and community can make their extensions too. Now if you are talking about a startup/init file like vimrc, then its a really nice idea and has been proposed before Here #68 (but havent worked on it).

[tomlin7]

This idea is nice actually, but you will only have to check for one startup file, not multiple ones that would be too much ig. Try considering this, I'll review again.

[ltaoist]

@billyeatcookies come on. Yes It functions like some initiate script, but with more considered: don't configure by verb but configure by noun . Philosophically, configure by what; or declaration, not configure by how; or calling. So I chose a name "preset".

(configure by noun may be not a good idea; I doubt on this.)

I had been a emacs user in about 2011-2014, I know that as a emacs user, one can run many even quirks lisp code in a init file, it was powerful although you should write a new editor in your init file. So I privately reject such a design. I thinks the setting dialog and extendsion api should be enough not by a init file.

However, it do need a "user private" ground. So I chose a name "preset".

I am not clear about "multiple ones". Is it means that the overlap between config manager, setting dialogs and such A preset files? Actually it now has not overlap instance; but may be some overlap in concept between their response edge.

As the preset itself, it should be and it is A files. I split them into difference example; but finally should just A preset file. I prompt that the point is not about how many files, the point is there should be a integrated way in meta methodology.

In other side, if we read and use the preset file randomly in many lines in many files, it do may some twist. Is this is not acceptable?

In conclusion, Key Points may be clarify further:

(a) Is a parallel preset file with config manager, setting dialogs and extension manager acceptable? It not, how to control the "user private" ground problem? More concretely, where to store the difference version setting of shells? #213

(b) What is the means "multiple ones startup files"? For a simplified production version, how should I do?

[tomlin7]

@ltaoist as the extension manager already exists, why should we add this presets feature. Don't extensions already do this?

[tomlin7]

@ltaoist after a discussion with some contributors, I think we should remove the config manager (which is not functional right now, so dont worry I will remove it soon); and add this startup-file based system in place.

now by "multiple files" i meant that you should keep only one startup file, lets call it .cookie file, only that will be loaded at startup and run using the mechanism you have in place. So, remove the checks for all the "presets" and check if this .cookie file exists, and if it does, then load it, run it :)

awesome idea though, I just had trouble picking which would be the best choice! ❤️

[ltaoist]

@billyeatcookies Seems that some consideration had made. I think this is good. I also had trouble which would be the best :-O

I feel difficult for a further discussion ; it is verbose. Take it easy, I will serve here ; more instructions or suggestions would not be blamed. Good luck!

[ltaoist]

I think this issue take a long time for resolving; it may be good to close it now, for there may be a better Interpret.

Good Luck!

[tomlin7]

@ltaoist sorry for the delayed reply, but I think the init file is a good idea, so that's why i kept #68 open. But the approach here is not quite right. I'll keep you updated on this issue! Thanks for the contributions ❤️