From: m0viefreak <m0viefreak.cm@googlemail.com>
To: zsh-users@zsh.org
Subject: API for zsh5.3 concerning ISEARCHMATCH_ACTIVE
Date: Tue, 10 May 2016 23:08:28 +0200 [thread overview]
Message-ID: <5efd6dc3-6779-4fe4-28c4-176536c8700d@googlemail.com> (raw)
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
reply other threads:[~2016-05-10 21:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5efd6dc3-6779-4fe4-28c4-176536c8700d@googlemail.com \
--to=m0viefreak.cm@googlemail.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).