[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: |
Dmitry Gutov |
Subject: |
Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please. |
Date: |
Mon, 13 Jun 2016 01:58:02 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 |
On 06/12/2016 12:34 PM, Alan Mackenzie wrote:
I can't reason about hard-widen very much, because I haven't read its
specification.
The change to the narrow-to-region's docstring in the patch contains the
specification. Here's a better link to the message:
http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01576.html
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.
...and time, if we're being realistic.
`widen' makes the entire buffer accessible. `narrow-to-region' makes
the specified region the accessible portion. And that's it! What could
be simpler?
If you take a shovel and remove its blade, the result will look very
simple. That doesn't mean it's appropriate for any interesting task.
Nowhere does narrow-to-region's documentation say it should only be used
in major modes.
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.
It's been a known problem for a while, and it has come up in multiple
discussions over the last years.
The "real problem" is a matter of perspective. Some might argue that
trying to use narrowing at all, for any purpose, is a bad idea, and
then, of course, the right choice would be to use something else.
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.
Please go ahead and write up this proposal in detail. It doesn't seem as
simple as you make it sound. And I wonder if it ends up to be different
from the "islands" proposal.
Further, font-lock is not the only facility we want here. Making
syntax-ppss obey region boundaries is another. There's also indentation
code, which is more difficult to handle, but limiting visibility there
somehow also seems essential.
The super mode can also adapt different simpler facilities, like Imenu,
using the same approach (go over the chunks, narrow to each, scan using
the language-appropriate tools, and concatenate the results).
See
https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816
That's rather a lot to take in before breakfast!
Did you have the breakfast yet? It's just 30 lines.
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 I said. To the extent the facilities allow, of course.
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.
Turns out, they are not general purpose enough. That's the problem.
There have been several discussions.
They're not coherent, and they're not very useful.
If there's anything in them that makes you confused, I've yet to hear
about it. As far as I can see, you're not interested in making even that
effort in learning the subject.
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.
I don't enjoy rehashing others' arguments when the original messages are
readable enough.
It's a small change, by itself. Please read the discussion, starting
with http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01129.html
And http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01182.html
in particular. After that, please let me know if you have any specific
questions.
This is, after all, what I did for the "islands" concept a couple of
months ago.
And I have spent considerable time contributing to that discussion as well.
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.
Sure. Please go ahead and present your thoughts on the subject.
I realize it might be rather complicated, actually, to use the narrowing
approach with CC Mode as submode. But I don't see any alternative
solutions that we're likely to implement. So it may be that some modes
will still refuse to work in multi-mode context.
- 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, 2016/06/12
- Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.,
Dmitry Gutov <=
- 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