Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Mon, Jan 11, 2016 at 03:04:33AM +0000, Guillaume Munch wrote:
> 
> Dear Enrico,
> 
> 
> Thank you for the recent patches that took into account some of my remarks.
> 
> I have been using master a lot recently and I noticed another issue
> which annoyed me: In 2.1, the behaviour when typing Enter at the
> beginning of a paragraph is consistently to start a new paragraph before
> it. In 2.2, the behaviour changes and sometimes it introduces a parbreak
> separator instead, after a non-standard paragraph. The behaviour is now
> inconsistent. I think that the introduction of a parbreak separator
> after a non-standard paragraph should only happen on an empty paragraph.
> This does not change the amount of Enter required to introduce a
> separator from a non-standard paragraph, but restores the consistency of
> introducing a new paragraph with Enter at the start of a paragraph.

Please, can you try the attached patch and report back whether it does
what you expect?

Then, please let me thank you for your reports aimed at improving the
overall user experience. I only regret that they are the only ones
after almost two years from the introduction of env separators and that
they come just before a release, when the time for testing is not so
much.

> Also, I wanted to say that given that I did not follow the original
> conversations, I have more of a user's view on this, so I do not think
> that my comments are redundant. Users, new users, now, and in two years,
> are not going to care about historic reasons for such interface choices...

Agreed.

> For the symbol itself, my suggestion was a very elongated version of ⌟,
> meant to recall the plain separator inset. But, a character that
> would match the meaning would be the pilcrow sign (¶). One would just
> have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
> is not displayed after a red pilcrow sign because this would look weird
> (although could be allowed as a temporary measure). On the other hand,
> what was the idea behind your suggestion of ↔ ?

The symbol should not be too large, because it can also appear at the
end of a line when importing old documents, so that the appearance
would be ugly. The ↔ is simply a symbol that cannot be exchanged with
the newline one and also gives the idea of a separator, although it
probably fails to convey the concept that it introduces a blank line
in the latex output. 

> Finally, for the entry method, you are already changing the meaning of
> "Alt+M P" from "parbreak separator" to "plain separator", so in any case
> you are already making a choice. I wanted to say that if the one who
> implements a new feature does not think about what is the best default,
> who does? I had to configure LyX for several co-authors and already have
> too much settings to remember to change (enabling paragraph marks,
> setting forward-search, some shortcuts...).

If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.

-- 
Enrico

diff --git a/src/Text3.cpp b/src/Text3.cpp
index ee0902a..0933000 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1107,13 +1107,11 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
                                prev = pit - 1;
                }
                if (prev < pit && cur.pos() == par.beginOfBody()
-                   && !par.isEnvSeparator(par.size() ? par.size() - 1 : 0)
+                   && !par.size() && !par.isEnvSeparator(cur.pos())
                    && !par.layout().isCommand()
                    && pars_[prev].layout() != par.layout()
                    && pars_[prev].layout().isEnvironment()
-                   && (!nextpar.isEnvSeparator(nextpar.size() ? nextpar.size() 
- 1 : 0)
-                           || nextpar.layout().isCommand()
-                           || nextpar.layout().isEnvironment())) {
+                   && !nextpar.isEnvSeparator(nextpar.beginOfBody())) {
                        if (par.layout().isEnvironment()
                            && pars_[prev].getDepth() == par.getDepth()) {
                                docstring const layout = par.layout().name();