Re: \[ddd]dots in mathed

2018-03-12 Thread Scott Kostyshak
On Tue, Mar 13, 2018 at 12:27:58AM +, Joel Kulesza wrote:
> On Fri, Mar 9, 2018 at 10:57 AM, Pavel Sanda  wrote:
> 
> > 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

2018-03-12 Thread Scott Kostyshak
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

2018-03-12 Thread Scott Kostyshak
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

2018-03-12 Thread list_email
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

2018-03-12 Thread Joel Kulesza
On Fri, Mar 9, 2018 at 10:57 AM, Pavel Sanda  wrote:

> 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

2018-03-12 Thread Paul A. Rubin

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

2018-03-12 Thread Richard Heck
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

2018-03-12 Thread Paul A. Rubin

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

2018-03-12 Thread Kornel Benko
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

2018-03-12 Thread 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.

Jürgen

> > 
> > Jürgen
> > 
> 
>  Kornel
> 

signature.asc
Description: This is a digitally signed message part


Re: Failing tex2lyx test

2018-03-12 Thread Kornel Benko
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 Thread 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.

I need a reproducible case in order to fix this.

Jürgen



>
> Kornel


Re: [LyX/master] Paint \dot & \ddot more like a dot

2018-03-12 Thread Richard Heck
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

2018-03-12 Thread Kornel Benko
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 Spitzmueller 
Date:   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)

2018-03-12 Thread Pavel Sanda
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

2018-03-12 Thread Pavel Sanda
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

2018-03-12 Thread Pavel Sanda
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

2018-03-12 Thread Pavel Sanda
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

2018-03-12 Thread Jean-Pierre Chrétien

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