Re: MPSL Command Documentation

On Mon, Dec 31, 2007 at 03:25:23PM -0500, Lee Page wrote:
> Hi Angel,
>
> I have set up the following page.  Would you mind looking over it and 
> giving any suggestions that come to mind?
>    http://growler.homelinux.org/mp_user_contrib/

Hi, Lee. You page is very interesting, I'm going to add a link from the
MP's page and announce it to the mailing list.

> Also, I have some questions/requests about MP:
>
>        * *Read only files don't seem to be regarded. * It looks like
>          you move the old file out of the way, save the current
>          version, and then copy the permissions of the old file onto
>          the new version.  Does MP not regard the write permission?

Yes, MP allows to modify read-only files, and it's intentional. Certainly,
the process is more or less the one you described: the original file is
deleted, rewritten and its original permission bits restored.

May be it's not a very orthodox behaviour, but I find it useful while
modifying system files as root and such. I don't really mind what the
permissions are, just modify the darned file and go on (but, of course,
leaving the permissions exactly the same). But not only as root; I want my
own files keep their permissions, but don't want to be bothered with
changing permissions just to modify a file.

Of course, UNIX semantics are kept by the system itself, and nothing of
this can be done if you're not the owner of the file (and you are not
root). In this case, when trying to save a modified file, the writing
fails, an alert is triggered and the file name inside MP is set to
<unnamed>.

There is more than that on overwriting files: there is a configuration
directive, mp.config.unlink, that controls the way of writing files: if
it's set (and it is by default), the overwriting behaviour is as I
described above; if it's set to 0, no unlinking is done and the file is
just truncated and overwritten. I don't really like this way of working,
but some people may expect it. The 'unlink before writing' is very useful
because it breaks hard links and allows you to have different copies of
files.

>        * *Detecting that a file has changed.*  It would be easy to
>          modify through another editor a file that MP has opened.          
> Could you make MP detect that a file has been touched outside
>          of the editor?

Do you usually do this kind of thing? I'll try to find a way of detecting
external modifications, but I'm not sure if it's something very useful.

>        * *Removing the default of auto-saving files on close.*          
> Sometimes I don't want to have all files auto-saved.  It would
>          be nice if I could asked on exit if I wanted the files saved
>          or not.

I'll think about it, but I don't see why this is a problem. Do you usually
modify many files and later decide to not save them? Are those files that
many that replying 'no' to the 'file modified. Save?' question is an
annoyance?

>        * *Backup files.*  I'd like to see a ".bak" file made each time
>          I open up a file in MP, or each time I save a file.  Either
>          way would be helpful.

I personally don't like them, but backup files are undoubtedly useful.
I'll implement them.

>        * *Using fully qualified paths for doc.name.*  I have had a
>          single file opened up in two separate buffers using MP simply
>          by referring to it by both the relative name and the absolute
>          name.  This could cause data corruption.

Yes, this is a problem I'll also recently found. There is some mechanism
to avoid it, but when you open a file from the command line and later open
from the 'open' dialog, both are not detected as the same one. Certainly
this must be fixed.

> I have also updated the MP command reference doc as I have been learning 
> the editor.  Would you mind replacing the current one with this one?

Of course; I've done it. Thanks again.

On this, I've started to document each MP function using my 'mp_doccer'
format inside the source code (see, for example, the mp.break_line()
function in mp_edit.mpsl from the latest Git sources). This is useful as
the documentation is always near the function and makes easier to update
the documentation in the case the function behaviour changes. It won't be
ready soon, but I'll use your document as a guideline. Once it's finished,
it will no longer be necessary to maintain your document separately, as it
will be automatically extracted from the sources.

Regards and thanks again,

-- 
Angel Ortega
http://www.triptico.com



-- 
To unsubscribe, send mail to mp-unsubscribe_lists.triptico.com.