Re: [code] [textadept] New Filter Format

From: Mitchell <>
Date: Mon, 26 Nov 2018 17:19:09 -0500 (EST)


On Mon, 26 Nov 2018, Mitchell wrote:

> Hi,
> On Tue, 16 Oct 2018, johannes wrote:
>> Hi Mitchell,
>> is it possible to add some kind of whitelist to the filter of
>> 'find_in_files'
>> ? E.g. parameters like 'included_dirs' and 'included_extensions'.
>> For example if you have a library folder to search through, e.g.
>> dir='/path/to/lib'. Then only files with extension in 'included_extensions'
>> and dirs in 'included_dirs' would be take into account. 'included_dirs'
>> would
>> be like this: {'/path/to/lib/subfolder1', '/path/to/lib/subfolder2'}.
>> As an alternative it would be ok, to add an boolean parameter 'whitelist'
>> to
>> the filter. If false, then the filter behaviour is like now. If true, all
>> filters would be inverted.
> I've committed a new filter[1] format that should be flatter and more
> intuitive. It will be in the next nightly build. From the new LuaDoc:
> A filter consists of Lua patterns that match file and directory paths to
> include or exclude. Exclusive patterns begin with a '!'. If no inclusive
> patterns are given, any path is initially considered. As a convenience,
> file extensions can be specified literally instead of as a Lua pattern
> (e.g. '.lua' vs. '%.lua$'), and '/' also matches the Windows directory
> separator ('[/\\]' is not needed).
> For example, a simple filter that accepts only '.lua' and '.c' files would
> look like this:
> local filter = {'.lua', '.c'}
> A filter that rejects anything in a directory called 'build', but accepts
> everything else might look like this:
> local filter = {'!/build'} -- or simply '!/build' without the {}
> A filter that looks for only '.lua' files within the directories 'foo/bar'
> and 'baz/quux' might look like this:
> local filter = {'.lua', 'foo/bar', 'baz/quux'}
> Finally, a filter that looks for anything other than '.luac' files within
> those same directories might look like this:
> local filter = {'!.luac', 'foo/bar', 'baz/quux'}
> Essentially, any inclusive patterns (patterns that do not begin with '!') are
> treated as logical OR and any exclusive patterns (patterns that begin with
> '1') are treated as logical AND. The order of filter items does not matter
> though.
> I hope this all makes sense.
> For the sake of compatibility, Textadept should be able to handle the
> old-style filter format, but it will warn you with a dialog that you should
> update your filters. That dialog provides a stack trace to pinpoint where the
> filter is coming from.

Oh, and for examples of how to migrate old filters to the new filter format, here's an example:

For the most part it just involves stripping a '!' prefix if it exists, or adding one if it does not.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Mon 26 Nov 2018 - 17:19:09 EST

This archive was generated by hypermail 2.2.0 : Tue 27 Nov 2018 - 06:54:34 EST