Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[Stefan Monnier]

> +            ('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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[João Távora]

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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[João Távora]

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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[Stefan Monnier]

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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[João Távora]

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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[Stefan Monnier]

> 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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[João Távora]

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

Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts

[Stefan Monnier]

> * If it returns nil it means "didn't match";
> * If it returns (nil) it means "matches but don't do anything"';

Good, thanks,


        Stefan