Le 19/08/2015 21:28, Georg Baum a écrit :
Guillaume Munch wrote:
Le 31/07/2015 23:08, Scott Kostyshak a écrit :
On Fri, Jul 31, 2015 at 12:05 PM, Guillaume Munch <ga...@free.fr>
wrote:
\{ and \% now correctly use the selection as their argument
instead of erasing it. Solves
<http://www.lyx.org/trac/ticket/6466>. Please criticise.
Also I noticed that LyX produces invalid LaTeX code if one
nests braces and comments, e.g. by typing \{\%\{\% ... but this
behaviour is already there before the patch.
I do not know this code enough to give feedback. However, I
wanted to ask you about a related idea (no problem if you are not
interested in discussing this). Suppose we have an inline math
inset, and we select the whole math inset (so with the cursor
outside the inset on the left, we do e.g. shift + <Right>). If I
do alt + M, {, the contents are replaced by an empty bracket
inset. I wonder though -- should we first convert the contents to
math, then put them in the brackets? So in the case I mentioned
above, the result would be the same as if we selected the entire
inside of the inset and did alt + M, {.
Any thoughts on this?
Currently you get different results for many actions if you select an
entire math inset or the entire math inset contents. I think this
makes sense: If you select the entire inset, then this is text mode,
and the text mode lfuns apply. If you select the inset contents, then
this is math mode, and the math mode lfuns apply.
In your particular case, Alt+M, { replaces any text selection with an
empty math brace inset, so from this point of vieew the behaviour is
consistent. One could of course think of trying to convert the
selection to math first and put it inside the math inset, but if this
is done then it should be done in general. It would fail in many
cases, but also work in may others, e.g. if only some letters without
any special formatting are selected.
Do you mean as per the attached? I had a quick look and found that
it could be made more consistent indeed with a small fix, to be
tested.
This looks a bit complicated. I could not yet look at it in detail,
but one thing that could be improved is the test for newcommand etc:
sel.find(from_ascii("\\newcommand"))) will also find a \newcommand in
the middle of the selecvtion, but what needs to be tested here is
whether the selection starts with such a command.
As described in the commit log, I already improved the situation much.
In detail it goes as follows:
The test sel.find(from_ascii("\\newcommand"))) no longer decides whether
a macro template is going to be introduced at this location. This role
is now devoted to the parsing function in MathMacroTemplate. If the
parsing fails, then we take the standard route and do not introduce a
macro template. Hence with the new code there are no more \invalidmacro
appearing.
Since the parsing already determines whether the code is meaningful (and
does so more reliably than a regexp), it is useless to try to replicate
this test here. (Also, I usually make minimal changes, for safety.)
Guillaume
