Re: Missing lyxeditor.cmd?
On Thu, Aug 22, 2019 at 11:26 AM Richard Kimberly Heck wrote: > ... > >>> I have installed LyX 2.3.3 on a Dell XPS laptop and, Lo, the > installation's bin directory appears to be missing lyxeditor.cmd, which is > of course crucial for inverse search. Is this an oversight? Or is it now in > some other directory? > >> We don't distribute this file. > > Huh. Unlike the macOS version, apparently. Why the difference with the > Windows distribution? > > I guess Stephan includes it. Maybe Uwe used to as well? I could include > it, too, I suppose, but I'm not actually a Windows user. We really do > need someone who is to take over Windows packaging. > I'm not really a Windows user either, but I got so irked with recent Mac laptops that I bought the (quite lovely) Dell in a fit of pique. I have to say that, once you get it set up right, LyX under Windows (and Linux) works rather better than it does under macOS. It loads *much *faster and just seems snappier all around; forward/inverse searching in particular is faster and more accurate. (Both startup and forward search on macOS have been glacial under the last few iterations, though they're improved in 2.3.3.) >> According to this page of the wiki: > >> > >> https://wiki.lyx.org/LyX/SyncTeX > >> > >> it's something you need to create yourself. > > The need to create lyxeditor.cmd is only mentioned in the section on > Okular for Windows. That one needs to create it oneself is as far as I can > see not mentioned in the section on configuring SumatraPDF, which is the > PDF viewer I'm using. Might the Keepers of the Wiki consider mentioning the > need to create this script right at the top of the section on SumatraPDF. > > The wiki is, well, a wiki, so anyone can edit it. Oh...right. :-) I'll try to gussy up the sections on LyX+SumatraPDF once the semester is comfortably under way. It could definitely use some work. -chris
Missing lyxeditor.cmd?
Gentle LyX folk, I have installed LyX 2.3.3 on a Dell XPS laptop and, Lo, the installation's bin directory appears to be missing lyxeditor.cmd, which is of course crucial for inverse search. Is this an oversight? Or is it now in some other directory? Thanks. Chris Menzel
Re: [ANNOUNCE] LyX 2.2.3 Released
I'm always hesitant to complain about this brilliant piece of software but, for me (Mojave 10.14.2 Beta) with this version, forward search (LyX ⟶ Skim) is still very slow and reverse search (Skim ⟶ LyX) appears to be nonfunctional. I've of course checked all the usual settings. -chris On Fri, Dec 14, 2018 at 9:32 AM Richard Kimberly Heck wrote: > ... > > Public release of LyX version 2.3.2 > === > > We are proud to announce the release of LyX 2.3.2. This is the second > maintenance release in the 2.3.x series. > > You can download LyX 2.3.2 from http://www.lyx.org/Download/. >
Re: No screen font smoothing in a Parallels VM
Problem solved! I upgraded to KDE Plasma version 5.14.2 (via the backports PPA) and LyX 2.3.1 and that solved the problem. (Not sure if either of itself would have done the job.) Thanks again to the LyX (and KDE) developers. Chris Menzel On Thu, Nov 1, 2018 at 12:07 PM Chris Menzel wrote: > Dear Lyx folk, > > I've just installed Parallels on my iMac in part because LyX runs so well > under Linux and Parallels creates very robust virtual machines (indeed, > some things in Linux (like trackpad gestures) work *better* in a Parallels > VM). LyX looks fantastic running natively on my (hi-res) iMac (the current > problems with boldface notwithstanding) and running natively on my > Dell laptop under Linux. But for some reason, when I run it under Linux in > a Parallels VM on my iMac, I'm not getting any font smoothing; screen fonts > are jaggy and pixelated. All other Linux apps looks great in the VM, > including those using the same screen font. I've attached a couple of > screensgrabs to illustrate the problem, one showing the lack of font > smoothing in LyX and another showing how the same font looks in all other > Linux apps. Is this a known issue? And, if so, is there a fix? I haven't > turned up anything after a lot of googling. > > Thanks for any ideas here. > > Chris Menzel >
Forward search bug?
Gentle LyX folk, I'm using Lyx 2.3.1-1 under Mojave beta 10.4.1. I've noticed that forward search (i.e., searching from inside LyX to the corresponding point in the PDF output that is displaying in Skim) has gotten very sluggish, especially the first time I invoke it — it can take a good 10-15 seconds, with LyX pretty much hung in the meanwhile; it takes several seconds upon subsequent invocations. In past versions, I was taken to the corresponding point in the PDF almost instantaneous. This is fairly low priority, since the functionality is still there, but does anyone know what might be going on here? Chris Menzel
Re: Bold face in LyX
Apparently the bug has been fixed in QT 5.12.0 beta 1: https://bugreports.qt.io/browse/QTBUG-69955. So hopefully we'll see an update before long. -chris On Fri, Oct 5, 2018 at 9:06 AM Scott Kostyshak wrote: > Hi Hal, > > On Fri, Oct 05, 2018 at 06:27:26AM -0700, Hal Kierstead wrote: > > All - > > > > I am using LyX 2.2.1-1 on macOS 10.14. > > Do you mean 2.3.1-1? > > > I can no longer distinguish boldface fonts from ordinary fonts in the > LyX document, although they appear correctly in the pdf output. This is the > case both when I enter the bold face font by hand or when I use an > environment like Theorem. Is this a known issue? Do you need an example? > The problem is obvious even in a two word document with the same word first > in bold face and then not. > > > > I believe this is a bug in Qt that only shows up on mojave. We are > tracking it here: > > https://www.lyx.org/trac/ticket/11271 > > Scott >
Re: Fwd: Ubuntu packages?
Thanks, Riki, I've built LyX in the past but it's been years! (Have recently returned to Linux after many years on OS X/macOS.) Offer of help appreciated. 2.3.0-1 is currently fine, but will endeavor to build it myself as soon as it seems at all necessary or advantageous. -chris On Mon, Oct 1, 2018, 1:36 PM Richard Kimberly Heck wrote: > On 10/1/18 1:12 PM, Chris Menzel wrote: > > Dear selfless and heroic LyX developers, > > I have noticed that the most recent version of LyX for Ubuntu is 2.3.0-1 > and (according to the PPA > <https://launchpad.net/~lyx-devel/+archive/ubuntu/release>) that version > was uploaded last March. I'm just wondering if this indicates that > maintenance of the Ubuntu port is stalled or if (as I suspect) other > obligations are (understandably) simply not allowing the maintainer time to > compile and package up the latest version. > > Liviu Andronic has provided a PPA for LyX for a while now, but I haven't > seen him on the list for a little while. > > Note that it is pretty easy to build LyX yourself on Linux. I can give > instructions if you need them. The main thing is just getting the build > dependencies installed. I think "apt-get build-deps lyx" will do that, > though I'm not sure if that gives you Qt4 or Qt5. > > RKH > > >
Ubuntu packages?
Dear selfless and heroic LyX developers, I have noticed that the most recent version of LyX for Ubuntu is 2.3.0-1 and (according to the PPA <https://launchpad.net/~lyx-devel/+archive/ubuntu/release>) that version was uploaded last March. I'm just wondering if this indicates that maintenance of the Ubuntu port is stalled or if (as I suspect) other obligations are (understandably) simply not allowing the maintainer time to compile and package up the latest version. Thanks! Chris Menzel
Adding symbols to LyX
Gentle LyX developers: What would it take to incorporate a couple of missing logical connectives? The symbols \boxright and \Diamondright from the txfonts package are used very commonly in modal logic to express the *would* and *might* counterfactual conditionals. (Kludged up out of separate symbols they are, roughly, □→ and ◇→.) It would be supercool if these were included in LyX's already great set of native math symbols. Chris Menzel
Adding symbols to LyX
Gentle LyX developers: What would it take to incorporate a couple of missing logical connectives? The symbols \boxright and \Diamondright from the txfonts package are used very commonly in modal logic to express the *would* and *might* counterfactual conditionals. (Kludged up out of separate symbols they are, roughly, "□→" and "◇→".) It would be supercool if these were included in LyX's already great set of native math symbols. Chris Menzel
Re: [Fwd: Small LyX 1.5.2 (OS X only?) ERT bug]
On Fri, Oct 26, 2007 at 03:13:19PM -0400, Bennett Helm wrote: I've found what looks like a very small bug in LyX 1.5.2 under at least OS X. I've not been able to check whether it arises on any other platform. If I open a new window on the document I'm editing (*the* feature I'd been waiting years for -- thanks LyX developers!) and insert an ERT, I cannot collapse it simply by clicking on the grey ERT area to the left of the ERT box. Similarly, if I click on a collapsed ERT, it does not open up. The same ERTs will collapse/open if I click on them in the original window. I can collapse and open ERTs in the new window by right clicking and using the dialog box, but I should think you'd want to see the same behavior regardless of the window. I cannot confirm on Intel Mac with 1.5.3svn: everything works as expected. (I don't have 1.5.2 handy to check.) Has anything changed here between 1.5.2 and current branch? Hm, I just looked for this behavior on a PPC version of 1.5.2 running on a machine in my office and did not have the problem described above, which I discovered on my Intel iMac at home. I will have another look when I return. Chris Menzel
Re: [Fwd: Small LyX 1.5.2 (OS X only?) ERT bug]
On Fri, Oct 26, 2007 at 03:13:19PM -0400, Bennett Helm wrote: >> I've found what looks like a very small bug in LyX 1.5.2 under at >> least OS X. I've not been able to check whether it arises on any >> other platform. If I open a new window on the document I'm editing >> (*the* feature I'd been waiting years for -- thanks LyX developers!) >> and insert an ERT, I cannot collapse it simply by clicking on the >> grey "ERT" area to the left of the ERT box. Similarly, if I click on >> a collapsed ERT, it does not open up. The same ERTs will >> collapse/open if I click on them in the original window. I can >> collapse and open ERTs in the new window by right clicking and using >> the dialog box, but I should think you'd want to see the same >> behavior regardless of the window. > > I cannot confirm on Intel Mac with 1.5.3svn: everything works as > expected. (I don't have 1.5.2 handy to check.) Has anything changed > here between 1.5.2 and current branch? Hm, I just looked for this behavior on a PPC version of 1.5.2 running on a machine in my office and did not have the problem described above, which I discovered on my Intel iMac at home. I will have another look when I return. Chris Menzel
Re: [WARNING] Bad bug in lyx 1.2.2 configure script
On Wed, Jan 08, 2003 at 12:32:24PM +0100, Jean-Marc Lasgouttes wrote: There is a very nasty bug in LyX 1.2.2 configure script: if you configure as root and an error occurs during the configure step (e.g. xforms not found), the the script will delete the /dev/null device. This undoubtly leads to very bad effect, since /dev/null is a very basic device in any unix system. Does anyone know if this bug affects the configure script in the fink OS X port of LyX with version number 1.2.2-1 (which I believe is the most current version available)? The -1 suggests that perhaps the script has been modified to remove the bug. Chris Menzel
Re: [WARNING] Bad bug in lyx 1.2.2 configure script
On Wed, Jan 08, 2003 at 12:32:24PM +0100, Jean-Marc Lasgouttes wrote: > > There is a very nasty bug in LyX 1.2.2 configure script: if you > configure as root and an error occurs during the configure step > (e.g. xforms not found), the the script will delete the /dev/null > device. This undoubtly leads to very bad effect, since /dev/null is a > very basic device in any unix system. Does anyone know if this bug affects the configure script in the fink OS X port of LyX with version number 1.2.2-1 (which I believe is the most current version available)? The "-1" suggests that perhaps the script has been modified to remove the bug. Chris Menzel
