* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
[not found] ` <E1aKX6t-0005s4-NF@vcs.savannah.gnu.org>
@ 2016-01-17 10:56 ` Dmitry Gutov
2016-01-17 21:14 ` John Wiegley
0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Gutov @ 2016-01-17 10:56 UTC (permalink / raw)
To: emacs-devel, Stefan Monnier
On 01/16/2016 11:06 PM, Stefan Monnier wrote:
> branch: master
> commit 8dafacd0419ea890af461c9d42d4642155681eec
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Commit: Stefan Monnier <monnier@iro.umontreal.ca>
>
> * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
Hi Stefan,
Are there any particular cases where we should use it? You've added the
var, but without any usages.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
2016-01-17 10:56 ` [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var Dmitry Gutov
@ 2016-01-17 21:14 ` John Wiegley
2016-01-17 21:32 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: John Wiegley @ 2016-01-17 21:14 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Stefan Monnier, emacs-devel
>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
> Are there any particular cases where we should use it? You've added the var,
> but without any usages.
I am also curious...
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
2016-01-17 21:14 ` John Wiegley
@ 2016-01-17 21:32 ` Stefan Monnier
2016-01-18 20:45 ` Dmitry Gutov
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2016-01-17 21:32 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
>>> * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
>> Are there any particular cases where we should use it?
Any time where you want to use a different syntax-table. E.g. e use it
in nxml-mode where the syntax-table to use normally should be
"text-like" (e.g. parens are matched), but where actual formal parsing
needs something very different (since nothing guarantees that parens
are matched, whereas matching <..> is a lot more useful).
I expect it to be handy as well in cases where the "normal" syntax table
may be changed at various times. E.g. this allows the use of
syntax-ppss within with-syntax-table. I actually imagine it may become
"normal and recommended" to set syntax-ppss-table in any buffer where
with-syntax-table may be used, since syntax-ppss can very easily be
triggered by accident (e.g. via forward-sexp -> syntax-propertize ->
syntax-ppss).
>> You've added the var, but without any usages.
Actually there is one usage in trunk (in nxml). I just mistakenly
installed it before installing the corresponding change in syntax.el.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
2016-01-17 21:32 ` Stefan Monnier
@ 2016-01-18 20:45 ` Dmitry Gutov
2016-01-18 22:12 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Gutov @ 2016-01-18 20:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On 01/18/2016 12:32 AM, Stefan Monnier wrote:
> Any time where you want to use a different syntax-table. E.g. e use it
> in nxml-mode where the syntax-table to use normally should be
> "text-like" (e.g. parens are matched), but where actual formal parsing
> needs something very different (since nothing guarantees that parens
> are matched, whereas matching <..> is a lot more useful).
Thanks. What is the purpose left for the "main" syntax table, though?
Doesn't paren-matching code call syntax-ppss anyway?
I'm worried that we have _three_ different syntax tables now (including
the font-lock- one), without clear documentation on how they should relate.
> I expect it to be handy as well in cases where the "normal" syntax table
> may be changed at various times. E.g. this allows the use of
> syntax-ppss within with-syntax-table. I actually imagine it may become
> "normal and recommended" to set syntax-ppss-table in any buffer where
> with-syntax-table may be used, since syntax-ppss can very easily be
> triggered by accident (e.g. via forward-sexp -> syntax-propertize ->
> syntax-ppss).
So, forward-sexp can trigger syntax-ppss via syntax-propertize, which
will use syntax-ppss-table, but forward-sexp itself will use the main
syntax table? At least when called with positive argument.
But up-list uses the return value of syntax-ppss, so it will be affected
by syntax-ppss-table? And backward-sexp, too?
It doesn't seem easy to reason about.
>>> You've added the var, but without any usages.
>
> Actually there is one usage in trunk (in nxml). I just mistakenly
> installed it before installing the corresponding change in syntax.el.
Yes, I missed that (that patch was long).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
2016-01-18 20:45 ` Dmitry Gutov
@ 2016-01-18 22:12 ` Stefan Monnier
2016-01-19 1:25 ` Dmitry Gutov
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2016-01-18 22:12 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
> Doesn't paren-matching code call syntax-ppss anyway?
Not that I know, no.
> I'm worried that we have _three_ different syntax tables now (including the
> font-lock- one), without clear documentation on how they should relate.
Yes, this whole area is rather murky. The font-lock syntax-table should
mostly disappear (90% of the uses were to turn "_" syntax into "w"
syntax so as to be able to use \< and \>, but this has been made
obsolete by the new \_< and \_>), I think.
But the interaction between the various syntax-tables as well as
forward-sexp-function deserves a serious rethink. I think such a rethink
will need to start by distinguishing "user-level dwimish" behavior and
lower-level behavior which adheres to strict syntax rules.
E.g. in TeX and HTML, we want to match parentheses even though the formal
syntax does not give any special rule to parentheses. Similar thing for
matching parens when the open and close parens are both inside comments,
but not inside the same one.
> So, forward-sexp can trigger syntax-ppss via syntax-propertize, which will
> use syntax-ppss-table, but forward-sexp itself will use the main syntax
> table? At least when called with positive argument.
Right.
> But up-list uses the return value of syntax-ppss, so it will be affected by
> syntax-ppss-table?
syntax-ppss is indeed used, but only to decide if we're strings or
comments, so it should be OK.
> It doesn't seem easy to reason about.
Indeed, it's not.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
2016-01-18 22:12 ` Stefan Monnier
@ 2016-01-19 1:25 ` Dmitry Gutov
2016-01-19 14:30 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Gutov @ 2016-01-19 1:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On 01/19/2016 01:12 AM, Stefan Monnier wrote:
>> Doesn't paren-matching code call syntax-ppss anyway?
>
> Not that I know, no.
electric-pair-syntax-info calls syntax-ppss. blink-matching-open calls
(forward-sexp -1).
> Yes, this whole area is rather murky. The font-lock syntax-table should
> mostly disappear (90% of the uses were to turn "_" syntax into "w"
> syntax so as to be able to use \< and \>, but this has been made
> obsolete by the new \_< and \_>), I think.
font-lock-syntax-table should go away, yes. But it's still there.
Are current-syntax-table and syntax-ppss-table allowed to differ more
than that?
> E.g. in TeX and HTML, we want to match parentheses even though the formal
> syntax does not give any special rule to parentheses. Similar thing for
> matching parens when the open and close parens are both inside comments,
> but not inside the same one.
Multiple major modes strike again! Or multiple syntactic regions,
anyway. I'm not sure if having a different value of syntax-table (any
variable) between different comments will help us any.
>> But up-list uses the return value of syntax-ppss, so it will be affected by
>> syntax-ppss-table?
>
> syntax-ppss is indeed used, but only to decide if we're strings or
> comments, so it should be OK.
Never for its 9th element?
>> It doesn't seem easy to reason about.
>
> Indeed, it's not.
So, I'm wondering if we could postpone introducing a new variable, and
implement the same thing in nxml-mode somehow in a different way.
But you've probably already considered that.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
2016-01-19 1:25 ` Dmitry Gutov
@ 2016-01-19 14:30 ` Stefan Monnier
0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2016-01-19 14:30 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
>>> Doesn't paren-matching code call syntax-ppss anyway?
>> Not that I know, no.
> electric-pair-syntax-info calls syntax-ppss.
Yes, but again that's only to figure out if we're inside
a string/comment, so I think it's fine.
> Are current-syntax-table and syntax-ppss-table allowed to differ more
> than that?
In the one current use case, they differ significantly, yes.
>>> But up-list uses the return value of syntax-ppss, so it will be affected by
>>> syntax-ppss-table?
>> syntax-ppss is indeed used, but only to decide if we're strings or
>> comments, so it should be OK.
> Never for its 9th element?
AFAICT no (even though it could, indeed).
>>> It doesn't seem easy to reason about.
>> Indeed, it's not.
> So, I'm wondering if we could postpone introducing a new variable, and
> implement the same thing in nxml-mode somehow in a different way.
I think syntax-ppss-table is "the right way" in that it is the place
where we can define the "low-level, strict, formal syntax".
This new variable makes it possible to use with-syntax-table safely with
any random syntax table which happens to parse things the way we
currently need it.
There are indeed potential problems with interactions with other
functions, but I expect that the right fix for them would be to be more
careful about whether they use the output of syntax-ppss (and hence
the proper syntax of the major mode) or if they use something else
(e.g. forward-sexp) to get a more dwimish behavior.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-01-19 14:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20160116200607.22534.62936@vcs.savannah.gnu.org>
[not found] ` <E1aKX6t-0005s4-NF@vcs.savannah.gnu.org>
2016-01-17 10:56 ` [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var Dmitry Gutov
2016-01-17 21:14 ` John Wiegley
2016-01-17 21:32 ` Stefan Monnier
2016-01-18 20:45 ` Dmitry Gutov
2016-01-18 22:12 ` Stefan Monnier
2016-01-19 1:25 ` Dmitry Gutov
2016-01-19 14:30 ` Stefan Monnier
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.