Scott Kostyshak | 23 Oct 11:38 2014

Coding practice: OK to leave dangling pointer if not currently used?

A commit that I introduced earlier caused crashes and I had to revert.
The reason was because I used a dangling pointer. It did not occur to
me that the pointer could be dangling. I just assumed it would not be
(I've learned my lesson). The reason why it becomes dangling is
because I add code after a dispatch and thus the buffer view might
have been destroyed (e.g. from closing a buffer or closing a view).

My solution is to simply refresh the pointer (I can get it from
currentBufferView()). However, this got me thinking: shouldn't we set
the pointer to null every time we know that it was destroyed? What if
we don't use that pointer again (as was the case before my commit)?
Looking back, it is pretty obvious that the pointer could have become
dangling and I should have realized this potential problem.

I guess I have two questions:
(1) Are there any comments on my patch?

(2) Even if I did not want to add code to GuiView::dispatch, would it
have been a reasonable patch to _only_ refresh the pointer after the
dispatch, just in case someone wanted to add code to it eventually?

Danilo Diedrichs | 15 Oct 20:27 2014


The link to download LyX-2.1.2 for Windows (both the “Bundle” and “Installer”) seem to be broken.  Can you fix them?



D. Diedrichs


Xiangcai Meng | 22 Oct 03:13 2014

Re: #9308: LyX cannot work properly in Yosemite

Dear LyX developper,
   Good morning.
   Thank you very much for your prompt response.
   I tried to report this bug to apple, but I am not an apple developers thus I could NOT successfully report this
bug now even after I register a new apple id. Hence, would you please find someone who is an apple developer
to report this bug and let them solve it as soon as they can?
   I think that many people are encountering this problem, not only me. If you can find a way to fix this problem,
we would really appreciate.
   Thank you very much for your support.
> On Oct 22, 2014, at 9:38 AM, LyX Ticket Tracker <trac <at>> wrote:
> #9308: LyX cannot work properly in Yosemite
> ---------------------------+------------------------
> Reporter:  mxc0206        |       Owner:  uwestoehr
>     Type:  enhancement    |      Status:  new
> Priority:  highest        |   Milestone:  2.1.x
> Component:  insetgraphics  |     Version:  2.1.2
> Severity:  critical       |  Resolution:
> Keywords:  os=macosx      |
> ---------------------------+------------------------
> Changes (by skostysh):
> * cc: switt (added)
> * keywords:  LyX Yosemite class missing convert missing => os=macosx
> * type:  defect => enhancement
> Comment:
> Note that this is a Mac bug (see e.g.
> program-stop-working-in-mac-os-x-yosemite) so I'm marking this as an
> enhancement request. Can you please report the root bug to Apple? It would
> indeed be nice to provide a workaround in LyX and I think our Mac LyX
> developer knows about it. But he is limited by resources (time, machines)
> so I don't know how long it will take.
> -- 
> Ticket URL: <>
> The LyX Project <>
> LyX -- The Document Processor

Stephan Witt | 21 Oct 14:17 2014

No fortune with cmake and file globbing

I've noticed some "interesting" effect.

There are some files different from others. E.g. the implementation of the GuiPainter class:

$ ls -l <at>  lyx/src/frontends/qt4/GuiPainter.*
-rw-r--r-- <at>  1 stephan  staff  17459 20 Okt 12:29 lyx/src/frontends/qt4/GuiPainter.cpp	   15 
-rw-r--r--  1 stephan  staff   5023 18 Okt 11:53 lyx/src/frontends/qt4/GuiPainter.h

I'm not sure how GuiPainter.cpp got this attributes but it gets stored in the dist archive like that:

$ bunzip2 -c lyx-release/LyX-2.2-2.2.0dev.tar.bz2 | tar tf - | grep GuiPainter

And now the consequence with cmake on Linux is: it tries to compile ._GuiPainter.cpp and fails.

Michael Clerx | 21 Oct 11:05 2014

Re: #7727: pressing Ctrl+Alt+A from within a math inset does not work

On 10/20/2014 08:24 PM, LyX Ticket Tracker wrote:
> #7727: pressing Ctrl+Alt+A from within a math inset does not work
> --------------------------+-------------------------
>   Reporter:  MichaelClerx  |       Owner:  lasgouttes
>       Type:  defect        |      Status:  new
>   Priority:  normal        |   Milestone:  2.1.x
> Component:  general       |     Version:  2.0.0
>   Severity:  normal        |  Resolution:
>   Keywords:                |
> --------------------------+-------------------------
> Comment (by skostysh):
>   As for a use case, the only one I
>   can think of is: suppose I start writing a note. Then I decide I want to
>   start over. I would want to select all text inside the note and delete it.
Another use case: Say I'm typing an equation "x+y" and I realise I 
should have been typing "1/(x+y)". I select all, cut, insert the 
fraction and paste back in the appropriate place.
Another use case is merging the contents of insets, for example if you 
want to replace a table of insets with an inset containing a table.
None of these occur if you know the exact formatting you want before you 
start, but in practice that doesn't happen very often.

Scott Kostyshak | 21 Oct 07:19 2014

[PATCH] should we increase this magic number? (LaTeX log scanning code)

If you export ACM-sigplan.lyx in the GUI, LyX says it was exported
successfully and shows the PDF. But if you look at the terminal output
you will see that pdflatex exited with error. The reason LyX doesn't
pick this up is because (1) it does not check the exit code (which is
a separate bug in my opinion) and (2) it does not detect an error when
scanning the log file. This patch addresses (2). I attach the log file
in case you are interested but do not want to install the LaTeX files
needed to test for yourself.

The problem was that we only register an error if there is 10 or fewer
lines in-between the "!" line and the line where the line number where
the error occurred (the "l." line). This patch increases that number
to 15. Why 15? Because we used 10 for 14 years and there weren't many
problems, at least not that anyone noticed. 15 is just enough to
detect the error in this particular case.

The number 10 was introduced at a2c6689c to address the following

+       * src/LaTeX.C (scanLogFile): errors where the line number was not
+       given just after the '!'-line were ignored (from Dekel Tsur).

Am I correct that the only drawback is in theory performance?

I would really like to fix (1) above, so I'm OK if there are
objections to this patch, as long as we agree that (1) should be

Attachment (ACM-sigplan.log): text/x-log, 11 KiB
Alfredo Braunstein | 20 Oct 19:25 2014

Problem with copy

Running under valgrind, open LyX (master branch), create a new
document, write 'a', select it and copy it; valgrind complains (see
below). I get it consistently.

A second copy doesn't give any problem, it's just the first one that
does. The problem seems related to a badly initialized temporary
buffer (maybe).

The problem is not present in 2.0.6. I got this while trying to
investigate #9302, don't know if it is related though.

==8953== Invalid read of size 1
==8953==    at 0x53353B: lyx::(anonymous
namespace)::pasteSelectionHelper(lyx::DocIterator const&,
lyx::ParagraphList const&, std::tr1::shared_ptr<lyx::DocumentClass
const>, lyx::Buffer*, lyx::ErrorList&) (CutAndPaste.cpp:144)
==8953==    by 0x538398: lyx::(anonymous
namespace)::putClipboard(lyx::ParagraphList const&,
std::tr1::shared_ptr<lyx::DocumentClass const>,
std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> > const&) (CutAndPaste.cpp:512)
==8953==    by 0x53965D: lyx::cap::copySelection(lyx::Cursor const&,
std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> > const&) (CutAndPaste.cpp:1007)
==8953==    by 0x539724: lyx::cap::copySelection(lyx::Cursor const&)
==8953==    by 0x67A6DB: lyx::Text::dispatch(lyx::Cursor&,
lyx::FuncRequest&) (Text3.cpp:1310)
==8953==    by 0x91D230: lyx::InsetText::doDispatch(lyx::Cursor&,
lyx::FuncRequest&) (InsetText.cpp:312)
==8953==    by 0x817CCA: lyx::Inset::dispatch(lyx::Cursor&,
lyx::FuncRequest&) (Inset.cpp:319)
==8953==    by 0x52AC92: lyx::Cursor::dispatch(lyx::FuncRequest
const&) (Cursor.cpp:399)
==8953==    by 0x9778A5:
lyx::frontend::GuiView::dispatchToBufferView(lyx::FuncRequest const&,
lyx::DispatchResult&) (GuiView.cpp:3295)
==8953==    by 0x98F670:
lyx::frontend::GuiView::dispatch(lyx::FuncRequest const&,
lyx::DispatchResult&) (GuiView.cpp:3844)
==8953==    by 0x95C409:
lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&,
lyx::DispatchResult&) (GuiApplication.cpp:1982)
==8953==    by 0x94D19E:
lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&)
==8953==  Address 0x17cbe996 is 390 bytes inside a block of size 984 free'd

