2017-11-10 12:08 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>:
>
>
> > On 10 Nov 2017, at 11:59, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
> >
> > My proposition was to force methodBody closing to be on first column,
> > and disambiguate potential method conflicts by forcing a more
> transparent white space.
> >
> > Maybe we can force the white space only on conflicting lines that would
> begin with a ].
> > Most methods are indented (and even formatted) so the conflict should be
> extremely rare.
> > It could happen though with multiple line literal string
> >
> > ^'
> > [
> > something went wrong here
> > ]
> > '
> >
> > If first column trick is not acceptable, then we will indeed come up
> with more visible escape sequences.
>
> But don't you think that it would be weird to insert extra whitespace and
> not remove it (under the assumption that it does not matter), because is
> string constants like in your example, you would actually change code !
>
> And yes, we are discussing a very rare case.
>
> But as you showed, simplifying #methodBody is really important.
>
>
Indeed, in some well known case, a literal would be modified bewteen Pharo
and Tonel which would be rare but weird...
Currently, Tonel does not have to change the syntax at all.
The first goals are:
- we should prefer a syntax agnostic format for two reasons
* not insulting the future and supporting alternate syntax extensions
(compilerClass)
* making the parsing both robust and efficient (not necessary to use a
RB parser for a quick scan)
- we don't want too many decorations that would make the Tonel syntax look
different from Pharo syntax
If we also want to support human edited Tonel files:
- we want something resilient (not be too much picky about a missing
leading space for example)
- we want the most simple rules and least surprising rules
The first two goals look really antagonist...
There are other possibilities: if we don't want to change the methodBody at
all, then let's change the opening/closing sequence
- at write, choose a closing sequence that has no exact match in source
code, then use the inverse sequence as the opening sequence
- at read, just scan for the inverse of opening sequence
opening sequence could be any combination of [{<(
or maybe just a single [ repeated as many times as necessary
> 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen <
> henrik.s.johan...@veloxit.no>:
> > Can a line with a single ] ever at the "right" indentation level?
> > Forcing autoformat at commit is a bit heavy hand, but maybe inserting a
> tab
> > (or 2,3,4 spaces?) would be an ok workaround that doesn't require special
> > decoding when loading the code?
> >
> > Cheers,
> > Henry
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >
> >
>
>
>
