New answers tagged

2

Rather than modifying the syntax tables, you can instead use the built-in superword-mode: Superword mode is a buffer-local minor mode. Enabling it changes the definition of words such that symbols characters are treated as parts of words: e.g., in ‘superword-mode’, "this_is_a_symbol" counts as one word. You can enable it per mode using a a hook: (...


5

Each major mode has its own syntax and syntax table. If you just put (modify-syntax-entry ?_ "w") in your init file, it gets evaluated in the buffer that is current when your init file is loaded -- not in a C/C++ buffer. To evaluate that sexp when in a C/C++ buffer you can put it in a function, which you add to the mode hook. For example (untested): (add-...


1

Thanks, Stefan, it seems to work like a charm! I.e. the parser state is exactly as expected, and e.g. forward-sexp now jumps over 'McDonald''s', which it did not do without the syntax propertizing. I am unsure where parse-sexp-lookup-properties, which must obviously be t for syntax table properties to be actually used, is set. pascal.el does not set it, ...


2

The syntax tables themselves can't handle this right, but Emacs offers syntax-propertize to circumvent this kind of limitation by giving special syntax to specific occurrences of characters in buffers. E.g. pascal-mode (where the same escaping is used in strings as the one you describe) has: (defconst pascal--syntax-propertize (syntax-propertize-rules ...


2

When there is an error in the syntax highlighting code, it is silently ignored by the font-lock package. When this happens, the buffer can be left in an unhighlighted state. You can use the package font-lock-studio to investigate what happens, and catch errors in the font-lock code. It is a debugger that lets you step each part of the font-lock rules and if ...


Top 50 recent answers are included