Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Thu, Oct 20, 2016 at 04:07:13PM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Oct 19, 2016 at 05:30:20PM -0700, Pavel Sanda wrote:
> > > Enrico Forestieri wrote:
> > > > On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > > > > 
> > > > > Funny thing is that my mutt read the previous message without doing
> > > > > what you describe...
> > > > 
> > > > I guess you are using the maildir format for your mailbox.
> > > 
> > > mbox here. but mutt version is somewhat archaic, that might be the cause.
> > 
> > This is weird. Are you sure those attachments actually start with
> > a "From " line in the mbox file? Maybe some email filtering program 
> > is helping you (procmail?). Another possibility is that there is
> > a configuration setting I am missing, but I was not able to find
> > anything with my search-fu abilities.
> > 
> 
> I use procmail indeed. URL below points to JMarc email as saved by procmail.
> Can your mutt process it propely as a single mail?
> http://195.113.26.193/~sanda/junk/msg.txt

Yes, of course, because procmail inserted a ">" just in front of the
"From " line in the attachment (which I do manually).

Care to share the corresponding config line(s) for procmail?

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Pavel Sanda]

Enrico Forestieri wrote:
> On Wed, Oct 19, 2016 at 05:30:20PM -0700, Pavel Sanda wrote:
> > Enrico Forestieri wrote:
> > > On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > > > 
> > > > Funny thing is that my mutt read the previous message without doing
> > > > what you describe...
> > > 
> > > I guess you are using the maildir format for your mailbox.
> > 
> > mbox here. but mutt version is somewhat archaic, that might be the cause.
> 
> This is weird. Are you sure those attachments actually start with
> a "From " line in the mbox file? Maybe some email filtering program 
> is helping you (procmail?). Another possibility is that there is
> a configuration setting I am missing, but I was not able to find
> anything with my search-fu abilities.
> 

I use procmail indeed. URL below points to JMarc email as saved by procmail.
Can your mutt process it propely as a single mail?
http://195.113.26.193/~sanda/junk/msg.txt

Pavel

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 05:30:20PM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > > 
> > > Funny thing is that my mutt read the previous message without doing
> > > what you describe...
> > 
> > I guess you are using the maildir format for your mailbox.
> 
> mbox here. but mutt version is somewhat archaic, that might be the cause.

This is weird. Are you sure those attachments actually start with
a "From " line in the mbox file? Maybe some email filtering program 
is helping you (procmail?). Another possibility is that there is
a configuration setting I am missing, but I was not able to find
anything with my search-fu abilities.

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Thu, Oct 20, 2016 at 03:12:50PM +0200, Jean-Marc Lasgouttes wrote:
> 
> I have searched a bit, and the only thing I have found (with my MUA
> Thunderbird)
> is to change _all_ my attachments to be base64. I'll try that, because I
> prefer to have you with me than against me ;), but I may have to revert to
> some more standard way of working.

No problem. I was suspecting I was the only one suffering this issue.
As I am an unreasonable man, I persist in trying to adapt the world
to myself instead of adapting to the world...

> >This is because mutt takes them to be separate emails placed somewhere
> >else in the list of emails and I have to search for them or edit the
> >mailbox file to add a ">" just before "From" in order to actually see
> >them as attachments.
> 
> That's very weird, if you ask me.

From the mutt manual (this From will be escaped by MUAs):

   mbox. This is a widely used mailbox format for UNIX. All messages are
   stored in a single file. Each message has a line of the form:
   From m...@cs.hmc.edu Fri, 11 Apr 1997 11:44:56 PST
   to denote the start of a new message (this is often referred to as the
   "From_" line). The mbox format requires mailbox locking, is prone to
   mailbox corruption with concurrently writing clients or misinterpreted
   From_ lines. Depending on the environment, new mail detection can be
   unreliable. Mbox folders are fast to open and easy to archive.

The last bits are the ones important to me and the reason I prefer mbox.
One can have a single mbox file in a given directory containing all email
exchanges about the documents in that directory.

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Scott Kostyshak]

