Sven Schreiber | 5 Mar 12:59 2015

Re: #9442: Paste via keyboard shortcut (sometimes) not working on Windows

Am 05.03.2015 um 12:13 schrieb LyX Ticket Tracker:
> Comment (by skostysh):
>   Thanks for taking the time to write this up, sven.
>   Regarding pasting TeX instead of math, this is expected to happen if you
>   paste outside of a math inset. If you start a math inset and then paste,
>   it should be pasted as math. Does that work?

Yes I'd say that if pasting works, then this works, too.
I was just quoting James's additional comment to make the report 
complete. You would have to ask him whether this part of his experience 
is just the expected behavior.

My own experience has nothing to do with "wrong pasting", it's about 
whether it does anything at all or not (-> 'command disabled' message).


Kornel Benko | 2 Mar 18:26 2015

Master: Unable to export to lyx2.1.x format

To reproduce:


Open new file 'xxx.lyx'

write xxx

File->Export->LyX 2.1.x


==> An error occurred while runnig:

python -tt xxxxxxxx


Calling manually I get


# python -tt /usr/local/lyx2.2/lyx2lyx/lyx2lyx -t 474 xxx.lyx

Warning: An error ocurred in 481, <function revert_phrases at 0x7feba3d40ed8>

Traceback (most recent call last):

File "/usr/local/lyx2.2/lyx2lyx/lyx2lyx", line 86, in <module>


File "/usr/local/lyx2.2/lyx2lyx/lyx2lyx", line 80, in main


File "/usr9/local/lyx2.2/lyx2lyx/", line 564, in convert


File "/usr9/local/lyx2.2/lyx2lyx/", line 618, in revert_phrases

if len(words) > 1 and words[0] == "\\begin_inset" and \

NameError: global name 'words' is not defined

Exit 1


In fact, it suffices to change manually '\lyxformat 485' to '\lyxformat 474' in xxx.lyx.



Ian Wilder | 1 Mar 19:48 2015

Patch for automake 1.15

On compiling master on OS X 10.10 with current macports, balks at automake 1.15. I updated to accept 1.15 and it seems to work, but I’m no expert.

Here’s the patch if it’s useful.

-- ian
Attachment (bump_automake_version.diff): application/octet-stream, 273 bytes

Raymond Rogers | 1 Mar 00:17 2015

Re: #9436: Lyx 2.2 Left/Right arrow keys

p, li { white-space: pre-wrap; }

Thanks for the attention! I am not surprised you can't reproduce it; after all I haven't been able to either. That's the reason I marked the priority low and severity minor. I don't exacly know which of the repositories I get it from. Synaptic has
Liviu Andronic <landronimirc <at>>
as the maintainer. I do git it through the updater though. If you want I will poke around and see which repository it's coming from. I guess I should have better records (and control).
I did have several edits tabbed up; about 6.


From "Help"

LyX 2.2.0dev (2014-04-14)

Built on Feb 27 2015, 01:35:35


Host type: x86_64-pc-linux-gnu

Special build flags: build=release warnings use-aspell use-enchant use-hunspell

C++ Compiler: g++ (4.8)

C++ Compiler flags: -Wall -Wextra -O2

C++ Compiler user flags:

Linker flags:

Linker user flags:

Qt Frontend:

Qt version: 4.8.6

Packaging: posix

LyX binary dir: /usr/bin

LyX files dir: /usr/share/lyx2.2

p, li { white-space: pre-wrap; }

On 02/28/2015 12:14 PM, LyX Ticket Tracker wrote:
#9436: Lyx 2.2 Left/Right arrow keys ------------------------+----------------------- Reporter: rrogers | Owner: rrogers Type: defect | Status: new Priority: low | Milestone: 2.2.0 Component: general | Version: 2.2.0dev Severity: minor | Resolution: Keywords: arrow keys | ------------------------+----------------------- Comment (by skostysh): I cannot reproduce this on Ubuntu 14.10. Did you compile LyX yourself? Are you using the PPA? Which LyX 2.2dev version are you talking about (which hash or which day)? You only experienced this the first time after you upgraded to LyX 2.2dev?

-- Two views on life: life is an art not to be learned by observation. George Santayana:Interpretations of Poetry and Religion It's kinda nice to participate in your life Raymond Rogers
Maximilian Proppert | 27 Feb 23:35 2015

Retina support on OS X (sponsoring?)

