Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]

[Vitalie Spinu <spinuvit@gmail.com>]

Ok, so the alternative proposal is not to do anything. I like that. The only
reason to have STRING-AFTER and STRING-BEFORE is potential mode specific
optimization. If that's not a concern, no need for that.

  Vitalie

>> On Mon, Mar 21 2016 16:56, Dmitry Gutov wrote:

> On 03/21/2016 04:42 PM, Vitalie Spinu wrote:

>>> """
>>> Instead, if you want to know what indentation an inner mode would return if
>>> STRING-BEFORE was before it, insert that string into the buffer (while
>>> inhibiting undo history). Call the indentation function, then remove the string.
>>> """
>>
>> Inner mode might decide to operate on string directly, or put stuff in a temp
>> buffer, work on last line only, or simply ignore it.

> Yes, each major mode would have to make all of these choices.

> Why burden them with that concern? Wouldn't that become a part of the same
> problem that you yourself mentioned, "teaching modes about multi-modes"?

>> Why to hard-wire the usage
>> of STRING-BEFORE so badly?

> What hard-wiring?

> STRING-BEFORE is not a tangible part of my proposal. There's no API change tied
> to it.

>> My gut feeling is to avoid modifying buffer context in indentation engine at all
>> costs.

> Why? That's worked out okay for me.

> Alternatively, you can create a temp buffer each time, compose pieces of inner
> mode text in it, and call the indentation function. Again, in multi-mode code.

>> In the future, if performance with temp buffers will be a real issue, we
>> can add more low level functions for fast operation on string to do some common
>> parsing tasks. We can even extend parse-ppss to deal with BEFORE-STRING.

> Performance is a distant concern, complexity is the immediate one. If modifying
> buffers turns out to be a problem, then we can do all the stuff you mention
> above.