From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>, Vitalie Spinu <spinuvit@gmail.com>
Cc: "Eli Zaretskii" <eliz@gnu.org>,
"Andreas Röhler" <andreas.roehler@online.de>,
"Stefan Monnier" <monnier@iro.umontreal.ca>,
"Drew Adams" <drew.adams@oracle.com>,
emacs-devel@gnu.org
Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:]
Date: Thu, 24 Mar 2016 00:34:58 +0200 [thread overview]
Message-ID: <bae02247-3d9f-c72c-88dd-8b96662de59a@yandex.ru> (raw)
In-Reply-To: <20160323211605.GA5324@acm.fritz.box>
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.
next prev parent reply other threads:[~2016-03-23 22:34 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160322022539.16038.77264@vcs.savannah.gnu.org>
[not found] ` <E1aiC0q-0004DL-40@vcs.savannah.gnu.org>
2016-03-22 12:08 ` [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Stefan Monnier
2016-03-22 19:44 ` Vitalie Spinu
2016-03-22 19:56 ` Drew Adams
2016-03-22 22:42 ` Vitalie Spinu
2016-03-23 0:44 ` Drew Adams
2016-03-23 7:16 ` Andreas Röhler
2016-03-23 11:58 ` Vitalie Spinu
2016-03-23 13:02 ` Andreas Röhler
2016-03-23 14:17 ` Vitalie Spinu
2016-03-23 15:34 ` Eli Zaretskii
2016-03-23 17:24 ` Andreas Röhler
2016-03-23 17:55 ` Eli Zaretskii
2016-03-23 18:53 ` Andreas Röhler
2016-03-23 21:57 ` Drew Adams
2016-03-23 22:13 ` Vitalie Spinu
2016-03-23 23:03 ` Drew Adams
2016-03-24 3:38 ` Eli Zaretskii
2016-03-24 12:24 ` Dmitry Gutov
2016-03-24 15:56 ` Eli Zaretskii
2016-03-24 18:55 ` Removing prog-indentation-context (was: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality) Stefan Monnier
2016-03-25 0:53 ` Removing prog-indentation-context Dmitry Gutov
2016-03-25 1:29 ` Dmitry Gutov
2016-03-25 2:09 ` Stefan Monnier
2016-03-25 11:38 ` Dmitry Gutov
2016-03-26 22:29 ` John Wiegley
2016-03-28 1:03 ` Dmitry Gutov
2016-03-25 15:45 ` Vitalie Spinu
2016-03-28 21:37 ` Dmitry Gutov
2016-03-28 22:08 ` Stefan Monnier
2016-03-28 22:55 ` Dmitry Gutov
2016-03-28 23:24 ` Stefan Monnier
2016-03-28 1:03 ` [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Dmitry Gutov
2016-03-24 3:37 ` Eli Zaretskii
2016-03-23 17:14 ` Andreas Röhler
2016-03-24 0:03 ` Vitalie Spinu
2016-03-24 0:37 ` Drew Adams
2016-03-24 2:36 ` Vitalie Spinu
2016-03-24 13:53 ` Drew Adams
2016-03-24 13:57 ` Dmitry Gutov
2016-03-24 14:31 ` Drew Adams
2016-03-24 14:56 ` Stefan Monnier
2016-03-24 15:13 ` Drew Adams
2016-03-24 15:20 ` Stefan Monnier
2016-03-24 7:00 ` Andreas Röhler
2016-03-23 14:29 ` Drew Adams
2016-03-23 21:16 ` A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Alan Mackenzie
2016-03-23 21:58 ` Vitalie Spinu
2016-03-24 17:44 ` Alan Mackenzie
2016-03-24 20:43 ` Vitalie Spinu
2016-03-23 22:34 ` Dmitry Gutov [this message]
2016-03-24 18:38 ` Alan Mackenzie
2016-03-24 20:22 ` Vitalie Spinu
2016-03-25 0:11 ` Dmitry Gutov
2016-03-27 12:09 ` Alan Mackenzie
2016-03-27 22:59 ` Dmitry Gutov
2016-03-29 0:07 ` Alan Mackenzie
2016-04-01 1:15 ` Dmitry Gutov
2016-04-05 16:29 ` Alan Mackenzie
2016-04-05 22:52 ` Dmitry Gutov
2016-04-18 21:32 ` Alan Mackenzie
2016-03-28 13:00 ` Filipp Gunbin
2016-03-25 18:20 ` Phillip Lord
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=bae02247-3d9f-c72c-88dd-8b96662de59a@yandex.ru \
--to=dgutov@yandex.ru \
--cc=acm@muc.de \
--cc=andreas.roehler@online.de \
--cc=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=spinuvit@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.