Add tiddler length to tiddler info panel

[RichShumaker]

Have the Tiddler Size listed in the Tiddler.

Rich Shumaker

[Jermolene]

This will require a new filter operator [length[text]] that returns the length of the text of a tiddler field/index.

[tobibeer]

Mhhh, had we this filter, how would we sort all tiddlers by it?

Perhaps something more like @Skeeve's lsort...

length macro and lsort filter @ tbdemo

...with the ability to also have it return the length for all matches so as to not be required to have an additional length macro.

[length[]] — calculate length
[length[sort]] — sort by length asc
![length[sort]] — sort by length desc
[length:field[]] — do any of the above for a named field

[Jermolene]

Mhhh, had we this filter, how would we sort all tiddlers by it?

It couldn't be used to sort by length. Rather than having a variant of the length filter operator that sorts, I think it would be better to extend the existing sort operator:

[tag[mytag]sort[!length(text)]]

[Skeeve]

I also thought about the idea to have something in the [] of sort, but as the filter syntax is too inconsistent, it won't work well.

If sort would accept the fieldname as colon-parameter, the brackets could be used for modifers. But it isn't that way and changing would break too much.

So I came up with lsort in the group:

lsort[] -> Sort by tiddler size (by length of its json-serialized form)
lsort[fieldname] -> sort by length of fieldname's value

/*\
title: $:/core/modules/filters/lsort.js
type: application/javascript
module-type: filteroperator

Filter operator for sorting

lsort[] : sort by tiddler size
lsort[fieldname] : sort by length of fieldname's value

\*/

(function(){

/*jslint node: true, browser: true */
/*global $tw: false */
"use strict";

/*
Export our filter function
*/

exports.lsort = function(source,operator,options) {
    var isDescending = operator.prefix === "!";
    var results = [];
    if(operator.operand === "") {
    source(function(tiddler,title) {
        var len = $tw.wiki.getTiddlerAsJson(title).length;
        results.push( { "title": title, "len": len } );
    });
    }
    else {
    source(function(tiddler,title) {
        var tdlr = $tw.wiki.getTiddler(title);
        var len = 0;
        if(tdlr) {
        len = (tdlr.fields[operator.operand] || "").length;
        }
        results.push( { "title": title, "len": len } );
    });
    }
    results.sort(function(a,b) {
    return isDescending ? b.len - a.len : a.len - b.len;
    });
    for( var i = results.length; i--;) {
    results[i] = results[i].title;
    }
    return results;
};
})();

And to get a length as text use this macro:

    /*\
title: $:/macros/skeeve/length.js
type: application/javascript
module-type: macro

<<length text>>

Examples:
<<length "sometext">>
<<length tiddler:"tiddlertitle">>
<$macrocall $name="length" text="sometext"/>
<$macrocall $name="length" tiddler={{!!title}}/>

\*/
(function(){

/*jslint node: true, browser: true */
/*global $tw: false */
"use strict";

/*
Information about this macro
This is a macro to get the length of a string/text or a tiddler.

For a tiddler's length the string-length of its JSON representation is used.
*/

exports.name = "length";

exports.params = [
    { name: "text" },
    { name: "tiddler" },
];

/*
Run the macro
*/
exports.run = function(text, tiddler) {
    if(!text) {
    if(!tiddler) {
        return 0;
    }
    text = $tw.wiki.getTiddlerAsJson(tiddler);
    }
    return text.length.toString();
};

})();

[Jermolene]

@Skeeve I see a connection with the requirement to support arithmetic expressions. One context for them is to embed them within filter strings, so I'm expecting that if we get that far we'll refactor the filter parsing code to better tolerate filter operands that are expressions.

[tobibeer]

I was just thinking that by adding a TEXT type to letfilter ...I might easily support a LENGTH operation... although, with no sorting either, yet.

I think your syntax...

[sort[!length(text)]]

...is perhaps a way to invent and address a "computed field" ...for things that are not truly fields in the sense of being set, but somewhat properties of a tiddler (and its components), i.e. text-length. Right now, I don't quite see any other "implicit properties"... perhaps a "field-type" could be such, where for given field-names there would be a lookup mechanism to qualify its type as any of TEXT, DATE, NUM, INT, BOOL, etc (ignore the case, if you must). So you could query...

