From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: "Wedler, Christoph" <christoph.wedler@sap.com>,
"Fabián E.Gallina" <fabian@anue.biz>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: antlr-mode.el - need some support by python.el
Date: Mon, 02 Mar 2015 20:04:31 +0200 [thread overview]
Message-ID: <54F4A62F.3040403@yandex.ru> (raw)
In-Reply-To: <jwvk2yze4ju.fsf-monnier+emacs@gnu.org>
On 03/02/2015 06:48 PM, Stefan Monnier wrote:
>> Maybe we can say that code inside narrowing is only allowed to call
>> `generic' features, which may or may not perform widening themselves.
>
> I'm not sure what that buys us.
The multi-mode facilities can override the generic features via
variables and/or advices, and disable widening, or make it somehow smarter.
>> The uses of `syntax-ppss' are harder to classify, but for font-lock we at
>> least have font-lock-dont-widen.
>
> But that's very crude. It only accounts for those (rather rare) cases
> where narrowing is used to focus on a "sub-buffer" (i.e. Info mode, and
> old Rmail). If something uses narrowing in those modes, then the result
> is plain breakage.
Indeed. But a multi-mode font-lock-fontify-region-function could perform
the "smarter" widening, which wouldn't suffer from this exact problem.
> Most uses of narrowing should be widened, so the rule goes rather in
> the opposite direction (which is why font-lock-dont-widen defaults to
> nil, for example).
That wouldn't be my preference, but either way, there could be a way to
disable or alter the behavior of `widen'.
While `widen-function' should be enough for this, maybe it's too
flexible after all: that variable would never be used (correctly) with a
buffer-local value. Only with local dynamic binding.
> Right, that's basically attacking the problem of distinguishing between
> different kinds of narrowing.
>
> But in any case, I think that relying on narrowing for the multi-mode
> support is a bad idea.
Maybe it's unfortunate that the main approaches to multi-mode
implementation ended up using one of the two bad ideas (indirect buffers
and narrowing), but they did, and we still don't have a good model from
implementing the needed features in a different way.
> It's OK if the API *allows* the use of
> narrowing, but requiring it would be a mistake.
I don't think any version of the API requires it. But in the multi-mode
context, I indeed expect it to be used.
Anyway, I think doing `widen' in prog-indent-line and prohibiting (in
the docstring) prog-indent-calculate-functions from doing that should
work just as well as prog-indentation-context (and better, from my
standpoint).
It doesn't require any changes to the narrowing/widening logic, so the
question of whether narrowing is a good approach can again be deferred
until later.
next prev parent reply other threads:[~2015-03-02 18:04 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 19:50 antlr-mode.el - need some support by python.el Wedler, Christoph
2015-01-16 23:37 ` Stefan Monnier
2015-02-05 11:39 ` Wedler, Christoph
2015-02-05 14:27 ` Stefan Monnier
2015-02-06 15:14 ` Wedler, Christoph
2015-02-06 17:47 ` Stefan Monnier
2015-02-13 10:56 ` Wedler, Christoph
2015-02-13 19:40 ` Stefan Monnier
2015-02-16 14:38 ` Wedler, Christoph
2015-02-16 19:23 ` Stefan Monnier
2015-02-17 10:55 ` Wedler, Christoph
2015-02-18 0:00 ` Stefan Monnier
2015-02-18 14:27 ` Wedler, Christoph
2015-02-18 3:39 ` Dmitry Gutov
2015-02-18 5:48 ` Stefan Monnier
2015-02-18 14:13 ` Wedler, Christoph
2015-02-18 15:13 ` Dmitry Gutov
2015-02-18 15:41 ` Wedler, Christoph
2015-02-18 17:56 ` Stefan Monnier
2015-02-19 2:43 ` Dmitry Gutov
2015-02-19 3:20 ` Stefan Monnier
2015-02-19 3:30 ` Dmitry Gutov
2015-02-19 13:18 ` Stefan Monnier
2015-02-21 22:14 ` Dmitry Gutov
2015-02-25 11:05 ` Wedler, Christoph
2015-03-01 17:04 ` Stefan Monnier
2015-03-01 22:16 ` Dmitry Gutov
2015-03-02 5:23 ` Stefan Monnier
2015-03-02 15:08 ` Dmitry Gutov
2015-03-02 16:48 ` Stefan Monnier
2015-03-02 18:04 ` Dmitry Gutov [this message]
2015-03-02 18:51 ` Stefan Monnier
2015-03-02 19:31 ` Dmitry Gutov
2015-03-03 16:32 ` Stefan Monnier
2015-03-04 16:53 ` Wedler, Christoph
2015-03-04 17:20 ` Dmitry Gutov
2015-03-05 9:46 ` Wedler, Christoph
2015-03-05 12:29 ` Dmitry Gutov
2015-03-05 12:43 ` Dmitry Gutov
2015-04-02 14:10 ` Wedler, Christoph
2015-04-07 17:49 ` Stefan Monnier
2015-04-09 14:07 ` Wedler, Christoph
2015-04-09 18:13 ` Stefan Monnier
2015-06-03 14:14 ` Wedler, Christoph
2015-06-03 15:31 ` Stefan Monnier
2015-06-05 14:17 ` Wedler, Christoph
2015-06-05 17:46 ` Dmitry Gutov
2015-06-08 9:12 ` Wedler, Christoph
2015-06-08 13:26 ` Stefan Monnier
2015-06-08 16:02 ` Dmitry Gutov
2015-06-08 20:50 ` Stefan Monnier
2015-06-08 21:33 ` Dmitry Gutov
2015-06-09 9:07 ` Wedler, Christoph
2015-06-09 15:58 ` Stefan Monnier
2015-06-09 19:05 ` Wedler, Christoph
2015-06-15 11:02 ` Dmitry Gutov
2015-06-08 13:18 ` Stefan Monnier
2015-03-04 17:37 ` Dmitry Gutov
2015-03-04 22:26 ` Stefan Monnier
2015-03-04 22:59 ` Dmitry Gutov
2015-03-10 1:16 ` Stefan Monnier
2015-03-21 15:30 ` Dmitry Gutov
2015-03-21 17:08 ` Stefan Monnier
2015-03-21 23:41 ` Dmitry Gutov
2015-03-22 13:54 ` Stefan Monnier
2015-03-22 19:31 ` Dmitry Gutov
2015-03-22 21:59 ` Stefan Monnier
2015-03-23 14:03 ` Dmitry Gutov
2015-03-23 19:25 ` Stefan Monnier
2015-03-04 16:29 ` Wedler, Christoph
2015-03-04 17:16 ` Dmitry Gutov
2015-03-01 22:25 ` Dmitry Gutov
2015-02-18 12:22 ` Wedler, Christoph
2015-02-18 15:29 ` Dmitry Gutov
2015-02-18 16:10 ` Wedler, Christoph
2015-02-18 22:55 ` Dmitry Gutov
2015-02-25 11:16 ` Wedler, Christoph
2015-02-18 3:15 ` Dmitry Gutov
2015-02-22 7:52 ` Andreas Röhler
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=54F4A62F.3040403@yandex.ru \
--to=dgutov@yandex.ru \
--cc=christoph.wedler@sap.com \
--cc=emacs-devel@gnu.org \
--cc=fabian@anue.biz \
--cc=monnier@IRO.UMontreal.CA \
/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.