Re: Allow space at beginning of (some?) insets

[Paul A. Rubin]

On 6/1/23 11:42, Scott Kostyshak wrote:

I come across the example in the attachment often in various forms. It would be 
nice if I could insert a space at the beginning of an inset.

Am I missing a more natural workaround than the ones shown in the example?

Scott

Would Insert > Formatting > Interword space (space-insert normal, bound 
to Ctrl+Alt+Space in cua.bind) be "more natural"?


Paul

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

Re: Alt/Option key question

[Paul A. Rubin]

On 3/30/23 16:24, Christopher Menzel wrote:

Gentle LyX folk:

I use the Emacs UI for LyX, which means the Option key (or Alt key, for PC 
users) gets a good workout — e.g., Opt-D deletes word-forward, Opt-F moves the 
cursor forward by word, etc. (In the standard LyX UI, those keys bring up the 
File and Document menus, respectively, so I disable that behavior with a custom 
stdmenus.inc file.) My issue is this. If I just depress the Option key and 
release it without having hit another key, it steals the cursor — it’s 
apparently waiting for an F or a D or one of the other keys (which I’ve 
deactivated) that bring up a menu — and I have to depress the Option key and 
let it up again to get the cursor back. This is a bit irritating: I often find 
myself depressing the Option key absent-mindedly when I’m thinking and it’s 
annoying to start typing and have nothing happen. Thus my question: Is there a 
way to prevent this, so that depressing/releasing the Option key simply has no 
effect on the cursor? Any thoughts appreciated.

Thanks.

Chris Menzel



What OS are you using? I don't experience this on Linux Mint.

Paul

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

Re: Bug in running external program (-shell-escape)

[Paul A. Rubin]

On 2/24/23 05:56, Mario D wrote:

It looks like I have found a bug using the external library in lyx:
if you pass the option
\tikzexternalize[prefix=some_dir/]
then lyx is not able to create the subdir "some_dir" in its temporary 
working dir under the /tmp tree, which results in a compilation error 
since lyx is not able to write the necessary files.


If you don't pass any prefix option, the file compiles correctly, 
since lyx can write all necessary files in the relative temp dir.


A MWE is the attached file, which results in the following latex source.

M

-
%% LyX 2.3.6 created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}

\makeatletter
%% User specified LaTeX commands.
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize[prefix=picts/]

\makeatother

\begin{document}
\[
 \begin{tikzpicture}
  \node (0) at (0,0) {$1$};
  \node (1) at (0,1) {$2$};
  \draw[-] (0) edge (1);
 \end{tikzpicture}
\]
\end{document}
-


I just added this to Trac: https://www.lyx.org/trac/ticket/12685.

Paul

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

Re: Donations

[Paul A. Rubin]

On 12/16/22 09:06, Pavel Sanda wrote:

On Wed, Dec 14, 2022 at 05:40:40PM -0500, Paul A. Rubin wrote:

Is it possible to make an unrestricted donation via PayPal. Every time I try
(using the button from the LyX.org donation page), I get the following
response: "Things don't appear to be working at the moment. Please try again
later." "At the moment" is apparently Latin for "ever".

No, we don't have viable donation channel anymore and no one seems to be
motivated to push this through...

Pavel

Thanks Pavel.

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

Donations

[Paul A. Rubin]

Is it possible to make an unrestricted donation via PayPal. Every time I 
try (using the button from the LyX.org donation page), I get the 
following response: "Things don't appear to be working at the moment. 
Please try again later." "At the moment" is apparently Latin for "ever".


Paul

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

Re: New Theorems Module

[Paul A. Rubin]

On 10/13/22 02:45, Udicoudco wrote:



On Fri, Sep 23, 2022 at 12:25 AM Paul A. Rubin  
wrote:


On 9/19/22 22:26, Udicoudco wrote:

I've noticed that the definition environment is not numbered in the
output files. After checking the module again, I hope there are no
issues any more. The fixed module is attached.

Regards,
Udi


I noticed a new pathology with this version. Steps to reproduce
are as follows:

 1. Compile the test_thmtools_module.lyx document (which works fine).
 2. Delete the entire contents of section 2, other than the
section heading, and recompile. I've attached the PDF I get.
Note the garbled contents where the theorem lists go.
 3. Make any minor edit to the document (to force a fresh compile)
and recompile. The output is as expected.

HTH,

Paul

--


Hi Paul,

Sorry for the late reply, it is the holiday season in my country.

I've managed to solve this issue with a simple trick. The updated 
module can be found in here <https://github.com/Udi-Fogiel/LyX-thmtools>.

If you will try it again, I would be glad to hear from you.

Best Regards,
Udi

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



Udi,

Speaking of late replies, it's my turn to apologize. You posted this 
just as I was heading out to a conference. Since getting back, I've been 
(slowly) catching up on accumulated work.


I just tested the updated module, and can confirm that the problem I 
noticed is gone. Good job!


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

Re: [Donation] Paypal error when donation

[Paul A. Rubin]

On 11/3/22 16:13, jonathan grolleau wrote:

Hi LyX Developer mailing list,

The donation button (https://www.lyx.org/Donate) which leads to Paypal 
website's, results in a Paypal side error : Things don't appear to be 
working at the moment. Please try again later.


Best regards,


Same thing happened to me just now.

Paul

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

Re: Different color of cursor in Math and Text Modes

[Paul A. Rubin]

On 10/9/22 12:30, Jean-Marc Lasgouttes wrote:

Le 09/10/2022 à 17:28, Rodolfo Oviedo a écrit :

Hi Jean-Marc,

Thank you for your reply!


You are welcome. Please keep lyx-devel in copy, it is better to share 
our thoughts with everyone.


I agree that it is enough. However, I think it is not optimum, 
especially because the corners are too thin to notice without a 
conscious effort to spot them. That is why I think that allowing a 
change in the color of the cursor would be helpful.


What is your setting (OS, screen) ? Do you have a HiDpi monitor ? 
Would it be better to have thicker corners?


If a set of four corners were substituted by a thin square, that 
would be immediately noticeable. I suppose the developers did not use 
squares because they found them too obtrusive.


Right, or we could change the background color to be more noticeable.
I'll vote for that. Sometimes it's a wee bit hard to tell whether I am 
in a subscript/superscript, or in the "owner" of the 
subscript/superscript, or what. For example, if you enter $\sum_1^n$ and 
then mouse between the subscript, the superscript and the summation 
sign, the corners never change. If we could change the background for 
just the "relevant portion" (say, the portion subject to destruction if 
I hit the backspace key), that would be helpful. Right now, if I have 
the cursor just past the summation and hit backspace, it highlights the 
whole thing, conveniently telling me the amount of destruction I am 
about to unleash; but if the cursor is somewhere within the summation, 
backspacing does no highlighting or warning and just destroys something. 
(This is on 2.3.6.) Somewhat unexpectedly, if the cursor is just to the 
left of the sigma, backspacing nukes both subscript and superscript but 
leaves the sigma.


Paul

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

Re: New Theorems Module

[Paul A. Rubin]

On 9/19/22 22:26, Udicoudco wrote:

I've noticed that the definition environment is not numbered in the
output files. After checking the module again, I hope there are no
issues any more. The fixed module is attached.

Regards,
Udi

I noticed a new pathology with this version. Steps to reproduce are as 
follows:


1. Compile the test_thmtools_module.lyx document (which works fine).
2. Delete the entire contents of section 2, other than the section
   heading, and recompile. I've attached the PDF I get. Note the
   garbled contents where the theorem lists go.
3. Make any minor edit to the document (to force a fresh compile) and
   recompile. The output is as expected.

HTH,

Paul


test_thmtools_module.pdf
Description: Adobe PDF document
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Paul A. Rubin]

On 9/15/22 20:24, Udicoudco wrote:

While trying to solve this issue, I also realised that if a user would
use a bilingual document, with theorems used in two languages, he will
only see the labels (in the list of theorems) of the language at which
the list of theorems will be written.

I believe I was able to solve both bugs, the new module file is attached.

Regards,
Udi


Udi,

Thanks for the detailed explanation. I tested the new module file, and 
it seems to fix the issue of what happens if you delete all instances of 
one species of environment and then recompile. While testing the other 
issue (list of theorems when there are none), I encountered a new pathology.


Start with an empty document, add your module, insert a list of theorems 
(and nothing else) and compile. An error occurs. The same error happens 
if I start with one or more theorem type environments present, compile 
(which works), then delete them and recompile (which bombs).


I was also wondering whether the menu item to insert a list of theorems 
could be added to the Insert > List / TOC menu via a tweak to the layout 
file. I suspect this is possible, but one of the developers more 
familiar with layouts than I am might have to weigh in with the details. 
It's the first place I would look when trying to insert a list of theorems.


Cheers,
Paul

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

Re: New Theorems Module

[Paul A. Rubin]

On 9/13/22 18:48, Udicoudco wrote:

On Tue, Aug 30, 2022 at 10:27 AM Jürgen Spitzmüller  wrote:

Am Donnerstag, dem 14.07.2022 um 14:17 +0300 schrieb Udicoudco:

Hello again,

Hi,

Hi Jürgen,
Thank you for the reply.


Thanks for this and sorry for the late reply. Most people are busy with
their real lifes.

No apologies needed, thank  you all for developing great software.


I had some mistakes in the .inc file and the .lyx file. The updated
files are attached.

As I do not use theorems myself, I cannot comment on the usage and
usefulness of thmtools and the need for a module. So you probably have
to be even more patient until the math users are back.

Well, the matter is not urgent, and I have patience :).


One remark on the layout:

AddToPreamble
  \usepackage{amsthm}
  \usepackage{thmtools}
EndPreamble

At least for amsthm, this should rather be

Require amsthm

I've fixed this issue (see the attached file). I'v also used the
DependsOn key so that the module will call thmtools only once.


I think also thmtools should be added to the packages LyX knows and
loaded that way.

I don't know how to do that.

Regards,
Udi


Hi Udi,

I've been playing a bit with your module, and I've encountered a couple 
of non-fatal issues. The first may sound a bit silly. If you have a list 
of theorems but do not have any theorem-like environments (either 
because you put in the list of theorems code first or because you 
deleted all the things that would have been listed and have not yet 
added new ones), the document will not compile because the thm-tools 
package has not been loaded. Either requiring thm-tools in the list of 
theorems environment or making it depend on theorems (the way claim, 
lemma etc. do) should cure that.


The second one is perhaps a bug in the thm-tools package itself. To 
reproduce it, you can follow these steps.


1. Open your test_thmtools_module.lyx file and compile it (which works,
   of course).
2. Delete the claims in section 2 (so that section 2 begins with
   Conjecture 2.1) and recompile. When I do this, I get four undefined
   control sequence errors, at least three of which contain the macro
   \claimname. If I select "view output anyway", the document seems to
   display correctly.
3. Now it gets goofier. If I make some trivial text edit (just to force
   a recompilation), say adding a character to the section heading, and
   recompile, the document compiles correctly without the error messages.

Something similar happens if, in step 2, I delete all the definitions 
rather than all the claims, except that the errors now refer to 
\definitionname. It's important to note that this only happens if I 
compile the original document first. If I open the document, delete 
claims or definitions, and then compile for the first time, there is no 
error. So something is carrying over (in the buffer directory) from the 
initial compilation that maybe ought not carry over. Also, it only seems 
to happen when I delete all of one type of environment (all claims, all 
definitions, ...). As long as I leave one claim or one definition 
intact, the error does not occur.


I did a little digging. It turns out that compilation creates both a 
.aux file and a .loe file in the buffer directory. After compiling the 
full document, both contain instances of \claimname. After deleting all 
claims and recompiling (producing the error messages), both are rebuilt 
with no references to \claimname. If, however, I delete either one after 
compiling the full document and before compiling the edited version, the 
edited version generates no error messages. So I suspect there is some 
sort of timing issue here, in which the first compilation of the edited 
document inherits some undefined instances of \claimname (missing from 
both .aux and .loe after they were rebuilt) whereas a recompilation does 
not inherit \claimname. Deleting either the .aux or .loe file may force 
them to rebuilt before \claimname leaks into the main document. I hope 
that makes sense. (If it does, please explain to me what I just wrote. :-))


Cheers,

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

Re: Keep focus of "find" when returning to LyX window

[Paul A. Rubin]

On 7/10/22 20:21, Scott Kostyshak wrote:

To reproduce:

1. Open (simple) search, and put your cursor in the search line edit.

2. Select a different window (e.g., alt-tab).

3. Go back to the LyX window.

For me, the focus is now in the main work area instead of the search line edit. 
Can anyone reproduce? Strangely, this doesn't happen with Advanced Find.

Has anyone else previously found this annoying? I came across this when I wanted to paste 
in something from a clipboard manager and wanted it to go in the "find" line 
edit. Instead, it gets pasted in the main work area.

Commenting out the line with "case QEvent::WindowActivate" in GuiView::event() 
fixes things for me. I'm not suggesting to remove that code especially since I don't 
understand it, but I'm just mentioning this observation in case it leads to something.

Scott

I can confirm it with LyX 2.3.6.1 on Linux Mint. I don't alt-tab very 
often, so it's never happened to me (hence not particularly annoying).


Paul

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

Re: 2.3.6.1 (Ubuntu 16.04) cannot import the exam class?

[Paul A. Rubin]

On 3/22/22 09:23, Uwe Brauer wrote:

Hi

I tried with the above version to import a LaTeX file that is written with the 
exam class.

The error message reads:


Creating file /home/oub/Downloads/Annu/annu-sol-template.lyx
Error: Could not read layout file for textclass "exam".
support/Systemcall.cpp (276): Systemcall: '/usr/bin/tex2lyx -f "annu-sol-template.tex" 
"annu-sol-template.lyx"' finished with exit code 1
Error: Cannot convert file

An error occurred while running:
/usr/bin/tex2lyx -f "annu-sol-template.tex" "annu-sol-template.lyx"

I attach the file just in case.

Any change to convert that?

Thanks and regards

Uwe Brauer



In order to use a LaTeX class in LyX, you have to have a corresponding 
layout file (which essentially maps elements of the LaTeX class to 
visual elements in the GUI). As far as I know, LyX does not provide a 
layout file for the exam class. There is a user-provided layout at 
https://github.com/fuhrmanator/lyx-layouts. Assuming you have the TeX 
class (exam.cls) installed, you can download the layout file from 
GitHub, put in your local layouts file (~/.lyx/layouts), reconfigure and 
restart LyX and try that.


Paul

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

Re: Weird compile result -- bug?

[Paul A. Rubin]

On 10/16/21 11:41 AM, Jürgen Spitzmüller wrote:

Am Samstag, dem 16.10.2021 um 11:28 -0400 schrieb Paul A. Rubin:

On Ubuntu and Mint with TeXLive, biblatex comes in one of the TeXLive
packages (texlive-latex-recommended?) but biber requires installation
of a separate package ("biber") that does not contain TeXLive in its
name. So I suspect it is not uncommon to install biblatex (via
TeXLive) and not have biber. Since biblatex still works, they may be
fine ... until someone sends them a LyX file that selects biber. LyX
changes that to "default" and the adventure begins.

This is a very bad package choice. IMHO biblatex package should require
biber. Biblatex only works to a very limited degree with bibtex8, many
styles and advanced features require biber.

You should file a bug report against them.


Actually, though, the bigger concern for me is that (before I
installed biber and reconfigured) arbitrary edits to the preamble in
such a file changed the biblatex load command that LyX put in the
.tex
file. Switching the processor from biber to default (or bibtex) when
LyX cannot find biber seems reasonable to me, but doing it somewhat
randomly is a bit too idiosyncratic for me. As I originally wrote,
just
adding a space at the end of the preamble was enough to change LyX's
behavior on my system.

As I tried to explain this is not due to preamble edits per se, but due
to doing any change in document preferences. As biber is not available,
it cannot be (re-)selected in settings. All we could do about that is
issue a warning.

Jürgen


I understand what you are saying, and I do think that LyX should warn 
the user any time it overrides a document setting made by the user. 
Going back to the original symptom (document setting says "biber", biber 
is not installed, bibliography does not appear in document), the only 
fix I can think of would be for LyX to scan each document when loading 
the document, checking that any software or class/style selections are 
known to exist on the system. Presumably LyX would then warn the user 
that the document calls for biber but biber is not installed.


This might be too infrequent a problem to warrant that level of 
attention, though, so I'm fine if the decision is to leave things be.


Paul

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

Re: Weird compile result -- bug?

[Paul A. Rubin]

On 10/16/21 10:45 AM, Jürgen Spitzmüller wrote:

Am Samstag, dem 16.10.2021 um 09:32 -0400 schrieb Paul A. Rubin:

That still leaves the question of whether what I originally saw was
unique to my system or would happen to anyone who opened a LyX doc
using biblatex with biber on a system that does not have biber
installed. Unfortunately, to test that you would need a biber-less
system.

The same will happen to other persons without biber installation. The
question is: How common is that?

What we could do is implement some warnings that inform these people
that the document expects biber but it isn't available, which is why a
fallback is used that results in (potentially) inferior output and also
might change the document settings.

Jürgen


On Ubuntu and Mint with TeXLive, biblatex comes in one of the TeXLive 
packages (texlive-latex-recommended?) but biber requires installation of 
a separate package ("biber") that does not contain TeXLive in its name. 
So I suspect it is not uncommon to install biblatex (via TeXLive) and 
not have biber. Since biblatex still works, they may be fine ... until 
someone sends them a LyX file that selects biber. LyX changes that to 
"default" and the adventure begins.


Actually, though, the bigger concern for me is that (before I installed 
biber and reconfigured) arbitrary edits to the preamble in such a file 
changed the biblatex load command that LyX put in the .tex file. 
Switching the processor from biber to default (or bibtex) when LyX 
cannot find biber seems reasonable to me, but doing it somewhat randomly 
is a bit too idiosyncratic for me. As I originally wrote, just adding a 
space at the end of the preamble was enough to change LyX's behavior on 
my system.


Paul

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

Re: Weird compile result -- bug?

[Paul A. Rubin]

On 10/16/21 3:14 AM, Jürgen Spitzmüller wrote:

Am Freitag, dem 15.10.2021 um 17:18 -0400 schrieb Paul A. Rubin:

1. View the document (which compiles correctly), then run 'grep
biblatex dev_mwe.tex' in the LyX buffer directory. The relevant
output line is "\usepackage[style=authoryear]{biblatex}".
2. Make an arbitrary text change in the document body (anywhere), to
force LyX to recompile. Repeat the previous step. The key line in the
.tex file is unchanged.
3. In Document > Settings... > LaTeX Preamble, add a space at the end
of the preamble and repeat the first step. The line in the .tex file
changes to "\usepackage[style=authoryear,backend=bibtex8]{biblatex}"
(i.e., the "backend" setting is added).

I cannot reproduce.


This also happens if I edit the text in the \lehead{}, \rohead{},
\refoot{} or \lofoot{} commands, or if I insert \usepackage{} in the
preamble, or basically if I make any non-fatal change to the
preamble.

Neither with this.


It makes no sense to me that any of those changes would affect
bibliography processing.

Well, here is a possible explanation:

The "bibtex8" backend is only added to the output when bibtex8 is
indeed used as a bibliography processor. But the document you sent has
\bibtex_command biber

However, maybe you do not have biber installed on your system. Then,
biber is not found by configure.py and not available as an option in
Document > Settings > Bibliography > Bibliography Processor. In such a
case, the option is reset to default (preferences). This is the only
way to assure the document compiles successfully on your system.
This happens if you do any change in document setting (preamble or
otherwise), as the bibliography processor combo does not have the biber
choice and is set to default. Check if the document has, after the
crucial change
\bibtex_command default

Now default means: Use preference settings. If you have in preferences
"Automatic" bibliography processor, LyX uses the best one available. If
biber is not available, this is bibtex8, hence the change.

Of course bibtex8 is much inferior to biber, and it can be expected
nowadays that people who use biblatex do have biber installed.

Best,
Jürgen



Jürgen,

I believe you are correct about biber. When I first encountered the bug, 
I did not have biber installed. So I installed biber and retested, 
finding the bug again ... because I forgot to reconfigure LyX. In both 
those instances, 'biber' was not an option on the processor drop-down 
list, and so LyX changed it to 'Default'. After reconfiguring LyX, 
'biber' is the selected option and the behavior is as it should be.


That still leaves the question of whether what I originally saw was 
unique to my system or would happen to anyone who opened a LyX doc using 
biblatex with biber on a system that does not have biber installed. 
Unfortunately, to test that you would need a biber-less system.


Maybe this is just too unusual to worry about.

Cheers,
Paul

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

Re: Weird compile result -- bug?

[Paul A. Rubin]

On 10/15/21 12:34 PM, Jürgen Spitzmüller wrote:

Am Freitag, dem 15.10.2021 um 11:51 -0400 schrieb Paul A. Rubin:

Over on the user list, there's a lengthy thread (actually set of
threads) triggered by user Rich Shepard trying to compile a report
whose
bibliography stubbornly refused to appear. Rich was using biblatex.
After copies trial and error, Rich got the report to work, but with
no
explanation why.

I was beating on a copy of it (which I am not at liberty to share)
and
discovered that if made any non-fatal change to the preamble, the
bibliography would show up. In particular, just adding \usepackage{}
(with the argument deliberately empty) to the preamble in LyX coaxed
the
bibliography to show up.

Comparing the .tex files that LyX exported with and without the
\usepackage{} command, I discovered two changes. One of course was
the
inclusion of \usepackage{}. The other was that
\usepackage[style=authoryear]{biblatex} in the original document
morphed
into \usepackage[style=authoryear,backend=bibtex8]{biblatex} in the
modified document.

So I went to the original document and, in the bibliography settings,
changed the processor option from default to bibtex8, and sure enough
the original compiled correctly.

I'm not sure if this is a bug or something the user is responsible
for
knowing (it was news to me, but I never use biblatex). So I'm
reporting
it here to let wiser minds decide.

Undecidable without a MWE.

Jürgen


Here's an MWE and the associated .bib file. Since I installed biber, I 
no longer fail to generate a bibliography under any scenario, but I can 
still reproduce behavior that I think is a bug. This is with LyX 2.3.6.1 
on Linux Mint 20.2 using TeXLive 2019. I'm using the PDF (pdflatex) 
output format throughout.


1. View the document (which compiles correctly), then run 'grep
   biblatex dev_mwe.tex' in the LyX buffer directory. The relevant
   output line is "\usepackage[style=authoryear]{biblatex}".
2. Make an arbitrary text change in the document body (anywhere), to
   force LyX to recompile. Repeat the previous step. The key line in
   the .tex file is unchanged.
3. In Document > Settings... > LaTeX Preamble, add a space at the end
   of the preamble and repeat the first step. The line in the .tex file
   changes to "\usepackage[style=authoryear,backend=bibtex8]{biblatex}"
   (i.e., the "backend" setting is added).

This also happens if I edit the text in the \lehead{}, \rohead{}, 
\refoot{} or \lofoot{} commands, or if I insert \usepackage{} in the 
preamble, or basically if I make any non-fatal change to the preamble.


It makes no sense to me that any of those changes would affect 
bibliography processing.


Paul

1.





dev_mwe.lyx
Description: application/lyx
% Encoding: UTF-8
@comment{x-kbibtex-encoding=utf-8}

@Article{VanDoornik2019,
  author   = {Van Doornik, D.M. and Kuligowski, D.R. and Morgan, C.A. and Burke, B.J. and Seamons, T.R.},
  journal  = {Fishery Bulliten},
  title= {Insights, from genetic analyses, into stock-specific distribution of juvenile steelhead (Oncorhynchusmykiss) from the Columbia River during early marine migration},
  year = {2019},
  doi  = {10.7755/FB.117.1-2.11},
  pages= {97--106},
  volume   = {117},
  abstract = {For anadromous Pacific salmon (Oncorhynchus sp.), ocean conditions during their initial entry into the marine environment can greatly affect their survival. Different life history types or stocks may experience different conditions during their marine entry because routes of early marine migration can differ among types or stocks. Steelhead (O. mykiss) from the For anadroumous Pacific salmon (Oncohrynchus sp.) ocean salmon (Oncorhynchus sp.), ocean conditions during their initial entry into the marine environment can greatly affect their survival. Different life history types or stocks may experience different conditions during their marine entry because routes of early marine migration can differ among types or stocks. Steelhead (O. mykiss) from the Columbia River are believed to migrate offshore quickly once they enter the ocean, but little is known about whether life history or stock-specific differences in early marine migration exist. We assembled a baseline of steelhead genetic data that allowed us to estimate the genetic stock of origin for juvenile steelhead that had been caught off the coasts of Washington and Oregon in May, shortly after their out-migration from freshwater. We found differences in the average locations of the various genetic stock groups of the Columbia River, dissimilarities that were most likely due to differences in the timing of the marine entry of juveniles. We also observed considerable variation among years in the average location where we caught steelhead and in the number of steelhead caught, results indicating that freshwater or marine conditions can influence the behavior or survival of steelhead.},
  keywords = {fish, Columbia River, ri

Weird compile result -- bug?

[Paul A. Rubin]

Hi all,

Over on the user list, there's a lengthy thread (actually set of 
threads) triggered by user Rich Shepard trying to compile a report whose 
bibliography stubbornly refused to appear. Rich was using biblatex. 
After copies trial and error, Rich got the report to work, but with no 
explanation why.


I was beating on a copy of it (which I am not at liberty to share) and 
discovered that if made any non-fatal change to the preamble, the 
bibliography would show up. In particular, just adding \usepackage{} 
(with the argument deliberately empty) to the preamble in LyX coaxed the 
bibliography to show up.


Comparing the .tex files that LyX exported with and without the 
\usepackage{} command, I discovered two changes. One of course was the 
inclusion of \usepackage{}. The other was that 
\usepackage[style=authoryear]{biblatex} in the original document morphed 
into \usepackage[style=authoryear,backend=bibtex8]{biblatex} in the 
modified document.


So I went to the original document and, in the bibliography settings, 
changed the processor option from default to bibtex8, and sure enough 
the original compiled correctly.


I'm not sure if this is a bug or something the user is responsible for 
knowing (it was news to me, but I never use biblatex). So I'm reporting 
it here to let wiser minds decide.


Paul

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

Re: embedded graphics

[Paul A. Rubin]

On 10/3/21 11:44 AM, Kornel Benko wrote:

Am Sun, 3 Oct 2021 11:29:02 -0400
schrieb "Paul A. Rubin" :


On 10/3/21 11:08 AM, Jürgen Spitzmüller wrote:

Am Sonntag, dem 03.10.2021 um 10:48 -0400 schrieb Paul A. Rubin:

Personally, I'd prefer to keep LyX files small and plain text. Also,
wouldn't embedding graphics introduce extra work if the source
graphic was changed? For instance, if I embedded a plot, then later
changed data an reran the plot, I would need to manually update the
LyX file.

I am completely with you, but I think if we could support both (as I
sketched in my mail) and maybe store the user's preference for saving
in session, everybody could be lucky.

Best,
Jürgen



I would be fine with it being an option, preferably with the choice
configurable in each document
and a default choice set in preferences.

The second sentence contradicts the use of
Document->Settings->Save as default


Cheers,
Paul


Kornel




OK, so rather than setting the default in global preferences, I guess it could 
be set
in document settings for whatever template is being used (including the default
document type for File > New).

Paul

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

Re: embedded graphics

[Paul A. Rubin]

On 10/3/21 11:08 AM, Jürgen Spitzmüller wrote:

Am Sonntag, dem 03.10.2021 um 10:48 -0400 schrieb Paul A. Rubin:

Personally, I'd prefer to keep LyX files small and plain text. Also,
wouldn't embedding graphics introduce extra work if the source
graphic was changed? For instance, if I embedded a plot, then later
changed data an reran the plot, I would need to manually update the
LyX file.

I am completely with you, but I think if we could support both (as I
sketched in my mail) and maybe store the user's preference for saving
in session, everybody could be lucky.

Best,
Jürgen


I would be fine with it being an option, preferably with the choice 
configurable in each document and a default choice set in preferences.


Cheers,
Paul

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

Re: embedded graphics

[Paul A. Rubin]

On 10/3/21 8:06 AM, Scott Kostyshak wrote:

On Sun, Oct 03, 2021 at 09:49:34AM +0200, Jürgen Spitzmüller wrote:


As to the request here, this would have the (severe) drawback that the
LyX file is no longer a plain text file.

I really don't know much about this, but couldn't we use some sort of ASCII 
encoding like base64 (https://en.wikipedia.org/wiki/Base64). I think that's 
what some mail programs do (e.g., mutt) to add attachments. Perhaps there is a 
disadvantage that the file size is (much) bigger than using a non-ASCII 
encoding?

Scott

Personally, I'd prefer to keep LyX files small and plain text. Also, 
wouldn't embedding graphics introduce extra work if the source graphic 
was changed? For instance, if I embedded a plot, then later changed data 
an reran the plot, I would need to manually update the LyX file.


The LyX Archive export seems to be a good solution for sharing (or 
archiving) documents.


Paul

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

Re: Magnification of pdf File Created by LYX

[Paul A. Rubin]

On 9/29/21 6:17 PM, Doug Martin wrote:



On Wed, Sep 29, 2021 at 1:24 PM Andrew Parsloe > wrote:


On 30/09/2021 9:03 am, Doug Martin wrote:

Rasmus,

Thanks for your quick response.
Of course one can do what you suggest, and I have done it.

But I do a lot of editing of LYX files and compiling to pdf
(many! times a day), and I want the pdf
file to be at 125% when I open it, and not have to scroll  to get
that.

I did find that there is a LaTeX \mag , e.g., \mag 1200 for
20% increase, but I haven't been
able to succeed using it by opening the LYX file and adding \mag
1200 (or whatever  turns
out to be needed), and saving it, whereupon I get an error.

This adjustment would seem to be something the the LaTeX to pdf
Conveter should control ???

Doug

On Wed, Sep 29, 2021 at 12:23 PM Rasmus K. Rendsvig
mailto:rends...@gmail.com>> wrote:

Dear Doug,

I am sorry if what you are describing is a more complex issue
then I what I hear it to be, but did you try changing the
zoom level in the pdf viewer itself?

Try e.g. pressing the Ctrl and the + keys simultaneously, or
holding Ctrl while scrolling up on your mouse wheel, or
clicking the field that says 56.7% and see if you can change
it there.

Kind regards,
Rasmus


On Wed, 29 Sep 2021, 18:07 Doug Martin, mailto:martinr...@gmail.com>> wrote:

My pdf files compiled from LYX always have 56.7%
magnification, no matter whether I use
different document classes such as Article versus svmono,
and I want them larger by default,
e.g., 125%. I have not found a solution in the User
Guide, and wonder if anyone can explain
how to do this?

Doug Martin

-- 
lyx-devel mailing list

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




-- 
R. Douglas Martin

Professor Emeritus in Applied Mathematics and Statistics
University of Washington


This sounds like a pdf viewer default setting. For instance in
SumatraPDF which I use, under Settings > Options I'm presented
with a small dialogue including the option Default zoom which not
only has things like Fit page, Fit width, Fit content, but a list
of default zoom levels (from 6400% down to 8.33%). For my aging
eyes I use 150% and that is what I get when I view (compile) a LyX
document.

Andrew


Andrew,

I had hoped some time ago that Acrobat Pro would do what your 
SumatraPDF does, but no such luck.
The settings are there in Acrobat Pro that promise to do it, but they 
don't work for a fresh pdf file.
I had pretty good support from Adobe on this problem about a year ago, 
and the only solution provided
was that I print the pdf file to Adobe pdf with settings that I use 
there.  Aside from this being a hassle to do a zillion times a day, it 
somehow removes the nice LYX created TOC from the pdf file.


FYI, I did a random sample of about 10 pdf files downloaded from 
different places, and most of them have large magnifications of about 
150 to 170, except for pdf files produced from LYX by colleagues and 
they seem to always be around 56% or so.


I also sent this problem to Springer tech support (for a book we are 
working on), which has been rather good, almost always providing a 
solution for our book LYX which is an svmono class.  I will forward to 
the list anything useful that I get from Springer.


Thanks,
Doug

-- 
lyx-devel mailing list

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




--
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
University of Washington


Doug,

I don't have Acrobat Pro, just Acrobat Reader (an old version, on 
Linux), so I don't know if this will help. The zoom level at which a 
file should be opened is apparently a property of the file (in some 
cases) and, when present, will override the default zoom setting in 
Reader (and presumably in Acrobat Pro). In Reader, you can go to Edit > 
Preferences... > Accessibility, and in the "Override Page Display" area 
put a check in the box for "Always use Zoom Setting", which activates a 
select box where you can pick your preferred zoom level.


If that fails, another possibility is to specify it in the command line 
that opens the PDF file. With Acrobat Reader 9 on Linux, the command 
would be


acroread /a "zoom=150=OpenActions" 

and you could either create a script/batch file to open PDFs or, if the 
issue is mainly when viewing a PDF from LyX, you could go (in LyX) to 
Tools > Preferences... > File 

Re: SSL certificate error

[Paul A. Rubin]

On 6/7/21 4:53 PM, Ricardo Berlasso wrote:

Hi, people,

Today, trying to enter https://www.lyx.org/  I 
get a SSL certificate error:


SEC_ERROR_EXPIRED_CERTIFICATE

Is it a known problem?

Regards,
Ricardo

I can confirm this. Apparently it expired today (June 7) at 17:26:04 
GMT. I'm cc-ing this to the dev list.


Paul

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

Re: Bug(?) when creating an align* with Ctrl+Return.

[Paul A. Rubin]

On 4/15/21 4:19 AM, Andrew Parsloe wrote:

Windows 10, LyX 2.4.0-alpha3 and 2.3.6.

Given a formula $ a=b=c $ position the cursor after the b and press 
Ctrl+Return. In LyX 2.4.0-alpha3 this produces

\begin{align*}
a & =b=c\\
\end{align*}
and leaves the cursor after the c. The cursor positioning and failure 
to transfer the part of the formula after the cursor to the newly 
created line seem like bugs to me.


In the align* formula again position the cursor after the b and press 
Ctrl+Enter. This time the result is

\begin{align*}
a & =b\\
 & =c\\
\end{align*}
with the cursor remaining just after the b. Except for the extra \\ 
(displaying in LyX as two empty blue boxes) this is what I expected 
the first time.


Andrew

Confirmed here (same two LyX versions, OS=Linux Mint), and I agree that 
Ctrl+Enter should split the equation at the cursor position in the first 
case.


Paul

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

Issue with find next in 2.4 Alpha 2

[Paul A. Rubin]

Hi all,

I just installed 2.4 Alpha 2 on Linux Mint 20.1 using Liv's repo. Since 
there's been some discussion of "find next" (or "find again") on the 
user list, I thought I'd give it a try. It seems to be slightly broken 
in 2.4 (okay in 2.3.6.1).


Test process:

1. Open a document.
2. Use Ctrl-F to open the find/replace dialog. Enter a term known to
   occur more than once in the doc. Click "Find Next".
3. With no further mouse clicks (so that focus remains on the
   find/replace dialog, and the search term remains highlighted in the
   dialog), type Alt+N. Expected behavior: the next occurrence of the
   search word is highlighted.

With 2.3.6.1, this works as expected. The search term remains 
highlighted in the dialog, there is a visual cue that the Find Next 
button is selected, and in the document window each Alt+N proceeds to 
the next instance of the search term.


With 2.4 Alpha 2, typing Alt+N toggles between highlighting the search 
term and selecting the Find Next button in the dialog. (These happened 
simultaneously in 2.3.6.1.) Importantly, the first occurrence of the 
search term in the document remains selected; no search for the next 
occurrence happens. Clicking the Find Next button does locate the next 
occurrence.


Paul


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

Re: Page Break vs New Page

[Paul A. Rubin]

On 1/24/21 1:50 PM, Richard Kimberly Heck wrote:

On 1/24/21 1:32 PM, Paul A. Rubin wrote:

On 1/24/21 12:36 PM, Richard Kimberly Heck wrote:

Over on lyx-users, we got a question that uncovered the fact that these
names are not very descriptive. (The user had used Page Break and gotten
surprising results: a very stretched Table of Contents.) The line breaks
have more descriptive names. Is there something else we could use for
Page Break that would indicate what it does? Something like "Page Break
(Stretch Page)" would work, but is kind of long

Riki



I'm no texpert, but I don't think page break (\newpage)

The difference here is between \newpage, which is what New Page gives
you, and \pagebreak, which is what Page Break gives you.



necessarily "stretches" the page in the sense of the problem raised on
the user list.

Both our user guide, section 3.5.5, and this page:

https://latexref.xyz/_005cnewpage.html

say that \pagebreak stretches the page, though it does not always seem
to do so.

Riki

Gotcha. So \pagebreak /may/ stretch the page and \newpage will not 
(hopefully). If the menus in LyX included tool tips, this would be the 
time to use them. Cramming that info into the menu text strikes me as 
difficult to do. I don't know if tool tips have ever been discusses. To 
me, almost all of the menu entries are sufficiently self-explanatory, so 
I've never really missed tool tips. There are a few, though, that would 
benefit from them (and maybe a few more that would help new users but 
would be of no value to seasoned veterans).


Paul


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

Re: Page Break vs New Page

[Paul A. Rubin]

On 1/24/21 12:36 PM, Richard Kimberly Heck wrote:

Over on lyx-users, we got a question that uncovered the fact that these
names are not very descriptive. (The user had used Page Break and gotten
surprising results: a very stretched Table of Contents.) The line breaks
have more descriptive names. Is there something else we could use for
Page Break that would indicate what it does? Something like "Page Break
(Stretch Page)" would work, but is kind of long

Riki


I'm no texpert, but I don't think page break (\newpage) necessarily 
"stretches" the page in the sense of the problem raised on the user 
list. That will depend on document class and context (e.g., table of 
contents or title page v. generic text), won't it? So a name that 
conveys stretching the page contents would be as misleading as a name 
that did not convey that (maybe more so, given the relative frequency of 
stretched v. unstretched pages).


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

Re: [CONFIRMED] Delimiter issue in 2.3.6.1 and in master

[Paul A. Rubin]

On 1/22/21 12:03 PM, Richard Kimberly Heck wrote:

On 1/22/21 11:17 AM, Pavel Sanda wrote:

On Thu, Jan 21, 2021 at 06:16:25PM -0500, Richard Kimberly Heck wrote:
the problem happens. It looks as if the images are not properly 
aligned and

maybe the top got cut off for some reason.
Does it get better if you increase DelimiterUi->LeftLW->iconSize by 
couple pixels?


It's being cached somewhere, I think. It does not happen on my desktop 
with a new user, though it does happen with the existing user (me!). 
Same machine, libraries, etc.


Riki


Same thing here (Linux Mint 20.1 Mate) -- icons are correct for a new 
user but buggered for me. They don't seem to be cached under /.lyx. 
Does Qt cache stuff somewhere?


Paul (aka original troublemaker)

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

Re: [CONFIRMED] Delimiter issue in 2.3.6.1 and in master

[Paul A. Rubin]

On 1/21/21 4:44 PM, Richard Kimberly Heck wrote:

On 1/21/21 3:07 PM, Paul A. Rubin wrote:
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a 
possible (minor) bug that I'd like someone to confirm. Create a math 
inset and click the toolbar button to insert paired delimiters. The 
lfloor and rfloor delimiters look correct to me, but the lceil and 
rceil delimiters are just vertical lines (no horizontal "flanges"). 
Anyone else seeing that?


Yes, I see it, and in master too. Screenshot attached.

Riki


Thanks. Thought I was losing it (which I suppose I still might be). I've 
filed a bug report (Ticket #12085) and attached your screenshot (with 
attribution, of course).


Paul

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

Delimiter issue in 2.3.6.1

[Paul A. Rubin]

I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible 
(minor) bug that I'd like someone to confirm. Create a math inset and 
click the toolbar button to insert paired delimiters. The lfloor and 
rfloor delimiters look correct to me, but the lceil and rceil delimiters 
are just vertical lines (no horizontal "flanges"). Anyone else seeing that?


Paul

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

Re: Feature Request from Doug Martin and Tom Philips

[Paul A. Rubin]

On 1/19/21 12:03 PM, Doug Martin wrote:

Scott (and all),

I have attached the LYX segment from one of our book chapters, along 
with a page from the compiled pdf file that contains

the resulting Table TS-2.1.

This tiny example illustrates how we currently make most of our tables 
using the kableExtra package (kable is included in knitr),
and if we had an R script to produce an LYX Table with the data frame 
(or data.table) as input, we would surely use it.


FYI, in case you want to compile the LYX file, you just need to strip 
out the Springer svmono (book templates) stuff, etc., in the
LaTeX preamble, install knitr and kableExtra from CRAN, and install 
the optimalPsiRho package with:


devtools::install_github("kjellpk/optimalRhoPsi").

Just before sending this I noticed the several other emails on the 
topic, and will take a look at them.


Thanks,
Doug

On Mon, Jan 18, 2021 at 11:27 AM Scott Kostyshak <mailto:skost...@lyx.org>> wrote:


On Mon, Jan 18, 2021 at 11:03:49AM -0800, Doug Martin wrote:
> On Mon, Jan 18, 2021 at 10:41 AM Scott Kostyshak
mailto:skost...@lyx.org>> wrote:
>
> > On Mon, Jan 18, 2021 at 07:25:42PM +0100, Jean-Marc Lasgouttes
wrote:
> > > Le 14/01/2021 à 05:34, Doug Martin a écrit :
> > > > JMarc and all,
> > > >
> > > > Tom and I use knitr extensively for R code chunks, and we
mostly use
> > > > kable with kableExtra to make tables.
> > > > The input to kable are R data frames, or data.tables,
which are the
> > > > result of model fitting and related calculations.
> > > > But we like to put mathematical expressions in selected
cells of
> > tables,
> > > > which is so easy with LYX tables, and we currently
> > > > have to make the data entry into LYX by hand from data
tables and
> > > > data.tables in order to make use of that feature.
> > > > So it would be great if we could import R data tables and
data.tables
> > > > into LYX tables, rather than using the kable/kableExtra
> > > > solution for our tables  (maybe I didn't make that clear
in my earlier
> > > > email).  Then we would probably would drop use of
> > > > kable/kableExtra.
> > >
> > > So you want to import as .tex the result of R processing.
This can be
> > done
> > > via "Paste from LaTeX". What would be missing for your
intended usage?
> >
> > From what I understand, they would like to import a .Rds file
without
> > having to manually convert it to LaTeX.
> >
>
> Scott,
>
> Definitely correct on the "without" part.  But we want to
directly import
> an R object
> of class data.frame or data.table into an LYX table.
>
> If we have to export such an object first, we would typically
export it to
> an .Rda object.
> But it would be far more convenient to not have to do that.

Thanks for the clarification, Doug. It might help us to have a
complete,
simple, example to play with. Can you give us the .lyx file and R
code/file? To make things perfectly clear to us, it might help to give
us a "before" version of the .lyx file and an "after" version of the
.lyx file. To create the "after" version you would have to do the
steps
manually, but by seeing it we could make sure we understand what you
want to automate and what you expect the result to be.

Thanks for your patience,

Scott



--
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
Founder and Former Director of MS-CFRM Program
depts.washington.edu/compfin/ <http://depts.washington.edu/compfin/>
University of Washington


Doug,

If I am understanding your example correctly, you actually redo the R 
calculations each time you compile the LyX document. Is that a desired 
feature, or would you be just as happy running the R code once and 
parking the generated table in the LyX document? I ask because elsewhere 
in the thread I pointed out (in a reply to Riki) that one can use a 
custom R function (which you could set up to load by default whenever 
you crank up R) to convert a data frame or table to LaTeX and copy the 
LaTeX code to the clipboard. After that, all you have to do is paste it 
into your open LyX document using the correct LyX command, and it goes 
in as a table.


Paul

--
Paul A. Rubin, Professor Emeritus
The Eli Broad College of Business
Michigan State University
Email: ru...@msu.edu <mailto:ru...@msu.edu>
Home page: https://rubin.msu.domains/
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Feature Request from Doug Martin and Tom Philips

[Paul A. Rubin]

On 1/18/21 5:12 PM, Richard Kimberly Heck wrote:

On 1/18/21 2:49 PM, Paul A. Rubin wrote:

On 1/18/21 2:03 PM, Doug Martin wrote:



On Mon, Jan 18, 2021 at 10:41 AM Scott Kostyshak <mailto:skost...@lyx.org>> wrote:


On Mon, Jan 18, 2021 at 07:25:42PM +0100, Jean-Marc Lasgouttes
wrote:
> Le 14/01/2021 à 05:34, Doug Martin a écrit :
> > JMarc and all,
> >
> > Tom and I use knitr extensively for R code chunks, and we
mostly use
> > kable with kableExtra to make tables.
> > The input to kable are R data frames, or data.tables, which
are the
> > result of model fitting and related calculations.
> > But we like to put mathematical expressions in selected
cells of tables,
> > which is so easy with LYX tables, and we currently
> > have to make the data entry into LYX by hand from data
tables and
> > data.tables in order to make use of that feature.
> > So it would be great if we could import R data tables and
data.tables
> > into LYX tables, rather than using the kable/kableExtra
> > solution for our tables  (maybe I didn't make that clear in
my earlier
> > email).  Then we would probably would drop use of
> > kable/kableExtra.
>
> So you want to import as .tex the result of R processing. This
can be done
> via "Paste from LaTeX". What would be missing for your
intended usage?

From what I understand, they would like to import a .Rds file
without
having to manually convert it to LaTeX.


Scott,

Definitely correct on the "without" part.  But we want to directly 
import an R object

of class data.frame or data.table into an LYX table.

If we have to export such an object first, we would typically export 
it to an .Rda object.

But it would be far more convenient to not have to do that.

Doug


Scott



--
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
Founder and Former Director of MS-CFRM Program
depts.washington.edu/compfin/ <http://depts.washington.edu/compfin/>
University of Washington


Doug,

I'm not sure that what you want (direct import without first 
exporting) is possible. Keep in mind that the source data frames / 
tables live inside an R session, to which LyX probably does not have 
access. So I'm pretty sure you will need to manually export the R 
objects, either by saving to .Rda files (and then importing them into 
a LyX document using a converter) or by running an R function/script 
that converts them to LaTeX or LyX source (or something else LyX can 
ingest).


Presumably one could script the R session itself so that the needed 
object was exported? I.e., can one do that from the command line? 
That's the kind of thing that an external template would do.


Riki



Riki,

What do you have in mind by "external template"? Definitely you can 
export objects from within the R session, whether it is done by entering 
a line of code at the command line, or adding code to a script or 
notebook, or doing something interactive from within a Shiny web 
interface or an IDE. It seems they are currently doing that now (with 
kable()). What I don't think is possible is to have both LyX and an R 
session running, go to LyX, and run a command sequence or script that 
would say "go into my R session, grab the data frame named 'results', 
and import it as a LyX table". Specifically, I don't think the "go into 
my R session" part is doable.


With the right stuff installed, I think a viable option is to use the 
clipboard. I'll use the (in)famous iris data frame (which comes 
preinstalled in R) as an example. Assume that I have both R and LyX 
open, and the 'clipr' and 'xtable' R packages loaded. The command 
'write_clip(capture.output(xtable(iris)))' formats the iris data frame 
as a LaTeX table and crams it into the system clipboard. In the LyX 
document, Edit > Paste Special > Paste from LaTeX imports it as a table 
(in a float inset, which can be dissolved if not wanted). The R command 
can be made into a function that can be loaded automatically when an R 
session starts, and I'm pretty sure I could turn it into an add-in with 
a shortcut in RStudio. Note that this would not require any changes to LyX.


Paul

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

Re: Feature Request from Doug Martin and Tom Philips

[Paul A. Rubin]

On 1/18/21 2:03 PM, Doug Martin wrote:



On Mon, Jan 18, 2021 at 10:41 AM Scott Kostyshak <mailto:skost...@lyx.org>> wrote:


On Mon, Jan 18, 2021 at 07:25:42PM +0100, Jean-Marc Lasgouttes wrote:
> Le 14/01/2021 à 05:34, Doug Martin a écrit :
> > JMarc and all,
> >
> > Tom and I use knitr extensively for R code chunks, and we
mostly use
> > kable with kableExtra to make tables.
> > The input to kable are R data frames, or data.tables, which
are the
> > result of model fitting and related calculations.
> > But we like to put mathematical expressions in selected cells
of tables,
> > which is so easy with LYX tables, and we currently
> > have to make the data entry into LYX by hand from data tables and
> > data.tables in order to make use of that feature.
> > So it would be great if we could import R data tables and
data.tables
> > into LYX tables, rather than using the kable/kableExtra
> > solution for our tables  (maybe I didn't make that clear in my
earlier
> > email).  Then we would probably would drop use of
> > kable/kableExtra.
>
> So you want to import as .tex the result of R processing. This
can be done
> via "Paste from LaTeX". What would be missing for your intended
usage?

From what I understand, they would like to import a .Rds file without
having to manually convert it to LaTeX.


Scott,

Definitely correct on the "without" part.  But we want to directly 
import an R object

of class data.frame or data.table into an LYX table.

If we have to export such an object first, we would typically export 
it to an .Rda object.