[field[!type(DATE)]]

[Skeeve]

I think we should reconsider the filter syntax. @Jermolene this is a topic I'm interested in.

My idea would be to have a new filter attribute, let's call it "select" as a working title. The 2 attributes would have to be mutually exclusive. For "select" we would require a new parser I'd like to write. The resulting parsing tree should be compatible to the current parsing tree.

What I need to clearly understand is the parsing tree.

Then we need to come up with a generic syntax which shouldn't be as ad-hoc as the current one. Especially variables and macros should be considered in order to avoid quoting issues.

The new filter (select) syntax would first be a plugin.

@Jermolene: What do you think?

[Jermolene]

Hi @Skeeve

My idea would be to have a new filter attribute, let's call it "select" as a working title.

I agree that that is the best way for us to explore alternative filter syntaxes.

The resulting parsing tree should be compatible to the current parsing tree. What I need to clearly understand is the parsing tree.

I'm not sure that we'd need compatibility at the parse tree level. All we really need is for the compiled filter function to be compatible.

Then we need to come up with a generic syntax which shouldn't be as ad-hoc as the current one

Ad-hoc! What are you suggesting? 😄

I actually feel a lot more content with the current filter syntax than I did a year ago. It still needs extending in some specific areas, but I don't think it's worked out badly.

As I think I've said before, if we're going to explore different filter syntaxes then I think there's little value in inventing yet another brand new language. I'd rather explore re-using existing languages, be it JavaScript or Lisp.

But in any event, the main thing is to do some experimentation.

[Skeeve]

Am 04.12.14 13:24, schrieb Jeremy Ruston - notifications@github.com:

The resulting parsing tree should be compatible to the current
parsing tree. What I need to clearly understand is the parsing tree.

I'm not sure that we'd need compatibility at the parse tree level. All
we really need is for the compiled filter function to be compatible.

I thought that's the same… Proof that I need to understand it better.

Then we need to come up with a generic syntax which shouldn't be
as ad-hoc as the current one

Ad-hoc! What are you suggesting? 😄

:D Ad-hoc I'd say I'd formalize the current syntax better.

I actually feel a lot more content with the current filter syntax than
I did a year ago. It still needs extending in some specific areas, but
I don't think it's worked out badly.

I still have the feeling there are too many places where, for example,
field names are allowed. Sometimes it's in the brackets, sometimes it's
after the colon. I'd like to have that standardised.

Rough idea for a single expression: ? ( ":"
<text_reference_or_field> )* "[" ? "]"

As I think I've said before, if we're going to explore different
filter syntaxes then I think there's little value in inventing yet
another brand new language. I'd rather explore re-using existing
languages, be it JavaScript or Lisp.

Yes… I seem to remember ;)

So now I think, maybe the attribute could be "lisp" and then we have a
stripped-down lisp implementation.

But in any event, the main thing is to do some experimentation.

Is the compiled filter described somewhere?

[Jermolene]

Is the compiled filter described somewhere?

You can see a compiled filter by running this:

$tw.wiki.compileFilter("HelloThere")

It's a function with two arguments, a source iterator that yields the titles to be filtered, and a reference to the widget in whose context the filter should be evaluated (eg used for evaluating variables).

The source iterator is a function that takes a single argument, a reference to a callback that is called with two arguments: a reference to each tiddler, and the title of the tiddler. The iterator invokes the callback once for each tiddler in the source.

[Skeeve]

Am 05.12.14 20:56, schrieb Jeremy Ruston - notifications@github.com:

Is the compiled filter described somewhere?

You can see a compiled filter by running this:

|$tw.wiki.compileFilter("HelloThere")|

This gives filterFunction(source, widget)

:( Not anything useful at the moment.

[Jermolene]

Try it in Chrome, it shows the source of the function, which is handy.

[Skeeve]

Am 05.12.14 21:20, schrieb Jeremy Ruston - notifications@github.com:

Try it in Chrome, it shows the source of the function, which is handy.

I can't. OS X 10.5.8 is not supported.