Re: \[ddd]dots in mathed
On Tue, Mar 13, 2018 at 12:27:58AM +, Joel Kulesza wrote: > On Fri, Mar 9, 2018 at 10:57 AM, Pavel Sandawrote: > > > Whether now, or after it's committed I would appreciate testing from > > someone > > sitting on Win and Mac(?Retina) machine to check whether they see what I > > see > > on linux for \dot and \ddot, i.e. the second attachment. > > > Looks good on a Mac Retina screen (see attached). For me, the dots are smaller (see attached). I prefer your output. Probably due to retina difference, but note that I have a different Qt version. Scott signature.asc Description: PGP signature
Re: [LyX/master] Paint \dot & \ddot more like a dot
On Mon, Mar 12, 2018 at 12:41:48PM +, Pavel Sanda wrote: > commit e41c80e224bfd89497e9cf9ddea73f1e635587e8 > Author: Pavel Sanda> Date: Mon Mar 12 13:40:52 2018 +0100 > > Paint \dot & \ddot more like a dot > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg204183.html > --- > src/mathed/MathSupport.cpp | 34 -- > 1 files changed, 24 insertions(+), 10 deletions(-) > Tested and looks good, thanks for the improvement. Scott signature.asc Description: PGP signature
Re: Update on 2.3.0 situation and Windows-specific issues
On Sun, Mar 11, 2018 at 08:52:52PM +, Uwe Stöhr wrote: > It is not, it only make things worse. Every dialog can cause confusions. You > are only looking from your professional view and I failed to make this > clear. I could be wrong on this, but I thought that I brought up the idea that the dialog could bring confusion before you did (unless I missed an email?): https://www.mail-archive.com/search?l=mid=20180310235731.h67c535wh5tmosoc%40steph I definitely agree that every additional dialog is an additional possibility for confusion. I think where we disagree is on the benefit that the dialog could bring. > Can't you see that the majority doesn't know what a package is? Most > of my students and colleagues didn't know this but were able to write their > master or Ph.D. thesis with LyX. > Therefore giving users a choice they don't understand is a problem. What is > if they deny to install LyX, continue using LyX 2.2.x and screw up their > MiKTeX? > Who has a chance to fix a broken package or similar? Those who know what a > package is. These guys have the knowledge to forbid any update if they like > to and the installer lets them do this. Average users would be lost with > their screwed-up LaTeX. Therefore I made my decision. I have thought about this, and I don't think the dialog will lead to such problems. Further, several others have agreed that this is not a concern. > I think you should respect that the guy who builds the installer and > provides support in case of a problem with it has good reasons. We spoke > about the topic, I red your arguments but stay with my decision. It is my > spare time in case of problems so I am the one risking something. I thought > about it a lot to be as safe as possible for most users. I do not like this talk of respect (and before, of trust). I respect you very much. You have given so much of your time to LyX, and you have spent so much time on parts of LyX that are not fun (e.g. documentation and supporting users) because you know how important it is for the users. I also trust you. But we are a team and we make decisions as a team. Going with the decision of the team has nothing to do with respect or trust. > I explained now in a dozen mails my decision. Feel free to add whatever you > like in the release notes. Feel also free not to announce the Win installer > officially or not to put it in ftp.lyx.org. > Let's end the debate. Please make your decision and let's focus in LyX > 2.3.1. Since you are the only one that supports not having a dialog, and everyone else (who has expressed an opinion) agrees that a dialog would be beneficial, my decision is that we should add the dialog. I ask that you respect the opinion of the group and that you add the dialog. I know you have already spent so much time on this, and I am sorry to ask you to do something that you do not want to do, but that is the decision of the group. Every one of us has been in the situation where we think we are right and the rest of the group is wrong. But it's important to understand that we must make decisions as a team. Scott signature.asc Description: PGP signature
Forward and reverse search failing (again?) on 2.3.0rc
With LyX 2.3.0rc and Skim on Mac, both forward search and reverse search are failing for me. Didn’t someone fix this not too long ago? It fails whether LyX is in some random location or the supposed default location /Applications/LyX.app. Jerry
Re: \[ddd]dots in mathed
On Fri, Mar 9, 2018 at 10:57 AM, Pavel Sandawrote: > Whether now, or after it's committed I would appreciate testing from > someone > sitting on Win and Mac(?Retina) machine to check whether they see what I > see > on linux for \dot and \ddot, i.e. the second attachment. Looks good on a Mac Retina screen (see attached). - Joel
Re: Diagnosing a crash
On 03/12/2018 07:41 PM, Richard Heck wrote: On 03/12/2018 07:36 PM, Paul A. Rubin wrote: Hi all, I have a very perplexing but utterly repeatable crash that I'm trying to diagnose, to determine whether I should file a ticket (or whether it's not a LyX issue). I'd appreciate any insight. Apologies for the length of what follows. Any time LyX crashes, it is a problem. The error may be coming from elsewhere, but we should deal with it. So I'd suggest filing a ticket. Richard Will do (tomorrow -- dinner beckons now). Paul
Re: Diagnosing a crash
On 03/12/2018 07:36 PM, Paul A. Rubin wrote: > Hi all, > > I have a very perplexing but utterly repeatable crash that I'm trying > to diagnose, to determine whether I should file a ticket (or whether > it's not a LyX issue). I'd appreciate any insight. Apologies for the > length of what follows. Any time LyX crashes, it is a problem. The error may be coming from elsewhere, but we should deal with it. So I'd suggest filing a ticket. Richard
Diagnosing a crash
Hi all, I have a very perplexing but utterly repeatable crash that I'm trying to diagnose, to determine whether I should file a ticket (or whether it's not a LyX issue). I'd appreciate any insight. Apologies for the length of what follows. I'm running LyX 2.2.3 on Linux Mint 18.3 MATE. The Qt version is 4.8.7 (both compile-time and run-time). I have Aspell, Enchant and Myspell installed. The OS uses English (US) as its default language. Symptom #1: With Aspell selected as the spellchecker, if I attempt to spellcheck any document, no matter how simple, LyX crashes. The crash message is .cset" could not be opened for reading or does not exist.lib/aspell/ Aborted (core dumped) With Enchant selected, there is no problem. Symptom #2: With Aspell set as the spellchecker, if I right click in any empty document, or on the handle of a float, things work as expected. If I right click in the text area of a non-empty document, I get the same crash. Here's the tail of output when I ran LyX with dbg -any and triggered the crash: frontends/qt4/Menus.cpp (2342): Context menu requested: context-edit frontends/qt4/Menus.cpp (2297): Triggered menu: context-edit AspellChecker.cpp (214): aspell user dir: /home/paul/.lyx/ AspellChecker.cpp (217): aspell sysdir dir: /usr/share/lyx/ .cset" could not be opened for reading or does not exist.lib/aspell/ Aborted (core dumped) So the right-click triggered a context menu, which then somehow seems to have invoked Aspell (?!) and caused the crash. Just to make this dopier, I have the same operating system and same version of LyX installed on my laptop and an older PC with no problems. The crash is happening on a new machine (with a different chip architecture, which hopefully does not matter) that I'm breaking in. Any suggestions on (a) why a right-click in the middle of some text would have anything to do with the spellchecker and (b) why Aspell is blowing up on just this one machine? Thanks, Paul
Re: Failing tex2lyx test
Am Montag, 12. März 2018 19:48:39 CET schrieb Jürgen Spitzmüller: > Am Montag, den 12.03.2018, 18:26 +0100 schrieb Kornel Benko: > > Should do as in case of test-structure.tex > > > > cd src/tex2lyx/test > > ./runtests.py path-to-tex2lyx ../../../lib/scripts /tmp CJK.tex > > Did that, the result generated in /tmp looks good (does not show the > problem you describe). > > So: > > > I need a reproducible case in order to fix this. Apparently you are testing lyx2.3.x. My mistake. The error shows with master-tree and master executables. > Jürgen > Kornel signature.asc Description: This is a digitally signed message part.
Re: Failing tex2lyx test
Am Montag, den 12.03.2018, 18:26 +0100 schrieb Kornel Benko: > Should do as in case of test-structure.tex > cd src/tex2lyx/test > ./runtests.py path-to-tex2lyx ../../../lib/scripts /tmp CJK.tex Did that, the result generated in /tmp looks good (does not show the problem you describe). So: > > I need a reproducible case in order to fix this. Jürgen > > > > Jürgen > > > > Kornel > signature.asc Description: This is a digitally signed message part
Re: Failing tex2lyx test
Am Montag, 12. März 2018 18:10:16 CET schrieb Jürgen Spitzmüller: > 2018-03-12 16:05 GMT+01:00 Kornel Benko : > > The problematic diff looks like: > > > > --- /usr2/src/lyx/lyx-git/src/tex2lyx/test/CJK.lyx.lyx Sun Mar 11 > > 19:35:25 > > 2018 > > +++ /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tex2lyx/test/ > > CJK.lyxMon Mar 12 16:03:37 2018 > > @@ -130,7 +130,27 @@ > > > > \end_inset > > > > Japanese > > > > - (this CJK environment will be put in ERT because LyX supports only one > > CJK > > + (this > > +\begin_inset ERT > > +status collapsed > > + > > +\begin_layout Plain Layout > > +C > > +\end_layout > > + > > +\end_inset > > + > > +JK environment will be put in ERT because LyX supports only one > > +\begin_inset ERT > > +status collapsed > > + > > +\begin_layout Plain Layout > > +C > > +\end_layout > > + > > +\end_inset > > + > > +JK > > I cannot reproduce. Note that I cannot run the tests themselves (since > cmake keeps on segfaulting), but when I do a roundtrip on the file > manually, I do not see the problem. cmake keeps on segfaulting? Or is it tex2lyx? Or python? Should do as in case of test-structure.tex cd src/tex2lyx/test ./runtests.py path-to-tex2lyx ../../../lib/scripts /tmp CJK.tex > I need a reproducible case in order to fix this. > > Jürgen > Kornel signature.asc Description: This is a digitally signed message part.
Re: Failing tex2lyx test
2018-03-12 16:05 GMT+01:00 Kornel Benko: > The problematic diff looks like: > > --- /usr2/src/lyx/lyx-git/src/tex2lyx/test/CJK.lyx.lyx Sun Mar 11 > 19:35:25 > 2018 > +++ /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tex2lyx/test/ > CJK.lyxMon Mar 12 16:03:37 2018 > @@ -130,7 +130,27 @@ > \end_inset > > Japanese > - (this CJK environment will be put in ERT because LyX supports only one > CJK > + (this > +\begin_inset ERT > +status collapsed > + > +\begin_layout Plain Layout > +C > +\end_layout > + > +\end_inset > + > +JK environment will be put in ERT because LyX supports only one > +\begin_inset ERT > +status collapsed > + > +\begin_layout Plain Layout > +C > +\end_layout > + > +\end_inset > + > +JK > I cannot reproduce. Note that I cannot run the tests themselves (since cmake keeps on segfaulting), but when I do a roundtrip on the file manually, I do not see the problem. I need a reproducible case in order to fix this. Jürgen > > Kornel
Re: [LyX/master] Paint \dot & \ddot more like a dot
On 03/12/2018 09:31 AM, Pavel Sanda wrote: > Pavel Sanda wrote: >> commit e41c80e224bfd89497e9cf9ddea73f1e635587e8 >> Author: Pavel Sanda>> Date: Mon Mar 12 13:40:52 2018 +0100 >> >> Paint \dot & \ddot more like a dot >> >> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg204183.html > Richard this might go to 2.3 as well if you want. > But it needs ack from mac and win person that \ddot & \dot works as expected > there. Fine for 2.3.2-staging when you get confirmation. Richard
Failing tex2lyx test
Lately, the test "tex2lyx/roundtrip/CJK.tex" fails. Bisecting and searching for the wrong looking diff led to *** 0f4c9027056a6f4f771382e9ebfc7940274bf5c0 is the first bad commit commit 0f4c9027056a6f4f771382e9ebfc7940274bf5c0 Author: Juergen SpitzmuellerDate: Sat Mar 10 14:58:55 2018 +0100 tex2lyx: make nested CJK parsing slightly less dumb. Fixes: #9562 :04 04 4cc422bc2f78eddf376ee4d52a4fab54c2b2a397 a3e56ae7deca45e8959bc1df11530937878816d2 M src *** The problematic diff looks like: --- /usr2/src/lyx/lyx-git/src/tex2lyx/test/CJK.lyx.lyx Sun Mar 11 19:35:25 2018 +++ /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tex2lyx/test/ CJK.lyxMon Mar 12 16:03:37 2018 @@ -130,7 +130,27 @@ \end_inset Japanese - (this CJK environment will be put in ERT because LyX supports only one CJK + (this +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout +C +\end_layout + +\end_inset + +JK environment will be put in ERT because LyX supports only one +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout +C +\end_layout + +\end_inset + +JK font mapping per document, this environment uses the \begin_inset ERT status collapsed *** Kornel signature.asc Description: This is a digitally signed message part.
Re: Undocked Outliner & multiple window crashes [#11004] (was: Beamer & Outliner broken)
Pavel Sanda wrote: > Scott Kostyshak wrote: > > On Fri, Jan 12, 2018 at 05:20:18PM +, Pavel Sanda wrote: > > > Pavel Sanda wrote: > > > > after pushing the outliner button we call in TocWidget::outline generic > > > > GuiApplication::dispatch which likely grabs currently active window; if > > > > that's > > > > the wrong window, it grabs wrong cursor position, moves wrong section > > > > and > > > > suddenly content of outliner and buffer structure are out of sync and > > > > crash is > > > > just matter of time > > > > > > > > Now this is not some glitch but rather conceptual problem how we handle > > > > lfuns from the widget(s). > > > > Opinions how to move forward? > > > > > > E.g. I could implement requested_guiview inside FuncRequest so we could > > > specify window > > > as the lfun request travels through GuiApplication. Any objections to > > > this solution? > > > > Bump. > > > > Scott > > I have patch along the lines above, i.e. when we request lyx::dispatch we also > provide guiview inside FuncRequest, so we can at least detect in > guiapplication::dispatch that current_view is different and stop there. So > this > crash is gone. > > Various attempts with raise/activewindow/setcurrentview for getting the right > window up in the first place did not seem to work. But it is difficult to be > sure, the scenario of multiple windows+undocked outliner is minefield with > crashes stemming from different reasons. I commited the fix for the crash above in 8725614e3f. The other one would need longer debug session. Pavel > There is immediately different crash - apparently when we load already > opened buffer in new window, the load resets tocwidget from the oldwindow > and if you click to some toc item without focusing old window first you often > get crash, see below. > > Thread 1 "lyx" received signal SIGSEGV, Segmentation fault. > 0x557742fd in lyx::CursorSlice::text (this=, > this=) at CursorSlice.h:119 > 119 Text * text() const { return inset_->getText(idx_); } > (gdb) bt > #0 0x557742fd in lyx::CursorSlice::text (this=, > this=) at CursorSlice.h:119 > #1 lyx::DocIterator::innerTextSlice (this=0x7fffcbd0) at > DocIterator.cpp:233 > #2 0x55774419 in > lyx::DocIterator::paragraphGotoArgument[abi:cxx11]() const (this= out>) at DocIterator.cpp:247 > #3 0x558ae1eb in lyx::TocItem::action > (this=this@entry=0x7fffcbd0) at TocBackend.cpp:75 > #4 0x55bbcc5f in lyx::frontend::TocModels::goTo (this= out>, type=..., index=...) at TocModel.cpp:316 > #5 0x55d1ebc6 in lyx::frontend::TocWidget::goTo > (this=this@entry=0x56b42330, index=...) at TocWidget.cpp:252 > #6 0x55d1ec0b in lyx::frontend::TocWidget::on_tocTV_pressed > (this=0x56b42330, index=...) at TocWidget.cpp:240 > ... > > I saw that when loading the buffer in new window the new guiview points to > buffer, which has pointer to old guiview. That trigers toc updates in old > window. Is this expected??? I seem to be somewhat lost why buffer has > pointer to guiview at all when multiple windows are possible. > > Pavel
Re: [LyX/master] Paint \dot & \ddot more like a dot
Pavel Sanda wrote: > commit e41c80e224bfd89497e9cf9ddea73f1e635587e8 > Author: Pavel Sanda> Date: Mon Mar 12 13:40:52 2018 +0100 > > Paint \dot & \ddot more like a dot > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg204183.html Richard this might go to 2.3 as well if you want. But it needs ack from mac and win person that \ddot & \dot works as expected there. Pavel
Re: Update on 2.3.0 situation and Windows-specific issues
Uwe Stöhr wrote: > I explained now in a dozen mails my decision. Feel free to add whatever you > like in the release notes. Feel also free not to announce the Win installer > officially or not to put it in ftp.lyx.org. Ok, can you please make it clear whether this silent behind-back upgrade is only part of bundle installer or is it part of the small one as well? Somehow it was not clear from your summary. > Let's end the debate. Please make your decision and let's focus in LyX > 2.3.1. I agree. Pavel
Re: Update on 2.3.0 situation and Windows-specific issues
Jean-Marc Lasgouttes wrote: > Note however that using LyX without LaTeX is not really a pleasure. One > gets at each use a dialog box on startup plus dialog box for each loaded > file complaining that something is wrong. I have to install texlive on my > home windows 10 computer just for that (I did not intend yet to actually > create documents there, I just wanted to debug display issues). > > While my use case is not important in itself, I think it would be > worthwhile to allow LyX to work nicely as a pure editor. I agree. Either we can add RC variable for ignoring those or we could adding "Do not show this message again" checkbox to the particular messages. Pavel
Re: Update on 2.3.0 situation and Windows-specific issues
Le 11/03/2018 à 18:17, Richard Heck a écrit : I cannot for the life of me see why adding a warning that proceeding with the installation will require updating MikTeX, and giving the user the option to abort the installation, could cause any problems at all. If there's a worry that this will confuse some users, then we could add text that says something like: If you do not use LaTeX outside of LyX, then it is safe for you to proceed. +1, and I will explain why below. I never came in in this debate because I am not a Windows user at all. However, I kept a 32bits Windows 10 boot on my wife's laptop, which I very seldomly use for mobile or gps maintenance, and which is not used by my wife at all. So I gave a try to the last Windows installer (5), bundle version (this version is not the subject of the present debate about MiKTeX update breaking things, but I wanted to have an idea of the involved dialogs). So the install went to its end without problems, but for the same message as racoon: Package "miktex-bin-2.9" is up to date. Sorry, but "MiKTeX Package Manager" did not succeed for the following reason: Package "miktex-console-bin-2.9" is already installed. The log file hopefully contains the information to get MiKTeX going again: C:/Users/Daniel/AppData/Local/MiKTeX/2.9/miktex/log/mpmcli.log You may want to visit the MiKTeX project page, if you need help. Sorry, but "MiKTeX Package Manager" did not succeed. The log file hopefully contains the information to get MiKTeX going again: C:/Users/Daniel/AppData/Local/MiKTeX/2.9/miktex/log/mpmcli.log You may want to visit the MiKTeX project page, if you need help. There are currently no updates available. This are further lines saying that Package "miktex-console-mpm-2.9" is installed. and installation proceeds. I do not know where to find the log, so I saw these lines because I pressed the « En savoir plus » button in the LyX Installation progress window, I guess that an average user would not do that and thus would not be affected. Then I opened LyX and tried to compile UserGuide.pdf. I must have been impatient because I first had an error about url.sty missing, I guess MiKTeX was still upgrading in the background. I finally got a successful compilation, but no output image because of missing pdf viewer (as I said, this Windows 10 is not used at all to parse documents). I exported to pdf via pdflatex and finally could open the file with Edge, which is thus not recognized as a pdf viewer, even after reconfigure. After the install and the UserGuide compilation, LyX-2.3.0 dir size is 383Mo, and MiKTeX 2.9 dir size is 1.14Go. On my Debian Stretch, I have this: $ du -skh /ext/lyx/lyx-2.3.0 /usr/local/share/lyx-2.3.0 /opt/texlive/2017/ 256M/ext/lyx/lyx-2.3.0/ (lyx compilation dir, can be removed) 42k /usr/local/share/lyx-2.3.0 (lyx resources dir) 5.9G/opt/texlive/2017/ (full TeXLive install) After this record of a bundle installation on a fresh computer, I come to Richard's proposal to add a 'later/continue' dialog at the beginning of the process for the plain installer. During the installation process, I was constantly reminded that there was some external stuff name MiKTeX which asked for permission to continue: * either in the process of MikTeX install itself (in English, AFAIR) * or in the process of background update when I asked for UserGuide compilation: Windows Defender opened a popup to ask if I trusted MiKTeX, and this for each package. So the average user cannot ignore that LyX requires MiKTeX, and is bored by messages about it, so I really do not see how a further message at the beginning of the installation process would really affect him more. Here is a proposal: "LyX is going to update MiKTeX to the last 2.9 version. "If you do not use MiKTeX with other applications than LyX, you can continue safely. "If you do use MiKTeX with other applications and do not want to update it right now or want to perform the update yourself, you may postpone LyX installation " Later Continue I can provide a French translation of this very quickly if needed. As a general comment, I would strongly support a full LaTeX distribution install process rather than an update on the fly, I never did LaTeX updates between releases when I was in charge of the LaTeX distribution management in my lab (->2008, teTeX then TeXLive on Unix, and proTeXt on Windows). proTeXt size is currently 2.6Go, and is not prone to updates between TL versions. -- Jean-Pierre