VIM the editor

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 3 4 (5) 6 7 »

broadblues

Re: VIM the editor

Posted on: 2019/5/8 10:15 #81

Home away from home

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

Blender For OS4.x : Blues : Walker Broad

kas1e

Re: VIM the editor

Posted on: 2019/5/8 12:31 #82

Home away from home

@broadblues
Quote:

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

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:


/*

 * Open a swap file for a memfile.

 * The "fname" must be in allocated memory, and is consumed (also when an

 * error occurs).

 */

    static void

mf_do_open(

    memfile_T    *mfp,

    char_u    *fname,

    int        flags)        /* flags for open() */

{

#ifdef HAVE_LSTAT

    stat_T    sb;

#endif



    mfp->mf_fname = fname;



    /*

     * Get the full path name before the open, because this is

     * not possible after the open on the Amiga.

     * fname cannot be NameBuff, because it must have been allocated.

     */

    mf_set_ffname(mfp);

#if defined(MSWIN)

    /*

     * A ":!cd e:xxx" may change the directory without us knowing, use the

     * full pathname always.  Careful: This frees fname!

     */

    mf_fullname(mfp);

#endif



#ifdef HAVE_LSTAT

    /*

     * Extra security check: When creating a swap file it really shouldn't

     * exist yet.  If there is a symbolic link, this is most likely an attack.

     */

    if ((flags & O_CREAT) && mch_lstat((char *)mfp->mf_fname, &sb) >= 0)

    {

    mfp->mf_fd = -1;

    emsg(_("E300: Swap file already exists (symlink attack?)"));

    }

    else

#endif

    {

    /*

     * try to open the file

     */

    flags |= O_EXTRA | O_NOFOLLOW;

#ifdef MSWIN

    /* Prevent handle inheritance that cause problems with Cscope

     * (swap file may not be deleted if cscope connection was open after

     * the file) */

    flags |= O_NOINHERIT;

#endif

    mfp->mf_fd = mch_open_rw((char *)mfp->mf_fname, flags);

    }



    /*

     * If the file cannot be opened, use memory only

     */

    if (mfp->mf_fd < 0)

    {

    VIM_CLEAR(mfp->mf_fname);

    VIM_CLEAR(mfp->mf_ffname);

    }

    else

    {

#ifdef HAVE_FD_CLOEXEC

    int fdflags = fcntl(mfp->mf_fd, F_GETFD);

    if (fdflags >= 0 && (fdflags & FD_CLOEXEC) == 0)

        (void)fcntl(mfp->mf_fd, F_SETFD, fdflags | FD_CLOEXEC);

#endif

#if defined(HAVE_SELINUX) || defined(HAVE_SMACK)

    mch_copy_sec(fname, mfp->mf_fname);

#endif

    mch_hide(mfp->mf_fname);    /* try setting the 'hidden' flag */

    }

}

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:


/*

 * Close the swap file for a memfile.  Used when 'swapfile' is reset.

 */

    void

mf_close_file(

    buf_T    *buf,

    int        getlines)    /* get all lines into memory? */

{

    memfile_T    *mfp;

    linenr_T    lnum;



    mfp = buf->b_ml.ml_mfp;

    if (mfp == NULL || mfp->mf_fd < 0)        /* nothing to close */

    return;



    if (getlines)

    {

    /* get all blocks in memory by accessing all lines (clumsy!) */

    mf_dont_release = TRUE;

    for (lnum = 1; lnum <= buf->b_ml.ml_line_count; ++lnum)

        (void)ml_get_buf(buf, lnum, FALSE);

    mf_dont_release = FALSE;

    /* TODO: should check if all blocks are really in core */

    }



    if (close(mfp->mf_fd) < 0)            /* close the file */

    emsg(_(e_swapclose));

    mfp->mf_fd = -1;



    if (mfp->mf_fname != NULL)

    {

    mch_remove(mfp->mf_fname);        /* delete the swap file */

    VIM_CLEAR(mfp->mf_fname);

    VIM_CLEAR(mfp->mf_ffname);

    }

}

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.

Edited by kas1e on 2019/5/8 13:16:28

Join us to improve dopus5!
AmigaOS4 on youtube

Petrol

Re: VIM the editor

Posted on: 2019/5/13 20:48 #83

Just popping in

Thank you for your work!

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

Regards,

redfox

Re: VIM the editor

Posted on: 2019/5/15 4:06 #84

Quite a regular

@kas1e
@sTix

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

Thanks to all involved with this project.

redfox

sTix

Re: VIM the editor

Posted on: 2019/5/15 9:26 #85

Just popping in

@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

kas1e

Re: VIM the editor

Posted on: 2019/5/16 6:42 #86

Home away from home

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

Join us to improve dopus5!
AmigaOS4 on youtube

sTix

Re: VIM the editor

Posted on: 2019/5/16 9:42 #87

Just popping in

@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 ;)

walkero

Re: VIM the editor

Posted on: 2019/5/16 11:09 #88

Site Builder

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.

Follow me on
Ko-fi, Twitter, YouTube, Twitch

MichaelMerkel

Re: VIM the editor

Posted on: 2019/5/16 11:28 #89

Not too shy to talk

@kas1e

Quote:

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

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

Michael Merkel

(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

trixie

Re: VIM the editor

Posted on: 2019/5/16 12:26 #90

Amigans Defender

@MichaelMerkel

Quote:

what currently is not ok is the required assign. this needs to be removed. special assigns for applications should be forbidden.

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

The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

sTix

Re: VIM the editor

Posted on: 2019/5/16 14:01 #91

Just popping in

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

kas1e

Re: VIM the editor

Posted on: 2019/5/16 14:12 #92

Home away from home

@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 :)

Join us to improve dopus5!
AmigaOS4 on youtube

sTix

Re: VIM the editor

Posted on: 2019/5/16 14:16 #93

Just popping in

@walkero

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

sTix

Re: VIM the editor

Posted on: 2019/5/16 15:37 #94

Just popping in

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

kas1e

Re: VIM the editor

Posted on: 2019/5/31 5:47 #95

Home away from home

@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 ! :)

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: VIM the editor

Posted on: 2019/12/30 13:02 #96

Home away from home

@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 ?:)

Join us to improve dopus5!
AmigaOS4 on youtube

sTix

Re: VIM the editor

Posted on: 2019/12/31 0:38 #97

Just popping in

@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

Skateman

Re: VIM the editor

Posted on: 2019/12/31 11:10 #98

Not too shy to talk

@sTix
@kas1e
@ (all other Devs)

Thanks a lot for all the hard work done!!

AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 550 / ATI X1950 / M-Audio 5.1 -> AmigaOS 4.1 FE / Linux / MorphOS
Amiga 1200 -> Recapped / PiStorm CM4 / SD HDD / WifiPi connected to the NET
Vampire V4SE TrioBoot
RPI4 AmiKit XE

Thematic

Re: VIM the editor

Posted on: 2020/1/20 12:22 #99

Quite a regular

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?

Edited by Thematic on 2020/1/20 12:44:29
Edited by Thematic on 2020/1/20 12:45:40

Thematic

Re: VIM the editor

Posted on: 2020/3/6 2:49 #100

Quite a regular

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.

Register To Post	« 1 2 3 4 (5) 6 7 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )