Re: [PATCH] etc/pickle-mode.el: add Emacs mode for .pk files

[Jose E. Marchesi]

Hi Aurélien.

    > My first comment is that we probably want to call this mode poke-mode
    > instead of pickle-mode.  Not all Poke files are pickles.  So we would
    > have:
    >
    >  poke-mode.el     -> Major mode for editing Poke programs.
    >  poke-map-mode.el -> Major mode for editing Poke MAP files.
    >  poke-ras-mode.el -> Major mode for editing Poke RAS files.
    >
    > and then, soon, we will add an Emacs-based editor based on poke, as the
    > machine-interface evolves:
    >
    >  poke.el -> Editor for structured binary data.
    >
    > WDYT?
    
    Sounds good :)
    
Ok, let's settle in poke-mode.el then.

    > Other than that, this looks very nice.  It will be interesting to write
    > an operator precedence SMIE grammar for Poke.
    
    My sarcasm-o-meter is not working well. You mean this is going to be a
    pain right? I've never used SMIE before but I suspected it wouldn't be
    easy... What should I know about the operator precedence of SMIE
    grammars? I only have a basic understanding of parsing in general.

No no sarcasm... parsing is one of my hard-to-confess perversions :)
    
    Emacs ships with an Emacs-lisp bison-like parser generator (Wysent) but
    I've never used it either. Sounds like a lot of work to reuse and it
    won't handle invalid states as you type so I don't know.

I would go with SMIE if possible.  A big advantage of operator
precedence grammars is that they are very good with "invalid" input and
partially constructed sentences.

I once wrote a SMIE-based grammar for Algol68.  You can find it in
http://www.jemarch.net/a68-mode.el

Basically we have to provide a BNF grammar, but the grammar should
implement certain restrictions if its to be used in an
operator-precedence parser.  I wrote a comment about it in a68-mode.el:

;; BNF grammar used in smie.
;;
;; Note that this grammar is an "operator grammar", meaning it can be
;; processed by an operator precedence parser.  The following
;; restrictions apply to operator grammars:
;;
;; - Epsilon rules are not allowed.
;; - Production rules can't have two consecutive non-terminals in
;;   their right side.
;;
;; Also, note that this grammar does not generate valid Algol68
;; programs.  Terminals that are not strings are not operators, and
;; are ignored by the parser: id, base-mode, string, char.
;;
;; In some cases those terminals are not included in the grammar to
;; avoid incompatibilities.  In concrete, in rules with right sides
;; containing <mode> <id> the identifier is removed.

The same remarks stand for Poke.

A CF grammar of Poke can be found in libpoke/pkl-tab.y, but of course
the SMIE grammar shouldn't be as complex: many constructions that do not
impact indentation don't need to appear in the grammar at all!

We should also provide a tokeniser.  That is a68-mode-smie-forward-token
and a68-mode-smie-backward-token in the mode above.

Note how some tricks are done, using the tokeniser to alleviate some of
the restrictions of the grammar.  For example, look at the rules:

      (generator-1 ("[" unit ":" unit "]" mode))
      (generator-2 ("[" unit ":" unit "]-gen" "[-gen" unit ":" unit "]" mode))

The first rule would match:

   [10]int

Whereas the second rule would match:

   [10][20]int

So it is up for tokeniser to distinguish the context for the token
"]-gen" as opposed to a normal "]".

Another example is the ":-use" token in the rule:

      (use ("USE" cslist-id ":-use"))

Where the tokeniser does

  (if (looking-back "USE[^A-Z]*")
      ":-use")

Fortunately syntactically Poke is _much_ simpler than Algol 68 :)

    > Where do you want to maintain the code?  I think that maintaining it in
    > poke.git makes sense, as you are proposing in your patch.  Please let me
    
    Initially I was planning to have a separate repo but later realized it
    would make more sense to have it in Poke repo to keep it in sync.
    
    I also thought that having third-party Poke things might unconsiously
    (or consiously) force the Poke language to be set it stone and leave no
    room for more drastic syntax changes. I would rather let you experiment
    freely while it is still possible :)
    
    > know your savannah user, and I will give you write permissions to the
    > repo.  From there, I guess we can do releases in MELPA, ELPA or
    > whatever.
    
    Great, thanks. My savanah user is aaptel.

Ok, I just added you to the poke savannah group.  Now you should have
write access.

Feel free to commit the mode, once renamed to poke-mode.el, to add
yourself to the "Write After Approval" section in HACKING, and to
AUTHORS.

Considering the Emacs mode is quite decoupled from the rest of the code,
you can add a new section right before Write After Approval:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Maintainers
~~~~~~~~~~~

Maintainers are individuals who are responsible for, and have permission
to check in changes in, certain subsets of the code, and push them to
the master branch.  Note that that maintainers still need approval to
check in changes outside of the immediate domain that they maintain.

Note also that maintainers are still asked to send [COMMITTED] messages
to the list with the patches they push.  This helps to keep the other
hackers aware of what is going on in other areas.

etc/poke-mode.el        Aurélien Aptel <aaptel@suse.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Please do not forget to update the TOC of the document.

    Side note: it feels really redundant to have ChangeLog entries in the
    ChangeLog file AND commit message. I feel like only one should be needed.

Yes.  We will soon be adopting a different strategy: either using a
script that generates the ChangeLog file from the commit messages or
using a script that generates the entries themselves from the
changesets...

Welcome on board! :)