Re: [code] [textadept] Proposed API Changes

From: Robert <>
Date: Tue, 19 Mar 2013 17:39:58 +0100

Hi Mitchell,

On Tue, Mar 19, 2013 at 4:52 PM, Mitchell <> 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
>'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.

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

> + Add io.snapopen(utf8_paths, filter, exclude_FILTER)
> Same documentation as
> - 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?

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

My three cent,

You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Tue 19 Mar 2013 - 12:39:58 EDT

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