[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limi
From: |
Dmitry Gutov |
Subject: |
Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] |
Date: |
Thu, 24 Mar 2016 00:34:58 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 |
Hi Alan,
On 03/23/2016 11:16 PM, Alan Mackenzie wrote:
All these options strike me as artificial, ad hoc, and ugly. I would go
for option number (5) - to transcend the "unwanted widen" problem - to
enhance Emacs such that users and Lisp hackers can freely narrow and
widen _without_ upsetting the @dfn{super mode} (the multiple mode
handling mode).
I disagree about ugly. Co-opting narrowing to do something useful for
once is a pretty neat, and minimal, approach.
Let us then have all these things in our super mode, such that their
current values are according to where point is - if we have an AWK
script embedded in a shell script, when point is in the AWK bit, the
mode line should say "AWK", the C-c C-? bindings from CC Mode should be
in force, the font locking should be AWK's, etc.
Each multi-mode package implements something like this already. It
doesn't work well e.g. because font-lock rules of each particular
language, indentation code, etc, are free to widen.
For this we will need a new type of local variable, an "island-local" or
"span-local" variable, or whatever you want to call it. Values of these
variables will vary according to where point is.
That part is already doable (and done), for most practical purposes.
To transcend the "unwanted widen" problem, there will be a very special
variable `restrict-to-island' or `restrict-to-span', or ..... When
bound to non-nil (by the super mode), this instructs certain primitives
to confine their attention to the individual island/span (or possibly a
chain of them). There will be no restrictions on `widen' or
`parse-partial-sexp', because there won't need to be.
`parse-partial-sexp' would simply skip over "foreign spans" looking for
the delimiter marking the beginning of the interesting span. Regexp
searching would likewise restrict its attentions, as would several other
facilities.
You'll have to present the total list of facilities, decide how the
islands would be applied, and other issues will likely come up from
unexpected places.
For instance, you said that there could be island-local variables. Can I
put some cache into one? Earlier, you suggested that the islands would
be applied via text properties. What happens to all island-local
variables when someone, somewhere, changes an island's boundary (maybe
adds, maybe removes, maybe moves it)? On the one hand, we'd probably
want to retain some variables, in order not to rerun the major mode
functions over and over again. On the other hand, if we were to put e.g.
syntax-ppss-last into an island-local variable (and it's a logical
continuation of this idea), after island boundaries change it should
what... become unbound? Nil? Or carefully managed by the mult-mode
package, which happens already.
Next, at which points exactly would Emacs look at the island boundaries
and change the island-local variables to the values set in the current
island? Probably not after each point movement. In post-command-hook?
That's also already done.
Although the above vision implies a lot of development work, there is
nothing there which is beyond our abilities to implement readily. It
would give us a true multi major mode capability, yet the impact on
individual major modes would be minimal.
I'm sure this is eventually doable. But this proposal looks rather
similar to what Lennart Borgman has been asking, in multi-mode related
discussions, on several occasions separated by years. Also in broad
strokes (probably a bit broader that these). Nobody has been both
capable and invested enough into the issue of multi-mode buffers to even
start working on it, AFAIK.
On the other hand, using narrowing for multi-mode purpose is a familiar
ground already, and the changes in Emacs core required to do so are
minimal. And most of the code written for Emacs has been taught to
respect narrowing bounds (even if only by the virtue of always using
(point-min) instead of 1), so we can utilize that.
Another (probably minor, it's hard to tell now) disadvantage, is if the
multi-mode package sets narrowing bounds itself, it will decide which
islands are visible from the current island, dynamically, so to speak.
Maybe just the current one. Or it can copy just a couple of islands from
the same mode to a temp buffer, call the indentation function there, and
use the result. Doing that using an islands framework limits it to a
predefined set of semantics (e.g. all Ruby islands see all other Ruby
islands).
That's not to say that being able to make parse-partial-sexp to skip
over certain intervals wouldn't be valuable. But you can do that, sort
of, already, by applying existing text properties to those intervals
(like beginning-of-comment/end-of-comment, or just "whitespace" over the
whole of it), and then removing them at the end of an operation. But the
end benefits might not be high enough to justify the necessary work and
the increase in complexity in internals.
- RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, (continued)
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Andreas Röhler, 2016/03/24
- RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Drew Adams, 2016/03/23
- A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Alan Mackenzie, 2016/03/23
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Vitalie Spinu, 2016/03/23
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Alan Mackenzie, 2016/03/24
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Vitalie Spinu, 2016/03/24
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:],
Dmitry Gutov <=
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Alan Mackenzie, 2016/03/24
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Vitalie Spinu, 2016/03/24
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Dmitry Gutov, 2016/03/24
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Alan Mackenzie, 2016/03/27
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Dmitry Gutov, 2016/03/27
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Alan Mackenzie, 2016/03/28
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Dmitry Gutov, 2016/03/31
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Filipp Gunbin, 2016/03/28
- Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:], Phillip Lord, 2016/03/27