@kas1e

Hmm that's interesting.

the SetProtect() function is called during the filehandle / descriptor close call as far as I recall.

Which files get the wrong protection bits and how are they created / manipulated by the prgram?

@broadblues
Quote:

It is swap files created by VIM when you editing main file. Swap files start with "." and ends with .swp.

Vim sources pretty big ones, so i can be wrong, but as far as i can see logic for creating/closing of swap files , they just use open()/close() calls.

At least in the https://github.com/vim/vim/blob/master/src/memfile.c

I can see:

Open swap file:



There is used mch_open_rw() for actual opening, and this one is defined in macros.h , like this:

#define mch_open_rw(n, f) mch_open((n), (f), 0)

which in turn defined in the vim.h like this:

# define mch_open(n, m, p) open((n), (m), (p))

Close swap file looks like this:



and then mch_remove() it's just :

#define mch_remove(x) remove((const char *) x)


I do not know when bits exactly gots cleared.. Visually on closing : so i tried to comment out all "close" functions in that memfile.c which i link above and while when exit from VIM bits still cleared, when i operate with tabs , and close tabs (without exit from Vim), then bits start to be _not_ cleared.

Probabaly when VIM exit fully its doing something else, not only those "close" functions from memfile.c, but at least that commenting out those close functison make closing of tab in VIM not clear the bits , mean that its indeed related to close() things too.

Thank you for your work!

I modified the script by adding a assign to runtime like this
'assign >nil: vim: runtime'

Regards,

@kas1e
@sTix

Very nice indeed. I downloaded today to try her out.

Thanks to all involved with this project.

redfox

@redfox

I've started to migrate the whole thing to GitHub. There's still some work left on the installer to make it work on all platforms but building it should work.

It would be great if there are people interested in becoming a collaborator / creating pull requests.

https://github.com/sodero/MUI-Vim

@sTix
Are you sure we need installers at all ? Classic "unpack&run" was always better, and all choice can be done from makefiles when pack lha ?

@kas1e

I think it's nice to have an installer. It makes it possible for the user to do choices after build time, choosing toolbar themes for example, handling .vimrc, perhaps installing plugins and so on. It also makes it possible to create a single archive for all platforms, without the user having to manually pick binaries.

Of course it's not strictly necessary, it's still possible to do an "unpack and run" installation for users who wish to do so. And I kind of like writing installers anyway ;)

Maybe a configuration app would be better for that. Think about it. The user makes a default installation really fast, and there is a configuration application that helps him enable/disable things through a GUI. This can be independent project as well.

@kas1e

Quote:

no installer please. unpack + copy folder to any destination.
what currently is not ok is the required assign. this needs to be removed. special assigns for applications should be forbidden.

regards...
michael

@MichaelMerkel

Quote:
Yes, a special assign is rarely needed, PROGDIR: should cover it nicely for the majority of applications.

@trixie

Indeed, it's just that "VIM:" is used by the part of Vim that I haven't touched (and have been for many many years) and I try to do as little patching as possible.

About the installer; like I said, having an installer doesn't make it impossible to not use it.

@sTix

With current installer there still will be problems for at least icons, which renamed with underscore at end, so unpack and run will fail a bit.

Anyway, if you doest mind, i can handle amigaos4 version easy, where we will have no installer at all (as seems everyone prefer it that way, and mason icons are default). For morphos and aros it can be used as before, so all happy. What you think ?

Also we can made ticket on github about "get rid of vim assign and replace all on progdir where need it". If you think is worth of :)

@walkero

I'm not to keen on writing an application like that. The possible number of options would be infinite. This is Vim ;)

@kas1e

Yes, it won't work as it is now. You could create an OS4 build target if you'd like to handle the OS4 icon / toolbar at build time.

Regarding "unpack and run": Does lha on OS4 handle symlinks? I might be doing something wrong here, but creating symlinks like evim -> vim (to start vim in simplified mode) doesn't seem to work on MorphOS.

What is the value of PROGDIR: when using symlinks?

@All
sTix has migrated project to github, and we add all changes done for os4 version, together with makefiles and co.

So, anyone can go there:

https://github.com/sodero/MUI-Vim/

And if want to build latest os4 version, doing that:

cd muivim/src
make -f Make_aos4_clib2.mak

The current difference between latest public releases (including os4 one), is that there we already add stack cookie (so no more crashes when use some stack-hungry plugins, like Hollywood one for example), as well as Ola update some days ago main vim's code base to fresh one.

Thanks to him ! :)

@all
There was a new release week ago of new vim, which now includes amigaos4 build by default as well, so sTix deal with all automation and archives ready for all platforms at the same time now.

Grab it from os4depot (in upload query for now).

You can check https://www.vim.org/vim-8.2-released.php to see what new.

Kudos to sTix who maintain it all!

@sTix
Any chance that you will look into adding real-mui-scrollbar support ?:)

@kas1e

About the scrollbars; I'm quite busy with other things right now so it's low prio for me I'm afraid. I'm not saying never though, but don't hold your breath while waiting for it

@sTix
@kas1e
@ (all other Devs)

Thanks a lot for all the hard work done!!

How do I use digraphs (combine two characters)?

The methods described in the built-in help do not work for me.
I looked into that a little because dead keys are completely ignored and the clipboard doesn't do as I'd expect. So if any of these is a simple thing I don't care about the rest.

":keymap" doesn't do anything other than complain about trailing characters, maybe this vim doesn't use it?

I found an easy to reproduce bug with December version. Well, I think it is. Iconify the editor, it doesn't matter if there's a document open. Use Exchange to "remove it". It will quit, but produce a DSI, too. So when you tell Grim Reaper to let it go, it seems to do so. I didn't look at RAM.