VarDiffString looks for "/" and treats the prefix it separates as a message, so "diff1/abcd"

[rkuivila]

performs VarDiffString::diff1 and then updates the string "abcd"

[LFSaw]

I'd rather not add this to value, makes things unnecessarily difficult. Why not have a separate method, or a predicate (i.e. 2nd argument) for value?

then, for convenience, its use could be encoded in the preprocessor directive:

t = Steno.push(s)

--1/ ababaaa // use directive 1
--3/ abadgaa // use directive 3

not so sure about naming of the diff algorithms, though...

[telephon]

Yes, I agree. Perhaps we should add a class that makes it easier to define ones own pre processor for steno.

In this case I thought that is a reasonable step in the development process to just take this as it is, because VarStringDiff is currently a playground for experimenting with diff algorithms.

As soon as we find that it is stable enough to fully integrate it, we definitely should refactor it. It is a logical extension of the former implementation of "!". The preprocessor can externally select diff algorithms, if it turns out to be a good idea to be able to select them from within the steno code.

[LFSaw]

Sounds like a good plan :)

Just as a heads-up: I'll use Steno for workshops with students and, as part of a larger framework, a piece that I'll perform mid-December. I have difficulties to keep track of these breaking changes while trying to keep up eliminating show-breaking bugs (see e.g. #42). I'd suggest to develop such major advancements in a parallel branch (where it is easy to test and code interfaces can be thought and discussed through) before committing it to master. Unfortunately, I only realised that I replied to an email by Ron that I thought was linked to the GH tracker but instead was a privat email by him... This lead to that my comment on the issue appeared here only after you merged...

On 23. Nov 2017, at 08:44, Julian Rohrhuber notifications@github.com wrote:

Yes, I agree. Perhaps we should add a class that makes it easier to define ones own pre processor for steno.

In this case I thought that is a reasonable step in the development process to just take this as it is, because VarStringDiff is currently a playground for experimenting with diff algorithms.

As soon as we find that it is stable enough to fully integrate it, we definitely should refactor it. It is a logical extension of the former implementation of "!". The preprocessor can externally select diff algorithms, if it turns out to be a good idea to be able to select them from within the steno code.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[telephon]

sounds good!

I have difficulties to keep track of these breaking changes while trying to keep up eliminating show-breaking bugs

Evidently, there are still some bugs in the current version, especially things like #39. I don't know - will they make your life difficult? We should be able to fix them, but it needs a bit of quiet thinking and solid testing.

[rkuivila]

Hi guys,

The basic question here is the kind of tool VarDiffString (or whatever) is supposed to be. My experience is that having it provide a callback interface actually makes things more difficult. And you are running into the same issue with the preprocessor issue.

So, why not replace (Var)DiffString with a simpler StringMapper class. Its role would be to encapsulate different mapping algorithms in an extensible way and provide mappings. A much simpler and more focused tool. It make the Steno code less complex as the callbacks in initDiff would be code in the iteration of the mapping array.

The Preprocessor class could have a similar tight focus (strip off preprocessor commands and return them to the caller).

These tools would be easier for others to use and make the Steno code more readable.

RJK

[LFSaw]

Evidently, there are still some bugs in the current version, especially things like #39. I don't know - will they make your life difficult? We should be able to fix them, but it needs a bit of quiet thinking and solid testing.

I think I'm fine for now... maybe we can have a look at it next week?

[telephon]

yes, let's try that.