API for zsh5.3 concerning ISEARCHMATCH_ACTIVE

API for zsh5.3 concerning ISEARCHMATCH_ACTIVE

[m0viefreak]

ZSH currently knows 5 specific highlighters in the zle_highlight array:

region, suffix, isearch, paste, special

While 'special' is a bit 'special', the first four are all very
straight-forward and directly related to positions in the current BUFFER.

To be able to work with the positions of these highlighters inside user
defined widgets such as zsh-syntax-highlighting, they need to be exposed
in some way.

In zsh5.2 only two of them are:

  paste:
  YANK_ACTIVE (integer)
  YANK_START (integer)
  YANK_END (integer)

  region:
  REGION_ACTIVE (integer)
  MARK (integer)
  CURSOR (integer)

I submitted a patch to support the other two, as well:
http://www.zsh.org/mla/workers/2016/msg00680.html

So in the current development version there is also:

  isearch:
  ISEARCHMATCH_ACTIVE (integer)
  ISEARCHMATCH_START (integer)
  ISEARCHMATCH_END (integer)

  suffix:
  SUFFIX_ACTIVE (integer)
  SUFFIX_START (integer)
  SUFFIX_END (integer)


However there are some points up for discussion:

1) isearch is a bit different from the others and one might also be
interested in the actual matched part of the BUFFER. So instead of only
exposing _ACTIVE _START and _END, it would be possible to actually
expose the MATCH itself instead:

  ISEARCHMATCH (scalar)
  ISEARCHMATCH_START (integer)
  ISEARCHMATCH_END (integer)

The "active" check would then essentially be a nonzero-check.

2) There are already some related paremters exposed that don't use the I
at the beginning of the name:

  LASTSEARCH (scalar)
  LASTABORTEDSEARCH (scalar)

Should we possible leave out the I as well?:

  SEARCHMATCH_ACTIVE (integer)
  SEARCHMATCH_START (integer)
  SEARCHMATCH_END (integer)

instead?

Note however that LASTSEARCH and LASTABORTEDSEARCH are fundamentally
different, since they describe a zle state of the past, while ISEARCH_*
aim to describe the present.


I for one like the way that all four of those special highighting
regions have a similar (integer-based) API. It is easy to reconstruct
the actual MATCH from BUFFER, _START, and _END, and we don't need to
make changes to the C code.

Are there any preferences as to what the API for zsh5.3 should be like?

--
m0vie