On Wed, Oct 19, 2016 at 11:50:06PM +0200, Enrico Forestieri wrote:
> On Wed, Oct 19, 2016 at 04:12:54PM -0400, Scott Kostyshak wrote:
> > On Wed, Oct 19, 2016 at 07:03:32PM +0200, Enrico Forestieri wrote:
> > 
> > > This is because mutt takes them to be separate emails placed somewhere
> > > else in the list of emails and I have to search for them or edit the
> > > mailbox file to add a ">" just before "From" in order to actually see
> > > them as attachments.
> > 
> > I wonder why all MUA's don't automatically escape the "From".
> 
> I think they do, but only when it is in the email body, otherwise they
> would change the attachment, which is no go. Here is how an email from
> JMarc looks like:

Ah I understand.

> > Note that I don't have to do any manual configuration for JMarc's
> > patches to show up in mutt, but I think this is due to different
> > settings for storing messages (e.g. $mbox_type).
> 
> I guess you use the maildir format.

Yes I do.

> > P.S. By the way, the following is an exciting project to follow:
> > https://github.com/neomutt/neomutt
> 
> Interesting. When NeoLyX? ;-)

That almost sounds scary.

Scott


signature.asc
Description: PGP signature

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

Le 19/10/2016 à 19:37, Richard Heck a écrit :

Yes, good for both. It will get much more testing in stable, and we are
presumably some ways from 2.2.3.


Thanks, I did that.

JMarc

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

Le 19/10/2016 à 19:03, Enrico Forestieri a écrit :

On Wed, Oct 19, 2016 at 06:20:51PM +0200, Jean-Marc Lasgouttes wrote:


Thanks, it seems to work well. Here is the combo commit, for reference.


Jean-Marc, please, can you use some kind of encoding (base64,
quoted-printable or whatever) when attaching patches that start
with the word "From"?


I have searched a bit, and the only thing I have found (with my MUA 
Thunderbird)
is to change _all_ my attachments to be base64. I'll try that, because I 
prefer to have you with me than against me ;), but I may have to revert 
to some more standard way of working.



This is because mutt takes them to be separate emails placed somewhere
else in the list of emails and I have to search for them or edit the
mailbox file to add a ">" just before "From" in order to actually see
them as attachments.


That's very weird, if you ask me.

JMarc

Re: [PATCH] Re: Return + Return in nested environments

[Pavel Sanda]

Enrico Forestieri wrote:
> On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > 
> > Funny thing is that my mutt read the previous message without doing
> > what you describe...
> 
> I guess you are using the maildir format for your mailbox.

mbox here. but mutt version is somewhat archaic, that might be the cause.
p

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> 
> Funny thing is that my mutt read the previous message without doing
> what you describe...

I guess you are using the maildir format for your mailbox.

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Pavel Sanda]

Enrico Forestieri wrote:
> On Wed, Oct 19, 2016 at 06:20:51PM +0200, Jean-Marc Lasgouttes wrote:
> > 
> > Thanks, it seems to work well. Here is the combo commit, for reference.
> 
> Jean-Marc, please, can you use some kind of encoding (base64,
> quoted-printable or whatever) when attaching patches that start
> with the word "From"?
> 
> This is because mutt takes them to be separate emails placed somewhere
> else in the list of emails and I have to search for them or edit the
> mailbox file to add a ">" just before "From" in order to actually see
> them as attachments.

Funny thing is that my mutt read the previous message without doing
what you describe...
Pavel

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 04:12:54PM -0400, Scott Kostyshak wrote:
> On Wed, Oct 19, 2016 at 07:03:32PM +0200, Enrico Forestieri wrote:
> 
> > This is because mutt takes them to be separate emails placed somewhere
> > else in the list of emails and I have to search for them or edit the
> > mailbox file to add a ">" just before "From" in order to actually see
> > them as attachments.
> 
> I wonder why all MUA's don't automatically escape the "From".

I think they do, but only when it is in the email body, otherwise they
would change the attachment, which is no go. Here is how an email from
JMarc looks like:

==
...
JMarc

--83A8A64D719F76B5A07C9640
Content-Type: text/x-patch;
 name="0001-When-breaking-an-empty-paragraph-reduces-depth-set-l.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-When-breaking-an-empty-paragraph-reduces-depth-set-l.pa";
 filename*1="tch"

From 43658068801ad9772728973103414e81373e5a75 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 13 Oct 2016 20:33:57 +0200
Subject: [PATCH] When breaking an empty paragraph reduces depth, set layout
 too
...
==

As you can see, the line "From 4365..." is the start of the attachment,
but all lines starting with "From " are, by the default, the start of
a new email in the mailbox format.

Instead, here is an email from you:

==
...
Scott

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; 
filename="0001-autotools-remove-duplicate-check-for-NLS.patch"
Content-Transfer-Encoding: quoted-printable

=46rom 6bfb47eadad68faa8be86506d56e888735f2c7c5 Mon Sep 17 00:00:00 2001
=46rom: Scott Kostyshak 
Date: Fri, 20 Nov 2015 22:15:34 -0500
Subject: [PATCH] autotools: remove duplicate check for NLS
...
==

Here the "From " line is encoded as "=46rom " and then later decoded
when displayed on screen. In this case you used quoted-printable, but
also base64 would do. No problem in this case with the mailbox format.

> Note that I don't have to do any manual configuration for JMarc's
> patches to show up in mutt, but I think this is due to different
> settings for storing messages (e.g. $mbox_type).

I guess you use the maildir format.

> P.S. By the way, the following is an exciting project to follow:
> https://github.com/neomutt/neomutt

Interesting. When NeoLyX? ;-)

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Scott Kostyshak]

On Wed, Oct 19, 2016 at 07:03:32PM +0200, Enrico Forestieri wrote:

> This is because mutt takes them to be separate emails placed somewhere
> else in the list of emails and I have to search for them or edit the
> mailbox file to add a ">" just before "From" in order to actually see
> them as attachments.

I wonder why all MUA's don't automatically escape the "From".

