all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: acm@muc.de, emacs-devel@gnu.org
Subject: RE: A vision for multiple major modes: some design notes
Date: Thu, 21 Apr 2016 13:26:53 -0700 (PDT)	[thread overview]
Message-ID: <f53cf2f2-32df-40f1-aef0-223958df130e@default> (raw)
In-Reply-To: <<83eg9y68jy.fsf@gnu.org>>

> > But just what does "the parts that affect redisplay" mean?
> > If we mean parts that need to do something particular wrt
> > redisplay, then yes, that makes sense.
> 
> I mean the part that is needed for redisplay to behave in each island
> according to user expectations.  For example, imagine that a mode that
> is relevant to a certain island chain sets up face-remapping-alist in
> some particular way -- when redisplay does its job, it repeatedly
> consults this variable when it needs to compute faces.  I'm saying
> that the part of the changes for this feature that affects redisplay
> will have to arrange for recalculation of the value of
> face-remapping-alist when the display engine gets to examining the
> portion of buffer text that belongs to this island chain.  Since the
> position where the display engine processes is not visible to Lisp,
> this arrangement will have to be in C.  And similarly with any other
> variable whose value the display engine accesses from its C code, like
> standard-display-table, for example.

Thanks for the example.  That's the kind of thing I thought
you had in mind.

> > You mentioned earlier that redisplay needs to access
> > buffer-local variables as it moves through the buffer.
> > And you said that redisplay needs to get the right values
> > of such variables.
> >
> > But for some island-chain operations, e.g. some that I'm
> > thinking of that do not care about the mode of a chain
> > or whether it even has a mode, I don't see why redisplay
> > would need to do anything special.
> 
> This could be so in some particular use cases, but it's not
> so in general.

Depends on what one means by "in general". ;-) To me, having
a different mode associated with a chain is a special case of
either having such a mode or not having one.  Likewise, for
having chain-local variables or not.  Both having and not
having are special cases of "in general".

> Modes do affect the way text is displayed.

Yes.  But if a chain does not use a mode that is different
from the buffer's mode, then there should be no special
mode-specific handling needed for it.

> Besides, Alan says that "most" buffer-local variables will
> become island-chain local.  If we believe him, then your
> use cases you mention above are lucky exceptions rather
> than the rule.

I don't see them as either lucky exceptions or the rule.
I imagine that there are lots of possible uses of a chain
of islands of text, some of which involve a different mode
or in some other way involve different display possibilities,
and some of which do not.

From the point of view of C code (e.g. redisplay) modification,
the latter use cases would I guess be lucky (little or nothing
new to do).  That doesn't mean they would be exceptional (rare)
in terms of user use cases.  (Dunno know whether they would be.)



  parent reply	other threads:[~2016-04-21 20:26 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 19:44 A vision for multiple major modes: some design notes Alan Mackenzie
2016-04-20 21:06 ` Drew Adams
2016-04-20 23:00   ` Drew Adams
2016-04-21 12:43   ` Alan Mackenzie
2016-04-21 14:24     ` Stefan Monnier
2016-04-23  2:20       ` zhanghj
2016-04-23 22:36       ` Dmitry Gutov
2016-04-21 16:05     ` Drew Adams
2016-04-21 16:31       ` Eli Zaretskii
     [not found]     ` <<64f1d39a-dfd0-44ca-86c1-b4d6104b5702@default>
     [not found]       ` <<83oa926i0e.fsf@gnu.org>
2016-04-21 16:59         ` Drew Adams
2016-04-21 19:55           ` Eli Zaretskii
     [not found]     ` <<<64f1d39a-dfd0-44ca-86c1-b4d6104b5702@default>
     [not found]       ` <<<83oa926i0e.fsf@gnu.org>
     [not found]         ` <<791d74d1-2b1d-4304-8e7e-d6c31af7aa41@default>
     [not found]           ` <<83eg9y68jy.fsf@gnu.org>
2016-04-21 20:26             ` Drew Adams [this message]
2016-04-20 22:27 ` Phillip Lord
2016-04-21  9:14   ` Alan Mackenzie
2016-04-22 12:45     ` Phillip Lord
2016-04-21 14:17 ` Eli Zaretskii
2016-04-21 21:33   ` Alan Mackenzie
2016-04-21 22:01     ` Drew Adams
2016-04-22  8:13       ` Alan Mackenzie
2016-04-22 17:04         ` Drew Adams
2016-04-22  9:04     ` Eli Zaretskii
2016-06-13 21:17     ` John Wiegley
2016-06-14 13:13       ` Alan Mackenzie
2016-06-14 16:27         ` John Wiegley
2016-04-21 22:19   ` Alan Mackenzie
2016-04-22  8:48     ` Eli Zaretskii
2016-04-22 22:35       ` Alan Mackenzie
2016-04-23  7:39         ` Eli Zaretskii
2016-04-23 17:02           ` Alan Mackenzie
2016-04-23 18:12             ` Eli Zaretskii
2016-04-23 18:26               ` Dmitry Gutov
2016-04-23 21:08               ` Alan Mackenzie
2016-04-24  6:29                 ` Eli Zaretskii
2016-04-24 16:57                   ` Alan Mackenzie
2016-04-24 19:59                     ` Eli Zaretskii
2016-04-25  6:49                       ` Andreas Röhler
2016-04-22 13:42     ` Andy Moreton
2016-04-23 17:14       ` Alan Mackenzie
2016-04-22 14:33 ` Dmitry Gutov
2016-04-22 18:58 ` Richard Stallman
2016-04-22 20:22   ` Alan Mackenzie
2016-04-23 12:27     ` Andreas Röhler
2016-04-23 12:38     ` Richard Stallman
2016-04-23 17:31       ` Alan Mackenzie
2016-04-24  9:22         ` Richard Stallman

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=f53cf2f2-32df-40f1-aef0-223958df130e@default \
    --to=drew.adams@oracle.com \
    --cc=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.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 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.