View Menu Shortcuts

[Richard Kimberly Heck]

I propose the attached changes to the View menu for 2.4. The big
advantage, to my mind, is much more sensible shortcuts. The downside
would be that we make such a change, of course, but I think it would be
worth it. I've also re-organized the menu to put what I would expect to
be more often used items at the top. I've also made the fold/unfold
items optional, since they crowd the menu when they are not needed.

Riki


diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index 024aa57370..5c9b60ec8c 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -336,21 +336,21 @@ Menuset
 #
 
Menu "view"
-   Item "Open All Insets|O" "inset-forall * inset-toggle open"
-   Item "Close All Insets|C" "inset-forall * inset-toggle close"
-   Separator
-   Item "Unfold Math Macro|n" "math-macro-unfold"
-   Item "Fold Math Macro|d" "math-macro-fold"
-   Separator
-   Item "Outline Pane|u" "dialog-toggle toc"
+   Item "Outline Pane|O" "dialog-toggle toc"
Item "Code Preview Pane|P" "dialog-toggle view-source"
Item "Messages Pane|g" "dialog-toggle progress"
-   Submenu "Toolbars|b" "toolbars"
+   Submenu "Toolbars|T" "toolbars"
Separator
-   Item "Split View Into Left and Right Half|i" "view-split 
horizontal"
-   Item "Split View Into Upper and Lower Half|e" "view-split 
vertical"
+   OptItem "Unfold Math Macro|n" "math-macro-unfold"
+   OptItem "Fold Math Macro|d" "math-macro-fold"
+   Separator
+   Item "Split View Into Left and Right Half|L" "view-split 
horizontal"
+   Item "Split View Into Upper and Lower Half|U" "view-split 
vertical"
OptItem "Close Current View|w" "tab-group-close"
-   Item "Fullscreen|l" "ui-toggle fullscreen"
+   Item "Fullscreen|F" "ui-toggle fullscreen"
+   Separator
+   Item "Open All Insets|I" "inset-forall * inset-toggle open"
+   Item "Close All Insets|C" "inset-forall * inset-toggle close"
Separator
Documents
End

Re: master: Crash with 'save as'

[Richard Kimberly Heck]

On 5/25/19 9:44 AM, Kornel Benko wrote:
> 1.) Open lib/doc/Customization.lyx
> 2.) Save as CustomizationMin.lyx in different directory --> crash
> The file CustomizationMin.lyx looks OK though.
>
> Backtrace:
> Thread 1 "lyx2.4" received signal SIGSEGV, Segmentation fault.
> 0x00d9c4b8 in lyx::CursorSlice::text() const (this=0x2c44160)
> at /usr2/src/lyx/lyx-git/src/CursorSlice.h:119
> 119   Text * text() const { return inset_->getText(idx_); }
> (gdb) p inset_
> No symbol "inset_" in current context.
> (gdb) bt
> #0  0x00d9c4b8 in lyx::CursorSlice::text() const (this=0x2c44160) at 
> /usr2/src/lyx/lyx-git/src/CursorSlice.h:119
> #1  0x00cf8050 in lyx::DocIterator::innerTextSlice() const 
> (this=0x2f57400)
> at /usr2/src/lyx/lyx-git/src/DocIterator.cpp:233

Like others, I can confirm. Bisect points at

commit 91a5263d681c60544501bd402b8c5c215ea071bd (HEAD, refs/bisect/bad)
Author: Juergen Spitzmueller 
Date:   Wed Aug 8 15:05:58 2018 +0200

    Extend list of accessible menu info
   
    When searching for and item in the menu, also try to consider those that
    require a BufferView (such as View/Update formats).
   
    Also, be explicit for the default format in order to find it.
   
    Fixes: #9851

You get the same crash if you modify (a copy of) Customization.lyx and
then Revert to Saved.

The problem is a stale TOC from before we reloaded the Buffer: When we
get to

            submenu.expandTocSubmenu(toc.first, *toc.second);

in Menus::expandToc, toc.first is "branch" (because that is a type of
TOC we had before) but toc.second is an empty vector, and eventually we
crash.

The attached fixes it for me, but I'm not sure it's correct.

Riki


diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 6665a731e1..008750a9bf 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -5430,6 +5430,7 @@ Buffer::ReadStatus Buffer::reload()
d->setParent(0);
ReadStatus const status = loadLyXFile();
if (status == ReadSuccess) {
+   tocBackend() = TocBackend(this);
updateBuffer();
changed(true);
updateTitles();

Re: Shortcut Conflict

[Richard Kimberly Heck]

On 5/28/19 8:02 AM, Jean-Marc Lasgouttes wrote:
> Le 28/05/2019 à 13:29, Pavel Sanda a écrit :
>> On Mon, May 27, 2019 at 11:54:14PM -0400, Richard Kimberly Heck wrote:
>>> The argument "Short Title" seems to have the same shortcut as "List /
>>> TOC", so we get a warning to that effect when e.g. in a section heading
>>> and opening the Insert menu.
>>>
>>> I don't know if we need to do anything about that or not, but it always
>>> seems to go to the List, since that's a menu.
>>
>> I would leave it as it is. P
>
> No, it is better to remove the shortcut from "Short Titles", since it
> will print annoying warnings on console. And it is useless to show a
> shortcut that does not really exist.

Yes, I agree, but let's hear from Jürgen, perhaps.


> PS: the purpose of these warnings is to be a bit annoying, but we
> could easily decide to print them only in developer mode, for example.
> That would be less annoying for plain users, but not as hidden as
> placing this in some debug channel.

I'm not sure how many users rum from the terminal anyway.

Riki

Re: Why BiBTeX files are given to LyX as absolute paths?

[Richard Kimberly Heck]

On 5/30/19 4:47 PM, Julien SCORDIA wrote:
>
> Hi, thanks for your reply, cf my answers below.
>
> On 5/28/19 6:22 AM, Richard Kimberly Heck wrote:
>> On 5/12/19 6:19 PM, Julien SCORDIA wrote:
>>> 1/ I have just realized today that when indicating a BiBTeX file as
>>> "../biblio.bib" in the file selection GUI, its absolute path appears in
>>> the list of bibliography files. This is not the same behavior as with
>>> image files where the relative paths is kept. Having relative paths
>>> allows to use symbolic links, and e.g. to copy all the directory of a
>>> LyX file containing images and biblio to another machine, without any
>>> other modification in the LyX file (i.e. no need to change absolute
>>> paths). Is there some reason for which the behavior is not the same for
>>> images and biblio files?
>> I doubt it, and it doesn't seem like the right behavior. Note that it
>> does give you a relative path, though, if you use a subdirectory. It is
>> only when you try to ascend the hierarchy that it doesn't work.
>
> Ok, I was not enough rigorous in my tests. Indeed this is the same
> behavior between Bibtex files and images: when ascending the hierarchy
> ("..") an absolute path is formed by LyX.
>
OK, so one mystery solved.


>>> To keep relative paths for biblio files, I have modified in
>>> GuiBibtex.cpp the two calls to browseRelToParent() in browseRelToSub().
>>> I use LyX 2.3.2 source code.
>> If you use that one, then relative paths like subdir/mybib.bib show up
>> as absolute. So it fails for the opposite reason. (See the explanation
>> in qt_helpers.h.)
>>
>> I would think what we want is a relative path period. But...anyone?
>
> In my case I have some directories dir1, dir2, etc. containing
> respectively lyxfile1.lyx, lyxfile2.lyx, etc., all using a biblio.bib
> file located at the same level as dir1, dir2, etc. So I need to
> reference biblio.bib as ../biblio.bib in each of the LyX files.
> Because these LyX files are synchronized on an external device such
> that they can be open on another computer, I don't want an absolute
> path to be formed by LyX biblio.bib, it would not be found on the
> other computer.
>
> So you understand that indeed I want a relative path, and as you say,
> to my mind a relative path is better in many if not all cases.
>
I can see the use case for sure. I'll start a new thread to see if we
can get someone's attention.


>>> 2/ With or without the code modification proposed above, I have remarked
>>> that indicating a biblio file in the current directory does not work. It
>>> seems strange, something may be wrong on my machine.
>> In what way does it not work?
>
> I have just reproduced the problem on my Linux machine, in an empty
> file/new test user with LyX-2.3.2. Scenario below, can you reproduce it?
>
I did not reproduce, but I have a theory about this: There's another
file biblio.bib elsewhere on your machine that LyX is for some reason
finding. (We use kpsewhich to try to find such files, though I'm a bit
puzzled why in this case.) Try running with "-dbg files". You should get
a report at some point of the form

Reading file location for [[fileid]]
Found at: [path]

I'll bet you find those seven references there.

Riki

Relative vs Absolute Paths

[Richard Kimberly Heck]

In some cases (e.g., BibTeX files), we use a relative path only if the
file is below the directory where the LyX file resides. So, e.g, if
someone has:

biblio.bib
dir1/file1.lyx
dir2/file2.lyx

and the like, they cannot use a relative path to biblio.bib, which it
might be perfectly sensible to do. So when they move across machines,
the file is not found. Is there some reason we do it this way? Why not
use a relative path whenever a reasonable one exists?

Riki

Re: Why BiBTeX files are given to LyX as absolute paths?

[Richard Kimberly Heck]

On 5/30/19 6:27 PM, Julien SCORDIA wrote:
> On 5/31/19 12:16 AM, Richard Kimberly Heck wrote:
>> […]
>>>>> 2/ With or without the code modification proposed above, I have remarked
>>>>> that indicating a biblio file in the current directory does not work. It
>>>>> seems strange, something may be wrong on my machine.
>>>> In what way does it not work?
>>> I have just reproduced the problem on my Linux machine, in an empty
>>> file/new test user with LyX-2.3.2. Scenario below, can you reproduce it?
>>>
>> I did not reproduce, but I have a theory about this: There's another
>> file biblio.bib elsewhere on your machine that LyX is for some reason
>> finding. (We use kpsewhich to try to find such files, though I'm a bit
>> puzzled why in this case.) Try running with "-dbg files". You should get
>> a report at some point of the form
>>
>> Reading file location for [[fileid]]
>> Found at: [path]
>>
>> I'll bet you find those seven references there.
> Thanks, indeed it allowed to find the bibliography file where these
> seven references are; this is a bibliography file of my Debian LaTeX
> distribution:
>
> Buffer.cpp (2435): Reading file location for ../biblio
> Buffer.cpp (2442): Found at: /home/test_user/biblio.bib
> Buffer.cpp (4877): Reloading bibinfo cache.
> Buffer.cpp (2435): Reading file location for biblio
> Buffer.cpp (2442): Found at:
> /usr/share/texlive/texmf-dist/bibtex/bib/msc/biblio.bib
> Buffer.cpp (2435): Reading file location for biblio
> Buffer.cpp (2442): Found at:
> /usr/share/texlive/texmf-dist/bibtex/bib/msc/biblio.bib
>
> But isn't it a bug? Why the scenario of my previous message does not work?

I am not sure. As I said, I can't reproduce with 2.3.x. The code looks
as if it should first look for a local file first, but there are
conditions under which it will not do so. Is there anything you do
between opening the file and trying to insert a citation?

Are you able to compile LyX? If so, there is debugging code we could
add, as well.

Note that changing the link name to abcdefg.bib probably makes it work
for now.

Riki

Re: Why BiBTeX files are given to LyX as absolute paths?

[Richard Kimberly Heck]

On 5/30/19 7:21 PM, Richard Kimberly Heck wrote:
> On 5/30/19 6:27 PM, Julien SCORDIA wrote:
>> On 5/31/19 12:16 AM, Richard Kimberly Heck wrote:
>>> […]
>>>>>> 2/ With or without the code modification proposed above, I have remarked
>>>>>> that indicating a biblio file in the current directory does not work. It
>>>>>> seems strange, something may be wrong on my machine.
>>>>> In what way does it not work?
>>>> I have just reproduced the problem on my Linux machine, in an empty
>>>> file/new test user with LyX-2.3.2. Scenario below, can you reproduce it?
>>>>
>>> I did not reproduce, but I have a theory about this: There's another
>>> file biblio.bib elsewhere on your machine that LyX is for some reason
>>> finding. (We use kpsewhich to try to find such files, though I'm a bit
>>> puzzled why in this case.) Try running with "-dbg files". You should get
>>> a report at some point of the form
>>>
>>> Reading file location for [[fileid]]
>>> Found at: [path]
>>>
>>> I'll bet you find those seven references there.
>> Thanks, indeed it allowed to find the bibliography file where these
>> seven references are; this is a bibliography file of my Debian LaTeX
>> distribution:
>>
>> Buffer.cpp (2435): Reading file location for ../biblio
>> Buffer.cpp (2442): Found at: /home/test_user/biblio.bib
>> Buffer.cpp (4877): Reloading bibinfo cache.
>> Buffer.cpp (2435): Reading file location for biblio
>> Buffer.cpp (2442): Found at:
>> /usr/share/texlive/texmf-dist/bibtex/bib/msc/biblio.bib
>> Buffer.cpp (2435): Reading file location for biblio
>> Buffer.cpp (2442): Found at:
>> /usr/share/texlive/texmf-dist/bibtex/bib/msc/biblio.bib
>>
>> But isn't it a bug? Why the scenario of my previous message does not work?
> I am not sure. As I said, I can't reproduce with 2.3.x. The code looks
> as if it should first look for a local file first, but there are
> conditions under which it will not do so. Is there anything you do
> between opening the file and trying to insert a citation?

I can reproduce now. The trick is to start LyX from some directory that
is not the one where the bibfile resides. Problem is in master as well.

Riki

Re: Why BiBTeX files are given to LyX as absolute paths?

[Richard Kimberly Heck]

On 5/30/19 7:29 PM, Richard Kimberly Heck wrote:
> On 5/30/19 7:21 PM, Richard Kimberly Heck wrote:
>> On 5/30/19 6:27 PM, Julien SCORDIA wrote:
>>> On 5/31/19 12:16 AM, Richard Kimberly Heck wrote:
>>>> […]
>>>>>>> 2/ With or without the code modification proposed above, I have remarked
>>>>>>> that indicating a biblio file in the current directory does not work. It
>>>>>>> seems strange, something may be wrong on my machine.
>>>>>> In what way does it not work?
>>>>> I have just reproduced the problem on my Linux machine, in an empty
>>>>> file/new test user with LyX-2.3.2. Scenario below, can you reproduce it?
>>>>>
>>>> I did not reproduce, but I have a theory about this: There's another
>>>> file biblio.bib elsewhere on your machine that LyX is for some reason
>>>> finding. (We use kpsewhich to try to find such files, though I'm a bit
>>>> puzzled why in this case.) Try running with "-dbg files". You should get
>>>> a report at some point of the form
>>>>
>>>> Reading file location for [[fileid]]
>>>> Found at: [path]
>>>>
>>>> I'll bet you find those seven references there.
>>> Thanks, indeed it allowed to find the bibliography file where these
>>> seven references are; this is a bibliography file of my Debian LaTeX
>>> distribution:
>>>
>>> Buffer.cpp (2435): Reading file location for ../biblio
>>> Buffer.cpp (2442): Found at: /home/test_user/biblio.bib
>>> Buffer.cpp (4877): Reloading bibinfo cache.
>>> Buffer.cpp (2435): Reading file location for biblio
>>> Buffer.cpp (2442): Found at:
>>> /usr/share/texlive/texmf-dist/bibtex/bib/msc/biblio.bib
>>> Buffer.cpp (2435): Reading file location for biblio
>>> Buffer.cpp (2442): Found at:
>>> /usr/share/texlive/texmf-dist/bibtex/bib/msc/biblio.bib
>>>
>>> But isn't it a bug? Why the scenario of my previous message does not work?
>> I am not sure. As I said, I can't reproduce with 2.3.x. The code looks
>> as if it should first look for a local file first, but there are
>> conditions under which it will not do so. Is there anything you do
>> between opening the file and trying to insert a citation?
> I can reproduce now. The trick is to start LyX from some directory that
> is not the one where the bibfile resides. Problem is in master as well.

I've fixed this in master. Unfortunately, it's too late for 2.3.3, but
it will be in 2.3.4.

Riki

Re: Possible to implement jupyter notebook features?

[Richard Kimberly Heck]

On 6/14/19 1:10 PM, Jason Sun wrote:
> With the help of the reticulate package and knitr package, we are able
> to now embed python and R code in lyx in a reproducible manner. But
> the problem is that we have to compile the file every time we need to
> see the execution result of the python/R code.  In jupyter notebook,
> this is not necessary and we can run the code chunks independently. 
>
>
> So the question is whether its possible to implement a similar
> functionality in future lyx versions? Briefly, the feature could be
> abstracted in the following manner:
>
> 1. Create a procedure to copy the code in the ERT/code chunks, open a
> new subprocess, in which runs the python/R REPL and paste the code
> into a subprocess.
> 2. Run the code. 
> 3. Return the result in the a panel/window.
> 4. Closed the subprocess.
>
> Is something like this possible?

I would have thought that preview insets could be used to do this. Use
Insert> Preview to create such an inset, and then put whatever you want
previewed into it.

Note that this is completely general: Anything you can put into LyX can
be put into a preview inset, and it should be updated whenever the
contents is.

Probably another way to do this would be to use external templates.

Riki

Stable Branch Closed

[Richard Kimberly Heck]

...for the 2.3.3 release. I'll let you know when it is open again.

Riki

LyX 2.3.3 Tarballs

[Richard Kimberly Heck]

Here:

    http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/

Please test and prepare binaries.

Riki

Re: LyX 2.3.3 Tarballs

[Richard Kimberly Heck]

On 6/11/19 12:57 PM, Kornel Benko wrote:
> Am Dienstag, 11. Juni 2019, 14:01:24 CEST schrieb Pavel Sanda:
>> On Tue, Jun 11, 2019 at 12:21:51PM +0200, Kornel Benko wrote:
>>> Tried to compile with cmake and enabled tests ... ( 
>>> -DLYX_ENABLE_EXPORT_TESTS=ON)
>> I propose that before cmake tests is considered to be showstopper for release
>> they do roughly the same as autotools make check (testing various 
>> src/../tests
>> codes, not this development stuff which seems extremely fragile to all sorts
>> of circumstances).
>>
>> Pavel
>>
> I suppose, you have tried to use the devel tests, still my opinion is 
> different.
> Nobody is forced to enable these tests, but why should we force anybody to not
> be able to run them?

What do we need to do to make the run-able? What's missing?

Riki

2.3.3 Release, Stable Open

[Richard Kimberly Heck]

It appears my IP must have changed, so I'm unable to upload the
binaries, etc, to the ftp server. Once that is sorted out, I'll get it
done. Hopefully, that will happen tomorrow. If not, I'm going to be away
for the weekend and may not be able to do it until I get back.

Nonetheless, stable branch is now open per usual.

Riki

Re: Outliner keyboard navigation fails on MacOS

[Richard Kimberly Heck]

Can we get this tested on MacOS?

On 6/19/19 4:52 PM, Jason Sun wrote:
> This problem is resolved by inserting the  following code to the
> TocWidget.cpp file
>
> voidTocWidget::keyPressEvent(QKeyEvent*event)
> {
> if(event->key()==Qt::Key_Return)
> {
> QModelIndexconst=tocTV->currentIndex();
> goTo(curIdx);
> gui_view_.setFocus();
> gui_view_.activateWindow();
> }
> }
> Will be pushing a fix to the branch soon. 
>
> On Wed, Jun 19, 2019 at 3:21 PM Jason Sun  > wrote:
>
> I use MacOX High Sierra 10.13.6 and LyX 2.3.2. 
>
> The problem is the outline items(sections in the document) can
> only be selected by mouse click. However, the same LyX 2.3.2 on
> RollApp(cloud version of LyX) doesn’t not have this problem. 
>
> After looking at the source code, I thought of two solutions but
> none of them worked.
>
> *Solution 1*. I added the following function to the TocWidget.cpp
> file to specifically handle the keyPressEvent: 
>
>
> 
> ---
> void TocWidget::keyPressEvent(QKeyEvent *event)
> {
> if(event->key() == Qt::Key_Enter)
> {
> QModelIndex const & curIdx = tocTV->currentIndex();
> goTo(curIdx);
> gui_view_.setFocus();
> gui_view_.activateWindow();
> }
> }
> 
> ---
>
> But it doesn’t work after compiling against Qt5 
>
>
>
> *Solution 2.* I tried to hack the original function
> on_tocTV_pressed by adding a keyboardModifier flag check:
>
> ___
> void TocWidget::on_tocTV_pressed(QModelIndex const & index)
> {
>
> Qt::MouseButtons const button = QApplication::mouseButtons();
> Qt::KeyboardModifiers const modifier =
> QApplication::keyboardModifiers();
> if ((button & Qt::LeftButton) ||
> modifier.testFlag(Qt::ShiftModifier)) {
> goTo(index);
> gui_view_.setFocus();
> gui_view_.activateWindow();
> }
> }
> ___
>
> But still to no avail. I am not sure what is the problem here. I
> need some help/guidance in making this work on MacOS since this is
> the only place that requires mouse input. If this could be solved,
> I can 100% write my document mouse free which is a huge
> improvement considering the going back and forth in a large
> document using a mouse causes some inconvenience.
>
> I also tried the same thing on 2.4 development build and the
> problem persists. I don’t even know how to debug the program. It
> would be very helpful if someone can tell me how to see(or print
> to status bar) all the variables or at least the QtIndices when
> navigating through the tocTV variable on GUI. 
>
>
>
> Jason Sun
> Ph.D Candidate
> Department of Statistical Science
> Cornell University
> 105 Malott Hall
> Ithaca, NY 14853-3201
>
>
>
>
> -- 
> /*Daqian Sun*/
> /Tel:607-379-5149
> /
> /Department of Mathematics /
> /Department of Economics/
> /Cornell University/
>
   

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

Hi, Jason,

Thanks for these ideas. I'm not an R user myself, though, so it would be
helpful to me if you could explain what it is you are trying to achieve.
It's best when thinking through issues like this one to separate the
problem from the solution. What's below seems to be a mix between those.

One reason I ask about this is that LyX 2.3.3 has added the ability to
edit the LaTeX preamble or the contents of an ERT inset using some
external editor. LyX 2.4.0 will extend that to 'collapsible' insets
generally, controlled by a layout tag EditExternal. So by activating
this tag for the appropriate kind of inset, you can edit its contents in
whatever editor you define for its format. That seems, if I'm reading
you right, to give you much of what you want---and to use your editor of
choice.

Riki


On 6/20/19 10:42 AM, Jason Sun wrote:
> I thought about this long and hard. It is possible to extend Lyx's
> functionality beyond the document processer. With the help you pybind
> 11 and Qt5, I think is it possible to implement some of the IDE
> features(think RStudio) in LyX. This would be extremely helpful in
> writing scientific document. Currently, my workflow is to write code
> in VS Code/Emacs and copy and paste everything back and forth between
> LyX and code editor. 
>
> * It is not terribly cumbersome. But if we can development LyX into
> something like RStudio, it would definitely save some time.
>
> * Because LyX has support for knitr. Provided the script editor
> QtWidget and console Widget has been implemented, it won't be very
> hard to build a communication mechanism between the IDE portion and
> the LyX main buffer view portion. This is a little bit like
> Jupyter Console (think IPython), but with much better Latex support. 
>
> My rough idea: 
>
> * I think the GUI and UI design part it not so hard. We could just
> create another ViewSource-like class that inherit DockView but with
> editable text field. As for console portion, there are quite a few
> example QtConsole, are we could develop our own wheel. I remember in
> my undergrad OS class. the first project was to implement a
> terminal-ish stuff. As far as I am concerned it is not terribly
> difficult as long as the signals child processes are handled right. 
>
> * The major work should be in the building a python repl inside LyX. I
> think LyX has its own Python for some of the scripting procedures, but
> it is not ideal to use this one. The better solution, IMO, is to
> enable loading the Python Interpreter the user assigned. This gives a
> larger flexibility for various reasons (say, some user might want to
> use TensorFlow. This would be greatly helpful). 
>
> * with pybind11, it is not really hard to open up a python interpreter
> inside c++ applications. The developers of pybind11 gave various
> examples on how to do it. Moreover, pybind11 is a header only library,
> which makes it easy to be built into other applications.
>
>
> These are my thoughts so far. Would be nice to hear some of your ideas
> on this. 
>
>
> Jason Sun
> Cornell University 

Re: TeXFiles.py compatibility with Nix on macOS

[Richard Kimberly Heck]

On 6/25/19 10:01 AM, Jean-Marc Lasgouttes wrote:
> Le 25/06/2019 à 15:21, Michael Roitzsch a écrit :
>> Hi JMarc,
>>
>>> I paused a bit at first due to the remark from Günter:
 I remember that some people complained because of delays when symlinks
 point to removable media or "the cloud". So there might be no "one
 setting
 fits all" approach.
>>>
>>> But now I think that the TeX is supposed to search everywhere in
>>> these directories anyway, so we should do the same IMO. Günter, do
>>> you agree?
>>
>> I understand the concern, but I do feel the same way. TeX will scan
>> these directories as well. And on the LyX side, I understand that the
>> scan result is cached, so it will not be a continuous burden.
>>
>
> I pushed the patch to master at 642b4acc.  Riki, OK for backport?

Yes.

Riki

[ANNOUNCE] LyX 2.3.3

[Richard Kimberly Heck]

Public release of LyX version 2.3.3
===

We are proud to announce the release of LyX 2.3.3. This is the third
maintenance release in the 2.3.x series.

You can download LyX 2.3.3 from http://www.lyx.org/Download/.

LyX is a document processor that encourages an approach to writing based
on the structure of your documents and not simply their appearance. It is
released under a Free and Open Source Software license.

LyX 2.3.3 is the result of on-going efforts to make our stable version more
reliable and more stable. One important change is that emergency files are
now renamed when users wish to save them. As a result, older emergency files
are not over-written. One major update allows for the editing of the
contents
of the user-provided premable, and the contents of ERT insets, in external
editors, a request that goes back to 2003 and bug #991.

Please note that the present version of the Windows installer does not
include
updates to such dependencies as ImageMagick. These will be included in an
updated installer to be released shortly.

If you think you have found a bug in LyX 2.3.3, please open a bug report at
http://www.lyx.org/trac/wiki/BugTrackerHome. If you're not sure whether it
really is a bug, you can e-mail the LyX developers' mailing list (lyx-devel
 lists.lyx.org) and ask.

If you have trouble using LyX or have a question, consult the documentation
that comes with LyX (under the Help or Apple menu) and the LyX wiki, which
is at http://wiki.lyx.org/. If you can't find the answer there, e-mail the
LyX users' list (lyx-users  lists.lyx.org), where you will find an
active community of people who are ready to help.

We hope you enjoy using LyX 2.3.3.

The LyX team.
http://www.lyx.org



What's new
==

** Updates:
***

* DOCUMENT INPUT/OUTPUT

- Preserving .lyx file permission when saving on linux systems (Qt5-only).

- Properly implement CJKutf8 (which never really worked as intended).


* USER INTERFACE

- Allow external editing of preamble and ERT (bugs 991, 7404).

- Allow nameref in math references (bug 9798).

- Fix renaming of citation references after changing bibliography key
  (bug 6494).

- Make tab movement visible (bug 10733).

- Add "Reset" and "Reset All Fields" buttons to Text Properties
  dialog (bug 11415).

- Add "Reset to Default" and "Reset All" buttons to Color Preferences
  (bug 10062).

- Insert new graphics inset on the correct cursor position.

- Fix regression where spaces are disappearing when editing text (bug
11412).

- The function textstyle-update now only changes explicitly stated font
  attributes (bug 1).

- Fix bad error message (bug 11486).

- Improve performance on Windows with lots of math insets or very long
  math formulas (bug 11546).

- Add Shortcut (Command-0) for workarwa zoom reset to mac.bind.

- Improve some icons (bug 11476).

- Improve line breaking of Chinese, Japanese and Korean text. There are
still
  issues, though (bug 10299).


* DOCUMENTATION AND LOCALIZATION

- The Bulgarian user interface localization has been updated and re-enabled.

- Updates to the Arabic, Czech, French, German, Italian, Brazilian
Portuguese,
  Russian, Slovak, Swedish, and Ukrainian localizations.

- Minor rework of the thesis example file in order to clear some
confusion about
  the included bibliography (bug 10748).




** Bug fixes:
*

* DOCUMENT INPUT/OUTPUT

- Added support for aastex62 (bug 11397)

- Fix problems with non-ASCII characters in path with recent LaTeX versions
  (bug 11146).

- Fix parsing of math-macro optional arguments after save-reopen (bug
11346).

- Fix handling of InPreamble styles in insets (bug 11557).

- Fix problem with wrongly inserted separator.

- Beamer: automatically nest column in columns.

- Fix Autonests and IsAutonestedBy layout tags with specific layout names
  (with space, underbar and enquoted).

- Fix SVG to PNG image conversion problem with inkscape on Mac.
  On-screen display of SVG graphics was broken for e.g. users guide.

- Fix paragraph alignment in RTL when using polyglossia (bidi) (bug 11399).

- Fix text direction of namerefs in RTL scripts when using polyglossia
(bidi)
  (bug 11518).

- Use proper listings font styles with polyglossia (bidi) and RTL (bug
11554).

- Fix LaTeX export of query strings in Hyperlinks (bugs 11482, 11511).

- Fix breakage caused by commas in the caption of listings (bug 11484).

- Fix LaTeX error caused by Control key shortcut inset on the Mac (remainder
  of bug 10641).

- Correctly add the branch name suffix when the stem of the filename
  contains a dot (bug 11490).

- Load required packages to correctly typeset unicode symbols entered
  in math mode (bug 11526).

- Only write btUnits if we have a bibliography (bug 11562).

- Fix paragraph break in particular cases (bug 11528).


* USER INTERFACE

- Rename emergency file when user wants to save it (bug 11464).

- Fix reloading of local layout file (bug 11120).

- Check for 

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 6/25/19 2:57 PM, Jason Sun wrote:
> I have attached a prototype in the screenshots in the attachment. 
>
> This is what I am trying to achieve - combining the computing power of
> jupyter and the latex power of LyX. It is still in early stages. More
> testing and further extension could easily be developed. Ideally, one
> could do the following few things with this feature
>
> 1. Edit the ERT box inside a code editor that is embeded in LyX
> powered by QScintilla2 with syntax highlighting and clangformat.

Why is it an advantage to be able to edit the code inside LyX, as
opposed to in an external editor of one's own choosing? We have tended
to resist embedding things inside LyX that can be done just as well, or
better, by an external program devoted to the task. For example, it was
once suggested that LyX should have an embedded BibTeX editor. But why?
Better, we thought, just to allow databases to be opened in external
programs and edited there.


> 2. Copy and paste the code in the ERT or codeListing  in the lyx
> editing pane or the code in the embeded code editor  and execute them
> in the embeded jupyter-console and get output(plots) displayed in the
> console(a separate plot pane) inside LyX.

Same question, basically.


> I looked at the current 2.4 dev source files, the design for external
> editor is a good idea. However, it does not seem to close the external
> editor properly. At least I tried on vscode and atom.

We do not close the external editor ourselves. The user might want to
leave it open for some reason. (E.g., there might be other files open in
the editor.)


> I also think that the tmp file approach could be internalized.

Not sure what you mean here.


> The end goal is to enable LyX be stronger if not as strong as jupyter
> notebook.
So the overall question is: Why not instead figure out how to make LyX
work well WITH jupyter notebook?

Riki

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 6/25/19 4:24 PM, Jason Sun wrote:
> One of the reason of embedding a terminal to basically ensure the
> jupyter_client is running in the backend. Say I want to write a stats
> book in latex that contains a lot of python and R code. After
> executing one piece of code, I might want to keep all the variables so
> that I can refer it later. Currently, I cannot do this in any special
> latex editor including lyx without compiling the tex file first. I
> could do it in vim or emacs or vscode because they are general purpose
> editors. However, writing latex in them is not a very pleasant
> experience for me personally. 
>
> That is the reason why I came with this idea of building a bridge
> between LyX and Jupyter to combine their powers. I thought about bring
> LyX to jupyter, but it is extremely difficult since Qt has limited
> support for web. Even if we take a step back to use python as a glue,
> we still need to port the whole lyx implementation to Python and use
> PySide2. It is by no means easy. Plus, PySide2 is relatively new. It's
> hard to predict the quality of the ported work.
>
> So the only viable option left, in my opinion, is to bring Jupyter to
> LyX.

I'm not familiar with Jupyter beyond my just-now explorations on the
web, so most of my questions and comments are probably naive. But have
you looked into external templates for LyX? That's another way we have
to interface with external programs. There's also the Preview inset,
which can be used to compile and embed almost anything into LyX.

The problem of persistent variables is maybe more complicated.

Anyway, I don't mean to be discouraging. But it always seems best to
spend a lot of time thinking about design issues before coding too much.
I've learned that the hard way.

Riki



>
> On Tue, Jun 25, 2019 at 4:10 PM Jason Sun  <mailto:ds...@cornell.edu>> wrote:
>
> So the overall question is: Why not instead figure out how to make LyX
> work well WITH jupyter notebook?
>
> One way to make it work well with jupyter notebook is to let it
> communicate with jupyter_client. CS and Stats community uses
> Jupyter and Latex a lot, but the two don't work well together. LyX
> has the advantage of being one of the best Latex editor. It would
> be kind of cool to let it have jupyter's capabilities. LyX already
> has knitr support. So it could takes a bit of extra work to extend
> it to be an interface to jupyter_client or jupyter console. One of
> the disadvantage of Jupyter Notebook is its latex capabilities. Cf
>     this discussion: https://github.com/jupyter/notebook/issues/1604
>
> On Tue, Jun 25, 2019 at 3:50 PM Richard Kimberly Heck
> mailto:rikih...@lyx.org>> wrote:
>
> On 6/25/19 2:57 PM, Jason Sun wrote:
> > I have attached a prototype in the screenshots in the
> attachment. 
> >
> > This is what I am trying to achieve - combining the
> computing power of
> > jupyter and the latex power of LyX. It is still in early
> stages. More
> > testing and further extension could easily be developed.
> Ideally, one
> > could do the following few things with this feature
> >
> > 1. Edit the ERT box inside a code editor that is embeded in LyX
> > powered by QScintilla2 with syntax highlighting and clangformat.
>
> Why is it an advantage to be able to edit the code inside LyX, as
> opposed to in an external editor of one's own choosing? We
> have tended
> to resist embedding things inside LyX that can be done just as
> well, or
> better, by an external program devoted to the task. For
> example, it was
> once suggested that LyX should have an embedded BibTeX editor.
> But why?
> Better, we thought, just to allow databases to be opened in
> external
> programs and edited there.
>
>
> > 2. Copy and paste the code in the ERT or codeListing  in the lyx
> > editing pane or the code in the embeded code editor  and
> execute them
> > in the embeded jupyter-console and get output(plots)
> displayed in the
> > console(a separate plot pane) inside LyX.
>
> Same question, basically.
>
>
> > I looked at the current 2.4 dev source files, the design for
> external
> > editor is a good idea. However, it does not seem to close
> the external
> > editor properly. At least I tried on vscode and atom.
>
> We do not close the external editor ourselves. The user might
> want to
>  

Windows Binaries

[Richard Kimberly Heck]

...are at ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ for testing. Please
let me know if they are OK. I'll be travelling tomorrow, but will do the
release over the weekend.

Riki

Re: LyX 2.3.3 Tarballs

[Richard Kimberly Heck]

On 6/11/19 3:19 PM, Kornel Benko wrote:
> Am Dienstag, 11. Juni 2019, 14:11:17 CEST schrieb Richard Kimberly Heck:
>> On 6/11/19 12:57 PM, Kornel Benko wrote:
>>> Am Dienstag, 11. Juni 2019, 14:01:24 CEST schrieb Pavel Sanda:
>>>> On Tue, Jun 11, 2019 at 12:21:51PM +0200, Kornel Benko wrote:
>>>>> Tried to compile with cmake and enabled tests ... ( 
>>>>> -DLYX_ENABLE_EXPORT_TESTS=ON)
>>>> I propose that before cmake tests is considered to be showstopper for 
>>>> release
>>>> they do roughly the same as autotools make check (testing various 
>>>> src/../tests
>>>> codes, not this development stuff which seems extremely fragile to all 
>>>> sorts
>>>> of circumstances).
>>>>
>>>> Pavel
>>>>
>>> I suppose, you have tried to use the devel tests, still my opinion is 
>>> different.
>>> Nobody is forced to enable these tests, but why should we force anybody to 
>>> not
>>> be able to run them?
>> What do we need to do to make the run-able? What's missing?
>>
>> Riki
>>
>>
> Attached should be OK. At least, with the mentioned files, the tests are 
> running.

Please go ahead. I'll rebuild the tarballs.

This won't affect the binaries already built, right?

Riki

Re: cancel background export process from icon?

[Richard Kimberly Heck]

On 5/13/19 4:42 AM, Jean-Marc Lasgouttes wrote:
> Le 13/05/2019 à 05:51, Richard Kimberly Heck a écrit :
>> Something like the following ought to work, but it won't link. I'm
>> terrible at linker errors. Help?
>
> Can we have the GuiClickableLabel stuff too?

Not sure why that didn't get included, but here's the full patch again.

Riki


>From a53e829ceaf4aa2f712c642ff1751f76dbe3fd94 Mon Sep 17 00:00:00 2001
From: Richard Kimberly Heck 
Date: Mon, 13 May 2019 14:00:43 -0400
Subject: [PATCH] Try to make spinner clickable.

---
 src/frontends/qt4/GuiClickableLabel.h | 42 +++
 src/frontends/qt4/GuiView.cpp | 16 +-
 src/frontends/qt4/GuiView.h   |  2 ++
 src/frontends/qt4/Makefile.am |  1 +
 4 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 src/frontends/qt4/GuiClickableLabel.h

diff --git a/src/frontends/qt4/GuiClickableLabel.h b/src/frontends/qt4/GuiClickableLabel.h
new file mode 100644
index 00..5f829c1455
--- /dev/null
+++ b/src/frontends/qt4/GuiClickableLabel.h
@@ -0,0 +1,42 @@
+/**
+ * \file GuiClickableLabel.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Richard Heck
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef GUICLICKABLELABEL_H
+#define GUICLICKABLELABEL_H
+
+#include 
+
+namespace lyx {
+namespace frontend {
+
+// see https://wiki.qt.io/Clickable_QLabel
+class GuiClickableLabel : public QLabel {
+	Q_OBJECT
+public:
+	explicit GuiClickableLabel(QWidget * parent)
+		: QLabel(parent)
+	{}
+
+~GuiClickableLabel() {}
+
+Q_SIGNALS:
+	void clicked();
+
+protected:
+	void mousePressEvent(QMouseEvent *) {
+		Q_EMIT clicked();
+	}
+};
+
+
+} // namespace frontend
+} // namespace lyx
+
+#endif  // GUISELECTIONMANAGER
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 98dba1dfa5..2742c3ea1c 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -19,6 +19,7 @@
 #include "FileDialog.h"
 #include "FontLoader.h"
 #include "GuiApplication.h"
+#include "GuiClickableLabel.h"
 #include "GuiCommandBuffer.h"
 #include "GuiCompleter.h"
 #include "GuiKeySymbol.h"
@@ -610,7 +611,7 @@ GuiView::GuiView(int id)
 	setAcceptDrops(true);
 
 	// add busy indicator to statusbar
-	QLabel * busylabel = new QLabel(statusBar());
+	GuiClickableLabel * busylabel = new GuiClickableLabel(statusBar());
 	statusBar()->addPermanentWidget(busylabel);
 	search_mode mode = theGuiApp()->imageSearchMode();
 	QString fn = toqstr(lyx::libFileSearch("images", "busy", "gif", mode).absFileName());
@@ -623,6 +624,7 @@ GuiView::GuiView(int id)
 		busylabel, SLOT(show()));
 	connect(_thread_watcher_, SIGNAL(finished()),
 		busylabel, SLOT(hide()));
+	connect(busylabel, SLOT(clicked()), this, SIGNAL(checkCancelBackground()));
 
 	QFontMetrics const fm(statusBar()->fontMetrics());
 	int const iconheight = max(int(d.normalIconSize), fm.height());
@@ -713,6 +715,18 @@ void GuiView::disableShellEscape()
 }
 
 
+void GuiView::checkCancelBackground()
+{
+	docstring const ttl = _("Cancel Export?");
+	docstring const msg = _("Do you want to cancel the background export process?");
+	int const ret =
+		Alert::prompt(ttl, msg, 1, 1,
+			_(" export"), _("Co"));
+	if (ret == 0)
+		Systemcall::killscript();
+}
+
+
 QVector GuiView::GuiViewPrivate::guiWorkAreas()
 {
 	QVector areas;
diff --git a/src/frontends/qt4/GuiView.h b/src/frontends/qt4/GuiView.h
index fa36f7ff8b..5dd84f3798 100644
--- a/src/frontends/qt4/GuiView.h
+++ b/src/frontends/qt4/GuiView.h
@@ -231,6 +231,8 @@ public Q_SLOTS:
 	void updateWindowTitle(GuiWorkArea * wa);
 	///
 	void disableShellEscape();
+	///
+	void checkCancelBackground();
 
 private Q_SLOTS:
 	///
diff --git a/src/frontends/qt4/Makefile.am b/src/frontends/qt4/Makefile.am
index e2e3e1ce5e..488e8ba224 100644
--- a/src/frontends/qt4/Makefile.am
+++ b/src/frontends/qt4/Makefile.am
@@ -198,6 +198,7 @@ MOCHEADER = \
 	GuiCharacter.h \
 	GuiCitation.h \
 	GuiClipboard.h \
+	GuiClickableLabel.h \
 	GuiCommandBuffer.h \
 	GuiCommandEdit.h \
 	GuiCompare.h \
-- 
2.17.2

Re: cancel background export process from icon?

[Richard Kimberly Heck]

PING!!

On 5/13/19 2:02 PM, Richard Kimberly Heck wrote:
> On 5/13/19 4:42 AM, Jean-Marc Lasgouttes wrote:
>> Le 13/05/2019 à 05:51, Richard Kimberly Heck a écrit :
>>> Something like the following ought to work, but it won't link. I'm
>>> terrible at linker errors. Help?
>> Can we have the GuiClickableLabel stuff too?
> Not sure why that didn't get included, but here's the full patch again.
>
> Riki
>
>

Re: master crash

[Richard Kimberly Heck]

On 5/22/19 6:26 PM, Pavel Sanda wrote:
> On Thu, May 23, 2019 at 12:21:49AM +0200, Pavel Sanda wrote:
>> lassert.cpp (51): ASSERTION pos <= par.size() VIOLATED IN 
>> TextMetrics.cpp:1619
>> (  1) src/lyx: lyx::doAssertWithCallstack(bool)
>> (  2) src/lyx: lyx::doAssert(char const*, char const*, long)
>> (  3) src/lyx: lyx::TextMetrics::leftMargin(int, int) const
>> (  4) src/lyx: lyx::TextMetrics::breakRow(lyx::Row&, int) const
>> (  5) src/lyx: lyx::TextMetrics::redoParagraph(int, bool)
>> (  6) src/lyx: lyx::BufferView::updateMetrics(lyx::Update::flags&)
>> (  7) src/lyx: lyx::BufferView::updateMetrics()
>> (  8) src/lyx: lyx::BufferView::resize(int, int)
>> (  9) src/lyx: lyx::frontend::GuiWorkArea::init()
>> ( 10) src/lyx: lyx::frontend::GuiWorkArea::GuiWorkArea(lyx::Buffer&, 
>> lyx::frontend::GuiView&)
>> ( 11) src/lyx: lyx::frontend::TabWorkArea::addWorkArea(lyx::Buffer&, 
>> lyx::frontend::GuiView&)
>> ( 12) src/lyx: lyx::frontend::GuiView::addWorkArea(lyx::Buffer&)
>> ( 13) src/lyx: lyx::frontend::GuiView::setBuffer(lyx::Buffer*, bool)
>> ( 14) src/lyx: lyx::frontend::GuiView::loadDocument(lyx::support::FileName 
>> const&, bool)
>> ( 15) src/lyx: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest 
>> const&, lyx::DispatchResult&)
>> ( 16) src/lyx: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest 
>> const&)
>> ( 17) src/lyx: lyx::dispatch(lyx::FuncRequest const&)
>> ( 18) src/lyx: lyx::frontend::Action::action()
>> ( 19) src/lyx: src/lyx() [0x8ac8dc4]
>> ...
>>
>> Anyone can reproduce?
> Actually whole editing process is broken, visible cursor no more follows 
> actual
> position of it in the document and I get crashes even in new docuemnt after 
> some basic editing...
>
> I can see that with qt5 as well, it seems that current master is seriously 
> broken.

Try reverting da2696cc, and see https://www.lyx.org/trac/ticket/11396.

Riki

Re: cancel background export process from icon?

[Richard Kimberly Heck]

On 5/23/19 8:58 AM, Pavel Sanda wrote:
> On Mon, May 13, 2019 at 02:02:54PM -0400, Richard Kimberly Heck wrote:
>> On 5/13/19 4:42 AM, Jean-Marc Lasgouttes wrote:
>>> Le 13/05/2019 ? 05:51, Richard Kimberly Heck a écrit :
>>>> Something like the following ought to work, but it won't link. I'm
>>>> terrible at linker errors. Help?
>>> Can we have the GuiClickableLabel stuff too?
>> Not sure why that didn't get included, but here's the full patch again.
> There is
> #include "moc_GuiClickableLabel.cpp"
> missing so linker see the definitions of qt-related functions to create 
> vtable.
>
> Since you don't have GuiClickableLabel.cpp you have to push it elsewhere,
> e.g. end of GuiView.cpp, though this unit crowded already...

PS I'd expect the build scripts to take care of compiling all that, no?

RKH

Re: cancel background export process from icon?

[Richard Kimberly Heck]

On 5/23/19 8:58 AM, Pavel Sanda wrote:
> On Mon, May 13, 2019 at 02:02:54PM -0400, Richard Kimberly Heck wrote:
>> On 5/13/19 4:42 AM, Jean-Marc Lasgouttes wrote:
>>> Le 13/05/2019 ? 05:51, Richard Kimberly Heck a écrit :
>>>> Something like the following ought to work, but it won't link. I'm
>>>> terrible at linker errors. Help?
>>> Can we have the GuiClickableLabel stuff too?
>> Not sure why that didn't get included, but here's the full patch again.
> There is
> #include "moc_GuiClickableLabel.cpp"
> missing so linker see the definitions of qt-related functions to create 
> vtable.
>
> Since you don't have GuiClickableLabel.cpp you have to push it elsewhere,
> e.g. end of GuiView.cpp, though this unit crowded already...

If I put some of the code into a GuiClickableLabel.cpp, and include
moc... as usual, that will take care of it?

Riki

Re: [LyX/2.3.x] * cs.po - finalize

[Richard Kimberly Heck]

On 5/6/19 9:18 AM, Pavel Sanda wrote:
> On Mon, May 06, 2019 at 03:00:21PM +0200, Pavel Sanda wrote: 
>>  #: src/Buffer.cpp:4793
>>  msgid ""
>>  "LyX was unable to rename the emergency file. You should do so manually. "
>>  "Otherwise, you will beasked about it again the next time you try to 
>> loadthis "
>>  "file, and may over-write your own work."
> 1) beasked & loadthis typos are now part of frozen strings.

Is this something we can change ourselves? In the source and in the po
files?


> 2) IIRC we were thinking about adding "Emergency file saved as whatever.lyx"
>as a notification for emergency rename...

Is there a bug for this?

Riki

Re: [LyX/2.3.x] * cs.po - finalize

[Richard Kimberly Heck]

On 5/20/19 9:37 AM, Pavel Sanda wrote:
> On Wed, May 08, 2019 at 05:38:41PM -0400, Richard Kimberly Heck wrote:
>> On 5/6/19 9:18 AM, Pavel Sanda wrote:
>>> On Mon, May 06, 2019 at 03:00:21PM +0200, Pavel Sanda wrote: 
>>>>  #: src/Buffer.cpp:4793
>>>>  msgid ""
>>>>  "LyX was unable to rename the emergency file. You should do so manually. "
>>>>  "Otherwise, you will beasked about it again the next time you try to 
>>>> loadthis "
>>>>  "file, and may over-write your own work."
>>> 1) beasked & loadthis typos are now part of frozen strings.
>> Is this something we can change ourselves? In the source and in the po
>> files?
> There is partisan solution in trying to fix already
> posted updates of po files, but it might lead to all sort of inconsistencies
> when people send you new updates with files they already started working with 
> etc...

That is what I meant. But they (and you) will get the updates when you
pull, won't you?

Riki

Re: [LyX/master] Enable optional \cite* arguments in biblatex-natbib

[Richard Kimberly Heck]

On 5/12/19 3:28 AM, Jürgen Spitzmüller wrote:
> Am Dienstag, den 07.05.2019, 14:51 +0200 schrieb Jürgen Spitzmüller:
>>> commit 6a4199ed233e5a9fe7fa0fbfd0266cd29560951b
>>> Author: Juergen Spitzmueller 
>>> Date:   Tue May 7 14:48:39 2019 +0200
>>>
>>> Enable optional \cite* arguments in biblatex-natbib
>> This is a candidate for stable, Riki.
> Riki? I think this is safe enough for 2.3.3.

OK then.

Riki

Re: LyX 2.4.0?

[Richard Kimberly Heck]

On 5/12/19 3:39 AM, Jürgen Spitzmüller wrote:
> I think we have accumulated more than enough features end enhancements
> that warrant a new major release:
> https://wiki.lyx.org/LyX/NewInLyX24
>
> How about releasing it real soon?

I guess it's an open question how soon it actually could be released,
but I'd be happy to see us start to move in that direction, i.e., think
about an alpha.

Riki

Re: cancel background export process from icon?

[Richard Kimberly Heck]

On 5/12/19 4:12 PM, Guenter Milde wrote:
> Dear LyX developers,
>
> "It is now possible to cancel background export processes. A menu entry
>  to do so will appear on the Document menu when such a process is underway."
>  
>  -- RELEADE-NOTES
>  
>
> May I suggest to make the "background process indicator icon" 
> (the animation in the right corner of the status bar) interactive?
> IMV it would be good to open a "cancel export process" dialogue when clickin
> on it.

I agree, and even thought of that, but I do not myself know how to do
it. If someone can give me an outline---or maybe just tell me where that
little spinner thing gets created---then I can do the work.

Riki

2.3.3 String Freeze: Please Prepare Translations

[Richard Kimberly Heck]

Strings are frozen now in the 2.3.x branch so that translations can be
prepared for LyX 2.3.3. Please have these done by Sunday, 19 May. I'll
plan to build the release shortly thereafter.

Apologies that it has taken so long to get 2.3.3 out. It's been a crazy
semester.

Riki

PS Apologies for duplicate messages, too. I sent from the wrong account
the first time.

Re: [LyX/2.3.x] Fix import of custom float definitions

[Richard Kimberly Heck]

On 7/5/19 12:37 PM, Juergen Spitzmueller wrote:
> commit 5afb71cb9bb1d9b10df2410b32f0a7720ad93182
> Author: Juergen Spitzmueller 
> Date:   Sun Jun 30 11:13:20 2019 +0200
>
> Fix import of custom float definitions
> 
> Candidate for stable

OK.

Riki

Re: Is it possible to make the ERT inset show different colors for different text?

[Richard Kimberly Heck]

On 6/27/19 1:36 PM, Kornel Benko wrote:
> Am Donnerstag, 27. Juni 2019, 12:08:05 CEST schrieb Jason Sun:
>> I think this is crucial to implement syntax highlighting of ERT box.
>>
> I don't think so. ERT is/was meant for text, which we do _not_ interpret.

Yes, if you want to do something like that, it'll be best to create a
new type of collapsible inset.

Riki

Re: [LyX/master] Proper number ordering with luabidi

[Richard Kimberly Heck]

On 7/11/19 3:59 AM, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 11.07.2019, 09:45 +0200 schrieb Juergen
> Spitzmueller:
>> commit 1d0929b5d9975923f3cbbe7f84e93f3b694a1ccb
>> Author: Juergen Spitzmueller 
>> Date:   Thu Jul 11 09:54:28 2019 +0200
>>
>> Proper number ordering with luabidi
>> 
>> As opposed to bidi (XeTeX), luabidi (LuaTeX) does no automatic
>> reordering,
>> so we need to use \\LR{}
> Riki, this is another thing to backport in the context of the luabidi
> fixes.

OK.

Riki

Re: Regression: Problem with Paths Containing ~ [Was Re: LyX 2.3.3 Error with iCloud Folders]

[Richard Kimberly Heck]

On 7/7/19 4:39 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 06.07.2019, 15:16 -0400 schrieb Richard Kimberly Heck:
>> Fine by me.
> I took this as also including stable, so I committed and backported.
>
> There are other (active) ASCII characters that might be worth checking,
> specifically @, #, $, % and &.

No problems with any of those.

Riki

Regression: Problem with Paths Containing ~ [Was Re: LyX 2.3.3 Error with iCloud Folders]

[Richard Kimberly Heck]

On 7/2/19 4:29 PM, Stephan Witt wrote:
> Am 02.07.2019 um 01:44 schrieb Richard Kimberly Heck :
>>  Forwarded Message 
>> Subject: [ANNOUNCE] LyX 2.3.3
>> Date:Mon, 1 Jul 2019 16:44:12 -0500
>> From:Mauricio Andrade 
>> To:  rikih...@lyx.org
>>
>>
>> After updating to 2.3.3 I no longer can compile files on iCloud folders that 
>> have paths like
>>
>>  ~/Library/Mobile Documents/com~apple~CloudDocs/
>>
>> I get this error several times with a minimal file (only title and a line of 
>> text):
>>
>> ! LaTeX Error: Missing \begin{document}.
>>
>> I’ll go back to 2.3.2 in the meanwhile.
>>
>> Thank you
>>
>> —
>> Mauricio Andrade
> Unfortunately I can reproduce the issue. One can test it w/o an iCloud folder.
> I’m not an user of iCloud - so I’ve made a directory with path
> "~/Library/My Mobile Documents/com~apple~CloudDocs" and placed a LyX document
> there. The exported tex files are the same with 2.3.2 and 2.3.3.
> I’m not sure if the tilde characters in the path name are the culprit.
>
> What happens on Linux with documents in such directory paths?

Same problem. I've traced it to:

\def\input@path{{/home/rikiheck/this~silly~dir/}}

It appears to be that LaTeX itself has problems with such paths. If we
add \detokenize:

\def\input@path{{\detokenize{/home/rikiheck/this~silly~dir/}}}

then it works.

In 2.3.2, we get:

\def\input@path{{/home/rikiheck/this\string~silly\string~dir/}}

This seems to be a regression in ac351f40f1d1. We used to call
support::latex_path here, but now only call os::latex_path, and the
result is that ~ doesn't get '\string'd. I would guess that there may be
similar problems with other characters that are handled there.

Note that this is also in master.

Riki

Re: [LyX/master] [2.3 cand.] Fix import of custom float definitions

[Richard Kimberly Heck]

On 6/30/19 5:04 AM, Juergen Spitzmueller wrote:
> commit bda3b6d07eb8ee199fbc80911e02d2adf87d14fc
> Author: Juergen Spitzmueller 
> Date:   Sun Jun 30 11:13:20 2019 +0200
>
> [2.3 cand.] Fix import of custom float definitions
> 
> Candidate for stable

OK.

Riki

Re: [LyX/master] update buffer after fixBiblio

[Richard Kimberly Heck]

On 4/20/19 1:47 PM, Juergen Spitzmueller wrote:
> commit 0a4686d8d345e7d2924bf990e99d957f045d581e
> Author: Juergen Spitzmueller 
> Date:   Sat Apr 20 19:53:24 2019 +0200
>
> update buffer after fixBiblio
> 
> fixes: #2743
> ---
>  src/Paragraph.cpp |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
> index 4e36f7f..e5327a4 100644
> --- a/src/Paragraph.cpp
> +++ b/src/Paragraph.cpp
> @@ -3723,6 +3723,8 @@ int Paragraph::fixBiblio(Buffer const & buffer)
>   insertInset(0, inset, font, Change(track_changes ? Change::INSERTED
>  : Change::UNCHANGED));
>  
> + // This is needed to get the counters right
> + buffer.updateBuffer();
>   return 1;
>  }

I am guessing this will be fine, but just so we're all on the lookout:
There have been cases where we're just 'not ready' for updateBuffer.
That's why we have the machinery to defer doing that until the end of
some other process. So if we start seeing crashes in certain cases, it'd
be worth looking here.

Riki

Re: r41227 - www-user/trunk/farm/cookbook/LyX

[Richard Kimberly Heck]

On 4/26/19 4:45 AM, Jean-Pierre Chrétien wrote:
> Le 26/04/2019 à 10:26, sp...@lyx.org a écrit :
>> Author: spitz
>> Date: Fri Apr 26 10:26:32 2019
>> New Revision: 41227
>> URL: http://www.lyx.org/trac/changeset/41227
>>
>> Log:
>> Name current bg translator
>>
>> (fixed in the po itself as well)
>
> I was about to post about that. Is it worth to check other translators?
> Riki, are your mail adresses used to warn about translation deadlines
> up to date?

I intend to extract them from the po files before sending out the notice
this weekend.

Riki

LyX 2.3.3 Error with iCloud Folders

[Richard Kimberly Heck]

 Forwarded Message 
Subject:[ANNOUNCE] LyX 2.3.3
Date:   Mon, 1 Jul 2019 16:44:12 -0500
From:   Mauricio Andrade 
To: rikih...@lyx.org



After updating to 2.3.3 I no longer can compile files on iCloud folders
that have paths like

 ~/Library/Mobile Documents/com~apple~CloudDocs/

I get this error several times with a minimal file (only title and a
line of text):

! LaTeX Error: Missing \begin{document}.

I’ll go back to 2.3.2 in the meanwhile.

Thank you

—
Mauricio Andrade

Test

[Richard Kimberly Heck]

Just making sure the lists are still functional

Riki

Re: Lyx v 2.3.X - severe Problems

[Richard Kimberly Heck]

On 8/19/19 2:41 PM, Matthias Görlach wrote:
>  
>> To check another thing: there is an automatic upgrade in configure run.
>> Perhaps it copies some problematic contents from your 2.2 installation.
>> To circumvent this you may try these commands (no sudo please):
>> $ mkdir /tmp/LyX
>> $ cd /tmp/LyX
>> $ python -tt /Applications/LyX.app/Contents/Resources/configure.py 
>> --binary-dir=/Applications/LyX.app/Contents/MacOS/
> My result (and config.log attached here)
> ls -ltr
> total 1088
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 ui
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 templates
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 scripts
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 layouts
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 kbd
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 images
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 examples
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 doc
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 clipart
> -rw-r--r--  1 mago  staff  99 Aug 19 20:30 chklatex.ltx
> -rw-r--r--  1 mago  staff 664 Aug 19 20:30 chklatex.log
> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 bind
> -rw-r--r--  1 mago  staff   19973 Aug 19 20:30 lyxrc.defaults
> -rw-r--r--  1 mago  staff   36766 Aug 19 20:30 clsFiles.lst
> -rw-r--r--  1 mago  staff  365181 Aug 19 20:30 styFiles.lst
> -rw-r--r--  1 mago  staff   26300 Aug 19 20:30 bstFiles.lst
> -rw-r--r--  1 mago  staff    4449 Aug 19 20:30 bibFiles.lst
> -rw-r--r--  1 mago  staff 293 Aug 19 20:30 lyxmodules.lst
> -rw-r--r--  1 mago  staff   37133 Aug 19 20:30 configure.log
> -rw-r--r--  1 mago  staff  26 Aug 19 20:30 chkmodules.tex
> -rw-r--r--  1 mago  staff   15685 Aug 19 20:30 cbxFiles.lst
> -rw-r--r--  1 mago  staff   17136 Aug 19 20:30 bbxFiles.lst

The configure script looks to be crashing when it tries to process the
first module file. The fact that chklatex.ltx and chkmodules.txt have
not been removed indicate that, as does the suspiciously small size of
your chkmodules.tex.

Can you run the command Stephan gave you from the terminal again, but
this time copy and paste the end of the output? I'm wondering whether
Python itself is issuing some kind of error message.

Can you also check the python version you are using? Run python --version.

I've just seen that I'm getting a crash with python 3.7.4, though a bit
later than you are:

+checking list of textclasses...
Traceback (most recent call last):
  File "/usr/local/share/lyx/configure.py", line 1896, in 
    ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1379, in checkLatexConfig
    retval = processLayoutFile(file, bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1327, in processLayoutFile
    % (classname, opt, desc, avai, prereq))
TypeError: %b requires a bytes-like object, or an object that implements
__bytes__, not 'str'

Riki

PS CC'ing lyx-devel now, and José.

configure.py crashing with Python 3 [was: LyX v 2.3.x - severe Problems]

[Richard Kimberly Heck]

On 8/19/19 4:16 PM, Matthias Görlach wrote:
> Hi,
>
> see below
>
> On 19.08.19 22:02, Richard Kimberly Heck wrote:
>> On 8/19/19 2:41 PM, Matthias Görlach wrote:
>>>  
>>>> To check another thing: there is an automatic upgrade in configure run.
>>>> Perhaps it copies some problematic contents from your 2.2 installation.
>>>> To circumvent this you may try these commands (no sudo please):
>>>> $ mkdir /tmp/LyX
>>>> $ cd /tmp/LyX
>>>> $ python -tt /Applications/LyX.app/Contents/Resources/configure.py 
>>>> --binary-dir=/Applications/LyX.app/Contents/MacOS/
>>> My result (and config.log attached here)
>>> ls -ltr
>>> total 1088
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 ui
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 templates
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 scripts
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 layouts
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 kbd
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 images
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 examples
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 doc
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 clipart
>>> -rw-r--r--  1 mago  staff  99 Aug 19 20:30 chklatex.ltx
>>> -rw-r--r--  1 mago  staff 664 Aug 19 20:30 chklatex.log
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 bind
>>> -rw-r--r--  1 mago  staff   19973 Aug 19 20:30 lyxrc.defaults
>>> -rw-r--r--  1 mago  staff   36766 Aug 19 20:30 clsFiles.lst
>>> -rw-r--r--  1 mago  staff  365181 Aug 19 20:30 styFiles.lst
>>> -rw-r--r--  1 mago  staff   26300 Aug 19 20:30 bstFiles.lst
>>> -rw-r--r--  1 mago  staff    4449 Aug 19 20:30 bibFiles.lst
>>> -rw-r--r--  1 mago  staff 293 Aug 19 20:30 lyxmodules.lst
>>> -rw-r--r--  1 mago  staff   37133 Aug 19 20:30 configure.log
>>> -rw-r--r--  1 mago  staff  26 Aug 19 20:30 chkmodules.tex
>>> -rw-r--r--  1 mago  staff   15685 Aug 19 20:30 cbxFiles.lst
>>> -rw-r--r--  1 mago  staff   17136 Aug 19 20:30 bbxFiles.lst
>>
>> The configure script looks to be crashing when it tries to process
>> the first module file. The fact that chklatex.ltx and chkmodules.txt
>> have not been removed indicate that, as does the suspiciously small
>> size of your chkmodules.tex.
>>
>> Can you run the command Stephan gave you from the terminal again, but
>> this time copy and paste the end of the output? I'm wondering whether
>> Python itself is issuing some kind of error message.
>>
> +checking list of modules...
> /Applications/LyX.app/Contents/Resources/layouts/algorithm2e.module
> Traceback (most recent call last):
>   File "/Applications/LyX.app/Contents/Resources/configure.py", line
> 1892, in 
>     checkModulesConfig()
>   File "/Applications/LyX.app/Contents/Resources/configure.py", line
> 1511, in checkModulesConfig
>     retval = processModuleFile(file, filename.encode('ascii'),
> bool_docbook)
>   File "/Applications/LyX.app/Contents/Resources/configure.py", line
> 1607, in processModuleFile
>     % (modname, filename, desc, pkgs, req, excl, catgy))
> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'

Yes, well, there's the crash.

This particular line is from 576b94138. Jürgen?


>> Can you also check the python version you are using? Run python
>> --version.
>>
> Python 3.3.7

Mostly, the point is that it's Python 3, though maybe the problem is
specific to this version. As I said, though, I'm seeing a crash here
with 3.7.4 that looks similar:

Traceback (most recent call last):
  File "/usr/local/share/lyx/configure.py", line 1896, in 
    ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1379, in checkLatexConfig
    retval = processLayoutFile(file, bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1327, in processLayoutFile
    % (classname, opt, desc, avai, prereq))
TypeError: %b requires a bytes-like object, or an object that implements
__bytes__, not 'str'

Mine comes from the same commit.

Riki

Re: [LyX/master] As observed on users list it's hard to guess where to setup external editor.

[Richard Kimberly Heck]

Fine to backport this if you wish.

On 8/16/19 5:30 PM, Pavel Sanda wrote:
> commit 58cf1c5345104cb3071bf6788f65e4fae07ac749
> Author: Pavel Sanda 
> Date:   Fri Aug 16 23:01:34 2019 +0200
>
> As observed on users list it's hard to guess where to setup external 
> editor.
> ---
>  src/frontends/qt/ui/LocalLayoutUi.ui |3 +++
>  src/frontends/qt/ui/PreambleUi.ui|3 +++
>  2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/src/frontends/qt/ui/LocalLayoutUi.ui 
> b/src/frontends/qt/ui/LocalLayoutUi.ui
> index abb29c5..fc753b7 100644
> --- a/src/frontends/qt/ui/LocalLayoutUi.ui
> +++ b/src/frontends/qt/ui/LocalLayoutUi.ui
> @@ -70,6 +70,9 @@
>   
>   
>
> +   
> +Editor for Latex (plain) format will be used
> +   
> 
>  Edit
> 
> diff --git a/src/frontends/qt/ui/PreambleUi.ui 
> b/src/frontends/qt/ui/PreambleUi.ui
> index 6c6b12e..8a7015c 100644
> --- a/src/frontends/qt/ui/PreambleUi.ui
> +++ b/src/frontends/qt/ui/PreambleUi.ui
> @@ -41,6 +41,9 @@
> 
> 
>  
> + 
> +  Editor for Latex (plain) format will be used
> + 
>   
>Edit
>   

Re: configure.py crashing with Python 3 [was: LyX v 2.3.x - severe Problems]

[Richard Kimberly Heck]

On 8/20/19 1:56 PM, Matthias Görlach wrote:
> Hi Riki,
>
> thank you for this analysis/hint - this was perfect for a "work around":
>
> 0) install python v 2.7.16 (well, will have to deal with things which
> require python 3.X)
> 1) deleted the LyX-2.3 directory (folder) from ~/Library/Application
> Support
> 2) mkdir of an empty Lyx-2.3 dir
> 3) cd into it
> 4) run python -tt
> /Applications/LyX.app/Contents/Resources/configure.py
> --with-version-suffix=-2.3
> --binary-dir=/Applications/LyX.app/Contents/MacOS/
> ==> 5) last lines of terminal output:
> ...
> +checking for package natbib [natbib]... yes
> +Inspection done.
> +Read the file doc/LaTeXConfig.lyx for more information.
>
>
> 6) low & behold: starting LyX 2.3 works fine - no error messages
> anymore (and my templates work again)
>
> Of course it will be better to eventually have LyX 2.3 working with
> the more recent python.

Thanks for confirming that this solves the problem. But yes, LyX is
supposed to work with Python 3, and obviously it does not at the moment.

We'll certainly want to test whatever changes we eventually make to
configure.py. I have created a bug report for this here:

https://www.lyx.org/trac/ticket/11642

If you add yourself (you may have to create an account) in the cc list,
you'll be notified as there are updates. It will be possible to test
this, simply by downloading the new configure.py script and running it
the same way.

Riki

Re: Missing lyxeditor.cmd?

[Richard Kimberly Heck]

On 8/22/19 12:06 PM, Christopher Menzel wrote:
> On 22 Aug 2019, at 10:39 AM, Richard Kimberly Heck  wrote:
>> On 8/22/19 10:48 AM, Chris Menzel wrote:
>>> 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?
>> 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.


>> 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.

Riki

Re: Missing lyxeditor.cmd?

[Richard Kimberly Heck]

On 8/22/19 10:48 AM, Chris Menzel wrote:
> 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?

We don't distribute this file. According to this page of the wiki:

    https://wiki.lyx.org/LyX/SyncTeX

it's something you need to create yourself. If you do a web search for
"lyxeditor.cmd", you'll find some other info along the same lines.

Riki

Re: Note formatting bug?

[Richard Kimberly Heck]

On 8/23/19 12:56 AM, Daniel wrote:
> On 2019-08-23 02:37, Daniel wrote:
>> On 23/8/19 0:13, Richard Kimberly Heck wrote:
>>> On 8/22/19 2:47 PM, Daniel wrote:
>>>> On 2019-08-22 19:42, Paul A. Rubin wrote:
>>>>> On 8/22/19 1:26 PM, Daniel wrote:
>>>>>> Could someone please test the following with the attached document:
>>>>>> 1. Open it
>>>>>> 2. Select all text
>>>>>> 3. Insert LyX note
>>>>>>
>>>>>> For me all text becomes formatted like a section heading. But bot
>>>>>> so if I first create the note and then paste the content into it
>>>>>> which seems strange.
>>>>>>
>>>>>> Daniel
>>>>> Same here (LyX 2.3.3).
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>> Thanks for checking. The problem seems to be that the LyX note uses
>>>> the "Plain Layout" (rather than "Standard" layout) which inherits
>>>> the layout of the paragraph the inset is placed in. I am not sure
>>>> there is currently a way to fix this.
>>>
>>> Note that the first line is section* and the second line is plain.
>>> As they were, except for the switch from standard.
>>>
>>> By default, insets do inherit the font from their parents. But you
>>> can change this:
>>>
>>> InsetLayout Note:Note
>>>
>>> Font
>>>
>>> Size normal
>>>
>>> Shape up
>>>
>>> Series medium
>>>
>>> EndFont
>>>
>>> End
>>>
>>> I would have expected
>>>
>>> InsetLayout Note:Note
>>>
>>> ResetsFont true
>>>
>>> End
>>>
>>> to work, but it does not seem to.
>>>
>>> Riki
>>>
>>
>> Thanks. Same here. Adding the first approach to my user dir. That
>> actually solves an annoying behavior.
>>
>> Daniel
>
> Patching the note inset makes working with them so much nicer! Should
> I file a report?

I think maybe I'd just start another thread explicitly about that topic.
I'm still puzzled about ResetsFont, too.

Riki

Re: Note formatting bug?

[Richard Kimberly Heck]

On 8/22/19 6:11 PM, Enrico Forestieri wrote:
> On Thu, Aug 22, 2019 at 08:47:43PM +0200, Daniel wrote:
>> On 2019-08-22 19:42, Paul A. Rubin wrote:
>>> On 8/22/19 1:26 PM, Daniel wrote:
 Could someone please test the following with the attached document:
 1. Open it
 2. Select all text
 3. Insert LyX note

 For me all text becomes formatted like a section heading. But bot so
 if I first create the note and then paste the content into it which
 seems strange.

 Daniel
>>> Same here (LyX 2.3.3).
>>>
>>> Paul
>>>
>>>
>> Thanks for checking. The problem seems to be that the LyX note uses the
>> "Plain Layout" (rather than "Standard" layout) which inherits the layout of
>> the paragraph the inset is placed in. I am not sure there is currently a way
>> to fix this.
> Insert an ampty ERT before the section. Put everything (including the ERT)
> into a LyX note. Now remove the empty ERT. See attached, where the previous
> three steps are illustrated.

This trick resets the outer layout to standard. But I think the issue
was that notes have the big font if they're in headings. I've always
found that wrong.

Riki

Re: Note formatting bug?

[Richard Kimberly Heck]

On 8/22/19 2:47 PM, Daniel wrote:
> On 2019-08-22 19:42, Paul A. Rubin wrote:
>> On 8/22/19 1:26 PM, Daniel wrote:
>>> Could someone please test the following with the attached document:
>>> 1. Open it
>>> 2. Select all text
>>> 3. Insert LyX note
>>>
>>> For me all text becomes formatted like a section heading. But bot so
>>> if I first create the note and then paste the content into it which
>>> seems strange.
>>>
>>> Daniel
>> Same here (LyX 2.3.3).
>>
>> Paul
>>
>>
> Thanks for checking. The problem seems to be that the LyX note uses
> the "Plain Layout" (rather than "Standard" layout) which inherits the
> layout of the paragraph the inset is placed in. I am not sure there is
> currently a way to fix this.

Note that the first line is section* and the second line is plain. As
they were, except for the switch from standard.

By default, insets do inherit the font from their parents. But you can
change this:

InsetLayout Note:Note

Font

Size normal

Shape up

Series medium

EndFont

End

I would have expected

InsetLayout Note:Note

ResetsFont true

End

to work, but it does not seem to.

Riki

Re: Note formatting bug?

[Richard Kimberly Heck]

On 8/22/19 7:38 PM, Scott Kostyshak wrote:
> On Thu, Aug 22, 2019 at 06:15:00PM -0400, Richard Kimberly Heck wrote:
>
>> This trick resets the outer layout to standard. But I think the issue
>> was that notes have the big font if they're in headings. I've always
>> found that wrong.
> I also have found it annoying.

Why doesn't ResetsFont work here? Should it? Or does it do something
else, say, indicate something about the LaTeX output?

Riki

Re: Notes inherit surrounding font

[Richard Kimberly Heck]

On 9/4/19 10:30 AM, Jean-Marc Lasgouttes wrote:
> Le 24/08/2019 à 07:49, Daniel a écrit :
>> Currently, IMO, notes behave in an unfortunate way in that they
>> inherit the surrounding font.
>>
>> Consider the attached document which has the following structure:
>>
>> *Section*
>> Text
>>
>> The first line is formatted as a section heading and the second as
>> standard text.
>>
>> In Lyx, select all text in the document and insert a note.
>>
>> The actual result is that all the text looks as if it where formatted
>> as section. This is misleading. It is also in many cases annoying.
>> For example, when adding a longer note to a section heading it
>> becomes huge.
>
> This is not misleading. 

I don't know if it's misleading, but I find it slightly annoying that
the font of the note is so huge. I might want a note in a non-empty
section heading to remind me of something, but I don't need it to be the
same size as the heading itself. There's no real need for it to be, either.

Riki

Re: [LyX/master] Follow some of the performance advice from cppcheck

[Richard Kimberly Heck]

On 9/13/19 11:09 AM, Jean-Marc Lasgouttes wrote:
> Le 13 septembre 2019 16:15:52 GMT+02:00, Jean-Marc Lasgouttes 
>  a écrit :
>> commit 714113655ad434f9a73d0101038568d59311af72
>> Author: Jean-Marc Lasgouttes 
>> Date:   Fri Sep 13 16:23:49 2019 +0200
>>
>>Follow some of the performance advice from cppcheck
>>
>>Most of that is changing string to string const &.
> There are 3 warnings that I did not fix in BiblioInfo.cpp about passing a 
> BiblioInfoList array by value.
>
> I figured I can ask first : is there a reason for copying the array or is it 
> an oversight?

Looking at git blame, it definitely looks like just an oversight. I
can't see any reason for it not to be a const ref. I've fixed it.

Riki

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

[Richard Kimberly Heck]

On 9/12/19 4:04 AM, Jean-Marc Lasgouttes wrote:
> Le 12/09/2019 à 01:38, Pavel Sanda a écrit :
>> I like this patch. Is it safe to put it into my personal 2.3 patchset
>> (in the terms of the patch being congruent with old 2.3 codebase
>> or way too many changes were done around in 2.4?)
>
> I like the patch too, and I checked that it applies almost cleanly
> (barring some indentation issues). I am going to work a bit with LyX
> 2.3 in the coming months and having it would be good (although working
> with master would be more fun).
>
> However, I am wary that there are workflows that I did not consider in
> the patch. This happened to me when I streamlined DEPM.
>
> But if there is a consensus about 2.3, I am OK with it.

The basic idea seems correct. I've played around with this before, too.
I haven't tested, but one question that arose when I was dealing with
this was with lists and depth issues.

In any event, this seems to be a big enough change to hold it for 2.4.0
(which we're supposed to be moving towards, right?). I'm intending to
get 2.2.4 under way in a week or so, once things calm down here a bit.
We could push to 2.3.x after that, so that it got tested, and it could
then appear in 2.3.5, whether that is the last release or not.

Riki

Re: Possible bug found by cppcheck

[Richard Kimberly Heck]

On 9/13/19 1:09 PM, Jean-Marc Lasgouttes wrote:
> In DocFileNamefilename::mangledFileName, I see:
>
> string const name = absFileName();
> // Now the real work
> string mname = os::internal_path(name);
> // Remove the extension.
> mname = support::changeExtension(name, string());
>
> So the assignment of internal_path is undone. Did we need it or not?

Probably it was intended, but I am guessing we do not see a bug because
it ends up not mattering. The "internal path" is a no-op on Unix and
just replaces \ with / on Windows. But those characters get removed by
the mangling algorithm anyway. In principle, then, it should be

    mname = support::changeExtension(mname, string());

but it won't change anything really.

Riki

Re: Stable-Only Branch Related Bug

[Richard Kimberly Heck]

On 9/16/19 3:27 PM, Pavel Sanda wrote:
> On Sun, Sep 15, 2019 at 08:20:48PM -0400, Richard Kimberly Heck wrote:
>> The attached file illustrates the bug: If we have a branch inset, then
>> it seems always to be followed by a \selectlanguage command, followed
>> then by a newline. This inserts unwanted space on export to PDF.
> Is it against the most recent version of branch?
> I was bitten by it in older checkouts but not now.

Yes, this seems to have been #11616.

Riki

Stable-Only Branch Related Bug

[Richard Kimberly Heck]

The attached file illustrates the bug: If we have a branch inset, then
it seems always to be followed by a \selectlanguage command, followed
then by a newline. This inserts unwanted space on export to PDF.

The bug does not seem to be in master.

Riki




branch_bug.lyx
Description: application/lyx

Re: Notes inherit surrounding font

[Richard Kimberly Heck]

On 9/6/19 11:48 AM, Daniel wrote:
> On 5/9/19 13:46, Jean-Marc Lasgouttes wrote:
>> Le 05/09/2019 à 06:54, Daniel a écrit :
>>> Can't test currently and I am not sure I understand correctly what
>>> the patch does. But as far as I do, I don't think I like it. If I
>>> understood you correctly, I can replicate the behavior of the patch
>>> in stable LyX by inserting the inset and setting the surrounding
>>> paragraph to Standard. But this is not intended in some cases. For
>>> example, in order to keep description labels together, I use a label
>>> inset that does nothing but surround the containing content with
>>> brackets {}. So, set a paragraph to Description, enter the label
>>> text, mark it and insert the label inset. But with your patch this
>>> will reset the description to plain, right?
>>
>> This is exact, but note that the behavior will not happen if you
>> insert your magic inset first and type into it afterwards. Moreover,
>> the patch will be tweaked to not touch layouts if the collapsible
>> inset forces plain layout, which I guess your label inset does (it
>> should anyway).
>>
>> So my position is
>> 1/ I am OK with a patch which changes the default font of note insets
>>
>> 2/ BUT we should be aware that this will hide a real bug (and not a
>> mere annoyance) that is that the layout surrounding the inset in your
>> example at the top of this thread should not be there. We should be
>> grateful for the inset to tell us that, not propose to shot the
>> messenger ;)
>>
>> So I would like to go forward with some changes of how layouts are
>> set/transferred when inserting insets, regardless of the cosmetic
>> changes in display.
> I am not convinced yet that changing the surrounding layout is the
> right thing to do.
>
> First, it seems good to get the same effect independent of the order
> of inserting inset and setting layout.
>
> Second, aren't there cases where one wants to have an inset embedded
> in a non-standard layout? If so, the user might have to reset the
> layout even if it was set as desired before inserting the inset.

I think there's some confusion about the issues here.

The 'surrounding layout' problem is actually more general. Suppose you
have a section, with header and associated text. Select the whole thing
and make it a branch. It will not do what you want. We really do need to
change the 'outside' layout in this case. (I think there might be a bug
about this, and I have done some work on the problem.)

The other issue is the font displayed within notes. JMarc is worried
about the case where the note is the only thing in the section heading
(say). I think you and I are more worried about the case where there are
other things in the section heading, but the font of the note ends up
looking too big. I see JMarc's point: There's no visual indication in
the text that we're in a section. But I also see our point: I want to
put notes in section headings sometimes, and it's annoying that they are
so huge.

Riki


>
> Daniel
>

Re: [LyX/master] Reset layout when inserting an inset over full paragraph(s)

[Richard Kimberly Heck]

On 9/12/19 3:43 PM, Jean-Marc Lasgouttes wrote:
> Le 12/09/2019 à 20:54, Richard Kimberly Heck a écrit :
>>> But if there is a consensus about 2.3, I am OK with it.
>>
>> The basic idea seems correct. I've played around with this before, too.
>> I haven't tested, but one question that arose when I was dealing with
>> this was with lists and depth issues.
>
> One thing that changes with the patch is that I condition on
> forcePlainLayout instead of allowMultiPar, because it seems to be the
> correct condition (and allowMultipar implies forcePlainLayout by
> default).
>
> I also removed some code that I believe to duplicate what is done in
> pasteSelectionHelper.
>
> I have no idea about depth issues, this is typically something I could
> have overlooked.
>
>> In any event, this seems to be a big enough change to hold it for 2.4.0
>> (which we're supposed to be moving towards, right?). 
>
> I take this as a subtle nudge in my direction. It is well deserved :)

No, not at all. I'd actually forgotten you'd taken that on. Scott has
been around again...


>
>> I'm intending to
>> get 2.2.4 under way in a week or so, once things calm down here a bit.
>> We could push to 2.3.x after that, so that it got tested, and it could
>> then appear in 2.3.5, whether that is the last release or not.
>
> I am not sure that we want to have a change we are not sure about in
> our last 2.3 release.
>
> We are sorely lacking daily builds for stable releases. If we knew how
> to automate these, that could be done by our CI tools. I have taken a
> look at the Ubuntu side of things, and ran away screaming. I do not
> have the time to invest in even understanding this thing. And daily
> build is one order of magnitude more difficulty. How can we find
> people who know how to get this up and running, at least when daily
> builds do not require manual intervention (we can afford some
> imperfectness here)?

I take it you mean daily builds of RPMs or something of the sort? Or do
you mean something else? If it's just the tarball we want, then that
ought to be quite easy.

Riki

Re: Renaming frontends/qt4 to frontends/qt ?

[Richard Kimberly Heck]

On 7/20/19 1:01 AM, Jürgen Spitzmüller wrote:
> Am Freitag, den 19.07.2019, 21:19 +0200 schrieb Jean-Marc Lasgouttes:
>> It is more and more absurd to have a front end named qt4 these days. 
>> What about renaming everything qt? It looks like a good idea before 
>> release to ease backport. Note that It might be that I am wrong, and 
>> that git is able to follow this quite well.
> Fine with me. I think git cherry-pick should be able to follow such
> changes (I was impressed recently to see that it considered a file
> rename in master when backporting to stable).

I think that would be fine and, potentially, save some hassle.

Riki

Re: Insert -> Field Questions / Comments

[Richard Kimberly Heck]

On 7/22/19 5:12 PM, Pavel Sanda wrote:
> On Sun, Jul 14, 2019 at 11:28:28PM -0600, Joel Kulesza wrote:
>> LyX Developers (Jürgen in particular):
>>
>> A few questions on the Insert -> Field capability with respect to version
>> control:
>>
>>1. When git hashes (i.e. VCS Revisions) are entered, I see that they are
>>updated when the underlying revision is updated.  This generally delights
>>me.  However, what governs this update logic timing (when the document is
>>opened, at some interval, etc.)?  Is there an indication to the user that
>>this part of the document has changed?  If not, should there be?
> Without looking at the code IIRC it updates at each document (re)load (that
> includes git commits via lyx gui).

I could be wrong, but it looks to be re-calculated each time through
updateBuffer (which would include reloads). Which, Joel, would mean it
is reset very often. Not on every keystroke, but almost that often.

The user should just expect these auto-calculated things to update, uh,
automatically, it seems to me.

Riki

Re: Why increase pref format when adding a new pref?

[Richard Kimberly Heck]

On 7/22/19 7:08 PM, Pavel Sanda wrote:
> On Mon, Jul 22, 2019 at 03:56:34PM +0200, Jean-Marc Lasgouttes wrote:
>> Le 20/07/2019 ?? 07:03, Jürgen Spitzmüller a écrit :
>>> Am Freitag, den 19.07.2019, 22:03 +0200 schrieb Jean-Marc Lasgouttes:
 I do not see the point of doing that, so I want to know what I miss.
>>> AFAIU the point is just to increase the version number to let older
>>> versions on LyX know that these prefs are not for them (otherwise they
>>> will complain about unknown prefs).
>> So it is the same when I introduce a new lfun? Just for the pleasure of 
>> breaking compatibility? I am not sure it is useful, since anyway what our 
>> user see is the jump between stable releases versions.
> I think you are right that increasing pref version make sense only for cases
> like renaming or deleting lfuns, where pref2pref conversion routines
> have some reasonable stuff to do (rename or delete lfuns within existing 
> prefs).

This was originally modeled on what we do for layouts, e.g. It is not
clear to me if there is a difference there or not. I'm guessing that
e.g. LyX 2.2 could choke badly if handed a 2.3 file, even if the only
changes were of this kind.

Riki

Re: Insert -> Field Questions / Comments

[Richard Kimberly Heck]

On 7/23/19 10:52 AM, Joel Kulesza wrote:
>
>
> On Mon, Jul 22, 2019 at 9:17 PM Richard Kimberly Heck
> mailto:rikih...@lyx.org>> wrote:
>
> On 7/22/19 5:12 PM, Pavel Sanda wrote:
> > On Sun, Jul 14, 2019 at 11:28:28PM -0600, Joel Kulesza wrote:
> >> LyX Developers (Jürgen in particular):
> >>
> >> A few questions on the Insert -> Field capability with respect
> to version
> >> control:
> >>
> >>    1. When git hashes (i.e. VCS Revisions) are entered, I see
> that they are
> >>    updated when the underlying revision is updated.  This
> generally delights
> >>    me.  However, what governs this update logic timing (when
> the document is
> >>    opened, at some interval, etc.)?  Is there an indication to
> the user that
> >>    this part of the document has changed?  If not, should there be?
> > Without looking at the code IIRC it updates at each document
> (re)load (that
> > includes git commits via lyx gui).
>
> I could be wrong, but it looks to be re-calculated each time through
> updateBuffer (which would include reloads). Which, Joel, would mean it
> is reset very often. Not on every keystroke, but almost that often.
>
> The user should just expect these auto-calculated things to
> update, uh,
> automatically, it seems to me.
>
>
> That is good news for my purpose.  Further, do we know if it is
> recalculated when rendered to PDF via command line? I hope so and will
> test later unless someone knows for sure...

Sorry, Pavel is right in his other message: This only gets re-calculated
when the document is reloaded, at least for git. I did not dig deeply
enough into the code to see where it is cached. So, in that sense, the
inset reports the revision on which the document is based. If the file
on disk were changed externally, then I think you'd get a warning about
that, and ask you to reload, or whatever.

In any event, this is calculated, fresh, if the document is exported via
the command line.

Riki

Re: Reconfiguring

[Richard Kimberly Heck]

On 7/15/19 5:38 PM, Jean-Marc Lasgouttes wrote:
> Le 15/07/2019 à 14:59, Daniel a écrit :
>> On 26/6/19 6:56, Andrew Parsloe wrote:
>>> Previously, when reconfiguring, some indication of progress has been
>>> displayed in the status line. With 2.3.3 under windows 10, there is
>>> no status line indication, in fact no indication whatever until I
>>> click on LyX when the operating system's rotating circle is
>>> displayed. This was momentarily disconcerting for me but could be a
>>> good deal more so for one of Uwe's "newbies".
>>>
>>> Andrew
>>
>> I see this too. Seems like LyX is becoming unresponsive during
>> reconfigure and hence does not update the status bar.
>
> The same happens in Linux, as I see it.

Weird. Confirmed. Also seems to be in master.

I'll try bisecting. (I have a bad fear this is my fault.)

Riki

Re: Reconfiguring

[Richard Kimberly Heck]

On 7/15/19 9:46 PM, Richard Kimberly Heck wrote:
> On 7/15/19 5:38 PM, Jean-Marc Lasgouttes wrote:
>> Le 15/07/2019 à 14:59, Daniel a écrit :
>>> On 26/6/19 6:56, Andrew Parsloe wrote:
>>>> Previously, when reconfiguring, some indication of progress has been
>>>> displayed in the status line. With 2.3.3 under windows 10, there is
>>>> no status line indication, in fact no indication whatever until I
>>>> click on LyX when the operating system's rotating circle is
>>>> displayed. This was momentarily disconcerting for me but could be a
>>>> good deal more so for one of Uwe's "newbies".
>>>>
>>>> Andrew
>>> I see this too. Seems like LyX is becoming unresponsive during
>>> reconfigure and hence does not update the status bar.
>> The same happens in Linux, as I see it.
> Weird. Confirmed. Also seems to be in master.
>
> I'll try bisecting. (I have a bad fear this is my fault.)

I'm seeing the same problem all the way back to 2.3.1. I can't compile
2.3.0 right now, due to an error involving QButtonGroup. Weird none of
us noticed it before

Riki

Re: Crash in mathed with aligned in align

[Richard Kimberly Heck]

On 7/26/19 12:46 AM, Daniel wrote:
> On 2019-07-25 23:40, Andrew Parsloe wrote:
>> I can create a crash by trying to delete the final column in the
>> following construction:
>>
>>
>> \begin{align*}
>>
>> \begin{aligned}\end{aligned}
>>
>> \\
>>
>> \end{align*}
>>
>>
>> To create:
>>
>>
>> 1. Ctrl+Shift+M to create a display math equation.
>>
>> 2. Ctrl+Return to create an align* environment
>>
>> 3. Insert > Math > Aligned Environment in the first (top left) cell
>>
>> 4 Move cursor to the top right cell
>>
>> 5. Try to delete this column
>>
>> 6. Crash. LyX reports " LyX Code: 89 name: mathsplit"
>>
>>
>> If the aligned environment is placed in the second (top right) cell,
>> trying to delete the first column causes the crash. Deleting the
>> column containing the aligned environment does not crash LyX.
>>
>>
>> There's no data loss. LyX manages to create an emergency file.
>>
>>
>> Andrew
>>
>
> I can reproduce. It doesn't crash LyX but only the active document.
> The deletion of the column seems to be the culprit because it is
> possible to delete the other row and also to delete the other column
> (and row) first and then insert the Aligned.

Someone please file a bug, component mathed.

Riki

Re: [LyX/master] Do not issue error dialog when no tag is found in git repo for tree-revision info.

[Richard Kimberly Heck]

On 7/25/19 8:22 AM, Pavel Sanda wrote:
> commit eceed02a90b3de41c0a8cfcd7ef2d859e9638993
> Author: Pavel Sanda 
> Date:   Thu Jul 25 14:31:20 2019 +0200
>
> Do not issue error dialog when no tag is found in git repo for 
> tree-revision info.
> 
> Reported by Joel Kulesza.
> 
> Candidate for branch.

OK.

Riki

Re: Proposal for UI enhancement: ticket #1624

[Richard Kimberly Heck]

Sorry to top post, but since this isn't a response to anything
particular

I do still have some worries of the sort I expressed at
https://www.lyx.org/trac/ticket/1624#comment:11. A label for a section
really shouldn't be in the section heading itself, from a LaTeX point of
view, though it's natural to put it there in LyX. There's been some
discussion of automatically moving such labels to right after the
\section command. But, now, many users don't put them in the heading, so
as not to generate bad LaTeX. Maybe they put labels at the beginning of
the first sentence. So it's hard to tell what's meant to be a 'section'
label. Possibly we could use the prefix to determine this ("sec:" in
this case), though any such algorithm will be error-prone. So it's not
that easy to tell if a section 'already' has a label.

Contradicting my former self, I think it would be best to skip this sort
of check and just have some mechanism through which one could "create a
label" for some pre-existing section, etc, which would be automatically
inserted at an appropriate point, and return you to the cross-ref dialog
with that reference pre-selected. That does make me wonder, along with
my former self, whether a clean way to do it would not be just to add
this "Create label..." functionality to the outliner, and add a button
to the cross-ref dialog that would, in effect, open the outliner, or put
the focus there if it already is open. The dialog, after all, will need
to look very similar. At the very least, though, you can get a list of
the sections, etc, that exist from the outliner backend.

Riki



On 9/29/19 7:34 AM, Andreas Nicolai wrote:
> Hi Scott,
>
> thanks for your ideas, let me comment below.
>>> I would like to contribute an improvement on this workflow:
>>> 1. Button and sub-dialog approach:
>>> - add a button on the dialog "Create label"
>>> - sub-dialog opens and allows selecting existing
>>> sections/subections/images/tables in a tree-view or filtered list-view
>>> (with combo-box filter)
>>> - if a label exists for this section -> close dialog using button
>>> "Select label"
>> It feels like there's an inconsistency here. At this point, the user has
>> clicked on "Create label". But for this situation (the label already
>> exists), there is no label that is created. I wonder if "Cancel" would
>> be the correct choice by the user if they want to use a label that's
>> already been created. Alternatively, perhaps my concern would be
>> addressed by renaming "Create label" to something else (I don't
>> currently have a suggestion).
> Indeed, "create label" might be misleading. Actually, the button spawns
> the regular "Insert label" Dialog (class GuiLabel). When confirmed, the
> user has effectively inserted a new label at the selected section/float.
> Maybe "Insert new label" or so might be better (actually, this modal
> "sub-dialog" variant isn't really my favourite).
>
>>> - in cross-reference dialog update list of labels and select newly
>>> created/selected label
>> Why do we need this step? i.e., why not directly insert the label just
>> created? I'm guessing it is because the user might want to change
>> something else in the cross-reference dialog, such as the "Reference
>> Format", but I just wanted to check that that's what you have in mind.
> Correct, that was my intention. After the label-selection normally one
> may adjust the reference format (actually, in my experience this happens
> only often when writing text with equation references and section/float
> references).
>
>
>>> 2. "switch selection list"-appraoch:
>>> This facilitates also the approach when users are not 100% sure which
>>> section to reference right now or when the choosen labels are not 100%
>>> clear in what they describe. In such cases the document structure and
>>> section captions can be a better way to select labels.
>>>
>>> Idea: the cross-reference dialog has two selection modes:
>>> a) as before, a groupable, filter-able list of existing labels
>>> b) a groupable list of all existing sections/subsections/images/tables,
>>> with highlighting (bold-face) for all list items that have already
>>> labels defined
>>>
>>> User can switch between both views via
>>> toggle-button/radio-button...Toolbox-Window..?
>> Interesting ideas! Just to be clear, instead of "images" I think you
>> mean "figure floats".
> Right. But in the tree view/list I would still distinguish between
> Graphics and Tables, since IMHO authors rather think in terms of
> Image-reference and table-references when writing text (such as "see
> Fig. \ref{fig:xxx}" or "in Table \ref{tab:xxx})".
>
>> And perhaps instead of "figures/tables" we can
>> generalize to "floats". I don't understand variant 2 well.
> Actually, variant 2 is pretty much what you would expect from a regular
> text processor. You (the author) type text where a reference might be
> needed/appropriate. For example: "This is the same as discussed already
> in section ". Now, you want to insert 

Re: Regression: Problem with Paths Containing ~ [Was Re: LyX 2.3.3 Error with iCloud Folders]

[Richard Kimberly Heck]

On 7/6/19 5:57 AM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 03.07.2019, 15:53 -0400 schrieb Richard Kimberly Heck:
>> Same problem. I've traced it to:
>>
>> \def\input@path{{/home/rikiheck/this~silly~dir/}}
>>
>> It appears to be that LaTeX itself has problems with such paths. If
>> we
>> add \detokenize:
>>
>> \def\input@path{{\detokenize{/home/rikiheck/this~silly~dir/}}}
>>
>> then it works.
>>
>> In 2.3.2, we get:
>>
>> \def\input@path{{/home/rikiheck/this\string~silly\string~dir/}}
> Note that the \string solution does not work any longer with recent
> LaTeX.
>
>> This seems to be a regression in ac351f40f1d1. We used to call
>> support::latex_path here, but now only call os::latex_path, and the
>> result is that ~ doesn't get '\string'd. I would guess that there may
>> be
>> similar problems with other characters that are handled there.
> \detokenize is only omitted for ASCII characters, so it seems
> worthwhile to handle just that special case (and add others if it turns
> out to be necessary).
>
> Like in the attached patch.

Fine by me.

Riki

2.3.4

[Richard Kimberly Heck]

Hi, all,

I know I've talked before about moving towards a 2.3.4 release, but
things have just been kind of crazy here. That said, I should have some
time for this now, and the Wayland bug seems to demand action. So: Are
there any lingering bugs we really need to fix? Especailly are there any
that would require string changes? I'd like to freeze strings and get
the email to translators this weekend, if possible, and we can hope for
an actual release around 1 December, possibly.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Exploitable Windows installation Lyx 2.3.3 ImageMagick 7.0.7-27

[Richard Kimberly Heck]

On 11/16/19 6:56 AM, Daniel wrote:
> On 15/11/19 18:27, Pavel Sanda wrote:
>> On Fri, Nov 15, 2019 at 10:29:37AM -0500, John wrote:
>>> Lyx for Windows installer 2.3.3-1 installs ImageMagick 7.0.7-27.  This
>>> version is subject to multiple buffer overflows (stack and heap) and
>>> several other vulnerabilities, allowing remote code execution if the
>>> user
>>> opens a LyX document incorporating a specially-crafted image.
>>>
>>> Solution:  Upgrade to ImageMagick 7.0.8-56 or newer in the LyX
>>> installer
>>> package.
>>
>> This is unfortunate consequence of windows packaging and it is true
>> in long term
>> that all bugs which are discovered in supporting packages (e.g.
>> imagemagick/
>> ghostscript) won't be quickly fixed. We unf do not have manpower to
>> issue new
>> installer just after next security bug appears in those packages.
>>
>> The good news is that 2.3.4 should be released rather soon with
>> hopefully
>> updated IM.
>>
>>
>> What just come to my mind - couldn't some windows 10 user actually
>> try to
>> use their brand new linux subsystem, and install LyX via this system?
>> If LyX was useful enough this way, we de facto solved packaging for
>> windows
>> and could replace our installation instructions on web.
>> The security updates will simply start flow through normal distro
>> channels
>> without burdening us.
>>
>> Pavel
>
>
> Just because some users might be able to do this doesn't mean that all
> LyX users on Windows are able to. Using Linux and, in particular, via
> the Linux Subsystem isn't something that comes easy for many Windows
> users. The Linux Subsystem seems more like a tool for administrators.

Longer term, this might work. Right now, this looks pretty cutting edge.
Who knows how long the Gods of Redmond will support it. I remember a
long time ago that Apple once allowed other manufacturers to install
their OS.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Exploitable Windows installation Lyx 2.3.3 ImageMagick 7.0.7-27

[Richard Kimberly Heck]

On 11/15/19 12:27 PM, Pavel Sanda wrote:
> On Fri, Nov 15, 2019 at 10:29:37AM -0500, John wrote:
>> Lyx for Windows installer 2.3.3-1 installs ImageMagick 7.0.7-27.  This
>> version is subject to multiple buffer overflows (stack and heap) and
>> several other vulnerabilities, allowing remote code execution if the user
>> opens a LyX document incorporating a specially-crafted image.
>>
>> Solution:  Upgrade to ImageMagick 7.0.8-56 or newer in the LyX installer
>> package.
> This is unfortunate consequence of windows packaging and it is true in long 
> term
> that all bugs which are discovered in supporting packages (e.g. imagemagick/
> ghostscript) won't be quickly fixed. We unf do not have manpower to issue new
> installer just after next security bug appears in those packages.
>
> The good news is that 2.3.4 should be released rather soon with hopefully
> updated IM.

I will figure out how to update IM when we release 2.3.4. It's largely
because I haven't had time to do that that I haven't done it.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Stable Branch String Freeze

[Richard Kimberly Heck]

Strings are now frozen in stable branch.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Fix crash with polyglossia and intitle commands when lang_auto_end is false

[Richard Kimberly Heck]

On 11/21/19 2:46 AM, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 21.11.2019, 08:24 +0100 schrieb Juergen
> Spitzmueller:
>> commit ed44bc9b12c0385eccf9323159365ae96b1b4f19
>> Author: Juergen Spitzmueller 
>> Date:   Thu Nov 21 08:38:21 2019 +0100
>>
>> Fix crash with polyglossia and intitle commands when
>> lang_auto_end is false
>
> Riki, this should go to 2.3.4, if possible.

If it seems safe enough to you. No string changes here as far as I can tell?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/2.3.x] remerge cs.po

[Richard Kimberly Heck]

On 11/22/19 11:44 AM, Richard Kimberly Heck wrote:
> On 11/22/19 6:34 AM, Pavel Sanda wrote:
>> On Thu, Nov 21, 2019 at 03:31:06PM -0500, Richard Kimberly Heck wrote:
>>> On 11/21/19 11:01 AM, Pavel Sanda wrote:
>>>> On Thu, Nov 21, 2019 at 04:44:57PM +0100, Pavel Sanda wrote:
>>>>> commit ea88310517c78bc17d96c9326a171a0a0acd7175
>>>>> Author: Pavel Sanda 
>>>>> Date:   Thu Nov 21 16:59:34 2019 +0100
>>>>>
>>>>> remerge cs.po
>>>>>
>>>>>  po/cs.po | 1937 
>>>>> +++---
>>>>>  1 files changed, 975 insertions(+), 962 deletions(-)
>>>> Riki, it looks like that not all .po files were remerged, I see new 
>>>> untranslated string for cs.po...
>>> So I need to remerge again?
>> Yes, please try, I will check whether I get the same result after your 
>> fresh-most remerge.
> Done. It looks to me from the diff as if it's just statistics that
> changed. But let me know if that's wrong.

Actually, no, it looks as if there have been some space issues fixed
that didn't get picked up before. Should I send a note to translators again?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/2.3.x] remerge cs.po

[Richard Kimberly Heck]

On 11/22/19 6:34 AM, Pavel Sanda wrote:
> On Thu, Nov 21, 2019 at 03:31:06PM -0500, Richard Kimberly Heck wrote:
>> On 11/21/19 11:01 AM, Pavel Sanda wrote:
>>> On Thu, Nov 21, 2019 at 04:44:57PM +0100, Pavel Sanda wrote:
>>>> commit ea88310517c78bc17d96c9326a171a0a0acd7175
>>>> Author: Pavel Sanda 
>>>> Date:   Thu Nov 21 16:59:34 2019 +0100
>>>>
>>>> remerge cs.po
>>>>
>>>>  po/cs.po | 1937 
>>>> +++---
>>>>  1 files changed, 975 insertions(+), 962 deletions(-)
>>> Riki, it looks like that not all .po files were remerged, I see new 
>>> untranslated string for cs.po...
>> So I need to remerge again?
> Yes, please try, I will check whether I get the same result after your 
> fresh-most remerge.

Done. It looks to me from the diff as if it's just statistics that
changed. But let me know if that's wrong.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/2.3.x] remerge cs.po

[Richard Kimberly Heck]

On 11/21/19 11:01 AM, Pavel Sanda wrote:
> On Thu, Nov 21, 2019 at 04:44:57PM +0100, Pavel Sanda wrote:
>> commit ea88310517c78bc17d96c9326a171a0a0acd7175
>> Author: Pavel Sanda 
>> Date:   Thu Nov 21 16:59:34 2019 +0100
>>
>> remerge cs.po
>>
>>  po/cs.po | 1937 
>> +++---
>>  1 files changed, 975 insertions(+), 962 deletions(-)
> Riki, it looks like that not all .po files were remerged, I see new 
> untranslated string for cs.po...

So I need to remerge again?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [patch] Refresh previews on branch toggle?

[Richard Kimberly Heck]

On 12/8/19 9:20 PM, Scott Kostyshak wrote:
> Attached is a patch that refreshes previews whenever the user activates
> or deactivates a branch. The motivation for this patch is that if a
> child document is previewed in the master document, and if the child
> document has the branch inside it as well, the preview will be incorrect
> when the branch is toggled (without this patch).
>
> However, this patch will cause all previews to refresh. I'm concerned
> that the inefficiency is not worth the benefit. Any thoughts on this
> patch and any thoughts on an ideal solution? For example, would
> removePreviews() and updatePreviews() ideally have arguments that allow
> to specify which type of previews to update?

It makes sense to me.

Do we have to remove previews first?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Note inset can not be dissolved in table

[Richard Kimberly Heck]

On 12/6/19 7:27 AM, Pavel Sanda wrote:
> On Fri, Dec 06, 2019 at 09:55:46AM +0100, Jean-Marc Lasgouttes wrote:
>>> This patch seems to fix the issue.
>>> For not having better idea I take descendable() as a reasonable proxy for 
>>> insets
>>> in which dissolving inset makes sense.
>>>
>>> I'll commit to master unless someone has better idea.
>> Pavel, could you try latest master?
> I tested it and it works well now.

If this is needed in stable, please go ahead.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [patch] Refresh previews on branch toggle?

[Richard Kimberly Heck]

On 12/9/19 10:40 AM, Scott Kostyshak wrote:
> On Sun, Dec 08, 2019 at 11:03:20PM -0500, Richard Kimberly Heck wrote:
>> On 12/8/19 9:20 PM, Scott Kostyshak wrote:
>>> Attached is a patch that refreshes previews whenever the user activates
>>> or deactivates a branch. The motivation for this patch is that if a
>>> child document is previewed in the master document, and if the child
>>> document has the branch inside it as well, the preview will be incorrect
>>> when the branch is toggled (without this patch).
>>>
>>> However, this patch will cause all previews to refresh. I'm concerned
>>> that the inefficiency is not worth the benefit. Any thoughts on this
>>> patch and any thoughts on an ideal solution? For example, would
>>> removePreviews() and updatePreviews() ideally have arguments that allow
>>> to specify which type of previews to update?
>> It makes sense to me.
>>
>> Do we have to remove previews first?
> Good question. It doesn't work if I don't include that line, and it's
> consistent with Buffer::reload(). The following contains a clue for why
> I think it's needed (copied from RenderPreview.h):
>
>   /** Remove a snippet from the cache of previews.
>*  Useful if previewing the contents of a file that has changed.
>*/
>   void removePreview(Buffer const &);
>
> From the perspective of the master document, the LaTeX export
> corresponding to the child document has not changed (it is just
> \input{child.tex}). So if we only "update" the previews, I think that
> would only regenerate previews for insets where the LaTeX as viewed by
> the master document has changed.
>
> The patch does not actually call the function I reference above. It uses
> removePreviews() (note the extra 's'), which creates an entirely new
> previewLoader. Perhaps it would be more efficient to loop through the
> insets and call removePreview() on them (or only the ones that depend on
> a file?).

It probably doesn't matter very much, since all the regeneration happens
in the background.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Export Errors

[Richard Kimberly Heck]

I can't follow that thread. Is any of it relevant to the 2.3.x branch?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

CMake Build Problem

[Richard Kimberly Heck]

I'm getting a repeatable error when building the master branch of LyX
with cmake on Fedora 30. What I've done is:

./autogen.sh
mkdir build-cmake
cd build-cmake
cmake ..
make

Result:

[ 70%] Linking CXX executable ../bin/lyx2.4
cd /cvs/lyx/lyx-devel/build-cmake/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/lyx2.4.dir/link.txt --verbose=1
/usr/bin/c++  -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing 
-O0 -g3 -D_DEBUG -flto -fno-fat-lto-objects  -rdynamic
CMakeFiles/lyx2.4.dir/Author.cpp.o
CMakeFiles/lyx2.4.dir/BiblioInfo.cpp.o CMakeFiles/lyx2.4.dir/Box.cpp.o
CMakeFiles/lyx2.4.dir/BranchList.cpp.o
CMakeFiles/lyx2.4.dir/Buffer.cpp.o
CMakeFiles/lyx2.4.dir/BufferEncodings.cpp.o
CMakeFiles/lyx2.4.dir/BufferList.cpp.o
CMakeFiles/lyx2.4.dir/BufferParams.cpp.o
CMakeFiles/lyx2.4.dir/BufferView.cpp.o
CMakeFiles/lyx2.4.dir/Bullet.cpp.o CMakeFiles/lyx2.4.dir/Changes.cpp.o
CMakeFiles/lyx2.4.dir/Chktex.cpp.o
CMakeFiles/lyx2.4.dir/CiteEnginesList.cpp.o
CMakeFiles/lyx2.4.dir/CmdDef.cpp.o CMakeFiles/lyx2.4.dir/Color.cpp.o
CMakeFiles/lyx2.4.dir/Compare.cpp.o
CMakeFiles/lyx2.4.dir/Converter.cpp.o
CMakeFiles/lyx2.4.dir/ConverterCache.cpp.o
CMakeFiles/lyx2.4.dir/CoordCache.cpp.o
CMakeFiles/lyx2.4.dir/Counters.cpp.o CMakeFiles/lyx2.4.dir/Cursor.cpp.o
CMakeFiles/lyx2.4.dir/CursorSlice.cpp.o
CMakeFiles/lyx2.4.dir/CutAndPaste.cpp.o
CMakeFiles/lyx2.4.dir/DepTable.cpp.o
CMakeFiles/lyx2.4.dir/Dimension.cpp.o
CMakeFiles/lyx2.4.dir/DocIterator.cpp.o
CMakeFiles/lyx2.4.dir/Encoding.cpp.o
CMakeFiles/lyx2.4.dir/ErrorList.cpp.o
CMakeFiles/lyx2.4.dir/Exporter.cpp.o
CMakeFiles/lyx2.4.dir/FloatList.cpp.o
CMakeFiles/lyx2.4.dir/Floating.cpp.o CMakeFiles/lyx2.4.dir/Font.cpp.o
CMakeFiles/lyx2.4.dir/FontInfo.cpp.o
CMakeFiles/lyx2.4.dir/FontList.cpp.o CMakeFiles/lyx2.4.dir/Format.cpp.o
CMakeFiles/lyx2.4.dir/FuncRequest.cpp.o
CMakeFiles/lyx2.4.dir/FuncStatus.cpp.o CMakeFiles/lyx2.4.dir/Graph.cpp.o
CMakeFiles/lyx2.4.dir/IndicesList.cpp.o
CMakeFiles/lyx2.4.dir/InsetIterator.cpp.o
CMakeFiles/lyx2.4.dir/InsetList.cpp.o CMakeFiles/lyx2.4.dir/Intl.cpp.o
CMakeFiles/lyx2.4.dir/KeyMap.cpp.o
CMakeFiles/lyx2.4.dir/KeySequence.cpp.o
CMakeFiles/lyx2.4.dir/LaTeX.cpp.o
CMakeFiles/lyx2.4.dir/LaTeXFeatures.cpp.o
CMakeFiles/lyx2.4.dir/LaTeXFonts.cpp.o
CMakeFiles/lyx2.4.dir/LaTeXPackages.cpp.o
CMakeFiles/lyx2.4.dir/Language.cpp.o CMakeFiles/lyx2.4.dir/Layout.cpp.o
CMakeFiles/lyx2.4.dir/LayoutFile.cpp.o
CMakeFiles/lyx2.4.dir/LayoutModuleList.cpp.o
CMakeFiles/lyx2.4.dir/Length.cpp.o CMakeFiles/lyx2.4.dir/Lexer.cpp.o
CMakeFiles/lyx2.4.dir/LyX.cpp.o CMakeFiles/lyx2.4.dir/LyXAction.cpp.o
CMakeFiles/lyx2.4.dir/LyXRC.cpp.o CMakeFiles/lyx2.4.dir/LyXVC.cpp.o
CMakeFiles/lyx2.4.dir/MetricsInfo.cpp.o
CMakeFiles/lyx2.4.dir/ModuleList.cpp.o CMakeFiles/lyx2.4.dir/Mover.cpp.o
CMakeFiles/lyx2.4.dir/OutputParams.cpp.o
CMakeFiles/lyx2.4.dir/PDFOptions.cpp.o
CMakeFiles/lyx2.4.dir/ParIterator.cpp.o
CMakeFiles/lyx2.4.dir/Paragraph.cpp.o
CMakeFiles/lyx2.4.dir/ParagraphMetrics.cpp.o
CMakeFiles/lyx2.4.dir/ParagraphParameters.cpp.o
CMakeFiles/lyx2.4.dir/PersonalWordList.cpp.o
CMakeFiles/lyx2.4.dir/PrinterParams.cpp.o
CMakeFiles/lyx2.4.dir/Row.cpp.o CMakeFiles/lyx2.4.dir/RowPainter.cpp.o
CMakeFiles/lyx2.4.dir/Server.cpp.o
CMakeFiles/lyx2.4.dir/ServerSocket.cpp.o
CMakeFiles/lyx2.4.dir/Session.cpp.o CMakeFiles/lyx2.4.dir/Spacing.cpp.o
CMakeFiles/lyx2.4.dir/TexRow.cpp.o CMakeFiles/lyx2.4.dir/Text.cpp.o
CMakeFiles/lyx2.4.dir/Text2.cpp.o CMakeFiles/lyx2.4.dir/Text3.cpp.o
CMakeFiles/lyx2.4.dir/TextClass.cpp.o
CMakeFiles/lyx2.4.dir/TextMetrics.cpp.o
CMakeFiles/lyx2.4.dir/Thesaurus.cpp.o
CMakeFiles/lyx2.4.dir/TocBackend.cpp.o
CMakeFiles/lyx2.4.dir/TocBuilder.cpp.o CMakeFiles/lyx2.4.dir/Trans.cpp.o
CMakeFiles/lyx2.4.dir/Undo.cpp.o CMakeFiles/lyx2.4.dir/VCBackend.cpp.o
CMakeFiles/lyx2.4.dir/VSpace.cpp.o CMakeFiles/lyx2.4.dir/WordList.cpp.o
CMakeFiles/lyx2.4.dir/boost.cpp.o
CMakeFiles/lyx2.4.dir/buffer_funcs.cpp.o
CMakeFiles/lyx2.4.dir/factory.cpp.o
CMakeFiles/lyx2.4.dir/lengthcommon.cpp.o
CMakeFiles/lyx2.4.dir/lyxfind.cpp.o CMakeFiles/lyx2.4.dir/main.cpp.o
CMakeFiles/lyx2.4.dir/output.cpp.o
CMakeFiles/lyx2.4.dir/output_docbook.cpp.o
CMakeFiles/lyx2.4.dir/output_latex.cpp.o
CMakeFiles/lyx2.4.dir/output_plaintext.cpp.o
CMakeFiles/lyx2.4.dir/output_xhtml.cpp.o
CMakeFiles/lyx2.4.dir/sgml.cpp.o CMakeFiles/lyx2.4.dir/texstream.cpp.o
CMakeFiles/lyx2.4.dir/version.cpp.o  -o ../bin/lyx2.4 ../lib/libmathed.a
../lib/libinsets.a ../lib/libfrontends.a ../lib/libfrontend_qt.a
../lib/libgraphics.a ../lib/libsupport.a ../lib/libmytheslibstatic.a
-lX11 /usr/lib64/libQt5X11Extras.so.5.12.5 -lxcb -lmagic
../lib/libfrontends.a /usr/lib64/libQt5Concurrent.so.5.12.5
/usr/lib64/libQt5Svg.so.5.12.5 /usr/lib64/libQt5Widgets.so.5.12.5
/usr/lib64/libQt5Gui.so.5.12.5 /usr/lib64/libQt5Core.so.5.12.5 -lz
lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:153
Please submit a full bug report,
with preprocessed source if appropriate.
See  for 

Re: [LyX/master] Mark insets with invalid buffer() in red in devel-mode.

[Richard Kimberly Heck]

On 10/21/19 11:25 AM, Jean-Marc Lasgouttes wrote:
> commit 067d6dc759b819d2a40a4dea0b09736d474ddc24
> Author: Jean-Marc Lasgouttes 
> Date:   Mon Oct 21 16:45:03 2019 +0200
>
> Mark insets with invalid buffer() in red in devel-mode.
> 
> We tend to have insets which buffer() member is invalid. To help
> debugging, this commit paints their background in red when devel-mode
> is on.
> 
> To this end, a new method develMode() is added to the Painter class.
> 
> With this commit, it is easy to see that macro template do not have a
> proper buffer set!

I was thinking to try adding inset().setBuffer() to the beginning of
updateBuffer() in master, as we discussed before, and see what happens.
And if that goes well, then to start removing manual setBuffer() calls
in various places, and see how that goes. Thoughts?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Numbered Lists features

[Richard Kimberly Heck]

On 10/23/19 4:49 AM, Jean-Marc Lasgouttes wrote:
> Le 23/10/2019 à 09:38, Eugénio Costa a écrit :
>> Hi Lyx developers,
>>
>> Lyx 2.3.1 on Fedora Linux
>> I use Lyx for standard text reports, articles and contract drafting.
>> -- 
>> Would like to suggest that some simple feature in the GUI to
>> personalize and define Numbered Lists would be an amazing feature for
>> next updates.
>
> Hello,
>
> There have been people asking for GUI editing of layouts for a long
> time... It is not easy to do correctly and this will certainly not be
> part of next version.
>
> Concerning the issue that you discussed in lyx-users of having an
> enumerated list for legal documents, it seems to be easy with enumitem
> and I can try to provide a module for that.

I have thought for a while that it might be nice to have a module (or
two, or three...) that defined a variety of common list types. Maybe
nicely commented, so people could see what else they'd need to do to
define some modification. (E.g., at least mention the various list
parameters one can tweak.) I've got some of these already in my own modules.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Backport some gcc9 fixes to branch

[Richard Kimberly Heck]

On 10/25/19 1:13 PM, Jean-Marc Lasgouttes wrote:
> Riki, is this OK?
>
> If this goes in, Kornel will probably have to backport some of his own
> patches.

I know nothing about such things. If you think it's a good idea, please
go ahead.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Mark insets with invalid buffer() in red in devel-mode.

[Richard Kimberly Heck]

On 10/21/19 12:43 PM, Jean-Marc Lasgouttes wrote:
> Le 21/10/2019 à 18:13, Richard Kimberly Heck a écrit :
>>>  To this end, a new method develMode() is added to the Painter
>>> class.
>>>   With this commit, it is easy to see that macro template do
>>> not have a
>>>  proper buffer set!
>>
>> I was thinking to try adding inset().setBuffer() to the beginning of
>> updateBuffer() in master, as we discussed before, and see what happens.
>> And if that goes well, then to start removing manual setBuffer() calls
>> in various places, and see how that goes. Thoughts?
>
> Sure, if we are sure that this propagates everywhere. But are we sure
> that we will never have to access buffer() before updateBuffer has
> been run on the whole document?