Dear all,

We are very happy with LyX when it comes to preparing complex documents and we would like to thank you for your continued contributions.

However, we are very interested in better support for retina (High DPI) screens as part of current Retina MacBook Pros or iMacs 5K. Our current understanding is, that retina support requires QT5 which in return is foreseen for LyX 2.2. Unfortunately, we were not able to find any information on the estimated release timeframe.

We would greatly appreciate some more detailed information on the status quo of retina support and we would also be willing to provide financial support in case this will speed things up. We noticed that there have been some user sponsored features in the past and retina support should be of interest to quite a few Mac users.

While at it, maybe you could also improve scrolling speeds when viewing documents that contain a lot of expanded branch or comment boxes. Scrolling and curser movements via arrow keys get sluggish even on a new quad core i5 iMac with 24 GB Ram and SSD.

We are looking forward to your feedback!

Kind regards


Maximilian Proppert
Licensed Pharmacist, Managing Director

Pharma-Labor Yvonne Proppert GmbH
Heilsbachstr. 13
53123 Bonn

phone: +49 228 710027-0
fax: +49 228 710027-90

maximilian.proppert <at>

Managing Directors: Yvonne Karmann-Proppert, Maximilian Proppert
Registration court 58001 Hagen, Germany, HRB 5085; VAT Reg. No. DE 126877967

Georg Baum | 27 Feb 22:23 2015

[patch] Fix automatic logofication of LyX, TeX etc (bug 4752)

One of the youth sins of LyX is that it replaces some special phrases 
automatically with a typeset version. This is not wanted in most cases (the 
LyX documentation being an exception) and filed as bug 4752. The replacement 
algorithm is rather limited, i.e. it converts these phrases even if they are 
part of a word like aLyXb into a\LyX{}b, which is most certainly never 

The attached patch follows the same line of thought as the previous work on 
dashes. Since lyx2lyx misses the information about passThru I had to 
introduce special tokens again. It was suggested in trac to use a flex 
inset, but I could not make it work, since flex insets do require arguments 
currently. Therefore I invented new kinds of InsetSpecialChar. As a side 
effect of the patch the export of the LaTeX2e logo to formats other than 
LaTeX is slightly improved. What I also like is the amount of code which is 
no longer needed. The inset solution is much cleaner and more robust.

If nobody complains I'll put this in soon.

Attachment (x.diff): text/x-patch, 37 KiB
Stephanie Andrews | 26 Feb 23:40 2015

lyx crashes when applying long table settings

Dear developers, 

I'm using lyx version 2.1.1 and found possibly a bug which seems similar to 
the problem reported here:

Inserting a table, setting it to long format, marking the whole table, 
changing text style - customize - size smaller
results in lyx crashing.


Justin Smith | 26 Feb 19:58 2015

Re: #9434: In version 2.1.3, paste pastes into multiple random places

On 02/26/2015 01:50 PM, LyX Ticket Tracker wrote:
> #9434: In version 2.1.3, paste pastes into multiple random places
> ---------------------+-------------------------
>   Reporter:  jsmith   |       Owner:  lasgouttes
>       Type:  defect   |      Status:  new
>   Priority:  normal   |   Milestone:  2.1.4
> Component:  general  |     Version:  2.1.3
>   Severity:  blocker  |  Resolution:
>   Keywords:           |
> ---------------------+-------------------------
> Comment (by skostysh):
>   What is your operating system? For some reason, we've seen similar
>   behavior to what you report but from what I know it's only from users on
>   Windows.
>   Also, do you suspend/resume?
The problem is resolved --- I was using Linux and the mouse wheel was 
pasting text into various places. I disabled it and the problem has not 
occurred again. Sorry to bother you!

Mark.Bravington | 24 Feb 23:33 2015

cursor movement / usability annoyances

I am a LyX lover. However ... :)

... inside equations and tables, Lyx's cursor movement "rules" drive me nuts! I dislike mousing, and
prefer cursor-movement keys as more predictable and requiring less conscious control. But the
key-based motion actually feels quite unpredictable and--- crucially--- it's non-reversible. Am I the
only one?

Some examples, not necessarily exhaustive:

 - If I'm inside a multi-line equation at the far RHS of a line, and press Right-Arrow by mistake, then Lyx
