Re: bug with camel case and delete-whole-word-match function

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sun, 24 Jul 2016 01:06:02 +0200
Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> On 5 Jul, Peter wrote:
> > If you have "ThisIsSomeWords"
> 
> > However, if you're on the "S", you get "Is" before and "Some" after.
> > Again there's no white space, so there's nothing to indicate to the
> > calling function that these are two separate words rather than bits of
> > the same word.  So I think we'd need to add some extra signalling from
> > match-words-by-style to indicate "I'm at a word start" whether or not
> > there's white space, which needs some thinking about.
> 
> Do we need to keep the existing seven elements of matched_words
> unchanged for backwards compatibility? Not that I can think of a
> particularly obvious way to augment it for this case. May be just
> a 1/0 indicator for start of word is the simplest. It also seems
> to lack having a <whitespace before the word> field.

Yes, something like that.  I was wondering if it was time to keep the
current way for backward compatibility but switch to a keyword-based
(associative array?) system for future enhancements.

> One is that if the cursor is in the middle of a block of whitespace
> at the end of the line, the 4th element (whitespace after cursor)
> is empty while element 7 contains the whitespace.
> A similar issue occurs at the start of the line - element 1 contains
> whitespace while element 3 doesn't.

Might simply not be using an inclusive enough type of white space?

pws