Re: Increase max range of zoom slider?
On Thu, Sep 15, 2022 at 05:46:23PM +0200, Jean-Marc Lasgouttes wrote: > Le 14/09/2022 à 17:44, Scott Kostyshak a écrit : > > I tested the zoom slider today out of curiosity and it works very > > smoothly. One thing I noticed is that the maximum of the range is too > > small for my computer/eyes. The maximum is 290. > > Could you tell us more about your setting? OS, monitor, maybe settings in > preferences (there is a dpi setting not available through GUI). OS is Ubuntu 21.04. This is on a laptop, a Dell XPS 9343. Although I'm using Ubuntu I've found the Arch Wiki helpful for specifications: https://wiki.archlinux.org/title/Dell_XPS_13_(9343) Apparently mine has a "13.3-inch FHD (1920 x 1080) infinity display". I tested with default LyX preferences and it is the same. Screenshot attached. As you can see in the screenshot, in the bottom right I have maxed out the slider. What does it look like for you when you max out the slider? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: New Theorems Module
On Thu, Sep 15, 2022 at 9:54 PM Paul A. Rubin wrote:
>
> 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.
>
Hi paul,
Thank you for trying out the module. I actually made the List of
Theorems layout dependent on the Theorem layout, but it seems that LyX
does not support the key DependsOn with flex insets, so in the new
module file the List of Theorems layout loads thmtools.
> The second one is perhaps a bug in the thm-tools package itself. To reproduce
> it, you can follow these steps.
Actually, it is not a bug in thmtools, it is just how latex works (see
the explanation below) with aux files, toc files, etc., but I did not
think of a situation such as you described when I wrote the module.
To write all the information needed to be in aux files and such, LaTeX
checks at the end of the compilation (for example, in thmtools it is
done with \AtEndDocument) if the aux file exists, if not it will
create one and write the information in it, if yes, it will update
what it needs to update. It does that at the end of the document so
there won't be a need to open the file and close it several times,
which might prolong compilation time.
When you call a macro such as \tableofcontents, or \listoftheorems in
our case, it will try to read the toc, or loe file, and get the
contents of the list from there, and since this file has not been
written yet (as it will be created at the end) the Table of Contents
or List of Theorems will be empty after the first compilation of a tex
file.
In LyX we don't experiencing it, since it will compile a number of
times, until the toc or lot will be with the right contents (which
usually takes two compilations), all the references will have the
correct numbering and pages (which might take more than two
compilations) and there are more stuff that requires multiple
compilations.
> Open your test_thmtools_module.lyx file and compile it (which works, of
> course).
> 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.
Each layout in the module defines a macro that holds the label of the
theorem (for example, for the Claim layouts it was \claimname). Since
we can't know in which language the user will use, we must make the
label protected, so it would not expand early, and we can change it
according to the language. A side effect of that, is the fact that
this macro was written to the loe file, without being expanded, and
thus remain as \claimname. After you erased the Claim layouts,
\claimname was was never defined, and the loe file will update at the
end of the compilation, after \listoftheorems already read the loe
file, and did not know what is \claimname.
> 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.
At the second compilation, the loe file has already been updated, and
\claimname was erased from there,
Re: New Theorems Module
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: Differences Between Theorems Modules (AMS and non AMS)
On 9/15/22 09:11, Jean-Marc Lasgouttes wrote: Le 14/09/2022 à 02:28, Udicoudco a écrit : Hello Lyx Developers, Recently I've been trying to understand more thoroughly how theorems modules are implemented in LyX, and I think I've come across some bugs, and some redundant modules (but I might have misunderstood a few things). Hello Udi, Thanks for looking at that. The first thing I've noticed is that all AMS theorems related modules load the packages amsmath and amsthm even if the use did not use any layout. I could not understand why, as amsthm does not depend on amsmath. I've tried to compile a lyx file containing all the layouts defined in Theorem (AMS), but i erased the line "Require amsmath,amsthm" from the module, and the file compiled (as amsthm is loaded by the layouts, there is no really a need to load the package if the user did not use any layout). This looks like a bug indeed. These have gone through so many versions, that I'm not surprised bugs have accumulated over the years. Cleaning it all up is a great idea. The second thing I've noticed, there is no difference between the files theorems.inc and theorems-ams.inc. In the description of the file theorems-std.module, which uses theorems.inc it is said that the module "Defines some theorem environments for use with non-AMS classes", but the module uses amsthm, and he is compilable with AMS classes. This is indeed surprising. In the old days, non-ams theorem modules did not use amsthm. But for some reason it was changed when modularizing the layouts. I am not sure whether we can revert this decision 14 years later (see below). If we don't, the two types of theorems should be merged indeed. The culprit is: commit f5a5be4d188a20ee2a5c0213ee11bf64c0908841 Author: Richard Heck Date: Thu Jan 10 04:58:20 2008 + Modularization of the AMS classes, and the theorem environments generally. This is Part I: The changes to the layout files and modules. Part II, still to come, will involve lyx2lyx to help people who were using the older classes. I'm guessing I failed to notice this similarity. That was a while ago! Riki -- Richard Kimberly (Riki) Heck Professor of Philosophy Brown University Pronouns: they/them/their Website: http://rkheck.frege.org/ Blog:http://rikiheck.blogspot.com/ Amazon: http://amazon.com/author/richardgheckjr Google Scholar: https://scholar.google.com/citations?user=QUKBG6EJ ORCID: http://orcid.org/-0002-2961-2663 Research Gate: https://www.researchgate.net/profile/Richard_Heck -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Differences Between Theorems Modules (AMS and non AMS)
Le 15/09/2022 à 14:17, Udicoudco a écrit :
Hello again,
I took a look at the Named Theorems Module today, and the LaTeX code
there seems to be a bit strange. In the preamble of the layout Named
Theorem there is the following code:
\newcommand\thmsname{\protect\theoremname}
\newcommand\nm@thmtype{theorem}
\theoremstyle{plain}
\newtheorem*{namedtheorem}{\thmsname}
\newenvironment{namedthm}[1][Undefined Theorem Name]{
\ifx{#1}{Undefined Theorem Name}\renewcommand\nm@thmtype{theorem*}
\else\renewcommand\thmsname{#1}\renewcommand\nm@thmtype{namedtheorem}
\fi
\begin{\nm@thmtype}}
{\end{\nm@thmtype}}
Hi again Udi,
This module has been proposed in ticket 6279
https://www.lyx.org/trac/ticket/6279
Updating and fixing it would be great. I think that the LabelString
could be empty, so that it is clear that the argument inset will be used
as a label. And the default could be set to "theorem", for example.
Feel free to propose a replacement.
JMarc
\ifx is not really a macro with two arguments, but it is only looking
at the next two tokens, it compares the token { with the one after it,
which causing, in this situation, to get always the false output.
This means that if a user would not give a name via the optional
argument, the output theorem will have a label "Undefined Theorem
Name", which I don't think is the preferable outcome (and it might not
be what the author of the module meant as well).
In addition, note that if there was a case that the true case was
happening, the environment theorem* is not defined anywhere in the
module, which will cause a LaTeX Error: Environment theorem*
undefined.
I think it is reasonable to change this module in a way that if the
optional argument is empty, the output would be a theorem with the
label "Theorem".
This way, there is only need for one layout in this module, the Named
Theorem layout, Since the Theorem* layout defined there would be
achievable with the Named Theorem with the default optional argument
(or by setting it to Theorem).
Also note that every line that does not end with a control word, TeX
will see a n end-of-line character, hence will add an (what i believe
to be in this case, an undesired) space (since space after control
words are ignored). So in the current code, there are also a few extra
spaces in the environment namedthm.
Best Regards,
Udi
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Increase max range of zoom slider?
Le 14/09/2022 à 17:44, Scott Kostyshak a écrit : I tested the zoom slider today out of curiosity and it works very smoothly. One thing I noticed is that the maximum of the range is too small for my computer/eyes. The maximum is 290. Could you tell us more about your setting? OS, monitor, maybe settings in preferences (there is a dpi setting not available through GUI). JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Unify wording for statistics
Le 15/09/2022 à 17:06, Jürgen Spitzmüller a écrit : One character (no blanks) Or 'One character (not a blank)' No, it means: We do not count blanks here. Note that this special case for One is bogus, since for en empty document, we show 0 characters (no blank) For some reason, only "1" is taken into account. I do not know though what is the right form that is correct for all languages. And I have not implemented (yet) the special support for that of gettext in our Messages class. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Unify wording for statistics
Am Mittwoch, dem 14.09.2022 um 14:21 +0200 schrieb Kornel Benko: > > If you have one character and a blank, > > Does this (for you) imply a blank is not a character? No. > > > then you have two different > > measures: > > > > One character (no blanks) > > Or 'One character (not a blank)' No, it means: We do not count blanks here. > > > 2 characters (incl. blanks) > > If we do not count non-blank-chars and blanks separately, we have > problems. > Just my 2 cent. I am not sure what you mean. Giving two measures (including and excluding blanks) is common in all editors I know. And these are also the two (char) measures you normally need (either of them) when accounting for publication rules. > BTW, what about other non-printable chars, like LF, new page, some > fills etc.? They are not counted. -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Differences Between Theorems Modules (AMS and non AMS)
Le 14/09/2022 à 02:28, Udicoudco a écrit : Hello Lyx Developers, Recently I've been trying to understand more thoroughly how theorems modules are implemented in LyX, and I think I've come across some bugs, and some redundant modules (but I might have misunderstood a few things). Hello Udi, Thanks for looking at that. The first thing I've noticed is that all AMS theorems related modules load the packages amsmath and amsthm even if the use did not use any layout. I could not understand why, as amsthm does not depend on amsmath. I've tried to compile a lyx file containing all the layouts defined in Theorem (AMS), but i erased the line "Require amsmath,amsthm" from the module, and the file compiled (as amsthm is loaded by the layouts, there is no really a need to load the package if the user did not use any layout). This looks like a bug indeed. The second thing I've noticed, there is no difference between the files theorems.inc and theorems-ams.inc. In the description of the file theorems-std.module, which uses theorems.inc it is said that the module "Defines some theorem environments for use with non-AMS classes", but the module uses amsthm, and he is compilable with AMS classes. This is indeed surprising. In the old days, non-ams theorem modules did not use amsthm. But for some reason it was changed when modularizing the layouts. I am not sure whether we can revert this decision 14 years later (see below). If we don't, the two types of theorems should be merged indeed. The culprit is: commit f5a5be4d188a20ee2a5c0213ee11bf64c0908841 Author: Richard Heck Date: Thu Jan 10 04:58:20 2008 + Modularization of the AMS classes, and the theorem environments generally. This is Part I: The changes to the layout files and modules. Part II, still to come, will involve lyx2lyx to help people who were using the older classes. The only difference I've found between theorems.inc and theorems-ams.inc, is the list of layouts the files provide at the beginning of the files (but they provide the same layouts, with the exact same definitions. I've used text comparison software to verify that). Because of that, I've concluded that the only differences between theorems-std.module and theorems-ams.module is that in theorems-std.module there are no unnumbered theorems (as theorems-ams.module includes theorems-starred.inc, but theorems-std.module does not), theorems-std.module does not load amsmath, and loads amsthm only if the user has used a layout that is not the proof layout, and the definition of the proof layout. And there is a NextNoIndent difference between the two that if probably wrong in one of the instances. I did not understand the purpose of the file theorems-proof-std.inc. This file is included in theorems-std.module, and it appears that this file is defining the proof environment (but the definition is quite different from the usual one), if it is not defined. Since amsthm defines the proof environment, if i will compile a file using Theorems module, the appearance of my proofs will depend if i used another layout provided by the module. Wont it be more reasonable to add to the proof layout defined in theorems-proof.inc the line "Require amsthm" and use this layout? if there is a theorems module that does not use amsthm (and currently i don't think there is one like that), it could include theorems-proof-std.inc. It made sense when plain theorems did not use amsthm. Another problem with the fact that the proof layout in theorems-proof.inc does not require amsthm, is with the module Theorems (Unnumbered). This module only loads amsthm if the user use one of the theorems layouts. if one would simply use the proof layout with this module, and no other layout from the module, with non-AMS class (as these classes also defines the proof environment), he will get the error "LaTeX Error: Environment proof undefined.". Could you give an example file for that issue? Another inquiry I have about the module Theorems (Unnumbered) is the file theorems-starred-equivalents.inc. This file only copies the starred theorems layouts but gives the new layout a name without a star, e.g., it defines a Theorem layout exactly as Theorem* layout (and this files misses the Fact layout). The comment at the top implies that this sorts the layouts. I do not know whether it is still true. For all these reasons i believe that with a little bi of modification to the non AMS modules (which actually use amsthm), the AMS modules are redundent, and it is probably wise to add the line "Require amsthm" to the proof layout. If this suggestion seems reasonable to everybody, i could start work on the matter, and send the relevent files after editing them as mentioned. I wonder if we could get rid of theorems.module, and add a theorem-plain that use plain LaTeX commands as "theorems.module" used to do. Then files using "theorems.module" c
Re: Differences Between Theorems Modules (AMS and non AMS)
Hello again,
I took a look at the Named Theorems Module today, and the LaTeX code
there seems to be a bit strange. In the preamble of the layout Named
Theorem there is the following code:
\newcommand\thmsname{\protect\theoremname}
\newcommand\nm@thmtype{theorem}
\theoremstyle{plain}
\newtheorem*{namedtheorem}{\thmsname}
\newenvironment{namedthm}[1][Undefined Theorem Name]{
\ifx{#1}{Undefined Theorem Name}\renewcommand\nm@thmtype{theorem*}
\else\renewcommand\thmsname{#1}\renewcommand\nm@thmtype{namedtheorem}
\fi
\begin{\nm@thmtype}}
{\end{\nm@thmtype}}
\ifx is not really a macro with two arguments, but it is only looking
at the next two tokens, it compares the token { with the one after it,
which causing, in this situation, to get always the false output.
This means that if a user would not give a name via the optional
argument, the output theorem will have a label "Undefined Theorem
Name", which I don't think is the preferable outcome (and it might not
be what the author of the module meant as well).
In addition, note that if there was a case that the true case was
happening, the environment theorem* is not defined anywhere in the
module, which will cause a LaTeX Error: Environment theorem*
undefined.
I think it is reasonable to change this module in a way that if the
optional argument is empty, the output would be a theorem with the
label "Theorem".
This way, there is only need for one layout in this module, the Named
Theorem layout, Since the Theorem* layout defined there would be
achievable with the Named Theorem with the default optional argument
(or by setting it to Theorem).
Also note that every line that does not end with a control word, TeX
will see a n end-of-line character, hence will add an (what i believe
to be in this case, an undesired) space (since space after control
words are ignored). So in the current code, there are also a few extra
spaces in the environment namedthm.
Best Regards,
Udi
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