Although the attachments show up by default for me, a convenient tool to
use is "ripmime". I have mutt configured so that if I press [a, the
attachments are all extracted to a temporary folder and then that folder
is opened in nautilus. Let me know if you would like to see the small
script that does that. Ah (after thinking for a minute), that would not
work for you because when you view JMarc's message the attachment is not
even in that message, so ripmime won't even be able to extract it.
Nevermind then.

Note that I don't have to do any manual configuration for JMarc's
patches to show up in mutt, but I think this is due to different
settings for storing messages (e.g. $mbox_type).

Scott

P.S. By the way, the following is an exciting project to follow:
https://github.com/neomutt/neomutt


signature.asc
Description: PGP signature

Re: [PATCH] Re: Return + Return in nested environments

[Richard Heck]

On 10/19/2016 12:20 PM, Jean-Marc Lasgouttes wrote:
> Le 19/10/2016 à 18:12, Enrico Forestieri a écrit :
>> I had a look and it turns out that the code dealing with separator
>> insets was specifically tailored to the old behaviour. If you change
>> that behaviour, you should also change the corresponding separator code.
>> This is what the attached patch does. It must be applied if your patch
>> is applied, otherwise not.
>>
>> Anyway, the previous behaviour was really strange and indeed also
>> the code to be changed for introducing a separator simplifies, as
>> you can see.
>
> Thanks, it seems to work well. Here is the combo commit, for
> reference. I propose to commit it to master and maybe branch
> (Richard?), so that we can evaluate whether we like it.

Yes, good for both. It will get much more testing in stable, and we are
presumably some ways from 2.2.3.

rh

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 06:20:51PM +0200, Jean-Marc Lasgouttes wrote:
> 
> Thanks, it seems to work well. Here is the combo commit, for reference.

Jean-Marc, please, can you use some kind of encoding (base64,
quoted-printable or whatever) when attaching patches that start
with the word "From"?

This is because mutt takes them to be separate emails placed somewhere
else in the list of emails and I have to search for them or edit the
mailbox file to add a ">" just before "From" in order to actually see
them as attachments.

Don't worry if this is not possible, but I see that Scott does it and
I have no problems with his attachments.

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

Le 19/10/2016 à 18:12, Enrico Forestieri a écrit :

I had a look and it turns out that the code dealing with separator
insets was specifically tailored to the old behaviour. If you change
that behaviour, you should also change the corresponding separator code.
This is what the attached patch does. It must be applied if your patch
is applied, otherwise not.

Anyway, the previous behaviour was really strange and indeed also
the code to be changed for introducing a separator simplifies, as
you can see.


Thanks, it seems to work well. Here is the combo commit, for reference. 
I propose to commit it to master and maybe branch (Richard?), so that we 
can evaluate whether we like it.


JMarc

>From 72f680d1d03acc52f57dd4873a676484a1927c49 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 13 Oct 2016 20:33:57 +0200
Subject: [PATCH] When breaking an empty paragraph reduces depth, set layout
 too

This requires an adaptation of the Separator inset insertion code,
which has been duly provided by Enrico.
---
 src/Text.cpp  |8 ++--
 src/Text3.cpp |8 +---
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/src/Text.cpp b/src/Text.cpp
index 007271d..16bf899 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -738,9 +738,13 @@ void Text::breakParagraph(Cursor & cur, bool inverse_logic)
 	Layout const & layout = cpar.layout();
 
 	if (cur.lastpos() == 0 && !cpar.allowEmpty()) {
-		if (changeDepthAllowed(cur, DEC_DEPTH))
+		if (changeDepthAllowed(cur, DEC_DEPTH)) {
 			changeDepth(cur, DEC_DEPTH);
-		else {
+			pit_type const prev = depthHook(cpit, cpar.getDepth());
+			docstring const & lay = pars_[prev].layout().name();
+			if (lay != layout.name())
+setLayout(cur, lay);
+		} else {
 			docstring const & lay = cur.paragraph().usePlainLayout()
 			? tclass.plainLayoutName() : tclass.defaultLayoutName();
 			if (lay != layout.name())
diff --git a/src/Text3.cpp b/src/Text3.cpp
index eafce28..85d0c3c 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1089,13 +1089,7 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
 		Paragraph const & par = pars_[pit];
 		bool lastpar = (pit == pit_type(pars_.size() - 1));
 		Paragraph const & nextpar = lastpar ? par : pars_[pit + 1];
-		pit_type prev = pit;
-		if (pit > 0) {
-			if (!pars_[pit - 1].layout().isEnvironment())
-prev = depthHook(pit, par.getDepth());
-			else if (pars_[pit - 1].getDepth() >= par.getDepth())
-prev = pit - 1;
-		}
+		pit_type prev = pit > 0 ? depthHook(pit, par.getDepth()) : pit;
 		if (prev < pit && cur.pos() == par.beginOfBody()
 		&& !par.size() && !par.isEnvSeparator(cur.pos())
 		&& !par.layout().isCommand()
-- 
1.7.9.5

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 02:53:43PM +0200, Jean-Marc Lasgouttes wrote:
> Le 19/10/2016 à 14:30, Jean-Marc Lasgouttes a écrit :
> >>Tested and I think there is a minor issue. In the attached .lyx file,
> >>put the cursor at the end of "hello". Press return three times. The
> >>first two times show that the issue initially reported is fixed (because
> >>it is itemize instead of enumerate), but the third return is unexpected
> >>for me. I expected it to go out of itemize, but instead it created an
> >>item with a separator.
> >>
> >>Can you reproduce the above with your patch?
> >
> >I see what you mean. I guess that I am colliding somehow with the logic
> >that introduces separator insets.
> 
> There is some kind of Clash beween the logic here and Enrico's logic wrt
> paragraph separators.
> 
> Here I am in a logic where using Return in an empty environment will signal
> that I want to close it and go to the uspper level.
> 
> Enrico's code, OTOH assumes that what is meant here is to split the
> environment in two but stay at the same level. I do not see why my patch
> made Enrico's code trigger. Well, I see it technically, but I do not see
> what sense it makes.
> 
> Enrico, do you have thoughts about what we really want there? What is the
> use case that we have in mind, especially when we are in a nested
> environment?

I had a look and it turns out that the code dealing with separator
insets was specifically tailored to the old behaviour. If you change
that behaviour, you should also change the corresponding separator code.
This is what the attached patch does. It must be applied if your patch
is applied, otherwise not.

Anyway, the previous behaviour was really strange and indeed also
the code to be changed for introducing a separator simplifies, as
you can see.

-- 
Enrico
diff --git a/src/Text3.cpp b/src/Text3.cpp
index eafce28..85d0c3c 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1089,13 +1089,7 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
Paragraph const & par = pars_[pit];
bool lastpar = (pit == pit_type(pars_.size() - 1));
Paragraph const & nextpar = lastpar ? par : pars_[pit + 1];
-   pit_type prev = pit;
-   if (pit > 0) {
-   if (!pars_[pit - 1].layout().isEnvironment())
-   prev = depthHook(pit, par.getDepth());
-   else if (pars_[pit - 1].getDepth() >= par.getDepth())
-   prev = pit - 1;
-   }
+   pit_type prev = pit > 0 ? depthHook(pit, par.getDepth()) : pit;
if (prev < pit && cur.pos() == par.beginOfBody()
&& !par.size() && !par.isEnvSeparator(cur.pos())
&& !par.layout().isCommand()

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 02:53:43PM +0200, Jean-Marc Lasgouttes wrote:
> 
> Enrico, do you have thoughts about what we really want there? What is the
> use case that we have in mind, especially when we are in a nested
> environment?

It does not seem to be something about nested environments. For example,
if you put the cursor after the "two" in the attached example and press 3
times return, everything works with or without your patch.
Moreover, the separator thing should trigger only when one is in a
standard environment when pressing return. I'll have a look.

-- 
Enrico
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 508
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Itemize
one
\end_layout

\begin_deeper
\begin_layout Enumerate
hello
\end_layout

\begin_deeper
\begin_layout Enumerate
two
\end_layout

\end_deeper
\end_deeper
\end_body
\end_document

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

Le 19/10/2016 à 14:30, Jean-Marc Lasgouttes a écrit :

Tested and I think there is a minor issue. In the attached .lyx file,
put the cursor at the end of "hello". Press return three times. The
first two times show that the issue initially reported is fixed (because
it is itemize instead of enumerate), but the third return is unexpected
for me. I expected it to go out of itemize, but instead it created an
item with a separator.

Can you reproduce the above with your patch?


I see what you mean. I guess that I am colliding somehow with the logic
that introduces separator insets.


There is some kind of Clash beween the logic here and Enrico's logic wrt 
paragraph separators.


Here I am in a logic where using Return in an empty environment will 
signal that I want to close it and go to the uspper level.


Enrico's code, OTOH assumes that what is meant here is to split the 
environment in two but stay at the same level. I do not see why my patch 
made Enrico's code trigger. Well, I see it technically, but I do not see 
what sense it makes.


Enrico, do you have thoughts about what we really want there? What is 
the use case that we have in mind, especially when we are in a nested 
environment?


JMarc

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

Le 14/10/2016 à 17:16, Scott Kostyshak a écrit :

On Fri, Oct 14, 2016 at 03:22:09PM +0200, Jean-Marc Lasgouttes wrote:

Le 07/10/2016 à 03:48, Scott Kostyshak a écrit :

I don't know much about layout nesting, but my first reaction is that I
agree with you regarding the expected behavior.


Did we figure out what the correct behavior for this is?


Please try that and tell me whether it works for you.


Tested and I think there is a minor issue. In the attached .lyx file,
put the cursor at the end of "hello". Press return three times. The
first two times show that the issue initially reported is fixed (because
it is itemize instead of ennumerate), but the third return is unexpected
for me. I expected it to go out of itemize, but instead it created an
item with a separator.

Can you reproduce the above with your patch?


I see what you mean. I guess that I am colliding somehow with the logic 
that introduces separator insets.


JMarc

Re: [PATCH] Re: Return + Return in nested environments

[Scott Kostyshak]

On Fri, Oct 14, 2016 at 03:22:09PM +0200, Jean-Marc Lasgouttes wrote:
> Le 07/10/2016 à 03:48, Scott Kostyshak a écrit :
> > > I don't know much about layout nesting, but my first reaction is that I
> > > agree with you regarding the expected behavior.
> > 
> > Did we figure out what the correct behavior for this is?
> 
> Please try that and tell me whether it works for you.

Tested and I think there is a minor issue. In the attached .lyx file,
put the cursor at the end of "hello". Press return three times. The
first two times show that the issue initially reported is fixed (because
it is itemize instead of ennumerate), but the third return is unexpected
for me. I expected it to go out of itemize, but instead it created an
item with a separator.

Can you reproduce the above with your patch?

Scott
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 508
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Itemize
one
\end_layout

\begin_deeper
\begin_layout Enumerate
hello
\end_layout

\end_deeper
\end_body
\end_document


signature.asc
Description: PGP signature