Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160423153356.ZM6960@torch.brasslantern.com>
Date: Sat, 23 Apr 2016 15:33:56 -0700
In-Reply-To: <20160423213607.GB1405@tarsus.local2>
Comments: In reply to Daniel Shahaf <d.s@daniel.shahaf.name>
        "Re: [PATCH] Expose isearch and suffix regions to widgets." (Apr 23,  9:36pm)
References: <1457905871-2808-1-git-send-email-m0viefreak.cm@googlemail.com> 
	<CAH+w=7Z-xQKMoNVK2MeOyj1ND22B8-yceU8FSfCp3xm6kyKEzQ@mail.gmail.com> 
	<CAH+w=7a=z+BnQmv027+4+3=KCEGXgtVf7hs+aSp+aVqKLJnebQ@mail.gmail.com> 
	<570A50CF.2000600@googlemail.com> 
	<20160411061647.GA5368@tarsus.local2> 
	<160411072508.ZM24168@torch.brasslantern.com> 
	<571265A4.9040000@googlemail.com> 
	<20160423213607.GB1405@tarsus.local2>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] Expose isearch and suffix regions to widgets.
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Apr 23,  9:36pm, Daniel Shahaf wrote:
}
} m0viefreak wrote on Sat, Apr 16, 2016 at 18:17:40 +0200:
} > I think ISEARCH_MATCH would be the ideal name, if the matched string was
} > exposed, but I haven't found a simple way to do that.
} 
} Something like the attached, perhaps?  Do you think something like this
} should be added?  (Myself, I'm not sure, since the value would be
} derivable from the three ISEARCHMATCH_* parameters' values.)

My point in suggesting ISEARCH_MATCH was to limit the feature to three
variables with "ISEARCH_" as a prefix.  This was countered with the
expressed desire to follow the "_ACTIVE" suffix pattern instead.  I'm
not particularly invested in this either way, but having *both* the
"_MATCH" and "_ACTIVE" variants is certainly redundant, and having
two different prefixes ("ISEARCH_" and "ISEARCHMATCH_") is annoying.

Other comments:

I will posit that isearch is rather different from YANK/SUFFIX/REGION
in that one might be interested in what the current search pattern is,
as well as what string is matched.

There are two existing variables LASTABORTEDSEARCH and LASTSEARCH which
refer to that search pattern, neither of which uses the "I", so maybe
these new three (or four or five) shouldn't use it either.

Those two variables aren't cleared when you start a new search, they
only change based on the final state of the search.