Hot answers tagged

6

Speed is a good reason to let the paren-matching be performed by syntax-tables where possible. In your case, the "parens" are not multi-char, so you can definitely use syntax-tables for them. In order to avoid treating -> as a paren closer, you can setup a syntax-propertize-function which modifies the syntax of those > which appear in ->. ...


5

Regarding 2, the problem is simple: your major-mode function needs to set comment-start. This part has nothing to do with SMIE. Regarding 3, I'm not sure exactly what it is you're doing (where is point? what does the buffer contain? what command have you run?). But I suggest to first concentrate on indentation of the non-comment parts of the code. As ...


4

Besides the SMIE package (which can indeed use a BNF grammar, but will usually not work well with a BNF grammar that was designed for the usual LALR-style parser), there's the wisi package available from GNU ELPA (http://elpa.gnu.org/packages/wisi.html): The wisi package provides utilities for using generalized LALR parsers to do indentation, ...


3

If you replace AttributeBegin and AttributeEnd with open and close parens, you code is basically of the form: test; (...) (...) (...) The reason for this indentation is that there is no ; between the three parenthesized elements. Basically, SMIE parses the above as a ; operator with test on the left and (...) (...) (...) on the right. And SMIE ...


3

Your problem lies within the indentation rules. You must align the text after "AttributeEnd" to the parent token of "AttributeEnd", i.e., its opener "AttributeBegin". You can do that with case ('(:after "AttributeEnd") (smie-rule-parent)) in function smie-sample-rules. There follows a complete minimal working example. First the Elisp code: (require '...


2

Check the code that uses sh-indent-after-continuation since that's the config variable that decides how continued lines should be indented. You'll probably want to look at the following change I installed recently: commit d6b49570f6fe1cfb5314c1b61b81ede0497a06b2 Author: Stefan Monnier <monnier@iro.umontreal.ca> Date: Tue Sep 29 21:43:07 2015 -0400 ...


1

Not sure why it highlights type as unmatched in the first case. Seems like a bug. If you don't want your = to match type then you're expected to set smie-blink-matching-inners to nil in your ~/.emacs. This said, I'm not completely sure if paren-mode obeys it. If not, that'd be a bug. Finally, you can also change your grammar to: ... (statement ("type" ...


1

You can also parse the empty string behind AttributeEnd as ;. Point behind AttributeEnd is the corresponding parser state. The only tricky detail is that you must flee from that position when you have parsed ; in forward direction and you may only parse the arrival at AttributeEnd as ; when you are parsing in backward direction. Minimal working example: (...


1

As suggested by Stefan in his comment, it seems like the best thing to do here is to modify the lexer(s) to return a virtual separator after "AttributeEnd" statements: (defun smie-sample-forward-token () "Go forwards to the next SMIE token." (let ((start-pos (point))) (forward-comment (point-max)) (cond ((and (> (point) start-pos) ...


1

In AttributeBegin test c d; AttributeEnd test c d; The Att..Begin...Att..End is just a (parenthesized) "expression", like test, c, and d because it's not separated from them with any keyword (which is why the same problem doesn't show up when you add a semi-colon between them). So SMIE considers the above as 4 ...


1

I just created a GNU Emacs major mode for editing BNF grammars. Currently provides basic syntax and font-locking for BNF files. EBNF and ABNF are in my plans for the near future.


1

You could start with something like (defconst foo-smie-grammar (smie-prec2->grammar (smie-bnf->prec2 '((exp ("begin" insts "end")) (insts (exp) (insts ";" insts)))))) ... (smie-setup foo-smie-grammar #'ignore) ...


1

A mode which heavily uses SMIE is https://github.com/elixir-lang/emacs-elixir Not sure if it really works though - see the list of indent-related bugs.


1

You'll probably want to use dummy comment settings. E.g. "#" for comment-start and "\\`.\\`" for comment-start-skip.


Only top voted, non community-wiki answers of a minimum length are eligible