But it would be far more convenient to not have to do that.

Doug


Scott



--
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
Founder and Former Director of MS-CFRM Program
depts.washington.edu/compfin/ <http://depts.washington.edu/compfin/>
University of Washington


Doug,

I'm not sure that what you want (direct import without first exporting) 
is possible. Keep in mind that the source data frames / tables live 
inside an R session, to which LyX probably does not have access. So I'm 
pretty sure you will need to manually export the R objects, either by 
saving to .Rda files (and then importing them into a LyX document using 
a converter) or by running an R function/script that converts them to 
LaTeX or LyX source (or something else LyX can ingest).


Note that if you do your R work in an IDE, such as RStudio, you could 
probably set up an addin / plugin /  to do 
the export by invoking a shortcut.


Paul

--
Paul A. Rubin, Professor Emeritus
The Eli Broad College of Business
Michigan State University
Email: ru...@msu.edu <mailto:ru...@msu.edu>
Home page: https://rubin.msu.domains/
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Problem with session handling on Linux

[Paul A. Rubin]

On 12/7/20 6:20 AM, José Abílio Matos wrote:


On Monday, December 7, 2020 10:04:03 AM WET Pavel Sanda wrote:

> Can you reproduce your problem with kill -9 $LYXPID ?

>

> Pavel


Yes.


In order to define a minimal example do the following.


1) Open LyX with the last opened files.

2) Create a new file and save it (this is important).

3) Kill the lyx instance with signal -9.

4) Reopen lyx and no file will be open we see only the spash screen.


Can you reproduce this?


Best regards,

--

José Abílio




I can reproduce it (Linux Mint 20, LyX 2.3.5.2). I used "pkill lyx" 
rather than "kill -9 ...", which probably makes no difference.


Paul

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

Re: New bug in change tracking?

[Paul A. Rubin]

On 7/26/20 5:56 AM, Enrico Forestieri wrote:

On Sat, Jul 25, 2020 at 05:43:59PM -0400, Paul A. Rubin wrote:

Can someone confirm that (a) I'm not hallucinating and (b) this is a new bug
(I couldn't find it in the issue tracker)? Create a test file with any text,
and turn on change tracking. Then change fonts on some words (italics, bold,
san serif, ...). None of the font changes are flagged as changes. Adding or
deleting characters still register as normal.

You are not hallucinating, and it has always been like that since the
beginning. Just checked it with lyx 1.4.


Thanks Enrico. I guess I'll file a ticket for it.

Paul

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

New bug in change tracking?

[Paul A. Rubin]

Can someone confirm that (a) I'm not hallucinating and (b) this is a new 
bug (I couldn't find it in the issue tracker)? Create a test file with 
any text, and turn on change tracking. Then change fonts on some words 
(italics, bold, san serif, ...). None of the font changes are flagged as 
changes. Adding or deleting characters still register as normal.


This is LyX 2.3.5-1 on Linux Mint 19.3.

Paul

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

Re: Bug or feature? [Change Tracking]

[Paul A. Rubin]

On 5/9/20 1:05 AM, Jürgen Spitzmüller wrote:

Am Freitag, den 08.05.2020, 17:14 -0400 schrieb Richard Kimberly Heck:

On 5/8/20 1:54 PM, Paul A. Rubin wrote:


Before I file a ticket on this, I'd like to get a sense of whether
it
is in fact a bug v. intended behavior.
Consider a document with an activated branch containing text that
has
been edited, and with change tracking turned on. The user wants to
dissolve the branch but retain the content. If the user does this
with
change tracking turned on, the entire branch gets crossed out and
the
full contents gets reproduced, which is a bit clunky to put it
mildly.
If the user turns off change tracking before dissolving the branch
inset, the branch contents are retained but none of the change
information survives. In particular, if the user has replaced one
word
with another, both words will survive in the latter case.
I tripped over this recently. My preferred behavior would be that
(with tracking temporarily turned off) dissolving the inset would
preserve the contents including tracking info. Am I off base here?


I would also think that is what should happen. A whole lot has been
done

in master on change tracking by Jürgen, though, so this may be be
fixed.

Yes: https://www.lyx.org/trac/ticket/10128

Jürgen


Great!

Paul

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

Bug or feature?

[Paul A. Rubin]

Before I file a ticket on this, I'd like to get a sense of whether it is 
in fact a bug v. intended behavior.


Consider a document with an activated branch containing text that has 
been edited, and with change tracking turned on. The user wants to 
dissolve the branch but retain the content. If the user does this with 
change tracking turned on, the entire branch gets crossed out and the 
full contents gets reproduced, which is a bit clunky to put it mildly. 
If the user turns off change tracking before dissolving the branch 
inset, the branch contents are retained but none of the change 
information survives. In particular, if the user has replaced one word 
with another, both words will survive in the latter case.


I tripped over this recently. My preferred behavior would be that (with 
tracking temporarily turned off) dissolving the inset would preserve the 
contents including tracking info. Am I off base here?


Thanks for any feedback,
Paul

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

Re: Import v. Insert

[Paul A. Rubin]

On 2/25/20 10:47 AM, Paul A. Rubin wrote:
There's a thread on the user list from someone running LyX 2.3.4.2 on 
Ubuntu 18.04.4. The File > Import File > LaTeX (plain) file dialog 
fails to show .tex files with the default (LaTeX) file filter, but 
does show them with the "all files" filter. In contrast, Insert > File 
> Child document ... dialog with the default filter (LaTeX/LyX 
documents) does seem to work for him.


Can anyone point to a difference in how the file filters are set up 
that might provide a clue. FWIW, I am unable to reproduce the problem 
on Mint (which is Ubuntu-based), but my file dialogs look 
substantially different from his (and not just because er spricht 
Deutsch). Could this be a Qt setting issue?


TIA,
Paul


Never mind -- my namesake Pavel sorted it out.

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

Import v. Insert

[Paul A. Rubin]

There's a thread on the user list from someone running LyX 2.3.4.2 on 
Ubuntu 18.04.4. The File > Import File > LaTeX (plain) file dialog fails 
to show .tex files with the default (LaTeX) file filter, but does show 
them with the "all files" filter. In contrast, Insert > File > Child 
document ... dialog with the default filter (LaTeX/LyX documents) does 
seem to work for him.


Can anyone point to a difference in how the file filters are set up that 
might provide a clue. FWIW, I am unable to reproduce the problem on Mint 
(which is Ubuntu-based), but my file dialogs look substantially 
different from his (and not just because er spricht Deutsch). Could this 
be a Qt setting issue?


TIA,
Paul

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

Re: Mailing list subscriptions

[Paul A. Rubin]

On 1/27/20 6:37 PM, Jean-Marc Lasgouttes wrote:

Le 02/12/2019 à 01:08, Paul A. Rubin a écrit :
I just got a monthly "mailman" reminder about my subscriptions to the 
lyx-devel and lyx-users lists (complete with passwords). It did not, 
however, mention the lyx-announce list, to which I was subscribed 
before the list hosting moved. Just to be safe, I tried to register 
my address, but got an email warning that the address was already 
registered.


Did the announce list not move when the others did? If it did, then 
it appears that my address is registered but mailman doesn't know it 
(?).


Hello Paul,

Indeed, the reminders were shut off for this list, I am not sure why.

This should be OK now.

JMarc
Thanks JMarc. I guess the acid test will be when the release message for 
the next version goes out.


Paul

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

Mailing list subscriptions

[Paul A. Rubin]

I just got a monthly "mailman" reminder about my subscriptions to the 
lyx-devel and lyx-users lists (complete with passwords). It did not, 
however, mention the lyx-announce list, to which I was subscribed before 
the list hosting moved. Just to be safe, I tried to register my address, 
but got an email warning that the address was already registered.


Did the announce list not move when the others did? If it did, then it 
appears that my address is registered but mailman doesn't know it (?).


Paul

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

Re: Missing conference emails

[Paul A. Rubin]

On 11/11/19 3:54 PM, Pavel Sanda wrote:

Hi,

I just discovered that I am not receiving some of lyx conference emails
(and I checked my spam folders to be sure).

E.g. Jose's answer to my email never made it back to me:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg209862.html
or last email from P Rubin on users list is missing here as well:
https://www.mail-archive.com/lyx-users@lists.lyx.org/msg109916.html

Could few other people check whether their mailboxes are in sync with
https://www.mail-archive.com/lyx-users@lists.lyx.org/ or
https://www.mail-archive.com/lyx-devel@lists.lyx.org/
or our switch to new conference engine has some problems?

Pavel

Pavel,

I just looked at the developer list archive and noticed a response from 
JMarc to the message preceding yours (window graphics not updating). In 
it, he appears to be saying that he's moderating the list pending 
solution of a spam problem. Might that be the problem?


Before the server switch, I was getting messages out of order ... by 
days. I would routinely see replies days, possibly a week or so, before 
seeing the messages to which they were replying. Since the server 
switch, I have not noticed that problem. As best I can tell, my 
mailboxes match the archives for both lists.


Paul

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

Re: Email lists

[Paul A. Rubin]

On 9/26/19 6:07 PM, Wierdl Máté wrote:

Guys,

In the last couple of days, there were some problems with the lyx 
email listserv accessing the network at my university. Sorry about 
that.  I think the issue is now resolved.


On the other hand, all the lyx lists will be moved from my university 
(U of Memphis) to a more stable environment at Ohio State University.  
This will happen next week sometimes.  There may be some more 
disruptions, as a result, but I really hope, that would last only one 
day.  I'll send a message to the list when the move begins, hence you 
can expect some disruptions.


Sry and best,

Máté
Thanks for the update (which appeared twice, so the issues may be 
continuing).


Paul

Mailing list adventures

[Paul A. Rubin]

Hi all,

Is someone in charge of smacking the listserv when it gets ornery? I've 
been having intermittent delivery failure problems (on the inbound-to-me 
side) for quite a while, including seeing replies to messages long 
before I see the original messages. I just got an email from user Rich 
Shepard. He had problems posting to the list, which he thinks he has 
fixed, but not he's not getting any posts to the [user] list. The last 
one I got was two days ago, so I don't know if the listserv is on 
vacation or it's just a mildly slow time for user posts.


Anyway, is there a person whose contact info I can pass to Rich?

Thanks,
Paul

Re: Note formatting bug?

[Paul A. Rubin]

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

Bug in external preamble edit

[Paul A. Rubin]

FYI, I just filed a ticket (#11640 
) on a bug in the new preamble 
external edit feature. For some odd reason, the file path is 
(tmp/lyx_tmpdir...) is passed correctly to one editor (xed), but the "t" 
in "tmp" is lopped off when passing it to another editor (notepad).


Paul

Re: Approve links on Wiki

[Paul A. Rubin]

On 5/12/19 3:38 AM, Jürgen Spitzmüller wrote:

Could some kind soul please provide me with the password that is needed
on the Wiki in order to approve links?

Thanks
Jürgen

Replied directly (hopefully with the correct pw).

Paul

Re: Reconfigure does not work for a specific user directory

[Paul A. Rubin]

On 3/10/19 8:47 PM, Scott Kostyshak wrote:

Attached is a user directory. I believe I happened to create it from a
weird situation. Maybe TeX Live was half-way installed or something like
that. In any case, LyX won't compile to PDF with pdflatex when this user
directory is used. That's probably not too strange. But when I
reconfigure and restart, LyX still doesn't want to compile to PDF with
pdflatex. Note that LyX will compile to PDF with lualatex. The
configure.log contains the following:

   INFO: checking for the pdflatex program...
   INFO: +checking for "pdflatex"...  yes

so I'm not sure why the button is greyed out.

To reproduce:

1. tar -xzf userdir123.tar.gz && lyx -userdir ./userdir123
2. Note that you cannot compile a simple "hello" document to PDF with pdflatex.
3. Reconfigure and restart.
4. You still cannot compile a simple "hello" document to PDF with pdflatex.

I can reproduce on 2.3.x and on master. Can anyone else reproduce?

I'm unsure if this is worth looking into since I think the user
directory was the result of a strange situation. But I remember seeing
reports where a reconfigure doesn't solve anything but removing the
directory does, so perhaps this situation is common in some way.

Scott
Confirmed on LyX 2.3.2. The converters for both LaTeX (pdflatex) to PDF 
(pdflatex) and LaTeX (plain) to DVI are missing in the Tools > 
Preferences... dialog. Both appear in the preferences file in your 
directory, but that file looks odd, and in particular lacks the opening 
comment about being created by LyX.


Comparing the configuration log in your directory to my normal one, and 
ignoring a few minor differences, yours contains a whole bunch of checks 
for document classes beginning with "test". For example:

INFO: +checking for document class testbraille [testbraille]... no
Mine has none of those. I'm not sure if this is significant. On the 
other hand, my  lyxrc.defaults and yours are identical (at least after I 
reconfigured in your directory).


At any rate, I tried editing the lines relating to the pdflatex and DVI 
converters out of the preferences file in your directory. After that 
(and a restart of LyX from that directory), both pdflatex and DVI output 
worked. So I think the problem is the odd (if not mangled) preferences file.


Paul

Re: File import error

[Paul A. Rubin]

On 3/2/19 3:16 PM, Richard Kimberly Heck wrote:

On 3/2/19 11:55 AM, Paul A. Rubin wrote:

On 3/2/19 7:58 AM, Jean-Marc Lasgouttes wrote:

Le 01/03/2019 à 21:43, Paul A. Rubin a écrit :

I have no idea if this makes a difference, but just in case it
triggers a thought: my desktop (where the issue never manifests) has
Qt 4.8.7 and 5.5.1 installed; my laptop (where the problem manifests
if I do not override the native dialog setting) has Qt 4.8.7 and
5.9.5. LyX uses 4.8.7 on both machines (or so it claims), so I would
not think the Qt 5 version would make a difference ... but lacking a
rational explanation for the difference in behaviors, who knows?

Also, is there any place where a Qt configuration file would be
stored that would explain why the native true/false thing has no
impact on my desktop but a big impact on my laptop? (All I know
about Qt is the spelling.)

What may be relevant is your desktop environment. In gnome, it will
be the gnome file dialog, in KDE the KDE file dialog, and may be others.

JMarc

I agree that the environment matters in general, but in this case
three different systems running Mint + MATE (which I believe is a
Gnome derivative) produced two different dialogs, one of which is
apparently the "native" dialog (based on the new configuration
setting) and one of which is not.

So which one seems to work, and which one does not?
Mint 19.1 (MATE): Problem occurs; setting "\use_native_dialog false" 
fixes it.
Mint 18.3 (MATE): Problem does not occur; setting neither 
"\use_native_dialog false" nor "\use_native_dialog true" changes anything.
Mint 18.1 (Cinnamon and MATE): Problem occurs; haven't heard yet from OP 
if "\use_native_dialog false" fixes it.
Ubuntu 18.04 (not sure of the environment): Problem occurs; haven't 
heard yet if "\use_native_dialog false" fixes it.


I believe you are able to compile LyX yourself, yes?
Theoretically. I've never compiled LyX myself; I always wait for Liviu 
to do the deed.

  Assuming so, we can
probably produce some debug code that might throw more light on this.
Well, if anybody wants to produce an Ubuntu Xenial-compatible binary 
with the debug code, I'm happy to give it a try here.


Paul

Re: File import error

[Paul A. Rubin]

On 3/1/19 5:47 PM, Scott Kostyshak wrote:

On Fri, Mar 01, 2019 at 03:43:08PM -0500, Paul A. Rubin wrote:


I have no idea if this makes a difference, but just in case it triggers a
thought: my desktop (where the issue never manifests) has Qt 4.8.7 and 5.5.1
installed; my laptop (where the problem manifests if I do not override the
native dialog setting) has Qt 4.8.7 and 5.9.5. LyX uses 4.8.7 on both
machines (or so it claims), so I would not think the Qt 5 version would make
a difference ... but lacking a rational explanation for the difference in
behaviors, who knows?

You could compare the output of "ldd" on the binaries. Maybe this will
work:

   ldd "$(which lyx)"
Both the desktop and laptop show libQtGui.so.4 and libQtCore.so.4 
(apparently the same versions), and in fact almost all the dependencies 
are the same. They have different versions of libhunspell and libpng 
(which I'm pretty confident have nothing to do with this), and for some 
reason the laptop shows a dependency on libbsd that the desktop does not 
have.


Not sure what else to look at. Do both use the same file system? I think
you can figure this out with the following command:

   df -h 
The option is actually -Th (in case anyone else is poking at this), and 
yes, they're the same (ext4).


So I remain baffled by the difference. (Fortunately, I've had plenty of 
experience at being baffled.)


Paul

Re: File import error

[Paul A. Rubin]

On 3/2/19 7:58 AM, Jean-Marc Lasgouttes wrote:

Le 01/03/2019 à 21:43, Paul A. Rubin a écrit :
I have no idea if this makes a difference, but just in case it 
triggers a thought: my desktop (where the issue never manifests) has 
Qt 4.8.7 and 5.5.1 installed; my laptop (where the problem manifests 
if I do not override the native dialog setting) has Qt 4.8.7 and 
5.9.5. LyX uses 4.8.7 on both machines (or so it claims), so I would 
not think the Qt 5 version would make a difference ... but lacking a 
rational explanation for the difference in behaviors, who knows?


Also, is there any place where a Qt configuration file would be 
stored that would explain why the native true/false thing has no 
impact on my desktop but a big impact on my laptop? (All I know about 
Qt is the spelling.)


What may be relevant is your desktop environment. In gnome, it will be 
the gnome file dialog, in KDE the KDE file dialog, and may be others.


JMarc
I agree that the environment matters in general, but in this case three 
different systems running Mint + MATE (which I believe is a Gnome 
derivative) produced two different dialogs, one of which is apparently 
the "native" dialog (based on the new configuration setting) and one of 
which is not.


Paul

Re: File import error

[Paul A. Rubin]

On 3/1/19 12:46 AM, Scott Kostyshak wrote:

On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote:

On 2/28/19 9:24 PM, Scott Kostyshak wrote:

On Thu, Feb 28, 2019 at 05:03:45PM -0500, Paul A. Rubin wrote:


I don't see anything like this in the bug tracker. Any suggestions on
something I can test here? Should I file a bug report?

As JMarc mentioned on the lyx-users thread, are there any differences in
preferences?

Scott

I can't find a switch for using native dialogs in the Tools > Preferences...

I don't think it is accessible from the GUI (but not sure of that
claim).


dialog, and I can't find any reference to it in any file in either
/usr/share/lyx or ~/.lyx (including subdirectories). Any suggestions where I
should look?

You don't need to look here, but this is the commit that introduced it:

   af795b80


Is this in 2.3.2? (FWIW, the version I have lists the build
date as 12/08/18.)

Yes the setting does apply for 2.3.x

You can just test with the following added to your preferences file:

   \use_native_filedialog false

and also try with

   \use_native_filedialog true

Any difference in behavior regarding this bug, between those two?

By the way, is the bug 100% reproducible on the system that has it? Can
you see *any* .tex files? Does it depend on the directory you're in?

I just tested but can't reproduce.

Scott
I have no idea if this makes a difference, but just in case it triggers 
a thought: my desktop (where the issue never manifests) has Qt 4.8.7 and 
5.5.1 installed; my laptop (where the problem manifests if I do not 
override the native dialog setting) has Qt 4.8.7 and 5.9.5. LyX uses 
4.8.7 on both machines (or so it claims), so I would not think the Qt 5 
version would make a difference ... but lacking a rational explanation 
for the difference in behaviors, who knows?


Also, is there any place where a Qt configuration file would be stored 
that would explain why the native true/false thing has no impact on my 
desktop but a big impact on my laptop? (All I know about Qt is the 
spelling.)


Paul

Re: File import error

[Paul A. Rubin]

On 3/1/19 3:30 PM, Andrew Parsloe wrote:

On 2/03/2019 8:31 AM, Scott Kostyshak wrote:

On Fri, Mar 01, 2019 at 01:45:48PM -0500, Paul A. Rubin wrote:

On 3/1/19 12:46 AM, Scott Kostyshak wrote:

On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote:


Is this in 2.3.2? (FWIW, the version I have lists the build
date as 12/08/18.)

Yes the setting does apply for 2.3.x

You can just test with the following added to your preferences file:

    \use_native_filedialog false

and also try with

    \use_native_filedialog true

Any difference in behavior regarding this bug, between those two?
Yes and no. On my desktop (where the problem does not manifest), 
neither of
those statements has any effect. Not only does the problem not 
occur, but

the file dialog layout/appearance does not change with either.

On my laptop (where the problem does manifest), the true setting 
matches

what is currently happening (with no setting in preferences), while the
false setting switches the dialog layout to match that of my desktop 
and

/gets rid of the problem/ (.tex files appear as expected).

That still leaves unanswered why it happens one place and not the 
other with
the same version of LyX (as best I can tell). I searched both ~/.lyx 
and
/usr/share/lyx (including subdirectories) on both laptop and 
desktop, and

\use_native_filedialog does not appear anywhere.

By the way, is the bug 100% reproducible on the system that has it?

Yes.

   Can
you see *any* .tex files?
No. With the default filter (.tex), only subdirectories appear; no 
files do.

   Does it depend on the directory you're in?

No.

I just tested but can't reproduce.

Interesting! So there seem to be two puzzles from what I understand:

1. Why is the default different on your systems.
2. Why can you only reproduce the bug on one system.


I wondered if this issue might show on a windows 10 laptop. The 
true/false settings produce different dialogues (dialogs?) but the 
.tex files show in both.


Andrew

Different looking dialogs would make sense. It would be interesting to 
know how the file filtering on Windows differs from the file filtering 
on Mint and Ubuntu.


Thanks. It's one more puzzle piece.

Paul

Re: File import error

[Paul A. Rubin]

On 3/1/19 2:31 PM, Scott Kostyshak wrote:


Interesting! So there seem to be two puzzles from what I understand:

1. Why is the default different on your systems.
2. Why can you only reproduce the bug on one system.

I agree.



I am accursed. If there is a bug in any piece of software, no matter how
obscure or hard to trigger, it will bite me. :-( I missed my calling --
should've been an alpha tester.

"First of all, it’s not in your head. [bugs] really do prefer some
people to others"
http://time.com/3311624/why-mosquitoes-bite/

That's another thing. Female mosquitoes adore me. (Female humans, not so 
much.)


Paul

Re: File import error

[Paul A. Rubin]

On 3/1/19 12:46 AM, Scott Kostyshak wrote:

On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote:


Is this in 2.3.2? (FWIW, the version I have lists the build
date as 12/08/18.)

Yes the setting does apply for 2.3.x

You can just test with the following added to your preferences file:

   \use_native_filedialog false

and also try with

   \use_native_filedialog true

Any difference in behavior regarding this bug, between those two?
Yes and no. On my desktop (where the problem does not manifest), neither 
of those statements has any effect. Not only does the problem not occur, 
but the file dialog layout/appearance does not change with either.


On my laptop (where the problem does manifest), the true setting matches 
what is currently happening (with no setting in preferences), while the 
false setting switches the dialog layout to match that of my desktop and 
/gets rid of the problem/ (.tex files appear as expected).


That still leaves unanswered why it happens one place and not the other 
with the same version of LyX (as best I can tell). I searched both 
~/.lyx and /usr/share/lyx (including subdirectories) on both laptop and 
desktop, and \use_native_filedialog does not appear anywhere.


By the way, is the bug 100% reproducible on the system that has it?

Yes.

  Can
you see *any* .tex files?

No. With the default filter (.tex), only subdirectories appear; no files do.

  Does it depend on the directory you're in?

No.


I just tested but can't reproduce.
I am accursed. If there is a bug in any piece of software, no matter how 
obscure or hard to trigger, it will bite me. :-( I missed my calling -- 
should've been an alpha tester.


Paul

Re: File import error

[Paul A. Rubin]

On 2/28/19 9:24 PM, Scott Kostyshak wrote:

On Thu, Feb 28, 2019 at 05:03:45PM -0500, Paul A. Rubin wrote:


I don't see anything like this in the bug tracker. Any suggestions on
something I can test here? Should I file a bug report?

As JMarc mentioned on the lyx-users thread, are there any differences in
preferences?

Scott
I can't find a switch for using native dialogs in the Tools > 
Preferences... dialog, and I can't find any reference to it in any file 
in either /usr/share/lyx or ~/.lyx (including subdirectories). Any 
suggestions where I should look? Is this in 2.3.2? (FWIW, the version I 
have lists the build date as 12/08/18.)


Paul

File import error

[Paul A. Rubin]

A rather mysterious issue has cropped up on the user list, and I'm 
moving it over here hoping someone will have a clue where to look. I'd 
file a bug report, but I'm not entirely sure it's a LyX bug.


Symptom: On some systems, the file dialog opened by File > Import > 
LaTeX (plain)... fails to find .tex files with the default file filter 
(*.tex) but sees them when you switch the filter to all files.


Now comes the goofy part.

 * The original report was by a user of Linux Mint 18 (Sarah), in both
   the Cinnamon and MATE desktop environments, using the version of LyX
   2.3.2 from Liviu's repository, on two different machines.
 * On my desktop (Mint 18.3 Sylvia, MATE, same version of LyX from same
   repo) I cannot reproduce this problem.
 * On my laptop (Mint 19.1 Tessa, MATE, same version of LyX from same
   repo) I can reproduce the problem.
 * Someone else reported the problem on Ubuntu 18.04 (also LyX 2.3.2,
   provenance unknown).

It doesn't seem to be a function of the desktop environment (MATE on 
both my systems), nor to an old versus new OS version (my desktop is a 
newer version the OP's and an older version than my laptop).


It doesn't seem to a function of the Qt version (identical across OP's 
machine and both of mine), nor the specific compilation of LyX (same 
binary, down to the compile date, on both my machines).


I don't think it's a MIME type issue. Both my desktop and my laptop give 
me the same MIME type (text/x-tex) for a .tex file.


I ran LyX with -dbg any on both systems, and both times when I opened 
the import menu item I saw the same info for the file filter:


Select with path "/home/paul", mask "LaTeX (plain) (*.tex);;All Files 
(*)", suggested ""
There is one other oddity, which may or may not be related to the 
problem. Despite the fact that the OP and I are running the same version 
of LyX (2.3.2) built with the same version of Qt (4.8.7) under the same 
desktop environment (MATE) on fundamentally the same OS (Mint), her file 
dialog and the file dialog on my laptop look the same as each other but 
different from the file dialog on my desktop (where things work). The 
layout of controls is a bit different, and on her machine and my laptop 
the filter select control is a button that just says "LaTeX" (with a 
down arrow to change types) whereas on my desktop there is a label field 
and a select control, with the select control entry defaulting to "LaTeX 
(plain) (*.tex)".


I don't see anything like this in the bug tracker. Any suggestions on 
something I can test here? Should I file a bug report?


Thanks,

Paul

Two layout questions

[Paul A. Rubin]

Hi,

I've got two questions about layouts. Attached is an MWE, which contains 
a local layout defining two environments. (Do not try to compile it, as 
the LaTeX names do not correspond to anything.)


Question 1: When I nest the Function inside the Algorithm, I get an 
empty line between the "Begin algorithm" label and the "Function" label. 
Any attempt to delete it screws things up royally. Is there an error in 
the Algorithm style definition causing that?


Question 2: The "End algorithm" label aligns horizontally with the 
"Begin algorithm" label, but the "End function" label is indented (by 
the width of the word "Function") relative to the "Function" label. I 
have no idea why that is happening. Can it be cured?


Thanks,
Paul



mwe.lyx
Description: application/lyx

Re: Layout/auto-nesting help

[Paul A. Rubin]

On 12/29/18 7:43 AM, Jürgen Spitzmüller wrote:

Am Freitag, den 28.12.2018, 17:54 -0500 schrieb Paul A. Rubin:

I've also run into a failure
with Edit > Undo that baffles me.

This is most probably
https://www.lyx.org/trac/ticket/11292

Jürgen

Looks like the fix is in for this problem as well. Thanks.

Re: Layout/auto-nesting help

[Paul A. Rubin]

On 12/29/18 7:40 AM, Jürgen Spitzmüller wrote:

Am Freitag, den 28.12.2018, 17:54 -0500 schrieb Paul A. Rubin:

I'm working on a custom module, and I've bumped into unexpected
difficulties getting autonesting to work. I've also run into a
failure
with Edit > Undo that baffles me. The attached MWE (give or take the
"minimal" part) contains an explanation of what I'm trying to do and
what is going wrong, an example that is correct in the document, and
a
second copy of the example minus a few key bits (to be used as a
"sandbox" if you would care to try things out). The module is in the
local layout section of the document settings, and requires the
algorithmicx.sty LaTeX package.

Thanks for any help or advice.

There were some bugs involved: the problem of the erroneously output
separator and parsing problems of Autonests and IsAutonestedBy with
layout names consisting of blanks or underlines (and also with enquoted
layout names).

These two are fixed now in master, and I hope I can fix them for 2.3.3
as well.

Thanks
Jürgen


Wow, that was quick! Incidentally, I had a suspicion about the blank in 
the layout name, so I tried using a hyphen (which seems to work for 
LyX-Code), but the problem persisted. The modified name 
("Declare-input/output") still contained the forward slash (/), so maybe 
that was also an issue? Hopefully your fix will resolve that as well.


Thanks Jürgen.

Paul

Layout/auto-nesting help

[Paul A. Rubin]

Hi,

I'm working on a custom module, and I've bumped into unexpected 
difficulties getting autonesting to work. I've also run into a failure 
with Edit > Undo that baffles me. The attached MWE (give or take the 
"minimal" part) contains an explanation of what I'm trying to do and 
what is going wrong, an example that is correct in the document, and a 
second copy of the example minus a few key bits (to be used as a 
"sandbox" if you would care to try things out). The module is in the 
local layout section of the document settings, and requires the 
algorithmicx.sty LaTeX package.


Thanks for any help or advice.

Paul



mwe.lyx
Description: application/lyx

Re: One reaction and one question regarding 2.3.2

[Paul A. Rubin]

On 12/20/18 8:18 AM, Daniel wrote:

On 20/12/2018 14:06, Jürgen Spitzmüller wrote:

Am Mittwoch, den 19.12.2018, 19:58 -0500 schrieb Paul A. Rubin:

Assuming this is the new normal for the style dialog, any chance
there could at least be a button at the bottom that would clear all
settings?


In the next release, the dialog will have a "Restore Defaults" button
that will set all widgets to default (and a "Reset" button that will
reset the initial value).

Jürgen



If I understood correctly, Paul would like to have an additional "set 
all to No change" button (which is neither Default nor the initial 
value), so that he can easily set and apply (say) one attribute only 
without changing any other attributes.


(And having all attributes set to "No change" used to be the standard 
in earlier versions of LyX. Hence no (or less) need for such a button 
in previous versions of LyX.)


Daniel

Yes, exactly. So if "defaults" means "change nothing", the "Restore 
Defaults" button is what I would like. If "defaults" means document-wide 
settings, I'm not sure how that would differ from the "Reset" button action.


Paul

One reaction and one question regarding 2.3.2

[Paul A. Rubin]

Hi all,

I just installed 2.3.2 and I have a question regarding change tracking. 
I'm not sure if this is a change in 2.3.2, or if it's always been this 
way and I just never tripped over it. If I have change tracking turned 
on and I change the font of a selection (for instance, by clicking the 
emphasis button, or via the text style dialog), the selection is /not/ 
marked as changed. That's very unhandy ...


... but not as unhandy as the new feature in the text style dialog that 
causes it to pick up the current settings of the selected (rather than 
initializing everything to "No change"). I frequently change just the 
series to bold and then use the apply last style button repeatedly. That 
will now screw up other text that I'm making bold if it has any 
characteristic different from the first text I made bold. Changing each 
of the other boxes in the style dialog to "No change" is a royal PITA. 
Assuming this is the new normal for the style dialog, any chance there 
could at least be a button at the bottom that would clear all settings?


Grump, grump, grump.

Paul

Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics

[Paul A. Rubin]

On 11/5/18 2:32 PM, Jeff Defoe wrote:
I realized I was using the Lyx from the Ubuntu repository. When I 
removed it, added the PPA, and installed LyX from that -- it now seems 
to work.


I do, however, have an odd problem where graphics often don't display 
in LyX, giving errors such as "error loading file into memory" or 
"error converting to loadable format" which I didn't get before 
upgrading to Ubuntu 18.04.


Best regards,

Jeff


One possibility has to do with Imagemagick. I recently opened an old LyX 
file with some EPS graphics, and got the "error converting" message on 
all of them. In Tools > Preferences... > File Handling > Converters, the 
converter for EPS to PNG is correctly configured to use the Imagemagick 
convert command. The catch is that recent versions of Imagemagick 
apparently ship with seriously anal retentive permissions by default. If 
you run "convert something.eps something.png" in a terminal, you get an 
error saying something about not being allowed access.


The fix is to open /etc/Imagemagick-6/policy.xml in an editor, using 
root privileges, and comment out the line "rights="none" pattern="EPS" />". I also commented out the equivalent 
lines for PS, PDF and XPS just to be safe. After that, LyX was able to 
display the EPS images.


Paul

Re: No PDF viewer installed

[Paul A. Rubin]

On 11/1/18 7:56 AM, Daniel wrote:
I am still getting the "No PDF viewer installed" error message when 
"pdfview" is selected as Viewer. I am a bit lost whether this should 
be fixed by now or not in 2.3.1. I saw that the "pdfview" option is 
missing in current master. Maybe that will be the "fix"?


Daniel

I'm using LyX 2.3.1 on Linux Mint. The installed copy of configure.py 
has pdfview at the head of the list of PDF viewer alternatives.


Paul

Re: Paragraph breaks

[Paul A. Rubin]

On 10/23/18 7:16 PM, Jean-Marc Lasgouttes wrote:

Le 23/10/2018 à 21:11, Paul A. Rubin a écrit :
I just tripped over something interesting (LyX 2.3.1), and I'd like 
to make sure it's deliberate before banking on it. I'm working with a 
module that adds various paragraph styles. When I'm in a paragraph 
whose style comes from the "standard" list (e.g., Verbatim or 
Description), if I hit return the new paragraph has the same style, 
while if I execute "paragraph-break inverse" the new paragraph has 
the Standard style. When I'm in a paragraph from my module, it's 
exactly the opposite: return takes me to a Standard paragraph (or, if 
nested, to the style of the nesting environment) but "paragraph-break 
inverse" takes me to an empty paragraph of the same style as the one 
I came from.


Is this intentional?


What is intentional is that the behavior is different between 
environments (which can span over several paragraphs) and commands, 
which do not.


Is this what you are seeing?

JMarc

Ah, I see. So Return and M-Return switch roles, depending on whether the 
current paragraph style is a command or environment. That is what I'm 
seeing, now that I know what to look for. I wonder if this should be 
documented somewhere? The LFUN manual says paragraph-break moves you out 
one level or produces a standard environment; it doesn't say anything 
about whether it is being used in an environment or a command. The User 
Guide has lots of examples, some using Return and some using Alt+Return, 
but I didn't see any guidance as to the rationale for one versus the other.


Anyway, I'm clear on it now. Thanks, JMarc!

Paul

Paragraph breaks

[Paul A. Rubin]

I just tripped over something interesting (LyX 2.3.1), and I'd like to 
make sure it's deliberate before banking on it. I'm working with a 
module that adds various paragraph styles. When I'm in a paragraph whose 
style comes from the "standard" list (e.g., Verbatim or Description), if 
I hit return the new paragraph has the same style, while if I execute 
"paragraph-break inverse" the new paragraph has the Standard style. When 
I'm in a paragraph from my module, it's exactly the opposite: return 
takes me to a Standard paragraph (or, if nested, to the style of the 
nesting environment) but "paragraph-break inverse" takes me to an empty 
paragraph of the same style as the one I came from.


Is this intentional?

Paul

Re: GUI indicator for a command environment

[Paul A. Rubin]

On 10/19/18 8:48 PM, Richard Kimberly Heck wrote:

On 10/19/18 3:46 PM, Paul A. Rubin wrote:

On 10/18/18 9:53 PM, Richard Kimberly Heck wrote:

On 10/18/18 2:01 PM, Paul A. Rubin wrote:

On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:

On 10/17/18 2:35 PM, Paul A. Rubin wrote:

On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:

On 10/17/18 9:30 AM, Paul A. Rubin wrote:

On 10/16/18 10:24 PM, Andrew Parsloe wrote:

On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:

Dear devs,

I'm struggling to cobble together a module supporting the 
pseudocode features of the algorithmicx package. As a 
disclaimer, I'm trying to avoid flex insets and stick to 
environments as much as possible, because there's less 
mousery switching an environment than insert an inset.


Right now, I'm tripping over the for block, which it 
implements by two LaTeX commands: \For{} and 
\EndFor. I can treat those as command styles and get the 
correct output, but the GUI is confusing to the user because 
nothing displays in the line ending the loop (it looks like a 
blank line to the user) and the condition appears in the 
starting line with no visible prefix (so it looks like any 
random statement in the algorithm, unless you notice what the 
environment select box is displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that 
appears in the GUI but /not/ in the compiled output. The 
"handle" for an inset would be fine, as would something like 
a bullet that was GUI-only. Can this be done with the current 
layout/module system?


TIA,
Paul
Is this what you are wanting (from Customization manual 
5.3.7)? (I experimented with this a couple of years ago, so my 
memory of the exact effect is somewhat hazy.)


Andrew

|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]

|Static|
means the label is simply what is declared as
|LabelString|. This will be displayed “inline”, at the
beginning of the paragraph. If the |LatexType| is
|Environment|, then it will be displayed only in the
first paragraph of any sequence of paragraphs with the
same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be
printed above the paragraph either at the beginning of
the line or centered.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command 
type style (and combined with a LabelString argument) it does 
not seem to do anything in either the GUI or the output. I 
tried it with an environment, and I believe the label string 
showed up in the output but not the GUI. (I would have to 
double-check that.)


Try this in Local Layout (to test):

Format 66

Style ForLoop

LatexType Command

LabelType Static

LabelString "ForLoop: "

EndLabelType Static

Margin Static

LeftMargin "ForLoop: "

LabelFont

Color red

Series bold

EndFont

EndLabelString " EndForLoop"

LatexName forloop

End

The margin always throws me off. If it's wrong, the label is off 
screen to the left.


You could also try "LabelType Above" and remove the margin stuff.

Riki

Thanks Riki! That at least gets me headed in the right direction. 
I don't know why I wasn't getting the label string to display 
before -- maybe because I failed to specify the Margin, 
LeftMargin or LabelFont? (I did specify LabelType and 
LabelString, with no luck.)


The margin business is going to be interesting. Your code has the 
correct left margin when select the ForLoop style from the 
environment list, but when I nest it (inside an algorithmicx 
environment) the label moves to the left (I would have expected 
right) and blows the left margin. I expect that an exhaustive try 
of all choices will eventually find one that works.


It would not surprise me if there were a bug here about margin 
handling. Can you send an MWE? Put any new layout code into Local 
Layout.


Riki


I think the attached MWE shows what I was talking about. (At least, 
it does for me.) To avoid requiring any special packages, I'm using 
the quote environment as a surrogate for the algorithmic 
environment and a dummy LaTeX function as a surrogate for the 
actual for block code.


Can you create a bug report for this? I do not know this part of the 
code at all well.


Riki


I could update the MWE to include what I discovered about other 
margin choices, but to be honest I'm not sure how much if any of this 
is a bug and how much is an ID10T error. :-)


It does not look right to me at all.

Riki


Okay, I've opened ticket 11347 for the label positioning 

Re: GUI indicator for a command environment

[Paul A. Rubin]

On 10/18/18 9:53 PM, Richard Kimberly Heck wrote:

On 10/18/18 2:01 PM, Paul A. Rubin wrote:

On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:

On 10/17/18 2:35 PM, Paul A. Rubin wrote:

On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:

On 10/17/18 9:30 AM, Paul A. Rubin wrote:

On 10/16/18 10:24 PM, Andrew Parsloe wrote:

On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:

Dear devs,

I'm struggling to cobble together a module supporting the 
pseudocode features of the algorithmicx package. As a 
disclaimer, I'm trying to avoid flex insets and stick to 
environments as much as possible, because there's less mousery 
switching an environment than insert an inset.


Right now, I'm tripping over the for block, which it implements 
by two LaTeX commands: \For{} and \EndFor. I can 
treat those as command styles and get the correct output, but 
the GUI is confusing to the user because nothing displays in 
the line ending the loop (it looks like a blank line to the 
user) and the condition appears in the starting line with no 
visible prefix (so it looks like any random statement in the 
algorithm, unless you notice what the environment select box is 
displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that appears 
in the GUI but /not/ in the compiled output. The "handle" for 
an inset would be fine, as would something like a bullet that 
was GUI-only. Can this be done with the current layout/module 
system?


TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? 
(I experimented with this a couple of years ago, so my memory of 
the exact effect is somewhat hazy.)


Andrew

|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]

|Static|
means the label is simply what is declared as
|LabelString|. This will be displayed “inline”, at the
beginning of the paragraph. If the |LatexType| is
|Environment|, then it will be displayed only in the
first paragraph of any sequence of paragraphs with the
same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed
above the paragraph either at the beginning of the line
or centered.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command 
type style (and combined with a LabelString argument) it does not 
seem to do anything in either the GUI or the output. I tried it 
with an environment, and I believe the label string showed up in 
the output but not the GUI. (I would have to double-check that.)


Try this in Local Layout (to test):

Format 66

Style ForLoop

LatexType Command

LabelType Static

LabelString "ForLoop: "

EndLabelType Static

Margin Static

LeftMargin "ForLoop: "

LabelFont

Color red

Series bold

EndFont

EndLabelString " EndForLoop"

LatexName forloop

End

The margin always throws me off. If it's wrong, the label is off 
screen to the left.


You could also try "LabelType Above" and remove the margin stuff.

Riki

Thanks Riki! That at least gets me headed in the right direction. I 
don't know why I wasn't getting the label string to display before 
-- maybe because I failed to specify the Margin, LeftMargin or 
LabelFont? (I did specify LabelType and LabelString, with no luck.)


The margin business is going to be interesting. Your code has the 
correct left margin when select the ForLoop style from the 
environment list, but when I nest it (inside an algorithmicx 
environment) the label moves to the left (I would have expected 
right) and blows the left margin. I expect that an exhaustive try 
of all choices will eventually find one that works.


It would not surprise me if there were a bug here about margin 
handling. Can you send an MWE? Put any new layout code into Local 
Layout.


Riki


I think the attached MWE shows what I was talking about. (At least, 
it does for me.) To avoid requiring any special packages, I'm using 
the quote environment as a surrogate for the algorithmic environment 
and a dummy LaTeX function as a surrogate for the actual for block code.


Can you create a bug report for this? I do not know this part of the 
code at all well.


Riki


I could update the MWE to include what I discovered about other margin 
choices, but to be honest I'm not sure how much if any of this is a bug 
and how much is an ID10T error. :-)


Paul

Re: GUI indicator for a command environment

[Paul A. Rubin]

On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:

On 10/17/18 2:35 PM, Paul A. Rubin wrote:

On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:

On 10/17/18 9:30 AM, Paul A. Rubin wrote:

On 10/16/18 10:24 PM, Andrew Parsloe wrote:

On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:

Dear devs,

I'm struggling to cobble together a module supporting the 
pseudocode features of the algorithmicx package. As a disclaimer, 
I'm trying to avoid flex insets and stick to environments as much 
as possible, because there's less mousery switching an 
environment than insert an inset.


Right now, I'm tripping over the for block, which it implements 
by two LaTeX commands: \For{} and \EndFor. I can 
treat those as command styles and get the correct output, but the 
GUI is confusing to the user because nothing displays in the line 
ending the loop (it looks like a blank line to the user) and the 
condition appears in the starting line with no visible prefix (so 
it looks like any random statement in the algorithm, unless you 
notice what the environment select box is displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that appears in 
the GUI but /not/ in the compiled output. The "handle" for an 
inset would be fine, as would something like a bullet that was 
GUI-only. Can this be done with the current layout/module system?


TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? (I 
experimented with this a couple of years ago, so my memory of the 
exact effect is somewhat hazy.)


Andrew

|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]

|Static|
means the label is simply what is declared as
|LabelString|. This will be displayed “inline”, at the
beginning of the paragraph. If the |LatexType| is
|Environment|, then it will be displayed only in the first
paragraph of any sequence of paragraphs with the same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed
above the paragraph either at the beginning of the line or
centered.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command 
type style (and combined with a LabelString argument) it does not 
seem to do anything in either the GUI or the output. I tried it 
with an environment, and I believe the label string showed up in 
the output but not the GUI. (I would have to double-check that.)


Try this in Local Layout (to test):

Format 66

Style ForLoop

LatexType Command

LabelType Static

LabelString "ForLoop: "

EndLabelType Static

Margin Static

LeftMargin "ForLoop: "

LabelFont

Color red

Series bold

EndFont

EndLabelString " EndForLoop"

LatexName forloop

End

The margin always throws me off. If it's wrong, the label is off 
screen to the left.


You could also try "LabelType Above" and remove the margin stuff.

Riki

Thanks Riki! That at least gets me headed in the right direction. I 
don't know why I wasn't getting the label string to display before -- 
maybe because I failed to specify the Margin, LeftMargin or 
LabelFont? (I did specify LabelType and LabelString, with no luck.)


The margin business is going to be interesting. Your code has the 
correct left margin when select the ForLoop style from the 
environment list, but when I nest it (inside an algorithmicx 
environment) the label moves to the left (I would have expected 
right) and blows the left margin. I expect that an exhaustive try of 
all choices will eventually find one that works.


It would not surprise me if there were a bug here about margin 
handling. Can you send an MWE? Put any new layout code into Local Layout.


Riki


An addendum to my MWE: by experimenting, I found that "Margin Manual" 
fixes the problem of the ForLoop label breaking the left margin (when 
embedded in an algorithm environment but not when out in the open). On 
the other hand, I have another LaTeX command style that introduces a 
LaTeX command with a single required argument (similar to \dummy in my 
MWE). To get the label on that to work, "Margin Manual" was the wrong 
choice; I needed "Margin Dynamic". Why the two styles differ in the 
margin they need is yet another mystery to me.


Paul

Re: GUI indicator for a command environment

[Paul A. Rubin]

On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:

On 10/17/18 2:35 PM, Paul A. Rubin wrote:

On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:

On 10/17/18 9:30 AM, Paul A. Rubin wrote:

On 10/16/18 10:24 PM, Andrew Parsloe wrote:

On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:

Dear devs,

I'm struggling to cobble together a module supporting the 
pseudocode features of the algorithmicx package. As a disclaimer, 
I'm trying to avoid flex insets and stick to environments as much 
as possible, because there's less mousery switching an 
environment than insert an inset.


Right now, I'm tripping over the for block, which it implements 
by two LaTeX commands: \For{} and \EndFor. I can 
treat those as command styles and get the correct output, but the 
GUI is confusing to the user because nothing displays in the line 
ending the loop (it looks like a blank line to the user) and the 
condition appears in the starting line with no visible prefix (so 
it looks like any random statement in the algorithm, unless you 
notice what the environment select box is displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that appears in 
the GUI but /not/ in the compiled output. The "handle" for an 
inset would be fine, as would something like a bullet that was 
GUI-only. Can this be done with the current layout/module system?


TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? (I 
experimented with this a couple of years ago, so my memory of the 
exact effect is somewhat hazy.)


Andrew

|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]

|Static|
means the label is simply what is declared as
|LabelString|. This will be displayed “inline”, at the
beginning of the paragraph. If the |LatexType| is
|Environment|, then it will be displayed only in the first
paragraph of any sequence of paragraphs with the same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed
above the paragraph either at the beginning of the line or
centered.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command 
type style (and combined with a LabelString argument) it does not 
seem to do anything in either the GUI or the output. I tried it 
with an environment, and I believe the label string showed up in 
the output but not the GUI. (I would have to double-check that.)


Try this in Local Layout (to test):

Format 66

Style ForLoop

LatexType Command

LabelType Static

LabelString "ForLoop: "

EndLabelType Static

Margin Static

LeftMargin "ForLoop: "

LabelFont

Color red

Series bold

EndFont

EndLabelString " EndForLoop"

LatexName forloop

End

The margin always throws me off. If it's wrong, the label is off 
screen to the left.


You could also try "LabelType Above" and remove the margin stuff.

Riki

Thanks Riki! That at least gets me headed in the right direction. I 
don't know why I wasn't getting the label string to display before -- 
maybe because I failed to specify the Margin, LeftMargin or 
LabelFont? (I did specify LabelType and LabelString, with no luck.)


The margin business is going to be interesting. Your code has the 
correct left margin when select the ForLoop style from the 
environment list, but when I nest it (inside an algorithmicx 
environment) the label moves to the left (I would have expected 
right) and blows the left margin. I expect that an exhaustive try of 
all choices will eventually find one that works.


It would not surprise me if there were a bug here about margin 
handling. Can you send an MWE? Put any new layout code into Local Layout.


Riki


I think the attached MWE shows what I was talking about. (At least, it 
does for me.) To avoid requiring any special packages, I'm using the 
quote environment as a surrogate for the algorithmic environment and a 
dummy LaTeX function as a surrogate for the actual for block code.


Paul




mwe.lyx
Description: application/lyx

Re: GUI indicator for a command environment

[Paul A. Rubin]

On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:

On 10/17/18 9:30 AM, Paul A. Rubin wrote:

On 10/16/18 10:24 PM, Andrew Parsloe wrote:

On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:

Dear devs,

I'm struggling to cobble together a module supporting the 
pseudocode features of the algorithmicx package. As a disclaimer, 
I'm trying to avoid flex insets and stick to environments as much 
as possible, because there's less mousery switching an environment 
than insert an inset.


Right now, I'm tripping over the for block, which it implements by 
two LaTeX commands: \For{} and \EndFor. I can treat 
those as command styles and get the correct output, but the GUI is 
confusing to the user because nothing displays in the line ending 
the loop (it looks like a blank line to the user) and the condition 
appears in the starting line with no visible prefix (so it looks 
like any random statement in the algorithm, unless you notice what 
the environment select box is displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that appears in 
the GUI but /not/ in the compiled output. The "handle" for an inset 
would be fine, as would something like a bullet that was GUI-only. 
Can this be done with the current layout/module system?


TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? (I 
experimented with this a couple of years ago, so my memory of the 
exact effect is somewhat hazy.)


Andrew

|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]

|Static|
means the label is simply what is declared as |LabelString|.
This will be displayed “inline”, at the beginning of the
paragraph. If the |LatexType| is |Environment|, then it will
be displayed only in the first paragraph of any sequence of
paragraphs with the same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed
above the paragraph either at the beginning of the line or
centered.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command type 
style (and combined with a LabelString argument) it does not seem to 
do anything in either the GUI or the output. I tried it with an 
environment, and I believe the label string showed up in the output 
but not the GUI. (I would have to double-check that.)


Try this in Local Layout (to test):

Format 66

Style ForLoop

LatexType Command

LabelType Static

LabelString "ForLoop: "

EndLabelType Static

Margin Static

LeftMargin "ForLoop: "

LabelFont

Color red

Series bold

EndFont

EndLabelString " EndForLoop"

LatexName forloop

End

The margin always throws me off. If it's wrong, the label is off 
screen to the left.


You could also try "LabelType Above" and remove the margin stuff.

Riki

Thanks Riki! That at least gets me headed in the right direction. I 
don't know why I wasn't getting the label string to display before -- 
maybe because I failed to specify the Margin, LeftMargin or LabelFont? 
(I did specify LabelType and LabelString, with no luck.)


The margin business is going to be interesting. Your code has the 
correct left margin when select the ForLoop style from the environment 
list, but when I nest it (inside an algorithmicx environment) the label 
moves to the left (I would have expected right) and blows the left 
margin. I expect that an exhaustive try of all choices will eventually 
find one that works.


Paul

Re: GUI indicator for a command environment

[Paul A. Rubin]

On 10/16/18 10:24 PM, Andrew Parsloe wrote:

On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:

Dear devs,

I'm struggling to cobble together a module supporting the pseudocode 
features of the algorithmicx package. As a disclaimer, I'm trying to 
avoid flex insets and stick to environments as much as possible, 
because there's less mousery switching an environment than insert an 
inset.


Right now, I'm tripping over the for block, which it implements by 
two LaTeX commands: \For{} and \EndFor. I can treat those 
as command styles and get the correct output, but the GUI is 
confusing to the user because nothing displays in the line ending the 
loop (it looks like a blank line to the user) and the condition 
appears in the starting line with no visible prefix (so it looks like 
any random statement in the algorithm, unless you notice what the 
environment select box is displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that appears in the 
GUI but /not/ in the compiled output. The "handle" for an inset would 
be fine, as would something like a bullet that was GUI-only. Can this 
be done with the current layout/module system?


TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? (I 
experimented with this a couple of years ago, so my memory of the 
exact effect is somewhat hazy.)


Andrew

|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]

|Static|
means the label is simply what is declared as |LabelString|.
This will be displayed “inline”, at the beginning of the
paragraph. If the |LatexType| is |Environment|, then it will
be displayed only in the first paragraph of any sequence of
paragraphs with the same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed above
the paragraph either at the beginning of the line or centered.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command type 
style (and combined with a LabelString argument) it does not seem to do 
anything in either the GUI or the output. I tried it with an 
environment, and I believe the label string showed up in the output but 
not the GUI. (I would have to double-check that.)


Paul

GUI indicator for a command environment

[Paul A. Rubin]

Dear devs,

I'm struggling to cobble together a module supporting the pseudocode 
features of the algorithmicx package. As a disclaimer, I'm trying to 
avoid flex insets and stick to environments as much as possible, because 
there's less mousery switching an environment than insert an inset.


Right now, I'm tripping over the for block, which it implements by two 
LaTeX commands: \For{} and \EndFor. I can treat those as 
command styles and get the correct output, but the GUI is confusing to 
the user because nothing displays in the line ending the loop (it looks 
like a blank line to the user) and the condition appears in the starting 
line with no visible prefix (so it looks like any random statement in 
the algorithm, unless you notice what the environment select box is 
displaying.


So what I'm looking for right now is a way to display a 
tag/prefix/symbol at the start of a command style that appears in the 
GUI but /not/ in the compiled output. The "handle" for an inset would be 
fine, as would something like a bullet that was GUI-only. Can this be 
done with the current layout/module system?


TIA,
Paul

Re: AICPA Support Case Created: Case #00005668

[Paul A. Rubin]

On 10/04/2018 06:10 PM, Richard Kimberly Heck wrote:

Is anyone else getting these? I seem to get one whenever I post to the list.

Riki

"Not I", said the little bear.

Paul



On 10/04/2018 05:58 PM, no-re...@aicpa-cima.com wrote:

Hello Richard,

Thank you for contacting AICPA Member Service. We have received your inquiry 
and will respond within 72 hours.

Your case reference # is: 5668

Note: Please add the email address in the above "From:" field to your address 
book or “safe” email address list to ensure delivery of responses.

Re: Ubuntu packages?

[Paul A. Rubin]

On 10/02/2018 09:19 AM, Liviu Andronic wrote:

Hi Scott,
Thanks for the reminder.

The packages are now uploaded on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/release

Please let me know if you encounter any issues with them. Regards,
Liviu


Liviu,

The Mint software updated just installed the new package, and it works fine.

Thank you very much for maintaining the repository!

Paul

Re: Ubuntu packages?

[Paul A. Rubin]

On 09/29/2018 11:45 AM, Chris Menzel wrote:

Dear selfless and heroic LyX developers,

I have noticed that the most recent version of LyX for Ubuntu is 
2.3.0-1 and (according to the PPA 
) that 
version was uploaded last March. I'm just wondering if this indicates 
that maintenance of the Ubuntu port is stalled or if (as I suspect) 
other obligations are (understandably) simply not allowing the 
maintainer time to compile and package up the latest version.


Thanks!

Chris Menzel
I'm curious about this myself. The last update to the PPA seems to have 
been in June. Has anyone heard from Liviu Andronic recently?


Paul

Re: Windows debug output

[Paul A. Rubin]

On 09/21/2018 03:13 PM, Enrico Forestieri wrote:

On Fri, Sep 21, 2018 at 01:32:24PM -0400, Paul A. Rubin wrote:

On 09/21/2018 01:28 PM, Jean-Marc Lasgouttes wrote:

Le 21/09/2018 à 19:20, Paul A. Rubin a écrit :

I'm embarrassed to have to ask, but how does one get debug output
with the Windows version of LyX (2.3 or later)? From a command
window, I've tried both "start LyX2.3 -dbg all" and "cmd /K LyX2.3
-dbg all", and have tried surrounding the executable name and flags
with quotes, and swearing in multiple languages while starting it,
to no avail. LyX starts every time, but I get no output in the
command window.

Try View>Messages Panel. From there you can tell also what debug
messages you want to see.

JMarc


Thanks, JMarc. The catch is, I'm trying to help someone diagnose why LyX
does not start (or at least does not reach the point of painting the main
window). So I need to get diagnostic messages in the "DOS window" if
possible. He gets no output there when he tries (and fails) to launch LyX.

Please, try launching LyX from a cygwin terminal. For some reason, the
output can be seen in this case, and LyX does not even detach from the
terminal. However, you have to use "-dbg any" rather than "-dbg all".

Thanks Enrico. I should have remembered that it's "any" and not "all" 
(although, as it turns out, the Windows binary still does not produce 
any output in the command window). I'm trying to help a user having 
problems with the "native" Windows version, and I don't think he has 
Cygwin installed (nor the Cygwin version of LyX).


Paul

Re: Windows debug output

[Paul A. Rubin]

On 09/21/2018 01:32 PM, Scott Kostyshak wrote:

On Fri, Sep 21, 2018 at 01:20:21PM -0400, Paul A. Rubin wrote:

I'm embarrassed to have to ask, but how does one get debug output with the
Windows version of LyX (2.3 or later)? From a command window, I've tried
both "start LyX2.3 -dbg all" and "cmd /K LyX2.3 -dbg all", and have tried
surrounding the executable name and flags with quotes, and swearing in
multiple languages while starting it, to no avail. LyX starts every time,
but I get no output in the command window.

Please don't be embarrassed. I (sincerely) have a lot of respect for
anyone who attempts to debug on Windows!

Hopefully someone else will give a more informative reply regarding the
command window, but you can alternatively get useful information if you
go to View > Messages Pane. You can make the same settings as you do
with the -dbg option. for example, you can click on the "Settings" tab
in the Messages Pane, and choose which messages you want to appear. In
the "Output" pane, note that you can right-click and do "Select All" to
paste into a separate text file. I'm guessing you already knew this, but
sometimes I forget about this option, so in case it is anything urgent,
I described it here.

Best,

Scott
Thanks Scott. As I (simultaneously) explained to JMarc, the problem is 
that the person I'm helping never gets the LyX GUI. Starting fails 
silently. I was hoping to get debug output in the DOS window (similar to 
what I get running LyX with "-dbg all" in a Linux terminal).


I really hate "failed silently" bugs. :-(

Paul

Re: Windows debug output

[Paul A. Rubin]

On 09/21/2018 01:28 PM, Jean-Marc Lasgouttes wrote:

Le 21/09/2018 à 19:20, Paul A. Rubin a écrit :
I'm embarrassed to have to ask, but how does one get debug output 
with the Windows version of LyX (2.3 or later)? From a command 
window, I've tried both "start LyX2.3 -dbg all" and "cmd /K LyX2.3 
-dbg all", and have tried surrounding the executable name and flags 
with quotes, and swearing in multiple languages while starting it, to 
no avail. LyX starts every time, but I get no output in the command 
window.


Try View>Messages Panel. From there you can tell also what debug 
messages you want to see.


JMarc

Thanks, JMarc. The catch is, I'm trying to help someone diagnose why LyX 
does not start (or at least does not reach the point of painting the 
main window). So I need to get diagnostic messages in the "DOS window" 
if possible. He gets no output there when he tries (and fails) to launch 
LyX.


Paul

Windows debug output

[Paul A. Rubin]

I'm embarrassed to have to ask, but how does one get debug output with 
the Windows version of LyX (2.3 or later)? From a command window, I've 
tried both "start LyX2.3 -dbg all" and "cmd /K LyX2.3 -dbg all", and 
have tried surrounding the executable name and flags with quotes, and 
swearing in multiple languages while starting it, to no avail. LyX 
starts every time, but I get no output in the command window.


Thanks,
Paul

Re: Closing ERT inset in LyX 2.3.0

[Paul A. Rubin]

On 09/12/2018 07:21 AM, Rasmus K. Rendsvig wrote:
included a "close inset" option to collapse them, but this is gone in 
2.3.0.



Not on my system (LyX 2.3.0, Linux Mint 18.3). If I right-click in an 
ERT box, "Close Inset" (accelerator key "C") is the second item in the 
context menu.


Paul

Re: Bug: note displays bold incorrectly

[Paul A. Rubin]

On 09/11/2018 11:23 AM, Scott Kostyshak wrote:

On Sat, Aug 25, 2018 at 05:37:42PM +0200, Kornel Benko wrote:

Am Samstag, 25. August 2018 11:05:52 CEST schrieb Paul A. Rubin 
:

1. Start a new file.
2. Toggle bold (e.g., ctrl + b).
3. Start a LyX note.
4. Type "A"
5. Toggle bold (e.g., ctrl + b).
6. Type "a".

I guess this might be a feature, since the whole inset is bold because
of (1). So even if there is unbolded text inside it, it should (?) be
displayed as bold. When I disolve the inset, then the text is free to
reclaim its previously ignored properties.

Scott

I think too. Mark, that you do not toggle between 'bold' and 'medium'
but between 'bold' and 'standard', whatever that may be.

Good point.


I guess I would tend to think that, in all matters of formatting or
style, the innermost setting (the setting most proximate to the text)
should rule. So I would expect that lower case "a" to be normal weight,
even with the bolding of the entire note. The one exception might be an
option to strip all formatting from the cursor selection, which would
overrule (and remove) any format stuff no matter how deeply nested.

That said, I would not be shocked if some users wanted to keep things
the way they are.

Paul

Like me.

Makes sense. I wonder if we could display somehow that the inset is
bold. Otherwise, it might be confusing to the user. One idea would be to
apply the bold to the text inside the inset rectangle thing (in this
case, to "Note").

Scott

That sounds like a good idea to me.

Paul

Odd experience with the Windows installer

[Paul A. Rubin]

I'm trying to help a colleague (on Windoze) whom I persuaded to try LyX 
(resulting in a borked MiKTeX system). So I decided to install both 
MiKTeX and LyX on a Win 10 virtual machine running on my Linux PC. My 
/tmp folder is shared with the VM (as drive X: in Windows), and I parked 
both installers there. The MiKTeX installation ran fine, and I tested it 
successfully by exporting the LyX intro help document to TeX and running 
pdflatex against it.


The adventure came when I tried to install LyX. The Windows file 
explorer showed LyX-230-Installer-005.exe with the correct file size. So 
did the dir command run in a command shell in the X:\ folder. When I 
tried to run it (either by double-clicking on the file in file explorer 
or by running it from the command line), however, the system said it 
couldn't find the file. (Note that, in the case of the command line, it 
said this after I used tab completion to fill in the line!)


So I went back to Linux, renamed the file in /tmp to "installer.exe", 
returned to the VM and the installer executed. (It's currently running 
the config script, which for some reason is excruciatingly slow on this 
setup.) I don't see anything in the file name that should offend 
Microsoft's sensibilities, so I'm at a loss as to why it could not find 
the file that it had no trouble finding. Thought I'd mention it here 
just in case someone else trips over it.


Paul

Re: Bug: note displays bold incorrectly

[Paul A. Rubin]

On 08/24/2018 11:19 PM, Scott Kostyshak wrote:

On Fri, Aug 24, 2018 at 02:17:30PM -0400, Paul A. Rubin wrote:

On 08/24/2018 12:58 PM, Scott Kostyshak wrote:

In the attached file, the LyX display shows that the lowercase "a" is
bold (see my screenshot), although it is not (as shown if you dissolve
the notes). Inside the note, the display changes when e.g. doing
"emphasize", but I cannot seem to write text that is displayed as
unbolded.

I can reproduce this back to 2.1.0. I have a feeling that this issue is
known, but I could not find the trac ticket. I looked through the bugs
in the components "font" and "insettext".

Can someone else reproduce? Is this a known issue or should I start a
new ticket?

Scott

Scott,

I confirm that your version displays the lower case a in bold in the GUI
with LyX 2.3, even after saving and reopening (which updates the LyX format
to 544). On the other hand, if I start from scratch and try to recreate it,
I get the upper case A appearing bold and the lower case a appearing normal,
as one would expect.

Diffing files, I see the problem. Your file contains the following (with
empty lines removed for readability):

\begin_layout Standard
\begin_inset Note Note
status open
\begin_layout Plain Layout
\noindent  <-- ??
\series bold   <-- oops
\begin_inset Note Note
status open
\begin_layout Plain Layout
\series bold
A
\series default
a
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout

When I start from scratch, the two lines I flagged are not present. In
particular, that "\series bold" that you have and I don't seems to apply to
the entire inner note.

As to how it got there, that I do not know.

Thanks for investigating, Paul! You solved the puzzle and now I figured
out how to reproduce the .lyx file I sent. But now I wonder if the
behavior is a feature and not a bug. In any case, here are the steps:

1. Start a new file.
2. Toggle bold (e.g., ctrl + b).
3. Start a LyX note.
4. Type "A"
5. Toggle bold (e.g., ctrl + b).
6. Type "a".

I guess this might be a feature, since the whole inset is bold because
of (1). So even if there is unbolded text inside it, it should (?) be
displayed as bold. When I disolve the inset, then the text is free to
reclaim its previously ignored properties.

Scott
I guess I would tend to think that, in all matters of formatting or 
style, the innermost setting (the setting most proximate to the text) 
should rule. So I would expect that lower case "a" to be normal weight, 
even with the bolding of the entire note. The one exception might be an 
option to strip all formatting from the cursor selection, which would 
overrule (and remove) any format stuff no matter how deeply nested.


That said, I would not be shocked if some users wanted to keep things 
the way they are.


Paul

Re: Bug: note displays bold incorrectly

[Paul A. Rubin]

On 08/24/2018 12:58 PM, Scott Kostyshak wrote:

In the attached file, the LyX display shows that the lowercase "a" is
bold (see my screenshot), although it is not (as shown if you dissolve
the notes). Inside the note, the display changes when e.g. doing
"emphasize", but I cannot seem to write text that is displayed as
unbolded.

I can reproduce this back to 2.1.0. I have a feeling that this issue is
known, but I could not find the trac ticket. I looked through the bugs
in the components "font" and "insettext".

Can someone else reproduce? Is this a known issue or should I start a
new ticket?

Scott

Scott,

I confirm that your version displays the lower case a in bold in the GUI 
with LyX 2.3, even after saving and reopening (which updates the LyX 
format to 544). On the other hand, if I start from scratch and try to 
recreate it, I get the upper case A appearing bold and the lower case a 
appearing normal, as one would expect.


Diffing files, I see the problem. Your file contains the following (with 
empty lines removed for readability):

\begin_layout Standard
\begin_inset Note Note
status open
\begin_layout Plain Layout
\noindent  <-- ??
\series bold   <-- oops
\begin_inset Note Note
status open
\begin_layout Plain Layout
\series bold
A
\series default
a
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout


When I start from scratch, the two lines I flagged are not present. In 
particular, that "\series bold" that you have and I don't seems to apply 
to the entire inner note.


As to how it got there, that I do not know.

Paul

Re: LyX should remember the last used template directory or use the user directory

[Paul A. Rubin]

On 07/28/2018 02:05 AM, Daniel wrote:

On 28/07/2018 01:32, Paul A. Rubin wrote:

On 07/27/2018 10:55 AM, Daniel wrote:
When selecting "New from Template..." LyX always starts at the 
template directory in the library directory. I guess when creating 
custom templates they should not be put into the library directory. 
But then one would have to always manually navigate to the template 
directory. So, LyX should remember the directory where the last 
template was opened from to make it easier to use one's own templates.


Alternatively, LyX should place all templates in the user directory 
and always start from there, so that the user can add a template there.


Daniel
Following advice from someone on the list (I think), I went to Tools 
> Preferences... > Paths and changed the template path to the 
template folder in the user directory. Now "New from Template" always 
starts from there. I added a symlink in the local templates directory 
to the LyX templates directory, so if I want a template that came 
with LyX I can just use that link to quickly get to the "official" 
directory.


Paul


Thanks Paul. That helps.

I must confess that I never used templates before. And found it to be 
working a bit different from the other features, like modules. 
Normally I would expect LyX to provide a list of templates that are a 
union of those in the library directory and the user directory while 
the same file in the user directory as in the library directory 
replaces it in the list. Wouldn't this be more natural?
If you mean a single chooser dialog with a merged list of the two 
directories, I agree it would make sense, but my impression is that LyX 
uses chooser dialogs provided by Qt, and I don't know if that is doable 
with the Qt dialogs. If not, the runner-up choice might be for the LyX 
installer to create the symlink I described automatically (after 
verifying one does not already exist) and then set the default template 
path to the user template directory.


I am mainly using templates to use the same document settings for new 
files. For my purposes it would actually be better if the document 
settings could also be imported from other files, for example a 
template. Here is an example for why this could be useful. While 
writing documents of the same type I am using my previous document 
settings for new files. But I keep also changing them, for example, 
when new settings are added to LyX. It would be great if there was an 
easy way to update the document settings by importing them from 
another LyX file.
So you are talking about copying settings from existing document A to 
existing document B (as opposed to copying from A to a new, unwritten 
document B, which is what the template functionality does)? I suspect 
that if this feature is added, someone will then want it done as a check 
list, so that users can cherry-pick which settings to copy over. You 
might want to submit an enhancement ticket requesting it (after checking 
to see if someone else already has).


Paul

Re: LyX should remember the last used template directory or use the user directory

[Paul A. Rubin]

On 07/27/2018 10:55 AM, Daniel wrote:
When selecting "New from Template..." LyX always starts at the 
template directory in the library directory. I guess when creating 
custom templates they should not be put into the library directory. 
But then one would have to always manually navigate to the template 
directory. So, LyX should remember the directory where the last 
template was opened from to make it easier to use one's own templates.


Alternatively, LyX should place all templates in the user directory 
and always start from there, so that the user can add a template there.


Daniel
Following advice from someone on the list (I think), I went to Tools > 
Preferences... > Paths and changed the template path to the template 
folder in the user directory. Now "New from Template" always starts from 
there. I added a symlink in the local templates directory to the LyX 
templates directory, so if I want a template that came with LyX I can 
just use that link to quickly get to the "official" directory.


Paul

Re: Windows + TeXLive + LyX 2.3.0

[Paul A. Rubin]

On 06/19/2018 10:47 AM, Pavel Sanda wrote:


Since we are doing changes in the installation workflow on Windows we should
consider to advocate TeX Live instead of MiKTeX on official LyX web page
and I have in mind two reasons:

1. increased document interoperability between architectures because both
Linux and Mac use preferably TeX Live (MacTeX is redistribution of
TeX Live if I read their pages right, CMIIW).

2. the instalation time of first install of MiKTeX (including triggered
online updates via configure) is *horrific*. As I wrote in some earlier
email, it took >1 hour to get LyX+MiKTeX working on clean Win machine
mainly because of MiKTeX package handling (and our reconfigure:).

Net TeXLive installer might be better in this regard. (?)



Before I will do my own experiments with Win TL 18, any windows users
around to comment on TeX Live advantages/drawbacks on windows, esp.
to points 1./2.

It's been quite a while since I switched from Windows to Linux, so my 
experience with MiKTeX may be dated. When I first started using LyX (on 
Windows), I'm not sure TeXLive had a Windows installer. At any rate, I 
used MiKTeX for years and was very pleased with it. Personally, I prefer 
the MiKTeX approach of installing and updating individual packages to 
the TeXLive bundle approach, where I have to figure out which bundle 
contains the one package I need, then install the entire bundle. I've 
tried tlmgr for individual packages with some success, but even that 
seems rougher to me than MiKTeX's installer.


Besides the disk footprint for TeXLive bundles, another consideration is 
bandwidth. If a Windows user has a slow connection, or is using a 
tethered phone (with a limited data plan), burning as little bandwidth 
as possible to get the needed packages can be a consideration.


Overall, I favor keeping the LyX installer distribution-agnostic. We can 
(and probably should) put links to TeXLive, MiKTeX and any other 
relevant distributions.


As to the points above, for #1, LaTeX packages should behave the same on 
all platforms (unless the dreaded Windows line endings somehow muck 
things up), so I'm not sure why it would make a difference if I used 
MiKTeX and my coauthor used TeXLive. For #2, I did not consider MiKTeX 
installation times bad back when I was using it. I would typically 
install just the base installer, then install individual packages when 
they first became needed.


Paul

Re: Windows + TeXLive + LyX 2.3.0

[Paul A. Rubin]

On 06/07/2018 12:23 PM, Richard Kimberly Heck wrote:

On 06/06/2018 11:26 PM, Scott Kostyshak wrote:

On Wed, Jun 06, 2018 at 08:50:29PM +, Paul A. Rubin wrote:

Sorry if this is answered somewhere -- I've been trying to follow the
various threads on a Windows installer but my aging brain is overloading.

Is there/will there soon be a 2.3.0 installer for Windows users who use
TeXLive and not MiKTeX? I've got a co-author in that category, and I would
like to introduce her to LyX.

Hi Paul,

 From what I understand, yes, the installer will support users who have TeX 
Live installed.

It always has, I believe. You just have to use the "basic" installer,
not the "bundled" one. It should detect TeXLive and configure itself
appropriately.

Riki

Thanks Riki (and thanks for wading into the Windows swamp to update the 
installer).


Paul

Re: Windows + TeXLive + LyX 2.3.0

[Paul A. Rubin]

On 06/06/2018 11:26 PM, Scott Kostyshak wrote:

On Wed, Jun 06, 2018 at 08:50:29PM +, Paul A. Rubin wrote:

Sorry if this is answered somewhere -- I've been trying to follow the
various threads on a Windows installer but my aging brain is overloading.

Is there/will there soon be a 2.3.0 installer for Windows users who use
TeXLive and not MiKTeX? I've got a co-author in that category, and I would
like to introduce her to LyX.

Hi Paul,

 From what I understand, yes, the installer will support users who have
TeX Live installed.

For the latest discussion, see:

https://www.mail-archive.com/search?l=mid=06053b91-24c8-a93c-42fc-609fd7e17b5f%40lyx.org

Scott

Thanks, Scott.

Paul

Windows + TeXLive + LyX 2.3.0

[Paul A. Rubin]

Sorry if this is answered somewhere -- I've been trying to follow the 
various threads on a Windows installer but my aging brain is overloading.


Is there/will there soon be a 2.3.0 installer for Windows users who use 
TeXLive and not MiKTeX? I've got a co-author in that category, and I 
would like to introduce her to LyX.


TIA,
Paul

Re: Greyedout note inside float caption

[Paul A. Rubin]

On 04/18/2018 03:28 PM, Pavel Sanda wrote:

Hi,

I have very outdated latex here, can anyone using more recent versions of
texlive confirm that when you insert greyedout note inside caption of floating
figure the document can't be compiled anymore?

Pavel
If the attached file is what you mean, I can confirm it. The error 
message is


! Argument of \@caption has an extra }.



