* 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.