Stéphane Mourey | 20 Oct 16:22 2014

Re: gpl

I hereby grant permission to license my contributions to LyX under the Gnu
General Public Licence, version 2 or later.

Blog: Impossible Exil
Ketil Thorgersen | 20 Oct 15:43 2014

Corkboard/Non-linear workflow enhancement?


I have eagerly been awaiting the development of the Corboard module for Lyx
outlined here: in 2013 as a
continuation of what Rob Oakes developed as Lyx-outline. I used to be using
Lyx-outline but then this Google summer code project came up and everything
stagnated... I would really hate to see this disappear as it was one of the
most useful things ever for a researcher like myself.

Does anyone know what is the status?

All the best!

Enrico Forestieri | 19 Oct 17:04 2014

Re: [LyX/master] #9130 Text in main work area isn't rendered with high resolution Add a LyX banner with double resolution for displays with high resolution.

On Sat, Oct 18, 2014 at 03:58:14PM +0200, Stephan Witt wrote:

> commit 6fdb32958c6f0e7397455734c207790468c2da6c
> Author: Stephan Witt <switt <at>>
> Date:   Sat Oct 18 15:57:21 2014 +0200
>     #9130 Text in main work area isn't rendered with high resolution
>     Add a LyX banner with double resolution for displays with high resolution.

Stephan, after this series of commits, the version info on the splash
screen is misplaced and also the size of the text is wrong (see attached
screen shot).

This occurs with Qt 5.3.2 and does not occur with Qt 4.8.6.
Tested on both Linux and Windows.


Stephan Witt | 18 Oct 17:18 2014

Re: [LyX/master] #9130 Text in main work area isn't rendered with high resolution Add a LyX banner with double resolution for displays with high resolution.

Am 18.10.2014 um 16:53 schrieb Jürgen Spitzmüller <spitz <at>>:

> Stephan Witt wrote:
>>> Why not SVG?
>> 1) I don't know of a SVG version of it.
>> 2) The SVG option for high resolution images needs some additional work.
> Is it really that much work (I mean for the banner, not the icons)?

The work I'm talking about is the implementation and choice of the correct size mapping.

> The quality of this banner <at> 2x.png is not too convincing, IMHO, so we need to 
> create a new vector version anyway, if we do not have one.

Yes, of course. I've made it for demonstration purpose and I'm not that proud of it.

> BTW it seems the banner was contributed by Joost.

Yes, I've asked for it in the past already. And I didn't get it -
so someone has to recreate it from scratch or make another one.