\par

l.30 Invisible Figure}

I've run across a `}' that doesn't seem to match anything.

For example, `\def\a#1{...}' and `\a}' would produce

this error. If you simply proceed now, the `\par' that

I've just inserted will cause me to report a runaway

argument that might be the root of the problem. But if

your `}' was spurious, just type `2' and it will go away.

Runaway argument?

\@captype {\def \@currenvir {lyxgreyedout}\edef \@currenvline 
{\on@line \ETC.


! Paragraph ended before \@caption was complete.



\par

l.30 Invisible Figure}

I suspect you've forgotten a `}', causing me to apply this

control sequence to too muc


This is with TeXLive 2017.

Cheers,
Paul


h text. How can we recover?

My plan is to forget the whole thing and hope for the best.





newfile1.lyx
Description: application/lyx

Re: Diagnosing a crash

[Paul A. Rubin]

On 03/13/2018 11:30 AM, Jean-Marc Lasgouttes wrote:

Le 13/03/2018 à 16:26, Paul A. Rubin a écrit :
Aspell is only available if the development headers (e.g. 
libaspell-dev on debian) are available at compile time .


JMarc
Ah. I installed the precompiled package from Liv's PPA, so I guess he 
compiled it without Aspell (which is fine with me).


When you do "lyx -version" the special build flags line will contain 
entries like use-enchant, use-hunspell, that tell you what spell 
checkers have been selected.


Not that enchant is a wrapper library that relies on other 
spellcheckers that can be aspell, hunspell, etc.


JMarc

JMarc
Looking at the enchant ordering file (and what is installed on my 
system), it appears that enchant is using aspell. So the crash with 
2.2.3 occurred when aspell was invoked directly but not when it was 
invoked through enchant.


Curiouser and curiouser.

Paul

Re: Diagnosing a crash

[Paul A. Rubin]

On 03/13/2018 11:12 AM, Jean-Marc Lasgouttes wrote:

Le 13/03/2018 à 15:56, Paul A. Rubin a écrit :
Apparently not. I just upgraded to 2.3.0. It selected Enchant as the 
spellchecker and did not give me any options in the drop-down list 
(even though aspell is installed here). On the bright side, that 
eliminates the bug.


Aspell is only available if the development headers (e.g. 
libaspell-dev on debian) are available at compile time .


JMarc
Ah. I installed the precompiled package from Liv's PPA, so I guess he 
compiled it without Aspell (which is fine with me).


Paul

Re: Diagnosing a crash

[Paul A. Rubin]

On 03/13/2018 04:37 AM, Pavel Sanda wrote:

Paul A. Rubin wrote:

.cset" could not be opened for reading or does not exist.lib/aspell/
Aborted (core dumped)

This looks totally weird. The correct error should say something like
"lib/aspell/your_encoding.cset" could not be opened for reading or does not 
exist.

Maybe the encoding is set to some strange character?
Is the same problem with 2.3.0? Actually do we even support aspell with 2.3.0?

Pavel
Apparently not. I just upgraded to 2.3.0. It selected Enchant as the 
spellchecker and did not give me any options in the drop-down list (even 
though aspell is installed here). On the bright side, that eliminates 
the bug.


Paul

Re: Diagnosing a crash

[Paul A. Rubin]

On 03/12/2018 07:41 PM, Richard Heck wrote:

On 03/12/2018 07:36 PM, Paul A. Rubin wrote:

Hi all,

I have a very perplexing but utterly repeatable crash that I'm trying
to diagnose, to determine whether I should file a ticket (or whether
it's not a LyX issue). I'd appreciate any insight. Apologies for the
length of what follows.

Any time LyX crashes, it is a problem. The error may be coming from
elsewhere, but we should deal with it. So I'd suggest filing a ticket.

Richard


Will do (tomorrow -- dinner beckons now).

Paul

Diagnosing a crash

[Paul A. Rubin]

Hi all,

I have a very perplexing but utterly repeatable crash that I'm trying to 
diagnose, to determine whether I should file a ticket (or whether it's 
not a LyX issue). I'd appreciate any insight. Apologies for the length 
of what follows.


I'm running LyX 2.2.3 on Linux Mint 18.3 MATE. The Qt version is 4.8.7 
(both compile-time and run-time). I have Aspell, Enchant and Myspell 
installed. The OS uses English (US) as its default language.


Symptom #1: With Aspell selected as the spellchecker, if I attempt to 
spellcheck any document, no matter how simple, LyX crashes. The crash 
message is

.cset" could not be opened for reading or does not exist.lib/aspell/
Aborted (core dumped)

With Enchant selected, there is no problem.

Symptom #2: With Aspell set as the spellchecker, if I right click in any 
empty document, or on the handle of a float, things work as expected. If 
I right click in the text area of a non-empty document, I get the same 
crash. Here's the tail of output when I ran LyX with dbg -any and 
triggered the crash:

frontends/qt4/Menus.cpp (2342): Context menu requested: context-edit
frontends/qt4/Menus.cpp (2297): Triggered menu: context-edit
AspellChecker.cpp (214): aspell user dir: /home/paul/.lyx/
AspellChecker.cpp (217): aspell sysdir dir: /usr/share/lyx/
.cset" could not be opened for reading or does not exist.lib/aspell/
Aborted (core dumped)
So the right-click triggered a context menu, which then somehow seems to 
have invoked Aspell (?!) and caused the crash.


Just to make this dopier, I have the same operating system and same 
version of LyX installed on my laptop and an older PC with no problems. 
The crash is happening on a new machine (with a different chip 
architecture, which hopefully does not matter) that I'm breaking in.


Any suggestions on (a) why a right-click in the middle of some text 
would have anything to do with the spellchecker and (b) why Aspell is 
blowing up on just this one machine?


Thanks,
Paul

Re: off topic: feedback after 3 months with Linux

[Paul A. Rubin]

On 10/30/2017 07:29 PM, Uwe Stöhr wrote:


I tried the PDF-form.lyx experiment. The default PDF viewer on my 
system (Xreader) seemed to handle most of the form features.


I also tried Xreader. There are several bugs in all PDF programs under 
Linux. For me the main bug is that I cannot use radio buttons but 
these are in most PDF forms (e.g. for sex/gender). Of course I already 
reported all bugs I found.
That's curious. I didn't have any problems with Xreader and gender radio 
buttons in PDF-form.lyx. In any case, I would definitely recommend 
getting the Linux version of Acrobat Reader. You can easily make it the 
default program for opening PDFs. I've never had any problems with it on 
Linux, and radio buttons work.


Paul