[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss return
From: |
Vitalie Spinu |
Subject: |
Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.] |
Date: |
Mon, 21 Mar 2016 17:52:41 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (gnu/linux) |
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.
- Re: [Patch] hard-widen-limits [was Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]], (continued)
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Dmitry Gutov, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Vitalie Spinu, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Dmitry Gutov, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Vitalie Spinu, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Dmitry Gutov, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Vitalie Spinu, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Dmitry Gutov, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.],
Vitalie Spinu <=
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Dmitry Gutov, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Stefan Monnier, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Vitalie Spinu, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Stefan Monnier, 2016/03/21
- Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.], Andreas Röhler, 2016/03/21