[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A vision for multiple major modes: some design notes
From: |
Alan Mackenzie |
Subject: |
Re: A vision for multiple major modes: some design notes |
Date: |
Fri, 22 Apr 2016 08:13:44 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
Hello, Drew.
On Thu, Apr 21, 2016 at 03:01:12PM -0700, Drew Adams wrote:
> [More interesting details. Thx.]
> > Given a buffer position, we need to be able to find the corresponding
> > island chain. "Obviously", we do this with a text property, which we
> > might as well call `island', or possibly `chain'. Since successive
> > accesses to chain local variables are very likely to be in the same
> > chain most of the time, we will cache the "current" chain in buffer
> > local variables.
> I guess you are referring to the possibility of more than one
> chain having an island at point, and wanting to pick up the right
> one as the "current" chain - so you check a text property, which
> identifies the chain that is currently active. Is that right?
Er, no. ;-) Even when there is only one island at point, we still need
to determine it. A text property is a good way of doing this.
> > When it comes to movement and search primitives, we want to adapt these
> > so that the impact on existing major modes is minimised. Ideally, we
> > would want major modes to "see" only their own islands (or lack
> > thereof). Thus we treat irrelevant islands as blocks of whitespace. It
> > seems to make sense to have such islands matched by subexpressions in
> > regexps which match spaces. This would obviate the need to amend a
> > great number of regexps currently coded in major modes.
> For search, at least, I don't see why you don't make use of
> `isearch-filter-predicate'. That's what I do in my code, to
> search only within (or without: complement) a set of zones
> (~chain of islands). That seems simple and cheap.
Thanks, I didn't know about that variable. But it may not be widely
applicable enough.
> [I also optionally dim the non-islands during search (or the
> non-non-islands, if complementing), so the areas being searched
> stand out more.]
That's another matter, at a different level of abstraction from the main
topic.
> > On the other hand, when a user does C-s or C-M-s, the Right Thing is
> > surely to search the buffer as a whole, without regard to islands. We
> > therefore need a flag which instructs the primitives how to behave when
> > there are islands. We might as well call this flag `in-islands', for
> > want of a better name.
> `isearch-filter-predicate'. It can let code know whether
> you are island-searching or not.
That would only work for isearch.
> > The user will, from time to time, delete the delimiters which define
> > islands, and will insert other ones.
> FWIW, markers as delimiters do not have that problem.
I think they do. What happens when you have two islands bounded by four
markers, and you delete a region containing the two middle markers;
MaaaaaaaaaaaM MbbbbbbbbbbbbbM
dddddddddddddddddd
? You might well not want the two islands a and b to be coalesced.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: A vision for multiple major modes: some design notes, (continued)
Re: A vision for multiple major modes: some design notes, Phillip Lord, 2016/04/20
Re: A vision for multiple major modes: some design notes, Eli Zaretskii, 2016/04/21
Re: A vision for multiple major modes: some design notes, Eli Zaretskii, 2016/04/22
Re: A vision for multiple major modes: some design notes, Alan Mackenzie, 2016/04/21
- Re: A vision for multiple major modes: some design notes, Eli Zaretskii, 2016/04/22
- Re: A vision for multiple major modes: some design notes, Alan Mackenzie, 2016/04/22
- Re: A vision for multiple major modes: some design notes, Eli Zaretskii, 2016/04/23
- Re: A vision for multiple major modes: some design notes, Alan Mackenzie, 2016/04/23
- Re: A vision for multiple major modes: some design notes, Eli Zaretskii, 2016/04/23
- Re: A vision for multiple major modes: some design notes, Dmitry Gutov, 2016/04/23
- Re: A vision for multiple major modes: some design notes, Alan Mackenzie, 2016/04/23