* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts [not found] ` <20181221180328.D755D20538@vcs0.savannah.gnu.org> @ 2018-12-22 16:26 ` Stefan Monnier 2018-12-22 21:23 ` João Távora 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2018-12-22 16:26 UTC (permalink / raw) To: emacs-devel; +Cc: João Távora > + ('after-stay (save-excursion > + (let ((electric-layout-rules nil) > + (electric-pair-open-newline-between-pairs nil)) > + (newline 1 t)))) I think the above let-binding of electric-pair-open-newline-between-pairs deserves a FIXME as well, because electric-layout-mode should ideally not need to know such details of about electric-pair-mode. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-22 16:26 ` [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts Stefan Monnier @ 2018-12-22 21:23 ` João Távora 2018-12-28 16:33 ` João Távora 0 siblings, 1 reply; 8+ messages in thread From: João Távora @ 2018-12-22 21:23 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> + ('after-stay (save-excursion >> + (let ((electric-layout-rules nil) >> + (electric-pair-open-newline-between-pairs nil)) >> + (newline 1 t)))) > > I think the above let-binding of > electric-pair-open-newline-between-pairs deserves a FIXME as well, > because electric-layout-mode should ideally not need to know such > details of about electric-pair-mode. Done. Indeed, as I described in the fixme electric-pair-open-newline-between-pairs is really a question of layout (not pairing) and thus a responsibility of e-l-m, but its API is not powerful enough yet to detect the exact situation yet. So it seems reasonable for now to do this, especially since electric-pair-open-newline-between-pairs is a part of e-p-m's external interface. João ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-22 21:23 ` João Távora @ 2018-12-28 16:33 ` João Távora 2018-12-28 17:51 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: João Távora @ 2018-12-28 16:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel On Sat, Dec 22, 2018 at 9:23 PM João Távora <joaotavora@gmail.com> wrote: > Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > >> + ('after-stay (save-excursion > >> + (let ((electric-layout-rules nil) > >> + (electric-pair-open-newline-between-pairs nil)) > >> + (newline 1 t)))) > > > > I think the above let-binding of > > electric-pair-open-newline-between-pairs deserves a FIXME as well, > > because electric-layout-mode should ideally not need to know such > > details of about electric-pair-mode. > > Done. Indeed, as I described in the fixme > electric-pair-open-newline-between-pairs is really a question of layout > (not pairing) and thus a responsibility of e-l-m, but its API is not > powerful enough yet to detect the exact situation yet. So it seems > reasonable for now to do this, especially since > electric-pair-open-newline-between-pairs is a part of e-p-m's external > interface. Stefan, did you have a look at the most recent version of this branch? (I rebased it meanwhile) I'd like to land it in master. e-l-m's API is should now be good enough to make electric-pair-open-newline-between-pairs its responsibility. João ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-28 16:33 ` João Távora @ 2018-12-28 17:51 ` Stefan Monnier 2018-12-28 22:00 ` João Távora 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2018-12-28 17:51 UTC (permalink / raw) To: João Távora; +Cc: emacs-devel The new API looks good to me, thanks. > (defvar electric-layout-rules nil > "List of rules saying where to automatically insert newlines. > > Each rule has the form (MATCHER . WHERE) where MATCHER examines > the state of the buffer after a certain character was inserted > and WHERE specifies where to insert newlines. > > MATCHER can be a character CHAR or a boolean function of no > arguments. Could we pass the inserted char to the function, so the function doesn't need to choose between looking at last-command-event, char-before, or yet something else? > The rule matches if the character just inserted was > CHAR or if the function return non-nil. ^^^^^^ returns > WHERE and can be: ^^^ > * one of the symbols `before', `after', `around', `after-stay' or > nil; nil doesn't need to be mentioned here, since it's a special case of "list of the preceding symbols". > * a list of the preceding symbols, processed in order of > appearance to insert multiple newlines; Great: much better than the previous approach of processing all matches. > Instead of the (MATCHER . WHERE) form, a rule can also be just a > function of no arguments. It should return a value compatible > with WHERE if the rule matches, or nil if it doesn't match. I think I'm fine with allowing MATCHER to be a function, and I'm fine with allowing (MATCHER . WHERE) to be a function, but I don't like the idea of allowing both, which seem a bit redundant (actually, allowing WHERE to be a function is also somewhat redundant with those, but it's part of the current API, so we're kind of stuck with it). [ BTW, the one user I know of the "WHERE is a function" (sml-mode) uses this function as a kind of predicate (it either returns `after` or nil) so it could get the same result with a MATCHER function (or a separate PREDICATE function). Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-28 17:51 ` Stefan Monnier @ 2018-12-28 22:00 ` João Távora 2018-12-29 15:59 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: João Távora @ 2018-12-28 22:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > The new API looks good to me, thanks. Cool. > Could we pass the inserted char to the function, so the function doesn't > need to choose between looking at last-command-event, char-before, or > yet something else? Passed it last-command event. Perhaps I should also mention that the function runs with point set to char-after of the insertion. > nil doesn't need to be mentioned here, since it's a special case of > "list of the preceding symbols". OK, but notice that because of the subtlety that when using the compound function, nil has the meaning of "no match". So if that function wants to match but don't insert anything, it has to return a list of the single element nil. So maybe I should add it back to the docstring (I just pushed the commit that removes it). > I think I'm fine with allowing MATCHER to be a function, and I'm fine with > allowing (MATCHER . WHERE) to be a function, but I don't like the idea > of allowing both, which seem a bit redundant Makes sense. MATCHER is only a character now. Tell me if it's good to go, and if I should squash the scratch branch into a single commit or just rebase the whole thing onto master, or merge or whatever. João ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-28 22:00 ` João Távora @ 2018-12-29 15:59 ` Stefan Monnier 2018-12-29 18:36 ` João Távora 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2018-12-29 15:59 UTC (permalink / raw) To: emacs-devel > Passed it last-command event. Perhaps I should also mention that the > function runs with point set to char-after of the insertion. Is it guaranteed that it's the case? >> nil doesn't need to be mentioned here, since it's a special case of >> "list of the preceding symbols". > > OK, but notice that because of the subtlety that when using the compound > function, nil has the meaning of "no match". So if that function wants > to match but don't insert anything, it has to return a list of the > single element nil. So maybe I should add it back to the docstring (I > just pushed the commit that removes it). It's not a problem here. It's a problem for the case where (MATCHER . WHERE) is a function (in which case returning nil is ambiguous, it could mean "matched but don't do anything" or "didn't match"). Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-29 15:59 ` Stefan Monnier @ 2018-12-29 18:36 ` João Távora 2019-01-02 1:53 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: João Távora @ 2018-12-29 18:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Passed it last-command event. Perhaps I should also mention that the >> function runs with point set to char-after of the insertion. > > Is it guaranteed that it's the case? Err no... Why the habit of making me think Stefan? Should be fixed now. >>> nil doesn't need to be mentioned here, since it's a special case of >>> "list of the preceding symbols". >> >> OK, but notice that because of the subtlety that when using the compound >> function, nil has the meaning of "no match". So if that function wants >> to match but don't insert anything, it has to return a list of the >> single element nil. So maybe I should add it back to the docstring (I >> just pushed the commit that removes it). > > It's not a problem here. It's a problem for the case where (MATCHER > . WHERE) is a function (in which case returning nil is ambiguous, it > could mean "matched but don't do anything" or "didn't match"). Yes, that was I was saying. I'm saying let's break the ambiguity like this: * If it returns nil it means "didn't match"; * If it returns (nil) it means "matches but don't do anything"'; So I've added the nil back to the symbols list. It's not super pretty, but not horrible either. João ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts 2018-12-29 18:36 ` João Távora @ 2019-01-02 1:53 ` Stefan Monnier 0 siblings, 0 replies; 8+ messages in thread From: Stefan Monnier @ 2019-01-02 1:53 UTC (permalink / raw) To: emacs-devel > * If it returns nil it means "didn't match"; > * If it returns (nil) it means "matches but don't do anything"'; Good, thanks, Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-01-02 1:53 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20181221180327.7142.84494@vcs0.savannah.gnu.org>
[not found] ` <20181221180328.D755D20538@vcs0.savannah.gnu.org>
2018-12-22 16:26 ` [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts Stefan Monnier
2018-12-22 21:23 ` João Távora
2018-12-28 16:33 ` João Távora
2018-12-28 17:51 ` Stefan Monnier
2018-12-28 22:00 ` João Távora
2018-12-29 15:59 ` Stefan Monnier
2018-12-29 18:36 ` João Távora
2019-01-02 1:53 ` Stefan Monnier
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).