moves me outside the equation, to the end. Then if press Left-Arrow hoping to "undo" the Right-Arrow, Lyx
moves me inside the equation, but to the very end of the final line. It's hard to find my way back to where I
was. Not impossible, obviously, but one should not have to think deeply about cursor movement...

 - Pasting into a multi-line equation moves me outside the equation afterwards. Finding my back is again
hard (and NB this isn't even the result of "user error"). But from an inline equation, this doesn't happen.

 - "Word-level" movement, which is useful or tempting because it can speed up movements within long lines of
equations or tables, also trips me often; for example, it can suddenly move me _outside_ the equation even
from the middle of a line.

 - Up-down movements also fail to "commute", try moving around formulae with subscripts and fractions.
Usually they don't throw me out of the equation altogether--- except that moving up from a superscript
inside an _inline_ equation moves me to the line of text above, and then moving down won't put me back into
the equation. Sigh...

 - When selecting/highlighting text within an equation/cell/table, with SHIFT pressed: go one character
outside the cell, and the whole cell is instantly selected (thus suddenly moving the _starting_ point of
the selection _backwards_), and there is no way to reverse the step. Since "characters" aren't all the
same size and it's sometimes hard to locate the invisible boundary of an equation/cell/table, this is a
pretty easy mistake to make. This is one case where I do sometimes do use the mouse (with SHIFT pressed), and
then it's even worse because the mouse sensitivity is so high. Try selecting the rest of a long piece of text
from the current cursor position to the end of the cell _without_ selecting the entire cell. I bet it'll
take you 2 or 3 attempts.

No doubt there's some internal logic to all this, but to me (despite several years of Lyx use) it still feels
awkward and unpredictable. I often don't even know why I've suddenly been dumped outside the
equation/table/cell, because I don't pay attention to individual keystrokes--- they're "automatic"
(albeit sometimes wrong). And finding my way to a particular spot inside an equation seems to require
random experimentation--- like a badly-designed maze game. Though in all other ways I prefer Lyx to
Scientific Word, IIRC Scientific Word had a much better "feel" in this respect.

Much the worst thing is the lack of reversibility--- very frustrating. This might be fixable by keeping
track of the last few movements. There'd be no need to keep many since this is only for "undo-move"
purposes; 3 or 4 would be fine, and the "trail" could be wiped clean by any real editing change.

Reversibility aside, I'm not sure whether there's a "solution" to the seeming unpredictability of
movement--- though it would be great if there was. However, I would certainly find it useful to have an
option *not* to move outside the equation (table, box,...) unless Lyx is specifically told to. (That
specific idea may not make any sense; I'm just trying to start a discussion.)



Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623

José Matos | 23 Feb 15:54 2015

Python 2 and 3 simultaneous support (1st step)

	the first step to start the procedure is to update the requirements for python to 2.7 as discussed last year.

	My problem is that as described last year I suggest to support python == 2.7.x (for any x) and python >= 3.3.0.

	I am at loss how to add this test to and similarly to cmake.

Any help from our resident experts Jean-Marc and Kornel.

José Abílio

Scott Kostyshak | 22 Feb 21:45 2015

[patches] Improve error reporting and log parsing

Attached are a sequence of patches addressing issues related to LyX's
error reporting and log parsing. I give more detailed descriptions of
them in the actual commit messages of the attached patches, but below
I list important points as well as a couple of questions. I have
brought up a couple of these topics in separate emails but since the
patches are dependent, I prefer to start this new thread and I will
reference the other threads when necessary (once the topics are
resolved here I will update the other threads for archive purposes).

- In brief testing, when I compile a .tex file that does not produce
output, no .pdf is created (not even an empty .pdf). Can anyone
confirm this?

- A "dummy function" means that the function has no effect, correct?

- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?
commit bea0925f8ccd617293d9171eef8453d938e3a44f
Author: Abdelrazak Younes <younes <at>>
Date:   Fri Dec 18 22:59:59 2009 +0000

    Converter: add a safe guard to Alerts because those cannot be
called from another thread. The whole Alert system must be rethought I
am afraid.

- To see why this patch is useful, open New > New from Template >
ACM-sigplan.lyx and compile. It says that compilation was successful
and shows the PDF. However, there was an error that was missed in
parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
'pdflatex  "newfile1.tex"' finished with exit code 1).
- For a related email thread, see

- This fixes the parsing that lead to the particular instance of the
bug fixed in patch 0005.
- For a related email thread, see <at>