all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Markus Triska <triska@metalevel.at>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 21526@debbugs.gnu.org
Subject: bug#21526: 24.5; prolog-mode: broken indentation for if-then-else construct
Date: Wed, 30 Sep 2015 20:35:40 +0200	[thread overview]
Message-ID: <87vbarwy9v.fsf@metalevel.at> (raw)
In-Reply-To: <jwvlhbocmji.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Wed, 30 Sep 2015 05:23:38 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't understand.  You say you want
>
>     :- multifile
>            pred1,
>            pred2,
>            pred3.

Yes, exactly. The most frequent such directives are:

    discontiguous dynamic meta_predicate module_transparent multifile 

Their unary argument is always a valid Prolog term itself, and the whole
directive is, like everything that appears in a Prolog file (except
comments), also a valid Prolog term, and ends with a '.'.

As a good approximation, you can expect these directives to have the
form:

   :- <keyword> pred1,
           pred2,
           ...,
           pred_n.

Where pred_k is a predicate indicator of the form Name/Arity, where
Name is a Prolog atom and Arity is an integer.

The atom may of course also contain a '.', for example, the directive
may look like:

   :- multifile 'unusual.predicate'/1.

This situation is very rare, but at least it should not produce errors.

> whereas clearly you'd like
>
>        multifile
>            (pred1,
>            pred2,
>            pred3)

Yes, this is because of the built-in precedences: multifile has
precedence 1150, and thus (,)/2 with arity 1000 binds more tightly.

> what should happen if "multifile" appears elsewhere?  what other keyword
> can appear where you have "multifile" and do they all use this
> same syntax?

The term above is just like any other Prolog term, so if multifile
appears elsewhere then, from a purely semantic point of view, I would
expect it to also indent just according to the structure of the
resulting Prolog term. However, not even Stefan Bruda's mode goes so far
as to ensure this kind of semantic indentation. For example, from a
purely semantic view, in the following example, the atom 'x' is an
argument of the operator multifile:

   test :-
           multifile
                   x.

However, as a first approximation, it would already be great to handle
this indentation of multifile just in directives (= lines where (:-)/1
is the primary functor). This is also what Stefan Bruda's mode does.

The same goes for the other keywords shown above.

The ability to define custom operators makes Prolog code harder to parse
and indent semantically than other languages. If you are interested in
truly pushing this to its ultimate conclusion, you will have to
dynamically take operator precedences into account, using Prolog's
current_op/3 predicate to look up the current precedences.

Independently of all this, would you please consider to set the default
value of prolog-electric-if-then-else-flag to t in Emacs? I find this
behaviour extremely useful, and other modes like C also have electric
indentation turned on by default in recent Emacs versions.

Thank you and all the best!
Markus





  reply	other threads:[~2015-09-30 18:35 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-20 13:02 bug#21526: 24.5; prolog-mode: broken indentation for if-then-else construct Markus Triska
2015-09-20 18:04 ` Stefan Monnier
2015-09-20 19:33   ` Markus Triska
2015-09-21  2:34     ` Stefan Monnier
2015-09-21  3:03     ` Stefan Monnier
2015-09-21  6:02       ` Markus Triska
2015-09-21 20:22         ` Stefan Monnier
2015-09-22  6:25           ` Markus Triska
2015-09-22 15:12           ` Stefan Monnier
2015-09-22 16:38             ` Markus Triska
2015-09-22 21:04               ` Markus Triska
2015-09-23 21:08                 ` Markus Triska
2015-09-25 16:20                   ` Markus Triska
2015-09-30  2:04                     ` Stefan Monnier
2015-09-30  3:28                   ` Stefan Monnier
2015-09-30  6:38                     ` Markus Triska
2015-09-30  9:23                       ` Stefan Monnier
2015-09-30 18:35                         ` Markus Triska [this message]
2015-09-30 20:19                           ` Stefan Monnier
2015-09-30 20:40                             ` Markus Triska
2015-10-01  0:14                               ` Stefan Monnier
2015-10-01  6:22                                 ` Markus Triska
2015-10-01 14:07                                   ` Stefan Monnier
2015-10-02 16:23                                     ` Markus Triska
2015-10-02 20:47                                       ` Stefan Monnier
2015-10-05 22:38                                         ` Markus Triska
2015-10-06  2:23                                           ` Stefan Monnier
2015-09-30 18:03                     ` Markus Triska
2015-09-30 21:19                       ` Stefan Monnier
2015-09-30  3:28                 ` Stefan Monnier
2015-09-30  2:07               ` Stefan Monnier
2015-09-30  6:32                 ` Markus Triska
2015-09-30  8:55                   ` Stefan Monnier
2015-09-30 18:11                     ` Markus Triska
2015-10-05 23:49                     ` Markus Triska
2015-10-06  1:17                       ` Stefan Monnier
2015-10-06 16:45                         ` Markus Triska
2015-10-06 20:09                           ` Stefan Monnier
2015-10-20 23:47                             ` Markus Triska
2015-10-21 16:06                               ` Stefan Monnier
2015-10-21 21:58                                 ` Markus Triska
2015-10-22  1:16                                   ` Stefan Monnier
2015-10-22 19:08                                     ` Markus Triska
2015-10-25 20:01                                       ` Stefan Monnier
2015-11-23 16:36               ` Stefan Monnier
2020-08-24 18:23                 ` Lars Ingebrigtsen
2015-09-29 15:27             ` Stefan Monnier
2015-09-29 16:24               ` Markus Triska

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vbarwy9v.fsf@metalevel.at \
    --to=triska@metalevel.at \
    --cc=21526@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.