[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could w
From: |
Alan Mackenzie |
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 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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).
- Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Alan Mackenzie, 2016/06/07
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Dmitry Gutov, 2016/06/07
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Alan Mackenzie, 2016/06/07
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Dmitry Gutov, 2016/06/07
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Alan Mackenzie, 2016/06/11
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Dmitry Gutov, 2016/06/11
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Alan Mackenzie, 2016/06/11
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Dmitry Gutov, 2016/06/11
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.,
Alan Mackenzie <=
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Dmitry Gutov, 2016/06/12
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Clément Pit--Claudel, 2016/06/12
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Alan Mackenzie, 2016/06/13
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Stefan Monnier, 2016/06/13
- RE: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Drew Adams, 2016/06/13
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Dmitry Gutov, 2016/06/13
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Alan Mackenzie, 2016/06/14
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., John Wiegley, 2016/06/13
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., John Wiegley, 2016/06/13
Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please., Stefan Monnier, 2016/06/08