From: Alan Mackenzie <acm@muc.de>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.
Date: Sun, 12 Jun 2016 09:34:25 +0000 [thread overview]
Message-ID: <20160612093425.GA3178@acm.fritz.box> (raw)
In-Reply-To: <411210d6-c6ce-fe24-63c2-27c0d6f9a6fb@yandex.ru>
Hello, Dmitry.
On Sun, Jun 12, 2016 at 01:52:42AM +0300, Dmitry Gutov wrote:
> On 06/11/2016 10:50 PM, Alan Mackenzie wrote:
[ .... ]
> I believe hard-widen can be made to work well, and not too hard to
> reason about.
I can't reason about hard-widen very much, because I haven't read its
specification.
> Although only time could tell.
No. A careful consideration of its proposed working before
implementation (let's call it a design ;-) can reveal a lot about how
well it could work.
[ .... ]
> > hard-widen seems to destroy the simplicity evident in narrow-to-region
> > and widen.
> What simplicity?
`widen' makes the entire buffer accessible. `narrow-to-region' makes
the specified region the accessible portion. And that's it! What could
be simpler?
That simplicity is a masterstroke in the early design of Emacs.
> narrow-to-region seemingly can't decide whether it's a command for
> users to invoke, or it's something for Lisp code to use.
That's the use case, not narrow-to-region itself. It's actually both a
user command and a Lisp function, deliberately so, masterfully so.
> We end up treating both cases the same, and that causes a lot of
> problems.
I have encountered no such problems in over 15 years of hacking Emacs.
I think you're seeing problems somewhere and blaming
narrow-to-region/widen, when the real problem is somewhere else.
> hard-widen would differentiate those.
And that would cause great problems. It would likely make
narrow-to-region/widen a pain to work with.
> > Why does (presumably) a super mode want to do anything with narrowing
> > anyway?
> How else would you apply each major mode's fontifications only within
> its subregions?
By adding the appropriate structures as buffer local variables (or
perhaps as text properties) which would delimit the subregions, then
enhance Font Lock to respect those boundaries.
> See
> https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816
That's rather a lot to take in before breakfast!
> > Narrowing is needed by users and by major modes, and its use by
> > a super mode might well clash.
> super modes are currently implemented as minor modes. major modes
> shouldn't override the choices made by minor modes, if at all possible.
What???? What major modes shouldn't override is user settings, or
possibly minor mode settings. The use/non-use of narrowing is NOT a
setting, any more than the use/non-use of cdr is. They're just general
purpose tools.
> > Is this hard-widen proposal at all
> > documented in any coherent fashion?
> There have been several discussions.
They're not coherent, and they're not very useful.
Could you please write this document. Given the massive change you want
to make in a fundamental Emacs tool, this is not unreasonable to ask.
This is, after all, what I did for the "islands" concept a couple of
months ago. Your document need only be 50 - 100 lines long at the most.
Writing such doc would certainly help you clear things up for yourself,
too.
> > I'm not convinced. But then, I don't know how the proposal will work in
> > any great detail.
> I've linked to the patch and the previous discussion not too long ago.
They are not useful for this purpose.
> > That paragraph worries me greatly. OF COURSE CC Mode uses
> > narrow-to-region and widen freely, there being code which can scarcely
> > work without it. I and other major mode maintainers will expect to
> > continue to be able to do so.
> The main thing CC Mode would have to worry about from then on, is that
> it won't always be able to goto-char to positions beyond the hard
> narrowing, even if they exist in the buffer (and are pointed to by some
> buffer-local data structure maintained by CC Mode's parser).
That sounds like something worthwhile sorting out in advance.
> There may be some alternative approaches to this, but a super mode has
> to be able to *somehow* limit CC Mode's activity if we want to be able
> to use it for syntax highlighting and indentation inside e.g. Noweb's
> code chunks.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2016-06-12 9:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 22:09 Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please Alan Mackenzie
2016-06-07 22:15 ` Dmitry Gutov
2016-06-07 22:48 ` Alan Mackenzie
2016-06-07 23:25 ` Dmitry Gutov
2016-06-11 10:07 ` Alan Mackenzie
2016-06-11 16:10 ` Dmitry Gutov
2016-06-11 19:50 ` Alan Mackenzie
2016-06-11 22:52 ` Dmitry Gutov
2016-06-12 9:34 ` Alan Mackenzie [this message]
2016-06-12 22:58 ` Dmitry Gutov
2016-06-13 1:44 ` Clément Pit--Claudel
2016-06-13 12:28 ` Alan Mackenzie
2016-06-13 12:56 ` Stefan Monnier
2016-06-13 13:28 ` Drew Adams
2016-06-13 15:36 ` Dmitry Gutov
2016-06-14 14:55 ` Alan Mackenzie
2016-06-13 21:12 ` John Wiegley
2016-06-13 21:16 ` John Wiegley
2016-06-08 12:43 ` Stefan Monnier
2016-06-11 10:24 ` Alan Mackenzie
2016-06-11 15:00 ` Stefan Monnier
2016-06-11 16:29 ` Dmitry Gutov
2016-06-11 21:24 ` Stefan Monnier
2016-06-11 21:44 ` Alan Mackenzie
2016-06-11 21:49 ` Stefan Monnier
2016-06-11 22:13 ` Alan Mackenzie
2016-06-12 4:06 ` Stefan Monnier
2016-06-11 22:17 ` Dmitry Gutov
2016-06-11 22:21 ` Dmitry Gutov
2016-06-11 16:32 ` Dmitry Gutov
2016-06-11 19:58 ` Alan Mackenzie
2016-06-11 22:28 ` Dmitry Gutov
2016-06-14 9:17 ` Andreas Röhler
2016-06-15 22:11 ` Stefan Monnier
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=20160612093425.GA3178@acm.fritz.box \
--to=acm@muc.de \
--cc=dgutov@yandex.ru \
--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.