From: Dmitry Gutov <dgutov@yandex.ru>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: Alan Mackenzie <acm@muc.de>,
Stefan Monnier <monnier@IRO.UMontreal.CA>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]
Date: Mon, 21 Mar 2016 13:47:51 +0200 [thread overview]
Message-ID: <328c7461-62c6-4228-f622-626349613a1d@yandex.ru> (raw)
In-Reply-To: <87a8lsd4j3.fsf@gmail.com>
On 03/21/2016 03:05 AM, Vitalie Spinu wrote:
>
>>> On Sun, Mar 20 2016 17:58, Dmitry Gutov wrote:
>
>> On 03/20/2016 02:15 PM, Vitalie Spinu wrote:
>
>> IIRC, using first-column is fairly justified, the outer mode can't add extra
>> indentation to the submode is a reliable, sane way
>
> The inner mode cannot often make that decision either.
What decision? One case where the mode cannot return its proposed
indentation at all, is when the resulting column would be negative.
Using first-column can make it positive again via simple addition.
Using calculate-indent-function which returns a numeric value, would
solve that as well, of course, at the expense of having to update all
major modes out there, and documentation. And making whatever
third-party guides are out there obsolete in this regard. I'm not really
against that, mind you.
> Same inner mode can be
> used in very different multi-mode contexts, each with their own semantics for
> chunks/headers/indentation. Reducing all that to a simple (first-column
> . previous-chunk) pair and letting inner mode do the job is surely not
> enough. The only actor to make that decision should be multi-mode engine itself.
I'm not claiming that using previous-chunk is good.
> Instead of teaching modes about multi-modes, a much better idea is to introduce
> `calculate-indent-function` which would accept POS and optional STRING-AFTER and
> STRING-BEFORE. This function will return the indentation of STRING-AFTER at POS
> assuming there is a virtual STRING-BEFORE just before POS.
Strings? Indentation engines do not deal with strings, they deal with
buffer contents. Having them handle this possibility would also amount
to sharing a part of multi-mode logic.
Instead, if you want to know what indentation an inner mode would return
if STRING-BEFORE was before it, insert that string into the buffer
(while inhibiting undo history). Call the indentation function, then
remove the string. Any performance concerns with that?
> Most modes indent reliably
> based on one previous line,
Ruby doesn't. Most modes based on SMIE will need more than the previous
line in the general case, too.
> Then a lot of modes don't even care about what's in the current line, so
> STRING-AFTER will be irrelevant as well.
Almost all of them care whether the current line contains }, or `end',
or `else', and so on.
>>> It's essentially a half-backed implementation of "hard widening" discussed
>>> earlier. Why not impose the widening restriction directly in `widen` then?
>>> Maybe bring widen to elisp and rename C widen into widen-internal. Then add
>>> generic `prog-hard-widen-limits` which would be checked along
>>> prog-indentation-context limits.
>
>> Right! At the very least, I we should extract the second element of
>> prog-indentation-context into a separate variable, and make prog-widen more
>> prominent.
>
> Not sure about removing second element. Good thing about keeping all of them in
> one place is for the indentation engine to be concerned with a single variable.
Didn't you mention font-lock and syntax-propertize yourself? Why would
they call a function that's solely dependent on an indentation variable?
In any case, your hard-narrowing proposal is very similar. Surely you
don't want to keep the second element of prog-indentation-context after
hard-narrowing becomes available?
> Only consumers of `hard-widen-limits` should be concerned with its side
> effects. But that's uniformly better than current situation when you cannot do
> much about restricting widen.
OK, so *every* consumer of widen will have to obey the hard limits. That
might work, if there's no low-level code that absolutely has to always
be able to widen to the whole buffer.
> BTW, I parse-partial-sexp must abide hard-widen-limits as well.
If you want parse-partial-sexp to obey limits, you narrow the buffer
around it.
> This way the
> request aired in bug#22983 of parse-partial-sexp == syntax-ppss will be
> automatically satisfied. You won't need syntax-ppss-dont-widen either.
That doesn't seem relevant. That bug is about stale cache values between
different narrowing bounds.
> A patch that would require hunting every single mode out there and implementing
> multi-modes locally should have been more carefully considered IMO. Emacs 25 is
> not yet there, so it's not late to reconsider that decision.
I concur.
next prev parent reply other threads:[~2016-03-21 11:47 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160311151512.GD2888@acm.fritz.box>
[not found] ` <b158555f-e014-ed7b-23eb-d80d2d77a6f4@yandex.ru>
[not found] ` <20160311212410.GG2888@acm.fritz.box>
[not found] ` <73903215-f94b-e194-7bfe-0d6350c95769@yandex.ru>
[not found] ` <20160311221540.GH2888@acm.fritz.box>
[not found] ` <2c301ec9-041d-9172-d628-479062314b23@yandex.ru>
2016-03-14 15:16 ` Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.] Alan Mackenzie
2016-03-14 17:34 ` Andreas Röhler
2016-03-14 20:06 ` Dmitry Gutov
2016-03-19 22:51 ` Vitalie Spinu
2016-03-20 2:19 ` Dmitry Gutov
2016-03-20 12:15 ` Vitalie Spinu
2016-03-20 15:58 ` Dmitry Gutov
2016-03-21 1:05 ` Vitalie Spinu
2016-03-21 3:11 ` Stefan Monnier
2016-03-21 5:05 ` Vitalie Spinu
2016-03-21 7:13 ` Andreas Röhler
2016-03-21 12:26 ` Stefan Monnier
2016-03-21 14:13 ` Vitalie Spinu
2016-03-21 14:43 ` Stefan Monnier
2016-03-21 16:42 ` Vitalie Spinu
2016-03-21 18:31 ` Stefan Monnier
2016-03-21 19:16 ` Vitalie Spinu
2016-03-21 20:47 ` Stefan Monnier
2016-03-21 20:33 ` Alan Mackenzie
2016-03-21 20:49 ` Stefan Monnier
2016-03-21 21:03 ` Drew Adams
2016-03-21 21:12 ` Dmitry Gutov
2016-03-21 16:45 ` Vitalie Spinu
2016-03-21 22:55 ` Dmitry Gutov
2016-03-22 14:51 ` Stefan Monnier
2016-03-22 18:17 ` Vitalie Spinu
2016-03-23 1:18 ` Dmitry Gutov
2016-03-23 13:18 ` Stefan Monnier
2016-03-22 18:26 ` Vitalie Spinu
2016-03-23 2:07 ` Stefan Monnier
2016-03-23 10:56 ` Vitalie Spinu
2016-03-23 11:41 ` Stefan Monnier
2016-03-23 12:39 ` Vitalie Spinu
2016-03-23 13:23 ` Stefan Monnier
2016-03-23 15:28 ` Dmitry Gutov
2016-03-23 21:51 ` Vitalie Spinu
2016-03-24 7:30 ` Andreas Röhler
2016-03-21 11:56 ` Dmitry Gutov
2016-03-21 5:08 ` [Patch] hard-widen-limits [was Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]] Vitalie Spinu
2016-03-21 12:39 ` Stefan Monnier
2016-03-21 12:54 ` Vitalie Spinu
2016-03-21 14:07 ` Stefan Monnier
2016-03-21 14:14 ` Vitalie Spinu
2016-03-21 14:04 ` Stefan Monnier
2016-03-21 14:33 ` Vitalie Spinu
2016-03-21 14:54 ` Stefan Monnier
2016-03-21 17:16 ` Vitalie Spinu
2016-03-21 18:36 ` Stefan Monnier
2016-03-21 19:18 ` Vitalie Spinu
2016-03-22 3:17 ` Vitalie Spinu
2016-03-22 9:57 ` Vitalie Spinu
2016-03-22 10:05 ` Vitalie Spinu
2016-03-22 11:57 ` Stefan Monnier
2016-03-22 16:28 ` Vitalie Spinu
2016-03-22 16:44 ` Stefan Monnier
2016-03-22 19:36 ` Vitalie Spinu
2016-03-23 2:22 ` Stefan Monnier
2016-03-23 11:41 ` Vitalie Spinu
2016-03-23 12:34 ` Stefan Monnier
2016-03-23 12:41 ` Vitalie Spinu
2016-03-29 21:43 ` Vitalie Spinu
2016-04-22 14:34 ` Dmitry Gutov
2016-04-24 7:22 ` Vitalie Spinu
2016-04-24 7:28 ` Achim Gratz
2016-04-24 11:33 ` Vitalie Spinu
2016-04-24 13:20 ` Andreas Schwab
2016-04-24 16:11 ` Vitalie Spinu
2016-04-24 16:19 ` Andreas Schwab
2016-04-24 16:41 ` Vitalie Spinu
2016-04-24 16:48 ` Andreas Schwab
2016-04-24 18:01 ` Vitalie Spinu
2016-04-24 19:05 ` Andreas Schwab
2016-04-28 13:29 ` Vitalie Spinu
2016-04-30 14:06 ` Stefan Monnier
2016-03-22 20:08 ` Richard Stallman
2016-03-22 22:45 ` Vitalie Spinu
2016-03-21 11:47 ` Dmitry Gutov [this message]
2016-03-21 12:40 ` Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.] Vitalie Spinu
2016-03-21 13:07 ` Dmitry Gutov
2016-03-21 14:20 ` Vitalie Spinu
2016-03-21 14:29 ` Dmitry Gutov
2016-03-21 14:42 ` Vitalie Spinu
2016-03-21 14:56 ` Dmitry Gutov
2016-03-21 16:52 ` Vitalie Spinu
2016-03-21 21:30 ` Dmitry Gutov
2016-04-03 23:34 ` John Wiegley
2016-03-21 14:02 ` Stefan Monnier
2016-03-21 14:31 ` Vitalie Spinu
2016-03-21 15:06 ` Stefan Monnier
2016-03-21 17:15 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=328c7461-62c6-4228-f622-626349613a1d@yandex.ru \
--to=dgutov@yandex.ru \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=spinuvit@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).