Only one way to find out...

More seriously, I think we /shoudn't/ be doing anything that accesses
buffer() before then, though there are some cases where we do. I think
there is such a case in the cut and paste code, though I'm not sure.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

2.3.4 Translations

[Richard Kimberly Heck]

Hi, all,

Please prepare translations for LyX 2.3.4. We hope to release around 1
December, so if you could finish it by the 27th or so, that'd be great.

Thanks for all you do to support LyX.

Riki
Stable Branch Maintainer


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Fix crash in selection manager

[Richard Kimberly Heck]

On 11/19/19 7:33 AM, Juergen Spitzmueller wrote:
> commit 5d45c10fc785961d7c5f9e1cc291f14a116b1227
> Author: Juergen Spitzmueller 
> Date:   Tue Nov 19 13:47:32 2019 +0100
>
> Fix crash in selection manager
> 
> Patch by Patrick De Visschere

Fine for stable if needed.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Fix issues with tilde in inputpath

[Richard Kimberly Heck]

On 11/20/19 5:43 AM, Juergen Spitzmueller wrote:
> commit a426b33067ae4e9d5452f13284f3e223d87ac45d
> Author: Juergen Spitzmueller 
> Date:   Wed Nov 20 11:57:32 2019 +0100
>
> Fix issues with tilde in inputpath
> 
> Fixes #11699
> ---

Fine for stable if needed.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Re-fix #11146 with recent LaTeX

[Richard Kimberly Heck]

On 11/20/19 5:43 AM, Juergen Spitzmueller wrote:
> commit e75fa6f3ac5735dfcd588acb5c187556bface16d
> Author: Juergen Spitzmueller 
> Date:   Wed Nov 20 11:48:18 2019 +0100
>
> Re-fix #11146 with recent LaTeX

Fine for stable if needed.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] GuiSelectionManager: fix getSelectedIndex for availableLV

[Richard Kimberly Heck]

On 11/20/19 7:52 AM, Juergen Spitzmueller wrote:
> commit 772f2a28414dae7765486ad7aff042e4299c7fb7
> Author: Juergen Spitzmueller 
> Date:   Wed Nov 20 14:07:05 2019 +0100
>
> GuiSelectionManager: fix getSelectedIndex for availableLV

Fine for stable if needed.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: \binomial already defined

[Richard Kimberly Heck]

On 11/20/19 3:38 AM, Jürgen Spitzmüller wrote:
> Am Dienstag, den 19.11.2019, 10:38 -0500 schrieb Neal Becker:
>> The attached test file gives me error \binomial already defined.
> Quickfix: Add to Document > Settings > Local Layout:
>
> Provides binom 1
>
>
> Background: LyX adds an own \binom definition if binom is used but
> amsmath not loaded. Beamer, however, automatically loads amsmath
> without telling LyX this.
>
> Fixed in master now.
>
> Could also go to stable.

Yes please.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: lyxeditor not executable when installed with cmake

[Richard Kimberly Heck]

On 11/26/19 3:04 PM, Kornel Benko wrote:
> Am Tue, 26 Nov 2019 20:57:22 +0100
> schrieb Kornel Benko :
>
>> Am Tue, 26 Nov 2019 19:52:15 +0100
>> schrieb pdv :
>>
>>> When installing with the latest CMake on MacOS the lyxeditor, inkscape 
>>> and maxima files, copied into the bundle, are not longer executable. 
>>> This is in particular a nuisance for the "reverse search" feature which 
>>> calls lyxeditor.
>>>
>>> In the "install(FILES ...)" command (in development/cmake/install.cmake) 
>>> the PERMISSIONS should be mentioned explicitly. See enclosed patch.
>>>
>>> Patrick  
>> Looks good. Will do it for master. Candidate for branch.
>>
>>  Kornel
> Too fast. What about
>   install(PROGRAMS ...)
> instead of 'install(FILES ...)?

Feel free to fix this in stable when you know exactly how to do it.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Building windows installer questions

[Richard Kimberly Heck]

On 2/11/20 3:30 PM, Yu Jin wrote:
> > I've been trying to build a windows installer to see how it works, but
> > I could not find the files FindProc.dll and INetC.dll, which are
> > mentioned in the Readme.txt file. Any Idea where I can locate them?
>
> I found these 2 plugins on the internet, the description just confused
> me a little bit. So I have tried to build the installer again. Found
> that the NSIS script searches for some more Qt files (in addition to
> the ones specified in the desctiption for compiling) inside of the bin
> folder of LyX, like Qt5OpenGL.dll, so I copied those.

Any updates you want to make to the README will be very welcome. I
pretty much gave up trying to do things that way because of all the
problems I encountered.


> Now NSIS asks me about the iconv.dll. In my Visual Studio solution
> this 3rd party project is a static library, so it does not produce a
> standalone dll file. I have seen however, that in the previous
> releases there is this dll and removing it causes LyX not being able
> to start. Should I be concerned about this? Or just modify the NSIS
> script making it not to search for iconv.dll?

In  my case, that is provided by the mingw cross compiler. But perhaps see:

    https://gnupg.org/download/iconv.html

It is crucial that this library be available to LyX.

Riki



> Am Di., 11. Feb. 2020 um 06:37 Uhr schrieb Richard Kimberly Heck
> mailto:rikih...@lyx.org>>:
>
> On 2/9/20 4:23 AM, Yu Jin wrote:
> > Hi,
> >
> > I've been trying to build a windows installer to see how it
> works, but
> > I could not find the files FindProc.dll and INetC.dll, which are
> > mentioned in the Readme.txt file. Any Idea where I can locate them?
>
> On my machine, these were just installed with NSIS. There was no need
> for me to copy those files. They were already where they were meant to
> be. It is possible I installed some plugin, but I don't recall
> doing so.
> I suspect that those steps in the Readme are out of date, therefore.
> (There's no 'bundle' installer, either, now.)
>
> Riki
>
>
>
>

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[ANNOUNCE] LyX 2.3.4.2 'Emergency' Release

[Richard Kimberly Heck]

This is an emergency release that fixes four bugs in 2.3.4. Only the
first two really warrant an emergency release, but while we're at it...

The first, bug #11728, caused a five-second delay when attempting
to save files on Windows. This was a side effect of the fix for #10091
and reminds us why it would be good to have more testing on Windows.

The second bug is discussed in this thread
    https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg210294.html
and concerns a crash related to the math toolbar. This was due to an
uninitialize buffer_ member revealed by the fix for #11586.

The third, bug #11724, affects Beamer presentations and causes bad output
when page geometry is set in certain ways. LyX should and how does ignore
such settings.

The last, bug #11579, is an old one, but a serious one, that prevents
the use of CJKUtf8 in ERT. It's a straightforward fix for a bug that is
pretty serious for people who encounter it.

All LyX users are encouraged to upgrade to 2.3.4.2.

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Building windows installer questions

[Richard Kimberly Heck]

On 2/11/20 3:30 PM, Yu Jin wrote:
>
> Am Di., 11. Feb. 2020 um 06:37 Uhr schrieb Richard Kimberly Heck
> mailto:rikih...@lyx.org>>:
>
> On 2/9/20 4:23 AM, Yu Jin wrote:
> > Hi,
> >
> > I've been trying to build a windows installer to see how it
> works, but
> > I could not find the files FindProc.dll and INetC.dll, which are
> > mentioned in the Readme.txt file. Any Idea where I can locate them?
>
> On my machine, these were just installed with NSIS. There was no need
> for me to copy those files. They were already where they were meant to
> be. It is possible I installed some plugin, but I don't recall
> doing so.
> I suspect that those steps in the Readme are out of date, therefore.
> (There's no 'bundle' installer, either, now.)
>

PS There is a 'large strings' build available here:

    https://nsis.sourceforge.io/Special_Builds

I think I may have installed that in the first place rather than do the
two-step in the README. And it may be that those plugins just got
installed along with it.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Building windows installer questions

[Richard Kimberly Heck]

On 2/9/20 4:23 AM, Yu Jin wrote:
> Hi,
>
> I've been trying to build a windows installer to see how it works, but
> I could not find the files FindProc.dll and INetC.dll, which are
> mentioned in the Readme.txt file. Any Idea where I can locate them?

On my machine, these were just installed with NSIS. There was no need
for me to copy those files. They were already where they were meant to
be. It is possible I installed some plugin, but I don't recall doing so.
I suspect that those steps in the Readme are out of date, therefore.
(There's no 'bundle' installer, either, now.)

Riki



-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [RFC][PATCH] Change to buffer lookup for given temporary files

[Richard Kimberly Heck]

On 2/23/20 7:50 AM, Jean-Marc Lasgouttes wrote:
> Le 23/02/2020 à 11:40, Enrico Forestieri a écrit :
>> On Sun, Feb 23, 2020 at 12:35:53AM +0100, Enrico Forestieri wrote:
>>> On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:

 Still, why realPath() returns a short path name in one case and not
 in the
 other case remains a mystery.
>>>
>>> Mystery solved. On Windows, our implementation of realPath() works
>>> only with
>>> file names but does not work with directory names. On the other hand,
>>> QFileInfo::canonicalFilePath() does not resolve junctions (directory
>>> symlinks).
>>
>> Dropping support for Windows Xp, the attached patch works for me with
>> both files and directories. I am going to apply it, as I think it is
>> not controversial, given that MS dropped support for Win7 these year
>> (while we still support both WinVista and Win7).
>
> I have no definitive idea about that, but you should update README if
> you apply it.

I am not totally sure, but I seem to recall that Uwe stopped pledging
support for XP quite some time ago. There was some specific reason, I
think, but I can't recall what it was.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Memory leak from list

[Richard Kimberly Heck]

On 2/23/20 8:23 AM, Scott Kostyshak wrote:
> On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote:
>> On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote:
>>> On 2/18/20 6:07 PM, Scott Kostyshak wrote:
>>>> Valgrind gave me the following error:
>>>>
>>>>   ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks are definitely 
>>>> lost in loss record 5,165 of 5,862
>>>>   ==732==at 0x483AE63: operator new(unsigned long) (in 
>>>> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>   ==732==by 0x103A62D: lyx::Buffer::cloneBufferOnly() const 
>>>> (Buffer.cpp:661)
>>>>   ==732==by 0x11E583C: lyx::(anonymous 
>>>> namespace)::copyToTempBuffer(lyx::ParagraphList const&, 
>>>> std::shared_ptr) (CutAndPaste.cpp:582)
>>>>   ==732==by 0x11E5C6A: lyx::(anonymous 
>>>> namespace)::putClipboard(lyx::ParagraphList const&, 
>>>> std::shared_ptr, 
>>>> std::__cxx11::basic_string, 
>>>> std::allocator > const&, lyx::BufferParams) (CutAndPaste.cpp:613)
>>>>   ==732==by 0x11E910B: lyx::cap::copySelection(lyx::Cursor const&, 
>>>> std::__cxx11::basic_string, 
>>>> std::allocator > const&) (CutAndPaste.cpp:1123)
>>>>   ==732==by 0x11E84F8: lyx::cap::copySelection(lyx::Cursor const&) 
>>>> (CutAndPaste.cpp:1024)
>>>>   ==732==by 0x13ECDAB: lyx::Text::dispatch(lyx::Cursor&, 
>>>> lyx::FuncRequest&) (Text3.cpp:1593)
>>>>   ==732==by 0x1767E04: lyx::InsetText::doDispatch(lyx::Cursor&, 
>>>> lyx::FuncRequest&) (InsetText.cpp:339)
>>>>   ==732==by 0x15FFC39: lyx::Inset::dispatch(lyx::Cursor&, 
>>>> lyx::FuncRequest&) (Inset.cpp:325)
>>>>   ==732==by 0x11D1B13: lyx::Cursor::dispatch(lyx::FuncRequest const&) 
>>>> (Cursor.cpp:825)
>>>>   ==732==by 0x1816F4F: 
>>>> lyx::frontend::GuiView::dispatchToBufferView(lyx::FuncRequest const&, 
>>>> lyx::DispatchResult&) (GuiView.cpp:3878)
>>>>   ==732==by 0x181B959: 
>>>> lyx::frontend::GuiView::dispatch(lyx::FuncRequest const&, 
>>>> lyx::DispatchResult&) (GuiView.cpp:4569)
>>>>
>>>> It comes from the following line (Buffer.cpp:661):
>>>>
>>>>   cloned_buffers.push_back(new CloneList);
>>>>
>>>> Currently cloned_buffers is a list. Would it make sense to 
>>>> make it a list of *smart* pointers instead? Alternatively we could make a 
>>>> class and then make a custom destructor that would free the CloneLists 
>>>> that the list elements point to?
>>> This is some kind of thinko, probably on my part. The code at line 549
>>> was supposed to be cleaning this up, but it actually only removes the
>>> entry from the list.
>>>
>>> If it works to make it a smart pointer of some kind, then that would be
>>> simplest. But I think we could just do something like:
>>>
>>> else {
>>>     delete(*it);
>>>     cloned_buffers.erase(it);
>>> }
>> Ah that makes sense.
> Riki, I propose that you commit. Thanks for the fix.

Just to check: You've verified this fixes the problem?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel