Re: [code] [textadept] Proposed API Changes

From: Ryan Pusztai <rpusztai.att.gmail.com>
Date: Tue, 19 Mar 2013 13:59:32 -0400

Hi Mitchell,

On Tue, Mar 19, 2013 at 12:39 PM, Robert <rob.g.att.web.de> wrote:

> Hi Mitchell,
>
> On Tue, Mar 19, 2013 at 4:52 PM, Mitchell <m.att.foicica.com> wrote:
> > I've been contemplating changes to the API:
> >
> > + Add lfs.dir_foreach(utf8_dir, f, filter, exclude_FILTER)
> > Iterates over all files and sub-directories in the directory
> > *utf8_dir*, calling function *f* on each file found.
> > *filter* and *exclude_FILTER* are identical to
> > _M.textadept.snapopen.open()'s respective parameters.
> > [...]
> > If *f* returns `false` explicitly, iteration ceases.
>
> A very useful function. How about not attaching this to the `lfs`
> module but the `io` module? The `lfs` module feels more "third-party"
> to me and it could be confusing.
>

Agree.

> > + Add io.MAX or io.SNAPOPEN_MAX
> > Same documentation as _M.textadept.snapopen.MAX
>
> I think SNAPOPEN_MAX makes it clearer where this constant belongs to.
>

Agree.

Can we also add a constant for width of the dialog. Or allow the snapopen
to have that passed into the function. I am very limited by the default
width, and right now, am forced to duplicate the snapopen module to allow
me to change the width.

> + Add io.snapopen(utf8_paths, filter, exclude_FILTER)
> > Same documentation as _M.textadept.snapopen.open.
> > - Remove _M.textadept.snapopen.DEFAULT_DEPTH
> > It was 99 anyway and MAX is probably more useful.
> > - Remove _M.textadept.snapopen
> > Moved functionality into core `io`.
> > ? io.snapopen's *utf8_paths* should be a '\n' separated string of
> > paths and no longer accepts a table (pass result of table.concat()
> > instead). This is consistent with io.open_file() which also accepts
> > '\n' separated files and not a table.
>
> Probably doesn't matter much and is easy to convert from string to
> table, but how about changing `io.open_file` to use a table?
>

I like the accept a table idea as well.

> >
> > Would these changes negatively impact anyone's modules? (e.g. textredux)
> > Obviously it would impact key bindings, but that is relatively minor.
>
> I don't think there should be a problem with Textredux or any other
> module I maintain.
>

Well I would have to copy and update the snapopen implementation in my
stuff to support 'width', but if that were included I would fall back to
relying on the default implimentation in the "common.display_filename"
module (I really appreciate the HOME path substitusion. Makes my paths
shorter as well.).

--
Regards,
Ryan
-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Tue 19 Mar 2013 - 13:59:32 EDT

This archive was generated by hypermail 2.2.0 : Wed 20 Mar 2013 - 06:39:52 EDT