all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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 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.