Re: [code] [textadept] Proposed API Changes

From: Mitchell <>
Date: Tue, 19 Mar 2013 21:32:02 -0400 (EDT)


On Tue, 19 Mar 2013, Ryan Pusztai wrote:

> Hi Mitchell,
> On Tue, Mar 19, 2013 at 12:39 PM, Robert <> wrote:
>> 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.
> Agree.

I had given a lot of thought to `io`, but iterating over directories
without reading or writing to files doesn't feel like `io`. I also don't
feel like it fits when looking at the current `io` API.

What about `os.dir_foreach()`? But that doesn't exactly feel right

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

Sure. The API would be `io.snapopen(utf8_paths, filter, exclude_FILTER,
...)` where `...` will be passed to `gui.filteredlist()`. Therefore
`io.snapopen('foo', nil, false, '--width', 500)` should set the width of
the dialog. That shouldn't be too much trouble.

>> + 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?
> I like the accept a table idea as well.

`io.open_file()` needs to accept '\n' delimited files because of the
return value from `gui.dialog('fileselect', ..., '--multiple')`. I will
consider allowing both types in both functions though.

Thanks for the feedback Robert and Ryan.


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 - 21:32:02 EDT

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