It turns out that it is always better using the copy of the MacroData
for updating the macro_ pointer to avoid problems related to the cursor
position.
This effectively makes the horizontal size policy "minimum", which
makes it clear that there is no advantage for this widget of
increasing the horizontal size past the minimum, allowing other
GUI elements to use the horizontal space if useful.
This change for caseCB is consistent with wordsCB and searchbackCB.
This can happen when a macro is copied and then the document where
it is defined is closed. In this case, the macro survives in the
cut stack but the the buffer pointer is dangling.
Now the minibuffer toolbar is "auto" by default. It is opened by
command-execute (M-x) and closed when the command is executed without error.
* make lyx::dispatch return a DispatchResult struct
* there is a new MINIBUFFER type of toolbar, that can be used for this use.
* remove special handling of M-x in minnibuffer; Escape can be used instead. Fix focus in this case.
* when minibuffer toolbar is "auto", make the toolbar close itself after
- a command has been executed without error
- an empty command has been executed
- the Escape key has been used
The 'using namespace std' at the top of the file makes it quite difficult to
understand which abs is used: double std::abs<double>(double) or
int ::abs(int)? Now it is explicit, and the code does not change in subtle
ways if somebody removes the using statement.
The horizontal size policy is now set to "MinimumExpanding", which
means that sizeHint() is enforced as a minimum, but that the widget
can make use of extra available space.
Before, the size policy was ignored, and often resulted in a
scrunched pane that had to have its size manually increased.
The symptom of the bug is that the preference could be incorrectly
displayed (based on the value of the statusbar preference).
This seems to have been a copy/paste mistake introduced in 214f7ed2.
The MacroData pointer is updated by MathData::metrics() which is not
called when selecting a math inset with instant preview for math on.
Thus, we have to update it in the copy constructor otherwise a crash
is almost assured when hitting Ctrl+C.
If latex fails to generate any output, the forked process was not removed.
Now, if a snippet was changed a new one was started but, if also the zoom was
changed, things went awry because the 2 concurrent processes were asked to
process again the same snippet. Previously this would have simply caused a
waste of resources because the changed snippet would have not been regenerated.
Also reset the guard due to the early exit.
If the zoom factor is changed right while the previews are being
regenerated, the refreshPreviews() method is a no-op. So, reschedule
the refresh until everything is ready.
Relying on the fact that the timer is not active anymore does not
guarantee that the previews at the correct zoom are ready because
the regeneration process may take several seconds and during this
time the zoom factor may be changed again. So, we need an additional
guard for assuring that everything has settled down.
We only look once for the definition of the same macro, but we have
to always check its arguments when the same macro appears more than
once in a math inset. So, move earlier this check.
The strategy adopted in bc47054b had some drawbacks related to the way
instant preview snippets are generated. See the subthread starting at
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg187916.html
for details.
The strategy adopted in this commit is that of adding macro definitions
only for the macros actually used in a preview snippet, independently
of whether some macro was already used in a previous snippet. In this way
the snippets don't need to be changed according to whether they are
compiled as a whole or separately from each other. This fact was causing
the regeneration of a preview snippet whenever the cursor entered the
corresponding inset, even if the generated image would have not changed.
The problem of defining or redefining a macro is taken care by the
python scripts.
Unfortunately I overlooked in 44f73b0650 that the first three whitespace
changes in box-color-size-space-align.lyx.lyx were actually correct, so they
should not have been reverted. In detail:
1), 2): The space after \raggedleft must not be part of the ERT inset, but it
is ouput by check_space() as part of the standard text which follows.
3): The space in front of www is caused by the fact that there is a
newline between the opening brace of the parbox and the \centering
command, so this space is not the one after \centering (which is
correctly swallowed). This additional space is in fact not needed,
and the contents would look better in LyX without it, but since it is
not caused by special code I'll put it back in the refernce for now.
We can still improve this in the future if anybody has a good idea.
The remaining whitespace issues are all fixed by a simple change in
parse_text(): Instead of always eating whitespace after detecting \centering
et al, and always output a space as part of the ERT if these commands need an
ERT, let the standard space handling mechanism kick in: skip whitespace if
no ERT is used (in this case LyX will always output the needed space), and
do not touch whitespace if an ERT is used.
The FIXME is not needed, this is how StyleChanger and FracChanger work:
In the constructor, they change the state of the FontInfo, and in the
destructor the state is set back. Therefore, all code that needs the changed
state, needs to be executed while the objects do still exist.
Until now the regeneration process was starting as soon as the zoom scale
factor was changed. This was causing some glitches, especially if the zoom
was changed by the mouse wheel, as on each change the process was started
again and again making zoom changes painful and causing races such that
one could end up with the text at some zoom factor and the previews at
another one. After this commit, the regeneration is started only after
the zoom factor has been stable for about 1 second. In this way, one can
use the mouse wheel for changing back and forth the zoom factor at own's
heart desire without any slow down due to the regeneration process running
in the background. For those using previews with numbered math equations,
a nice possibility for getting the equations correctly numbered in sequence
(after removing or adding an equation) is using the shortcuts Alt+ and Alt-
in rapid sequence (less than a second between the keystrokes). Previously,
this would have triggered twice the regeneration, but now only once.
